Help needed to log X_FORWARDED_FOR IP addresses with authentication credentials.

[sundarnut]

Hello folks at VanDyke,

In regard to the VShell SFTP server, we desire to implement one of these two things:

1) Log the external IP address behind the firewall/load balancer (via the X_FORWARDED_FOR headers inserted, like 207.82.250.251 instead of 10.11.12.13) and the credential name (like johndoeinc) when the server authenticates someone successfully. We can use this to build a threat model and map of individual credentials and their geo-location external IPs.

OR

2) Build a PAM that will extract this value and write it to a log file with a successful login event, if this does not exist as yet in the product.

What will be the process? This will help us mitigate a lot of threats as we are unsure of our partners managing their usernames/passwords and/or SSH keys securely and auditably.

Thanks very much! We love you folks!

[jdev]

Hello sundarnut,

X-FORWARDED-FOR is an HTTP header.
SFTP is a subsystem of the SSH2 protocol.
SSH2 is built upon TCP (not HTTP).

• How would you envision an HTTP header like X-FORWARDED-FOR having any applicability to SSH2/SFTP connections?
• Does your firewall/load balancer send HTTP headers when forwarding non-HTTP connections?

You mentioned "PAM", as a possible solution. PAM can mean a lot of things in different contexts.

• Are you running VShell (vshelld) on UNIX, and referring to PAM as Pluggable Authentication Module, or is your PAM referring to something else (please provide detail)?

If UNIX PAM (Pluggable Authentication Module) is what you mean, it's difficult for me to envision how PAM could potentially extract an X-FORWARDED-FOR value if the connection protocol isn't HTTP. It's highly likely I'm missing something obvious, so if you can fill in as many details as possible in relation to X-FORWARDED-FOR being present in anything but HTTP protocol-level connectivity, that would be very helpful.

If the higher-priority goal is building a threat model based on the actual source IP of incoming TCP connections, it would seem more appropriate to configure the forwarding behavior of your firewall/load balancer to not perform any NAT in the case of TCP-level forwards directed to the VShell SFTP service.

--Jake