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
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
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).
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
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.