[gentoo-user] SSH brute force attacks and blacklist.py

[gentoo-user] SSH brute force attacks and blacklist.py

[Steve]

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?

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

Steve

-- 
gentoo-user@lists.gentoo.org mailing list

[gentoo-user] Re: SSH brute force attacks and blacklist.py

[7v5w7go9ub0o]

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

Re: [gentoo-user] SSH brute force attacks and blacklist.py

[Alan McKinnon]

On Wednesday 27 February 2008, Steve wrote:

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

blacklist.py seems to work well for you, so why not just set 
BLOCKING_PERIOD to it's maximum value?

I would imagine that even after say one week the vast majority of zombie 
bots would have given up and moved on



-- 
Alan McKinnon
alan dot mckinnon at gmail dot com

-- 
gentoo-user@lists.gentoo.org mailing list

[gentoo-user] Re: SSH brute force attacks and blacklist.py

[7v5w7go9ub0o]

Sorry .... here's the link I should have posted:

http://www.cipherdyne.org/fwknop/
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] SSH brute force attacks and blacklist.py

[Justin]

Steve schrieb:
> 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?
>
> 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...
>
> Steve
>

Try fail2ban. I started as newby on iptables and I still am, because it 
is very easy to configure and does it job perfect.

http://gentoo-wiki.com/HOWTO_fail2ban
http://www.fail2ban.org/wiki/index.php/Main_Page
-- 
gentoo-user@lists.gentoo.org mailing list

[gentoo-user] Re: SSH brute force attacks and blacklist.py

[Remy Blank]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: SSH brute force attacks and blacklist.py

[Anno v. Heimburg]

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

[Iain Buchanan]

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 x0000 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

Re: [gentoo-user] Re: SSH brute force attacks and blacklist.py

[Etaoin Shrdlu]

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

[Steve]

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

[Willie Wong]

On Thu, Feb 28, 2008 at 11:13:10AM +0000, 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

[Willie Wong]

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