Re: SSH Brute force attacks - Script version 1.0

Re: SSH Brute force attacks - Script version 1.0

[Taylor, Grant]

There has been question on the list asking me to post a ""final (or most current) version of the SSH_Brute_Force script so I am doing just that.  I have included a version number in the subject line so it should be easier to identify in the future.

Below is the most recent script version that has been discussed on the NetFilter mail list.  I am going to call this version "NetFilter MailList SSH_Brute_Force Chain".

# NetFilter MailList SSH_Brute_Force Chain version 1.0.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH --set --rsource -j SSH_Brute_Force
iptables -A SSH_Brute_Force -s $My_Home_Firewall_IP -j RETURN
iptables -A SSH_Brute_Force -s $My_Office_Firewall_IP -j RETURN
iptables -A SSH_Brute_Force -s $My_Girlfriends_Firewall_IP list -j RETURN
iptables -A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN 
iptables -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
iptables -A SSH_Brute_Force -p tcp -j TARPIT

Below is the version of this script that I tend to run on my firewall at home for various reasons which will be explained below.  I am going to call this version "Grant's personal SSH_Brute_Force Chain".

# Grant's personal SSH_Brute_Force Chain version 1.0.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_Brute_Force
iptables -A SSH_Brute_Force -s $My_Home_Firewall_IP -j RETURN
iptables -A SSH_Brute_Force -s $My_Office_Firewall_IP -j RETURN
iptables -A SSH_Brute_Force -s $My_Girlfriends_Firewall_IP list -j RETURN
iptables -A SSH_Brute_Force -m recent --name SSH --set --rsource
iptables -A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN 
iptables -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
iptables -A SSH_Brute_Force -p tcp -j TARPIT

The reason that I tend to run my (Grant's) personal SSH_Brute_Force version of the script verses the "NetFilter MailList SSH_Brute_Force" version is that I want / like the ability to jump to the SSH_Brute_Force chain with out having to remember to add the "-m recent --name SSH --set --rsource" parameters to the rule that jumps to the SSH_Brute_Force chain.  IMHO this makes this chain easier to use in the future and easier to maintain as you don't have to remember to update multiple calling rules, just the one rule in the SSH_Brute_Force chain its self.

A note about the RETURN verses the ACCEPT targets.  The RETURN target is going to go back to the chain that jumped to the SSH_Brute_Force chain and continue processing from where it left off.  This method is great if you want to pass your traffic through more types of sanity checks / filters.  The RETURN target is what you will likely see used in more compelx firewall scripts.  On the other side of the coin is the ACCEPT target which will directly allow the traffic to pass through the firewall and on in to the server in question.  This is better for simple firewall scripts where you only want to proccess one filter, SSH_Brute_Force chain in this case, on the traffic.  The ACCEPT target is less likely to be seen in the more complex firewall scripts.

A note about the TARPIT verses the DROP targets.  The TARPIT target is a special target that will consume few resources to hold open the SSH connection and cause the sending / attacking system to spend system resources / time (delay) before it eventually force closes the connection on it's end.  The advantage of this is that you slow down the attacker and thus help make the internet ever so slightly more secure by delaying who the attacker can attack because the attacker is busy attacking you in a maner that does not harm you.  If you consider that the attacker can attack only so many hosts in a specific amount of time and you make the attacker take longer to attack one host they will ultimetly attack fewer hosts.  The DROP target will not consume any more resources than the TARPIT target but will allow the attacker to continue with the next host immedietly as you are doing nothing to sl
 ow the attacker down.  About the only reason I can see to use the DROP target verses the T
ARPIT target would be if you do not have the TARPIT target avaliable and you do not for some reason want to change that.

There have been a lot of people wanting to run a varient like the one below.

iptables -A INPUT -p tcp --dport 22 -s ! $My_Home_Firewall_IP -m state --state NEW -m recent --name SSH --set --rsource -j SSH_Brute_Force
iptables -A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN 
iptables -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
iptables -A SSH_Brute_Force -p tcp -j TARPIT

This version is just fine and will acomplish the same thing in a different manner.  My problem with this version is that it does not scale well to have multiple different source IPs that you want to have be known good with out using something like IPSets.  Also there is the fact that the "-m recent --name SSH --set --rsource" parameters are added to the calling rule(s), discussed earlier.

Finally a brake down of what / why / how the script actually does what it does for those who are interested.

1)  The kernel will have to know to jump to the SSH_Brute_Force chain some how, thus the "-j SSH_Brute_Force" somewhere in your firewall script.
2)  There should be some way to white list known good IP addresses to be SSHing in from, hens the "-s $My_Home_Firewall_IP -j RETURN" line(s) or the "-s ! $My_Home_Firewall_IP ... -j SSH_Brute_Force" line(s).
3)  Somewhere we will have to "--set" the recent counter for this packet, be it on the line that jumps to the SSH_Brute_Force chain or in the SSH_Brute_Force chain its self.
4)  The real ""magic of this script is on the line that checks to see if the hitcount on the recent list is at a value that we determine to be bad and if not RETURN back to the calling chain.
5)  Any thing that we have not returned by this point qualifies as traffic that is likely an SSH brute force attempt thus we LOG and TARPIT the traffic.

One last note is that there has been a request to update this script to alter a list of known bad hosts that can safely be dropped across the board.  I will be working on such a script and should hopefully be able to submit that version to the list as well.  Said version of the script will be based on my "Grant's personal SSH_Brute_Force Chain version 1.0" of the SSH Brute Force chain / script.  I expect that this version will have additional recent match lists for hosts that are known SSH brute force attackers and can safely be blocked for growing intervals of time, likely an hour, day, week, month, year, and permanent (at least that is what I'm thinking about writing).  I will probably rename some of the recent match lists to reflect more what they are so that they could be used in other tests to safely block hosts there too. This should be a good example of a much larger more fleet or
 iented script to be used on multiple production servers.



Grant. . . .

P.S.  This idea of an SSH_Brute_Force chain has obviously grown way beyond the original question and I think is impacting more and more people thus I think it is about time to set up a site somewhere dedicated to this for even more people to be able to find information and benefit (or detrimented by) from this script.  If any one knows a good place for this I would be greatly appreciate being told where to go with this.  I don't know / think that places like SourceForge or FreashMeat are appropriate for firewall scripts, though I could be wrong.  I would think there would be a good place on the NetFilter web site, though I'm not sure how to go about this my self.  Again any help / input / guidance would be welcome.

SSH Brute force attacks - Script version 1.0

[curby .]

Pardon my inability to reply to the original post, but I just
subscribed.  Here is the version of the script I am considering, but
have questions about.

iptables -A INPUT -p tcp --dport 22 -s ! $My_Home_Firewall_IP -m state
--state NEW -m recent --name SSH --set --rsource -j SSH_BF
iptables -A SSH_BF -m recent ! --rcheck --seconds 60 --hitcount 3
--name SSH --rsource -j RETURN
iptables -A SSH_BF -j LOG --log-prefix "SSH Brute Force Attempt:  "
iptables -A SSH_BF -p tcp -j TARPIT



(1) First of all, why should there be a -p tcp in the TARPIT line? 
Somewhere in the original thread I think there was mention of nonTCP
packets that would get into the script and that such packets shouldn't
get dropped, but the rule that jumps to our SSH_BF script only matches
TCP packets anyway.  Looks like something's wrong if nonTCP packets
get to the chain at all.



(2) Next, people interested in implementing this sort of protection
might consider changing the duration and number of matches.  For
example, the current 60:3 settings allow a total of 180 attempts in an
hour but only in bursts of three per minute.  We can consider two
classes of people attempting to connect to the server: brute force
attackers and legitimate scripts and human users.  In the former case,
attempts per unit time as time goes to infinity is what they are
concerned about.  In the latter case, access is usually bursty. 
Consider allowing 50 matches every hour, as in

iptables -A SSH_Brute_Force -m recent ! --rcheck --seconds 3600
--hitcount 50 --name SSH --rsource -j RETURN

Now attackers have fewer than a third of the attacks per hour they can
mount on the system, but chatty backup scripts or admins are allowed
the bursty access (like opening 5 shells/scp streams at once) that
they might sometimes need or like to use.  (Whether this legitimate
but potentially disruptive behavior should be allowed is another
thing.)



(3) Also, is this the only position for the negation that makes the
rule work as intended?  It seems to say "Allow/return packets where it
isn't the case that we've seen more than or equal to three connection
attempts in the last 60 seconds."  To me, the following is more
intuitive:

iptables -A SSH_Brute_Force -m recent --rcheck --seconds 60 !
--hitcount 3 --name SSH --rsource -j RETURN

which reads "Allow/return packets from sources that have attempted
connections less than three times in the past 60 seconds."  This is
totally a subjective preference, but in the interest of learning how
the recent match really works and avoiding stupid mistakes, I want to
verify that this revised rule would have the same effect in the
context of this chain.

Thanks!

Re: SSH Brute force attacks - Script version 1.0

[Marius Mertens]

Hi everybody,

On Saturday, June 25, 2005 8:58 PM,
curby . wrote:

> (1) First of all, why should there be a -p tcp in the TARPIT line?

This is because what TARPIT does, only works with tcp. It is similar to the 
fact, that for example the specification of --dport in a rule only works 
with either -p tcp or -p udp. Since the next logical question might be "But 
what exactly does TARPIT do that only works with tcp?" I took the freedom 
and googled a site that I think covers the rough basics quite 
straightforward: http://cpc.freeshell.org/linux/kernel-tarpit.html
The short version of this is: the -p tcp is not for a special filtering 
purpose, it's there because -j TARPIT wants it and you just have to do it 
;-)

> (2) Next, people interested in implementing this sort of protection
> might consider changing the duration and number of matches.

IMHO this is mostly just a matter of personal taste (or rather, what your 
network environment needs), so it is all your choice how you configure it. 
Personally I like to use it with short timespan and very small number of 
connections, because SSH access from outside is not frequently needed, just 
from time to time. The main reason for me to use it, is to stop 
script(kiddie)s from using my bandwidth, processor time and precious 
harddrive space by filling my logs with their attempts guess a weak 
username/password. Since none of them ever tried more than 50 combinations, 
I am very happy with DROPping them for a while until they move to the next 
host after their third connection attempt. But if you are more afraid that 
somebody might try to get into your machine by guessing passwords over an 
extended period of time, the longe timespan with a corresponding number of 
connections might be more suitable for you. Also if your SSH is used in a 
"bulky" way like you described it, a low number of tries within a short 
timespan might not be suitable for your setup.
But as I said, my reason for using this is more to annoy automated scans, 
than to provide additional protection. Your passwords/allowed users should 
be configured in a way, that even without additional limits you don't have 
to worry about anybody breaking in. So the best is to see this ruleset as a 
nice addition that keeps your logs cleaner.

> (3) Also, is this the only position for the negation that makes the
> rule work as intended?

Yes, you are telling the recent module to do an rcheck in the list, 
the --seconds and --hitcount just specifiy further criteria for that rcheck. 
The negation belongs to the whole rcheck construct, you cannot invert just 
single comparisons within that. Btw, be careful there, at least with my 
installation an incorrectly placed "!" does not trigger an error message, 
but is just ignored, so your rule might do the opposite of what you wanted 
it to do. For details and where negations are valid you can also have a look 
at "iptables -m recent --help"

HTH,

Marius 

Re: SSH Brute force attacks - Script version 1.0

[Jan Engelhardt]

On another note; I was criticized for using

  -m limit --limit 2/minute -p tcp --dport 22

which was too perceived as too restrictive by some (or just one).
Anyway, I've looked closer into the manpage of dstlimit and
I would be glad to exchange my lines with

  -m dstlimit --dstlimit 2/minute --dstlimit-mode srcip-dstip
  -p tcp --dport 22

Comments please :)


Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de

Re: SSH Brute force attacks - Script version 1.0

[curby .]

On 6/25/05, Marius Mertens <marius.mertens@gmx.de> wrote:
> > (3) Also, is this the only position for the negation that makes the
> > rule work as intended?
> 
> Yes, you are telling the recent module to do an rcheck in the list,
> the --seconds and --hitcount just specifiy further criteria for that rcheck.
> The negation belongs to the whole rcheck construct, you cannot invert just
> single comparisons within that. Btw, be careful there, at least with my
> installation an incorrectly placed "!" does not trigger an error message,
> but is just ignored, so your rule might do the opposite of what you wanted
> it to do. For details and where negations are valid you can also have a look
> at "iptables -m recent --help"

Ah, indeed that command shows that --seconds and --hitcount cannot
take a negation.  I was going by
http://www.netfilter.org/documentation/HOWTO//netfilter-extensions-HOWTO-3.html#ss3.16
which shows that almost all options can take a negation.  Reading the
fine manual was my downfall. =)

Thank you for the informative response.

Re: SSH Brute force attacks - Script version 1.0

[Marius Mertens]

Hi everybody,

On Sunday, June 26, 2005 10:46 PM,
Jan Engelhardt wrote:

> On another note; I was criticized for using
>
>  -m limit --limit 2/minute -p tcp --dport 22
>
> which was too perceived as too restrictive by some (or just one).

Well, if it is too restrictive can only be said by knowing your environment,
but I certainly agree that it is a very restrictive setting to allow not
more than 2 connections per minute no matter what their source is. If your
system is accessible from the internet, it would allow a way too easy DOS,
and I assume that is exactly the reason why you want to exchange the line
;-)

> Anyway, I've looked closer into the manpage of dstlimit and
> I would be glad to exchange my lines with
>
>  -m dstlimit --dstlimit 2/minute --dstlimit-mode srcip-dstip
>  -p tcp --dport 22
>
> Comments please :)

This seems to do virtually the same, what the version with -m recent does,
so I think it should do the trick for you, especially if you successfully
used -m limit before and had no trouble with it. I have never used -m
dstlimit before, but there are two comments that came into my mind:
If you are afraid of somebody trying to DOS you, the recent match with the
added TTL check might be an even better choice.
Second is that while reading the manpage, I was a bit surprised when I saw
the default of 10 seconds for --dstlimit-htable-expire. You should test if
you don't have to increase that value to not end up with a rule that allows
one connection attempt every 10 seconds.
When implemented correctly to allow state NEW packets at the given rate and
DROP or REJECT them if they exceed their limits both recent and dstlimit
should do well, so it's probably just a matter of taste then ;-) I can only
say that I'm using the version with recent match like the "NetFilter
MailList SSH_Brute_Force Chain version 1.0" Grant posted, and it works
perfectly well for me. But I can't see a reason that dstlimit would not
work, so maybe you just want to try and test it ;-)

HTH,

Marius

Re: SSH Brute force attacks - Script version 1.0

[curby .]

On 6/27/05, Marius Mertens <marius.mertens@gmx.de> wrote:
> If you are afraid of somebody trying to DOS you, the recent match with the
> added TTL check might be an even better choice.

I've been wondering about recent's TTL check and its ability to
prevent or even reduce DOSing.

To test if the TTL option is used, the attacker can send regular
(nonspoofed) ssh requests until they start becoming unresponsive (call
this number n), then try sending another request with a different TTL.
 If that request returns, TTL match is being used so simply send n-1
requests with different TTLs and the spoofed address.  Unless the
route from the attacker to the sshd is longer than the route from the
spoofed client IP to the sshd and the client uses a TTL of 255 (or
something similarly high), the legitimate client will still be DOSed. 
Knowledge of the client system's OS or TCP stack is also reasonably
easy to acquire, and can help narrow down the TTLs that need to be
sent.  Or the attacker can be lazy and send 250 or so SYN packets with
different TTLs and the spoofed IP.

In short, if an attacker know's you're using recent to track ssh
requests, and is not so clueless that he doesn't know about the TTL
option to recent, you're dead whether or not you use the TTL option.

On a related note, I really hope ISPs are doing some egress filtering
to prevent these packets with source IPs not on the expected subnet
from getting out.  I wonder how many do...

Re: SSH Brute force attacks - Script version 1.0

[Stephen Frost]

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

* curby . (curby.public@gmail.com) wrote:
> On 6/27/05, Marius Mertens <marius.mertens@gmx.de> wrote:
> > If you are afraid of somebody trying to DOS you, the recent match with the
> > added TTL check might be an even better choice.
> 
> I've been wondering about recent's TTL check and its ability to
> prevent or even reduce DOSing.

recent's not going to prevent a DOS.  It tries to avoid becoming the
cause of a DOS but there's only so much it can do.

> To test if the TTL option is used, the attacker can send regular
> (nonspoofed) ssh requests until they start becoming unresponsive (call
> this number n), then try sending another request with a different TTL.
>  If that request returns, TTL match is being used so simply send n-1
> requests with different TTLs and the spoofed address.  Unless the
> route from the attacker to the sshd is longer than the route from the
> spoofed client IP to the sshd and the client uses a TTL of 255 (or
> something similarly high), the legitimate client will still be DOSed. 

Sure, but at least it's a little harder than just having to know the
other client's IP address, that's kind of the point.  There's also an
opportunity here for someone to notice what's happening and take action
about it.  Alternatively, there could be additional checks to try and
thwart this (such as checking for multiple packets with different TTLs
from the same source IP and raising a big stink about it, or flipping
the check around to require a specific TTL for a given IP, etc).

> Knowledge of the client system's OS or TCP stack is also reasonably
> easy to acquire, and can help narrow down the TTLs that need to be
> sent.  Or the attacker can be lazy and send 250 or so SYN packets with
> different TTLs and the spoofed IP.
> 
> In short, if an attacker know's you're using recent to track ssh
> requests, and is not so clueless that he doesn't know about the TTL
> option to recent, you're dead whether or not you use the TTL option.

ipt_recent is far from fool-proof and you're describing a known
limitation of it, not anything new.  The TTL option is just there to
make it more difficult, it's by no means a solution to the potential
problem.  Generally I'd think finding the client IP is expected to be 
somewhat difficult by itself.  There's also escape-routes to some
extent, you can have a special rule which watches for packets matching
something and removes blocks on that source address, perhaps
indefinitely or for some specified time, or only when matching the same
TTL as the key packet, etc.

> On a related note, I really hope ISPs are doing some egress filtering
> to prevent these packets with source IPs not on the expected subnet
> from getting out.  I wonder how many do...

Not nearly enough, unfortunately.

	Stephen

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

Re: SSH Brute force attacks - Script version 1.0

[Steven M Campbell]

Taylor, Grant wrote:
># NetFilter MailList SSH_Brute_Force Chain version 1.0.
>iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH --set --rsource -j SSH_Brute_Force
>iptables -A SSH_Brute_Force -s $My_Home_Firewall_IP -j RETURN
>iptables -A SSH_Brute_Force -s $My_Office_Firewall_IP -j RETURN
>iptables -A SSH_Brute_Force -s $My_Girlfriends_Firewall_IP list -j RETURN
>iptables -A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN 
>iptables -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
>iptables -A SSH_Brute_Force -p tcp -j TARPIT
>
>  
Thanks, that is most informative.  Here's an (hopefully) interesting 
twist on that:

-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set 
--name SSH --rsource -j SSH
-A SSH -m recent --rcheck --seconds 300 --hitcount 7 --name SSH 
--rsource -j DROP
-A SSH -m recent --rcheck --seconds 30 --hitcount 4 --name SSH --rsource 
-j RETURN
-A SSH -j DROP

Now we must make 3 failed attempts to connect within 30 seconds then the 
4'th through 7'th attempts will be allowed.  Further attempts will not 
be allowed until 5 minutes of idle time.   Port scanners should blow 
right past this thinking "the port is closed", you can still get in by 
doing multiple attempts and anyone who does figure it out still can only 
issue 4 brute attempts every 5 minutes.

Re: SSH Brute force attacks - Script version 1.0

[Jan Engelhardt]

Hi,


a general note on SSH rate limiting:
because someone might try [ multiple passwords for one given user ] per 
connection, it would be wise to use MaxAuthTries 1 in the sshd config file so 
that every password test requires a new connection, and therefore undergoes 
the "real" limit. I currently have MaxAuthTries 2 and it's not working bad 
either.



Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/