Alternative means to handle failed authentications

[jimbobmcgee]

I'm having some trouble preventing spurious connections to my load balanced SFTP servers, because the load balancer proxies the connection to the server, thus obscuring the source IP with its own (making the Deny Hosts feature effective useless).

I appreciate that the lack of SSH inspection is a limitation of the load balancer in question (and not VShell), so I've started looking at possible alternatives, both leveraging the Authentication Failed trigger to do either of the following:

1. Tally the source port (as determined by the load balancer, and seen by VShell) to the source IP (as seen by the load balancer) and denying said source IP in the load balancer's access list (using the load balancer's API)
2. Wait a number of seconds (i.e. to significantly slow down the rate of automated connection attempts)

I can't do the first, because there is no substitution variable for the client port that I can use in the trigger, so I can't pass the port number to the trigger script without strenuously mining the log file.

I can't do the second, because the trigger appears to run out-of-band, so the wait does not impose itself on the connection in question. This would probably also affect the first since, if the trigger does not wait, the connection could be gone from the load balancer before the script can tally the port to an IP.

Is there any way I can make the trigger run in-band (e.g. can a "wait for exit" option be added to the trigger definition)?

Instead, is there any way a tarpitting-style wait option could be added natively to the VShell app?

Are there any other thoughts on how I might achieve some measure of control over spurious connections (without resorting to taking the service out of load balancing)?

J.

[bgagnon]

Hello J.

What version of VShell is installed?

On what operating system?

[jimbobmcgee]

This particular setup is v3.9.2b556 on Win2008R2...

[bgagnon]

Thanks J!

What do you mean by spurious connections?

Are these connection attempts by unauthorized users?

What problems are the spurious connections causing in VShell?

Are you evaluating VShell or do you have a license?

If the latter, is it for Administrator, Workgroup or Enterprise version?

[jimbobmcgee]

By "spurious connections" I mean regular attempts to break into the SFTP server by unknown parties, either by dictionary or brute force -- the kind of thing that the "Denied Hosts" feature would traditionally prevent.

However, I can't use the "Denied Hosts" feature because I have no way to pass the real source IP address to the VShell instance because the load balancer is proxying the connection (and so, the source IP as seen by VShell is that of the load balancer).

We are running under an unlimited connection license.

[bgagnon]

Hello jimbobmcgee,

Thanks for the clarification.

There is not currently a solution for this available in VShell (or a workaround we could think of that would be applicable).

I have added this thread to a feature request in our product enhancement database to add the ability to configure a tarpit-style wait option in VShell (for load balance scenarios where Deny Host will not work). Should a future release of VShell include this feature, notification will be posted here.

If you prefer direct e-mail notification, contact support@vandyke.com and include "Feature Request - Forum Thread #11235" in the subject line.

[jimbobmcgee]

Thanks, Brenda; a tarpitting option would indeed satisfy option #2, provided the delay is not influenced by source IP.

Adding the source TCP port to the list of trigger substitution variables, and adding a 'wait for exit' option to the triggers function would also be welcome features.

[bgagnon]

Hi jimbobmcgee,

To clarify, VShell's "Authentication failed" trigger is fired only after the user has exhausted the maximum number of authentication attempts and the connection has already been closed.

The maximum number of authentication attempts is configured in the SSH2 / Authentication category of VShell's control panel.

I have created an additional feature request to add a trigger that will fire for each authentication failure (not just when max reached).