Dictionary Attacks

[ynyng]

Running VShell on Windows platform. I've seen several posts in other forums about preventing brute force dictionary attacks. My logs fill every day with such attempts, some lasting for hours. When I see these, I add the offending IP to the connection filter. It would be nice, however, if VShell had the ability to recognize failed login attempts by IP address and auto-block them. Any thoughts on this feature?

[kelli.burki]

Making a change to dynamically update the connection filters in the event of a suspected dictionary attack is easier for Windows than it is for UNIX servers. Which platform are you running on?

Also, here are a few other questions that I would love your feedback on if we implemented this (other's please chime in too):

1. Do you want VShell to update / integrate w/ existing filter list?

2. Do you want the dynamic entries to persist across restart?

3. Do you want timeouts or thresholds?

4. Do you want the option to let the attacker think he/she/it is continuing to make progress?

5. Do you want to be able to minimize the effect of the dynamic response on legitimate connections from the attacking IP?

--kelli

[toloughlin]

I too noticed this on my Linux Vshell. I have since changed the ssh port in vshell to over 25000 .... port scans will take forever to get up that high!

With regards to the filters above ...

2. Do you want the dynamic entries to persist across restart?

Yes.

In addition:
Is a specific vshell password/user db (like /etc/passwd) going to be implemented? There was talk a while back, but haven't heard much since.

[kelli.burki]

Originally Posted by toloughlin

Is a specific vshell password/user db (like /etc/passwd) going to be implemented? There was talk a while back, but haven't heard much since.

I'm a little confused, are you asking for a different user database to authenticate against, or to use /etc/passwd ?

A while back we were exploring several options -- an api that would allow you a username password against whatever backend you wanted to use it with (i.e. MySQL or something like that). Is that what you're asking about?

If so, we had talked about that, but had much greater requests for more established auth methods like PKI etc. thus the 2.5 UNIX x.509 certificates. I haven't actually had a request for the separate user db auth for a little while.

Do you mind exploring with me, I'd love to hear about what business objectives you'll be meeting with this option.

--kelli

[ynyng]

Nice response time. Thanks! We run Win2k3 servers in DMZ behind PIX 515E. Am also running VShell 2.3b1 on a Win2k3 x64 test server now. Regarding your other Q's:

1. This would be nice. Once used a product from Internet Security Systems that integrated manual and auto filters into one list (with different icons for easy differentiation). The system administrator had the ability to edit or delete items in either category on the list.

2. Absolutely.

3. If I understand the question, both, but not necessarily in the the context of your existing software design. A disconnection from the present VShell server for either (a) bad logon attempts or (b) an authentication timeout is not a deterent since the server does not prevent the hacker from reconnecting immediately. (My log today had 59MB of such attempts from Asia Pac). It would be nice if the software would auto-block an IP address using the connection filter under administratively set parameters: (Var A) # failed logon attempts from a single IP within (Var B) specific time period results in (Var C) IP blocking for a specific length of time. Does this make sense?

4. No, because of possible bandwidth issues. I'd rather they go away.

5. Yes.

Thanks for listening!

[kelli.burki]

Originally Posted by ynyng

Am also running VShell 2.3b1 on a Win2k3 x64 test server now.

2.3b1 or 2.5b1? I'm very interested in how that is working for you.

Originally Posted by ynyng

1. This would be nice. Once used a product from Internet Security Systems that integrated manual and auto filters into one list (with different icons for easy differentiation). The system administrator had the ability to edit or delete items in either category on the list.

Thanks -- the different icon thing is a very nice idea.

Originally Posted by ynyng

3. If I understand the question, both, but not necessarily in the the context of your existing software design. A disconnection from the present VShell server for either (a) bad logon attempts or (b) an authentication timeout is not a deterent since the server does not prevent the hacker from reconnecting immediately. (My log today had 59MB of such attempts from Asia Pac). It would be nice if the software would auto-block an IP address using the connection filter under administratively set parameters: (Var A) # failed logon attempts from a single IP within (Var B) specific time period results in (Var C) IP blocking for a specific length of time. Does this make sense?

Nice. Makes a lot of sense. I like the three different ways of controlling. Would you tie the "bad logon attempts" to the same setting we currently have for bad logon attempts or have a new one specifically for this purpose? I guess, I'm asking, is there a reason (less confusing, greater flexibility, etc.) that you might want both of them?

If this situation came up (dictionary attack like you described above) -- where would (or did) you go looking for this feature hoping to find an answer?

If you didn't find it, what would you be searching for in the help?

Originally Posted by ynyng

4. No, because of possible bandwidth issues. I'd rather they go away.

No problem. I think that makes our life easier, but good to know your thoughts here.

[toloughlin]

I'm a little confused, are you asking for a different user database to authenticate against, or to use /etc/passwd ?

A while back we were exploring several options -- an api that would allow you a username password against whatever backend you wanted to use it with (i.e. MySQL or something like that). Is that what you're asking about?

In my mind, I remembered this thread:
http://forums.vandyke.com/showthread.php?t=338

I thought there was going to be something unique to VShell, where I don't have to mesh a local & remote-only database. I'll have to look further into X.509 ... haven't had to work with is, so I haven't explored it.

I have local users, they need shell access, etc ... the full boat; I have customers that only need SFTP - so, I don't need them in my Linux passwd file (so I think).

Let me do some more looking into it ... but feel free to shoot back some thoughts.

[ynyng]

Quote: 2.3b1 or 2.5b1? I'm very interested in how that is working for you.

2.5b1. It is working fine.

Quote: Would you tie the "bad logon attempts" to the same setting we currently have for bad logon attempts or have a new one specifically for this purpose? I guess, I'm asking, is there a reason (less confusing, greater flexibility, etc.) that you might want both of them?

I would integrate configuration options into the existing "Authentication Options", and programmatically add the IP source of the bad attempts to the connection filter. As I said, the current authentication options really provide no benefit since the offender can immediately reconnect.

Quote: If this situation came up (dictionary attack like you described above) -- where would (or did) you go looking for this feature hoping to find an answer?

I went straight to authentication options and was actually suprised that the program has no was to prevent offenders from reconnecting at will. I then researched triggers; I assumed I might be able to somehow script a trigger which would add offending IP to the connection filter, but wrote to the forum instead since this seemed like a basic feature easily added to the core program. ;-)