[Intrusions] Locking down SSH, dictionary attacks
mtowers at linuxmail.org
Sat Mar 11 18:17:37 GMT 2006
Just a thought, why don't you use the options in iptables to the long duration of brute force events?
snippet from the article
"Restricting the Number of Connections with limit and iplimit*
The limit matching extension can be used to limit the number of times a rule matches in a given time period while the iplimit extension can restrict the number of parallel TCP connections from a particular host or network. These extensions can be used for a variety of purposes:
* to protect against DOS (denial of service) attacks such as preventing a flood of HTTP requests to your web server while ensuring all your customers have unlimited access;
* to prevent a brute-force attack to guess passwords;
* to limit Internet usage by staff during working hours;
* and many many more.
Let's take the case where we want to limit the Internet usage of our employees during working hours. We could use a rule like:
-A FORWARD -m state --state NEW -p tcp -m multiport --dport http,https -o eth0 -i eth1 \
-m limit --limit 50/hour --limit-burst 5 -j ACCEPT
This rule assumes that we are acting as a proxy server where the external connection is via eth0 and eth1 connects to our office network. The rule limits all of our internal computers to only 50 new HTTP or HTTPS connections per hour and the use of --limit-burst prevents any one employee from using up all 50 in one go. Packets can be matched /day, /hour, /minute or /sec.
The --limit-burst parameter can be quite confusing at first. In the above example, it will ensure that if all employees are trying to access the Internet throughout the hour then only 5 connections are made every 5 minutes. If 30 minutes pass with no connections and then there is a sudden rush for the remaining 30 minutes, only 5 connections will be permitted every 2.5 minutes. I once heard it explained as follows:
For every limit rule, there's a "bucket" containing "tokens". Whenever the rule matches, a token is removed and when the token count reaches zero, the rule doesn't match anymore.
--limit is the bucket refill rate.
--limit-burst is the bucket size (number of tokens that it can hold).
The iplimit extension allows us to restrict the number of parallel TCP connections from a particular host or network. If, for example, we wanted to limit the number of HTTP connections made by any single IP address to 5 we could use:
-A INPUT -p tcp -m state --state NEW --dport http -m iplimit --iplimit-above 5 -j DROP"
Would save your logfiles taking a beating, but would still switch to certs ect, Seems a shame to mess traditions up by switching ports. :)
> ----- Original Message -----
> From: "Andrew Daviel" <andrew at andrew.triumf.ca>
> To: intrusions at incidents.org
> Subject: [Intrusions] Locking down SSH, dictionary attacks
> Date: Fri, 10 Mar 2006 12:33:11 -0800 (PST)
> FYI - just got zapped by one of those SSH exhaustion scanners (again)
> 1st generation - try 4 accounts e.g. guest/guest against everyone
> 2nd generation - multiple passwords but slow, doesn't show above noise on
> individual syslogs
> 3rd generation - who cares, let's blast! 230 tries in 3 minutes
> To combat 2nd gen I poll multiple syslogs several times an hour, and any
> source going over a couple dozen failures across site is firewalled.
> 3rd gen got lucky before it was blocked a few minutes later
> So, I'm wondering how to lock down SSH a bit more (on Linux, maybe
> Solaris, MacOS).
> On critical machines with few users, I have disabled password logins -
> keys only, and maybe only listen to certain addresses. And on one
> standalone machine I have set norootlogin.
> But what to do with multiuser machines ? Users are likely to revolt if
> told they have to generate keypairs everywhere. (We have been reluctant
> to get into Kerberos, and besides I'm not sure without some research
> whether it would help. Ditto PAM-based stuff)
> What I'd like to do is have different authentication requirements for
> root and for user accounts (other than "no root at all")
> - must use keys, not password
> - must connect from 10.4.0.0
> user A:
> - can use keys or password
> - can connect from anywhere
> users B,C:
> - can connect from anywhere with keys
> - can connect from 10.4.0.0 with passwords
> ... OK, have just RTFM :-)
> and have now set "PermitRootLogin without-password"
> which does the most important thing
> ... just checked my home logs .. darn scanners have 2000 attempts
> there, too - so I've just installed my 2nd gen blocking script
> as well as fixing root
> Guess if I really want address-based filtering I could run a second
> server on a different port with different config options, but this
> is probably OK for now ...
> (if anyone wants my blocking script - simple perl thing using iptables -
> mail me. 3rd gen blocking will probably get written, monitoring "tail -f
> /var/log/secure" ... should probably add check for success from scanning
> source, too)
> Andrew Daviel, TRIUMF, Canada
> Tel. +1 (604) 222-7376 (Pacific Time)
> security at triumf.ca
> Intrusions mailing list
> Intrusions at lists.sans.org
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
More information about the Intrusions