Re: Options to block brute force attacks


Randy Yates wrote:

[snip]
Hi Mike,

I'm not Mike but...

Correct me if I'm wrong, but the implication here is that a
brute-force attack is usually orchestrated by ganging up as many
simultaneous connections (N) to the target as possible, essentially
allowing N password attempts per T time, where T is the time to
connect, enter a password, observe the response, and disconnect. This
gives attackers a speed-up of a factor of N over a simple
one-at-a-time approach. Am I thinking about this correctly?

No. There are many different brute force attack procedures, from the
simplest of one connection trying passwords for one user name, to the
most complex of distributed connections trying passwords for multiple
users.

The configuration parameters for sshd try to address any kind of
flooding, not necesarily an attack but you play your odds.

Other alternatives, and they have been discused in this list recently,
are teergrube (tar pits) and automated tcp_wrappers use (like DenyHosts
that I mentioned wich also includes sharing of known attacker IPs).
The first one slows down the attacker (attacker is defined as anyone
giving invalid passwords repetedly), the second uses the optional
compiled support for tcp_wrappers in sshd to deny connections after a
threshold is reached.

While I see that, given this attack tactic, the "three colon
separated" version of MaxStartups, S:P:M, can help mitigate
brute-force attacks by a factor >= N/M, it still doesn't eliminate
them.

Correct. None of the counter-measures eliminate attacks.

There seem to be superior solutions. For example, establish a maximum
number N of connection attempts from any specific domain. This would
imply that the maximum number of *simultaneous* connections from that
domain is also N.

Yes, and that could be done at the firewall.

However, this technique may become inefficient for the daemon because it
requires every domain that's ever attempted to connect to be stored in
a database, and the database must be searched for each new connection.

Usually those databases include a timestamp and they are cleaned
periodically.

Therefore one way to mitigate this problem is to augment the approach
above to also specify a "timeout period" after which connections from
the domain are allowed again. For example establish a new parameter
MaxAttempt = K:L, where K is the maximum number of attempts that
are allowed and L is a timeout period (say, in seconds) after
which the daemon will allow the domain to attempt to connect once
again. In this manner the daemon only has to keep domains that attempted
to connect in the last L seconds, and could possibly just keep this
in cache memory rather than storing to non-volatile storage.

All this is done by DenyHosts and other similar programs.

One thing not discused is that the parameters have to be determined for
each situation, if you have low connection rates the values should be
low numbers, but if you have a server that many people use
simultaneously then the numbers will have to be higher.

Regards.
--
René Berber

.

Relevant Pages

  • Re: Dictatorship Rules HWC.Com
    ... > through a "denial of service" attack. ... > their machines. ... > repeatedly open connections and block them out. ... this means that A) you could have a trojan program that was ...
    (rec.toys.cars)
  • Re: New virus?
    ... P2P networks, listen on TCP port 81, and attempt downloading files ... witnessed outbound connections on TCP port 81, ... web servers via HTTP in order to register itself with the server's ... attack targeting two unrelated financial services organizations. ...
    (sci.med.transcription)
  • Re: Dictatorship Rules HWC.Com
    ... through a "denial of service" attack. ... When you get thousands of machines ... repeatedly open connections and block them out. ... this means that A) you could have a trojan program that was ...
    (rec.toys.cars)
  • Re: SNORT or other IDS
    ... Turned out it was not an attack... ... connections. ... NO_CACHE so the aol cache servers were hamering us with requests... ... We are using foundry loadbalancer... ...
    (microsoft.public.security)
  • Re: server udp port 60556 (Unix Box) attacked by 18.18.18.18
    ... Snooping or a denial of service attack? ... someone who used PortSentry to automatically block connections to ... be able to rate limit connections. ... outboard monitoring box could be practical. ...
    (comp.security.misc)