Home page logo

oss-sec logo oss-sec mailing list archives

Re: speaking of DoS, openssh and dropbear (CVE-2006-1206)
From: Nico Golde <oss-security+ml () ngolde de>
Date: Tue, 3 Jan 2012 00:33:01 +0100

* Kurt Seifried <kseifrie () redhat com> [2012-01-02 04:56]:
By establishing a large number of connections and holding them open (this 
typically requires only a few packets or less per second from the attackers 
system) an attacker can hold a connection open indefinitely or until a 
timeout condition is reached. 

We have seen this attack before: SYN flooding, Slowloris, airline seat 
reservations, email spam, password brute forcing attacks, etc.

I definitely agree, the root problem is pretty similar (I like airline seat 
reservation :D).

2) Random drops

Another strategy is to randomly drop connections when load gets high. The 
theory is that legitimate connections will continue to try and connect, by 
dropping connections and reducing load there is a better chance that 
legitimate clients will get through. Unfortunately with a typical DoS or 
DDoS style attack to attackers connections will vastly outnumber legitimate 
connection attempts.

Or as in some of the slowloris "fixes" not dropping random connections, but 
incrementally changing the connection timeout with the load/number of 
connections. I think this is a fairly sane tradeoff.

3) Progressive timeouts/lockouts

To prevent password guessing attacks at the console some Linux systems 
implement a progressive timeout, if you get the password wrong you have to 
wait a second, if you get it wrong again you have to wait 2 seconds, then 4 
seconds, etc. This reduces the number of attempts an attacker can make. In 
terms of OpenSSH we could for example implement a lockout, if you connect 
but fail to login you have to wait 10 seconds, the second time you need to 
wait 20 seconds, etc. There are a large number of downsides to this however: 
you need to store a database of IP's or networks to lockout and for how 
long, you may have multi user systems connecting to yours which means one 
user making a typo (or maliciously fail to login, thus locing everyone else 

If you combine this with a per-ip based connection count, you could achieve 
that without needing to store connections in a database, but only apply this 
to active connections. I haven't checked the source, but I would expect there 
is already a datastructure to operate on lists of connections.

I think we agree that 4 and 5 would be really suboptimal solutions for the 
case of openssh.

6) hash cash and work functions

The idea here is simple, make the attack computationally expensive and the 
attacker will not be able to cause as much trouble. For large scale or 
sustained attacks simply increase the work function (like bcrypt, you can 
effectively select how much work it is to decrypt the password), this could 
also be done in the fly, as an increasingly number of connections occur 
increase the work function. 

Do you know of any existing service that implements such an approach? I would 
love to check this out in detail on an example.

7) Grey listing

This is more applicable to email but can work with other protocols 
potentially. Basically you tell clients that their connection cannot be 
serviced and that they should come back later and try again. Legitimate 
clients will come back and attempt to connect again, most illegitimate 
clients (at least in the spam world) will simply move on and try other 
hosts. This type of solution will probably not work well with interactive 
protocols such as SSH or for targeted attacks. 

I guess this would be rather annoying for ssh as an attacker either can 
directly reconnect, in which case the effect of this is practically non
existent or it becomes very annoying from a user PoV.


But what if the attacker has a 10,000 node bot net?

While this is an argument that is valid, I think this would be an argument 
that doesn't matter for most users. A possible use of the script I sent would 
be to e.g. prevent an admin to login via ssh while the server is exploited 
through another service. In such a case I would find it fairly weird if a 
botnet is used at the same to achieve this. Also since security is hardly a 
state and I think in practice the difference really matters, I do believe
it is useful to significantly raise the bar of the thread from a home-user to 
a distributed attacker.

The first three solutions (early drops, random drops and progressive 
timeouts) can be implemented in OpenSSH server side without requiring any 
changes to the protocol or clients.

Reputation based systems can be implemented within OpenSSH (but I wouldn't, 
because it is a bad bad idea) or at the OS level in firewall code, 
reputation based systems would require no changes to OpenSSH clients or the 

Port knocking can implemented at the OS or firewall level, but requires 
client software and user training/etc. Widespread deployment isn't going to 
happen anytime soon (although I'd be curious to see how adoption would be if 
we shipped something to support it by default). 

I still think that for the average user the per-ip based connection count is a 
fairly good solution. Of course not optimal in case of DDoS attacks, even 
though as an openssh user, I feel like it's ok to neglect this problem in 
It would also be interesting to see some input from the openssh people, hence 
I CCed the dev list (hopefully the right one).
For reference: 

The rest of the solutions do not lend themselves to this problem or would 
require significant changes to the OpenSSH protocol/client/server which is a 
bad bad idea.

Anything we do to address this issue should be extremely simple and 
conservative, the OpenSSH server and client are very stable and robust 
pieces of code, any modifications to them make me nervous. 

I suspect the simplest and more effective solution might be some form of 
progressive timeout for IP's that fail to authenticate (drop the connection 
entry silently and ignore them in favor of real clients). 

Long term I'd like to see more work on hash cash type solutions, being able 
to arbitrarily set or have a reactive system that requires increased work on 
the client end to prove they are a legitimate client would help with this 
whole DoS/DDoS class of problem to some degree.

See above, it would be really nice to see if there is a project which already 
does that.

Kind regards
P.S. if anyone has a clue on why that script still works with dropbear, even 
though it already seems to implement per-ip based connection counting...
Nico Golde - http://www.ngolde.de - nion () jabber ccc de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.

Attachment: _bin

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]