Re: [gentoo-user] Re: SSH brute force attacks and blacklist.py
On Wednesday 27 February 2008, Remy Blank wrote: Steve wrote: I'm one of the (many) people who has opportunists trying usernames and passwords against SSH... while every effort has been made to secure this service by configuration; strong passwords; no root login remotely etc. I would still prefer to block sites using obvious dictionary attacks against me. The best advice I can give is to use public key authentication only. This will defend against all dictionary-based attacks, which is what you describe. The only remaining problem is that your log files will be filled with unsuccessful login attempts. A simple solution is to run sshd on a non-standard, high-numbered port, e.g. in the 30'000. Bots only ever try to connect on port 22. This will *not* improve the protection of your server, but it will avoid having your logs spammed. Agreed. For me, changing the port SSH listens on alone eliminated 99% of brute force attempts. I also agree on public key authentication. Depending on the OP's needs and context), he might also be interested in portknocking (no flames please :-)). -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Re: SSH brute force attacks and blacklist.py
Thanks for all your suggestions... I will look into fail2ban... that might be what I need... While I could crank BLOCKING_PERIOD for blacklist.py to an absurdly high value, this (AFAIK) will not persist blocks when the server is powered down or rebooted. I need to retain port 22 and can't easily do port-knocking - since some of the clients I require to connect to my server are in restrictive environments. I've another idea too... I'm happy to entirely cut off all services from any IP that attempts to brute-force SSH passwords... as it is an unequivocal act of aggression that would not arise with any legitimate clients... Another aside is that in some restrictive environments it is hard to securely obtain my private key without first obtaining a secure off-site connection. For this reason, I prefer to have the facility to log in using username/password - my compromise is to make my password extremely complex... plus using a non-obvious user-id, which again hampers attackers. While interesting, I don't think the connection rate limiter is for me... I may want to legitimately make rapid connections at some time or other. :-) -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Re: SSH brute force attacks and blacklist.py
On Thu, Feb 28, 2008 at 11:13:10AM +, Penguin Lover Steve squawked: Thanks for all your suggestions... I will look into fail2ban... that might be what I need... While I could crank BLOCKING_PERIOD for blacklist.py to an absurdly high value, this (AFAIK) will not persist blocks when the server is powered down or rebooted. Hum, that is interesting. I haven't played with blacklist.py, but if it runs on top of iptables, the iptables init script *should* save the current config when powering down. I sort of depended on that when I cobbled together a perl script 2 years ago to parse the sshd log and ban sites using iptables. Also, I would not suggest banning forever. I started with the same mentality as you and coded as such. I switched quickly to banning for 1 hour when once, due to not noticing the caps-lock light, I banned my work computer completely... After switching to the 1 hour ban, I did a small experiment and saved about 2 months worth of logs. Not a single ip address has been banned more than once (but there were several /24 in Korea, Taiwan, and Mexico that have many ip addresses banned). Based on this, I don't think it is strictly necessary to ban forever. Just my 2 cents. W -- Santa's helpers are subordinate clauses. Sortir en Pantoufles: up 447 days, 14:37 -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Re: SSH brute force attacks and blacklist.py
On Wed, Feb 27, 2008 at 10:39:15PM +0100, Penguin Lover Anno v. Heimburg squawked: It limits the number of new connections on each port in INPUT_LIMITER_TCPPORTS from any individual host to INPUT_LIMITER_COUNT within INPUT_LIMITER_TIME. My experience suggests that finding the right INPUT_LIMITER_TIME would be difficult. From my experience (by reading the logs after I cobbled together a patch work solution to blacklist hosts), the typical behaviour of a sshd bruteforce attack, after you start dropping packets from it, is that it will begin to add a geometrically increasing sleep time between attempts and continue for about 30 minutes to an hour. So if your time parameter is on the order of several seconds, the attack will be like try, try, try, doh! connection timed out, wait a bit, try again, doh! still timed out, wait a bit longer, hey it works now, try, try , doh! time out again rinse and repeat. But if you set the time parameter to minutes or tens of minutes, then you risk banning yourself if you need multiple instances of ssh. (Yes, screen is nice, but sometimes I like to keep two terminals open. And there's always the case of saving work, quitting, logging out; doh! forgot to do something, log back in again scenario.) W -- When a clock is hungry it goes back four seconds. Sortir en Pantoufles: up 447 days, 14:54 -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] Re: SSH brute force attacks and blacklist.py
Steve wrote: I can't believe that I'm the only person with this, so it's probably worth asking. I'm one of the (many) people who has opportunists trying usernames and passwords against SSH... while every effort has been made to secure this service by configuration; strong passwords; no root login remotely etc. I would still prefer to block sites using obvious dictionary attacks against me. I used to use DenyHosts - but that became annoying as it used rather a lot of resources (and relied upon tcp wrappers... which, I'm informed are somewhat old-fashioned) I migrated to try using iptables as my firewall and using blacklist.py - which I got working after some minor config-tweaking. I'm aware that there is configuration in the blacklist.py script for BLOCKING_PERIOD - but what I really miss the blocked forever nature of the DenyHosts alternative though I prefer every other aspect of the iptables/blacklist.py approach. Has anyone else resolved this? As far as I'm concerned, once I detect someone has attempted a brute force (which blaclist.py does fantastically well) what I want is for no further communication to be accepted from the IP address - even after I reboot etc. While I don't know which sites I want to be accessible from in advance, I can be sure none of them would launch a brute force attack against me. :-) Recommendations? If this is a personal or low-user connection, consider fwknop - single packet authorization port knocking. - works well for my home box - the port simply drops pings, connection attempts, etc. 'til opened - fwknop uses pcap to listen for authorization packets; when one comes through with the correct (encrypted) command, it'll send an iptables command to temporarily open the port for a designated period of time allowing you to connect. The encrypted packets include a time of day field to prevent replay attacks. http://www.cipherdyne.org/fwknop/download/ I'm looking for the neatest Gentoo way to do this... rather than recommendations for how to write something to do what I want from scratch... fwknop is not Gentoo; but compiles cleanly. HTH -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] Re: SSH brute force attacks and blacklist.py
Sorry here's the link I should have posted: http://www.cipherdyne.org/fwknop/ -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] Re: SSH brute force attacks and blacklist.py
Steve wrote: I'm one of the (many) people who has opportunists trying usernames and passwords against SSH... while every effort has been made to secure this service by configuration; strong passwords; no root login remotely etc. I would still prefer to block sites using obvious dictionary attacks against me. The best advice I can give is to use public key authentication only. This will defend against all dictionary-based attacks, which is what you describe. The only remaining problem is that your log files will be filled with unsuccessful login attempts. A simple solution is to run sshd on a non-standard, high-numbered port, e.g. in the 30'000. Bots only ever try to connect on port 22. This will *not* improve the protection of your server, but it will avoid having your logs spammed. -- Remy signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: SSH brute force attacks and blacklist.py
Justin wrote:
Try fail2ban
Alternatively, you can use the builtin iptables connection rate limiter.
Excerpt from my home-grown firewall script:
for port in $INPUT_LIMITER_TCPPORTS; do
$IPT_IN -p tcp --dport $port -m state --state NEW -m \
recent --name limit-${port} --set
$IPT_IN -p tcp --dport $port -m state --state NEW -m \
recent --name limit-${port} --rcheck --seconds
$INPUT_LIMITER_TIME --hitcount $INPUT_LIMITER_COUNT -j \
LOG --log-prefix limit-rjct-${port}
$IPT_IN -p tcp --dport $port -m state --state NEW -m \
recent --name limit-${port} --rcheck --seconds
$INPUT_LIMITER_TIME --hitcount $INPUT_LIMITER_COUNT -j REJECT \
$IPT_IN -p tcp --dport $port -m state --state NEW -j
LOG --log-level notice --log-prefix limit-acpt-${port} \
$IPT_IN -p tcp --dport $port -m state --state NEW -j ACCEPT
done
It limits the number of new connections on each port in
INPUT_LIMITER_TCPPORTS from any individual host to INPUT_LIMITER_COUNT
within INPUT_LIMITER_TIME.
More precisely, it does the following:
1. When a new connection is established by a previously unkown host, set a
mark (first rule).
2. When the number of marks from that host has exceeded the specified upper
connection limit, reject the connection (third rule), you could also drop.
3. Otherwise, accept the connection (fifth rule)
Rules numbers 2 and 4 are for logging purposes only, and have no impact on
functionality. By using --log-prefix, you can use your logging daemon's
filtering capabilities to sort these requests into new
The count is reset after INPUT_LIMITER_TIME seconds have passed. Thus, after
exceeding INPUT_LIMITER_COUNT, you have to wait for $INPUT_LIMITER_SECONDS
before a new attempt.
Oh yeah, $IPT_IN is shorthand for ${IPTABLES} -t filter -A INPUT, where
${IPTABLES} points to the iptables executable, of course.
The advantage of this solution is that it does not rely on log files parsing
or any other magic, it simply counts the number of connections from each
host on a specific port. It it does very easy on CPU and very stable, it
continues working as long as your kernel works.
The disadvantage is that it does not rely on log files parsing or any other
magic, it simply counts the number of connections from each host on a
specific port. It cannot do anything clever. Also, your iptables -L output
gets a bit cluttered by adding five rules for every port you want to
rate-limit.
Anno.
--
gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Re: SSH brute force attacks and blacklist.py
On Wed, 2008-02-27 at 21:24 +0100, Remy Blank wrote: A simple solution is to run sshd on a non-standard, high-numbered port, e.g. in the 30'000. Bots only ever try to connect on port 22. This will *not* improve the protection of your server, but it will avoid having your logs spammed. +1 I hosed my router, and had to go back to an old one that could only forward port 22 to an internal machine port 22. I got lots of brute force attacks. Well, most of them only tried about 5 passwords each, so not exactly brute force... Anyway, once I upgraded my router again and forwarded port x to port 22, I haven't seen one since. HTH, -- Iain Buchanan iaindb at netspace dot net dot au Linux - because software problems should not cost money. -- Shlomi Fish -- gentoo-user@lists.gentoo.org mailing list
