Automatically Ban SSH Password Hackers
Josh
After reading over my /var/log/messages file this week, I was a little
shocked to see how many
folks like to bang on my ssh server in hopes of getting in on a weak
password.
I wrote a script that might be useful to protect against this kind of thing:
-Here is what it does:
-It parses your /var/log/messages file
-It pulls all of the ip addresses that tried
and failed to break into your SSH server
-It constructs and executes an iptables
statement that drops all traffic from these
ip addresses.
-I included a place in the script to insert
trusted ip addresses so you can
make a mistake from work and not
get yourself banned.
Take a look. I'm an amatuer at this kind of thing.
Dominik L. Borkowski
Here's an easier way, which works real time, and the bots stop after the
first try:
iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent
--update --seconds 15 -j DROP
iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent
--set -j ACCEPT
Grant
>Josh wrote:
>>
>> Take a look. I'm an amatuer at this kind of thing.
>>
>> http://freewebspace.planetdns.net/banssh.tar
>
>Here's an easier way, which works real time, and the bots stop after the
>first try:
>
>iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent
>--update --seconds 15 -j DROP
>iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent
>--set -j ACCEPT
Dominik:
How do you tell if it is an unwanted login attempt? If you don't
offer ssh login on port 22, what need to play games on that port?
Josh:
I've often thought about 'closing the loop' between ssh login failures
and random callers, I found it easier to close port 22 :o)
When I open the port it is for known IPs only. Seems safer to me.
I think one idea worth trying is to run a second sshd for external
access that allows RSA (or whatever, non-password) login only, and
perhaps on a non-standard port. Just so the kiddies' scripts go
looking elsewhere.
Grant.
Dominik L. Borkowski
> Dominik:
> How do you tell if it is an unwanted login attempt? If you don't
> offer ssh login on port 22, what need to play games on that port?
games? what games? the two iptables rules i've provided block multiple ssh
attempts from the same source in a short time span. legitimate users still
can login, multiple ssh attempts fail for 15 seconds.
works like a charm for the attack bots, they try only ONCE before they drop.
the solution doesn't hinder any legitimate use. and yes, i run it on
servers with tons of users.
Josh
not exactly sure how to set it up at this point, but it seems like it would
be more secure than password verification.
Thanks for the tips.
Josh Beck
"Dominik L. Borkowski" <d...@vbi.vt.edu> wrote in message
news:di9r3t$k08$1...@solaris.cc.vt.edu...
Grant
>Grant wrote:
>> How do you tell if it is an unwanted login attempt? If you don't
>> offer ssh login on port 22, what need to play games on that port?
>
>games? what games? the two iptables rules i've provided block multiple ssh
>attempts from the same source in a short time span. legitimate users still
>can login, multiple ssh attempts fail for 15 seconds.
Sorry, on first reading I missed that the first valid ssh login gets
through, and also arms the recent' timer to block retries.
>works like a charm for the attack bots, they try only ONCE before they drop.
>the solution doesn't hinder any legitimate use. and yes, i run it on
>servers with tons of users.
Yes, I agree with you now. Teach the users to get their password
right first time?
Back when I tried it I was using much longer delays, for a different
purpose (web server). The recent table filled up quickly and I turned
to other methods.
Cheers,
Grant.
Mogens V.
> Hello all,
>
> After reading over my /var/log/messages file this week, I was a little
> shocked to see how many
> folks like to bang on my ssh server in hopes of getting in on a weak
> password.
> I wrote a script that might be useful to protect against this kind of thing:
>
> -Here is what it does:
> -It parses your /var/log/messages file
> -It pulls all of the ip addresses that tried
> and failed to break into your SSH server
> -It constructs and executes an iptables
> statement that drops all traffic from these
> ip addresses.
> -I included a place in the script to insert
> trusted ip addresses so you can
> make a mistake from work and not
> get yourself banned.
Or just change sshd to run on some highport in the 20-30000 range.
If you don't need to be able to access your sshd from anywhere, then
limit access to sshd (port 22 or the highport) in hosts.allow - you
probably already do have ALL: ALL in hosts.deny ..
Besides that, make it more difficult to misuse sshd:
Port 28376 # no, I don't use that port myself ;)
Protocol 2
KeyRegenerationInterval 300
LoginGraceTime 15
StrictModes yes
RSAAuthentication yes
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreRhosts yes
# KeepAlive is spoofable, use ClientAlive..
#KeepAlive yes
KeepAlive no
ClientAliveInterval 20
ClientAliveCountMax 6
MaxStartups 4
--
Kind regards,
Mogens Valentin
Kiddion
> shocked to see how many
> folks like to bang on my ssh server in hopes of getting in on a weak
> password.
> I wrote a script that might be useful to protect against this kind of thing:
Running my ssh on a different port that 22 has proved to be a more
effective way of protection.
Instead of trying a large list of username/passwords on one target, more
and more hackers try one username/password on a large list of targets.
It's often very hard to detect and ban them...
Thomas Carter
This is good stuff. Can it be modified so that it does NOT apply to
specific IP addresses? In my case, I would like for it to apply to
incoming SSH connections from any IP addresses, except for those from
boxes in my LAN - a 192.168.0.xxx network.
Robby Workman
Sure...
Add a rule above those something like this:
iptables -A INPUT -p tcp -i eth0 -s 192.168.0.0/24 --dport 22 -j ACCEPT
Ideally, if this is a firewall box, you have a separate interface for
the LAN, or if it's inside the LAN, your firewall should be dropping
all traffic coming from the internet having source addresses in the
private address range.
RW
--
Thomas Carter
> Thomas Carter wrote:
>> On Sat, 08 Oct 2005 19:38:59 -0400, Dominik L. Borkowski wrote:
>>>
>>>Here's an easier way, which works real time, and the bots stop after the
>>>first try:
>>>
>>>iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m
>>>recent --update --seconds 15 -j DROP
>>>iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m
>>>recent --set -j ACCEPT
>>
>>
>> This is good stuff. Can it be modified so that it does NOT apply to
>> specific IP addresses? In my case, I would like for it to apply to
>> incoming SSH connections from any IP addresses, except for those from
>> boxes in my LAN - a 192.168.0.xxx network.
>
>
> Sure...
>
> Add a rule above those something like this: iptables -A INPUT -p tcp -i
> eth0 -s 192.168.0.0/24 --dport 22 -j ACCEPT
OK, thanks.
> Ideally, if this is a firewall box, you have a separate interface for the
> LAN, or if it's inside the LAN, your firewall should be dropping all
> traffic coming from the internet having source addresses in the private
> address range.
I wanted to set the rules on my firewall box, applying to the NIC
connected to the Internet but, as it happens, it is running an old version
of iptables that does not support this mechanism. I'll use the recipe you
gave until I get around to upgrading the firewall box.