SSH Brute force attacks

SSH Brute force attacks

[Brent Clark]

Hi All

One one of my hosted boxes, my logwatch scripts continuously pipe out my 
ssh and auth log of unsuccessful dictionary attacks

I came across this link : http://blog.andrew.net.au/2005/02/17/

And seen that it would help me slow (in hope) that malious person done.

Would anyone care to comment / share tips etc on what I have below

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set 
--name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A SSH_WHITELIST -s $MYIPADDRESS -m recent --remove --name SSH 
-j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent 
--update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix 
"SSH BRUTE"
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent 
--update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Kind Regards
Brent Clark

Re: SSH Brute force attacks

[Mogens Valentin]

Brent Clark wrote:
> Hi All
> 
> One one of my hosted boxes, my logwatch scripts continuously pipe out my 
> ssh and auth log of unsuccessful dictionary attacks

Change the sshd listener port to a highport..

> I came across this link : http://blog.andrew.net.au/2005/02/17/
> 
> And seen that it would help me slow (in hope) that malious person done.
> 
> Would anyone care to comment / share tips etc on what I have below
> 
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set 
> --name SSH
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
> iptables -A SSH_WHITELIST -s $MYIPADDRESS -m recent --remove --name SSH 
> -j ACCEPT
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent 
> --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix 
> "SSH BRUTE"
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent 
> --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Interesting, but will have to experiment a bit before commenting.
Is  $MYIPADDRESS  your (rfc)private IP?
If so, is your intent to remove yourself here?

-- 
Kind regards,
Mogens Valentin


"One thing you can say about ignorance,
  it causes a lot of interesting arguments."
   -- Bob Heil (from his book "Concert Sound")

Re: SSH Brute force attacks

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



use sshd_config to do the most here for you, set this;

PasswordGuesses                 1

That will slow auto scripts and kiddies down.  The default here is 3.  you 
might also, since sshd is tcpd capable, restrict sshd to only allow 
logings from specific addresses and users, and tcpd logs this all nicely 
for one as well.

Thanks,

Ron DuFresne


On Fri, 6 May 2005, Brent Clark wrote:

> Hi All
>
> One one of my hosted boxes, my logwatch scripts continuously pipe out my ssh 
> and auth log of unsuccessful dictionary attacks
>
> I came across this link : http://blog.andrew.net.au/2005/02/17/
>
> And seen that it would help me slow (in hope) that malious person done.
>
> Would anyone care to comment / share tips etc on what I have below
>
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set 
> --name SSH
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
> iptables -A SSH_WHITELIST -s $MYIPADDRESS -m recent --remove --name SSH -j 
> ACCEPT
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update 
> --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH BRUTE"
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update 
> --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
>
> Kind Regards
> Brent Clark
>

- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCe8Wnst+vzJSwZikRAjNyAKDG4YSEHKO3TG0PbrKS7apsUMoM8wCfeyHo
vRw5TCVAqSLN9CZSzbAT3Hs=
=ylIV
-----END PGP SIGNATURE-----

Re: SSH Brute force attacks

[Taylor, Grant]

# Let's jump to the SSH_Brute_Force chain if this is a new connection that is not from my IP address.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -s ! $MYIPADDRESS -j SSH_Brute_Force
# If there have not been 4 NEW connection attempts from this source IP address in the last 60 secons let's return to the INPUT chain.
iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 60 -m recent --hitcount 4 --set --name SSH -j RETURN
# Well, the NEW connection has been seen so let's update the SSH recent list.
iptables -A SSH_Brute_Force -m recent --name SSH --update
# I like to log on a line by it's self so I don't have to remember to do it on my last line prior to the end of my script.
iptables -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
# Let's send the person that is trying to SSH in to us to the TARPIT target and make them think twice before they try again.
# TARPIT will force the site that is SSHing in to us to timeout the connection.  Sure stick you hand in my port, I'll grab hold of it and not let go,
# you will ahve to chew your arm off and grow a new one and try again.
iptables -A SSH_Brute_Force -j TARPIT
# I can be a mean vindictive SoB (Sweet Old Buzzard.  NOT!)


Brent Clark wrote:
> Hi All
> 
> One one of my hosted boxes, my logwatch scripts continuously pipe out my 
> ssh and auth log of unsuccessful dictionary attacks
> 
> I came across this link : http://blog.andrew.net.au/2005/02/17/
> 
> And seen that it would help me slow (in hope) that malious person done.
> 
> Would anyone care to comment / share tips etc on what I have below
> 
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set 
> --name SSH
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
> iptables -A SSH_WHITELIST -s $MYIPADDRESS -m recent --remove --name SSH 
> -j ACCEPT
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent 
> --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix 
> "SSH BRUTE"
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent 
> --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
> 
> Kind Regards
> Brent Clark
> 

Re: SSH Brute force attacks

[Eric Wood]

----- Original Message ----- 
From: "Taylor, Grant"
Subject: Re: SSH Brute force attacks
> # TARPIT will force the site that is SSHing in to us to timeout the 
> connection.  Sure stick you hand in my port, I'll grab hold of it and not 
> let go,
> # you will ahve to chew your arm off and grow a new one and try again.

Very nice.  This is going into my standard config.  hehe.
But for those interested, in order to get the recent module working for 
RHEL3, you must recompile iptables srpm and follow this bugzilla report:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155608

-Eric Wood 

Re: SSH Brute force attacks

[Brent Clark]

Taylor, Grant wrote:
> # Let's jump to the SSH_Brute_Force chain if this is a new connection 
> that is not from my IP address.
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -s ! 
> $MYIPADDRESS -j SSH_Brute_Force
> # If there have not been 4 NEW connection attempts from this source IP 
> address in the last 60 secons let's return to the INPUT chain.
> iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 60 
> -m recent --hitcount 4 --set --name SSH -j RETURN
> # Well, the NEW connection has been seen so let's update the SSH recent 
> list.
> iptables -A SSH_Brute_Force -m recent --name SSH --update
> # I like to log on a line by it's self so I don't have to remember to do 
> it on my last line prior to the end of my script.
> iptables -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force 
> Attempt:  "
> # Let's send the person that is trying to SSH in to us to the TARPIT 
> target and make them think twice before they try again.
> # TARPIT will force the site that is SSHing in to us to timeout the 
> connection.  Sure stick you hand in my port, I'll grab hold of it and 
> not let go,
> # you will ahve to chew your arm off and grow a new one and try again.
> iptables -A SSH_Brute_Force -j TARPIT
> # I can be a mean vindictive SoB (Sweet Old Buzzard.  NOT!)

Hi all

Thanks to Grant for the info above, but for some funny reason I cant get 
the following to work

iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 60 
-m recent --hitcount 4 --set --name SSH -j RETURN

this what I get back:
=====================
[root@abc root]# iptables -A SSH_Brute_Force -m recent --name SSH ! 
--rcheck --seconds 60 -m recent --hitcount 4 --set --name SSH -j RETURN
iptables v1.2.9: Unknown arg `4'
Try `iptables -h' or 'iptables --help' for more information.
[root@ns root]#


Regards
Brent Clark

Re: SSH Brute force attacks

[Taylor, Grant]

> Thanks to Grant for the info above, but for some funny reason I cant get 
> the following to work
> 
> iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 60 
> -m recent --hitcount 4 --set --name SSH -j RETURN
> 
> this what I get back:
> =====================
> [root@abc root]# iptables -A SSH_Brute_Force -m recent --name SSH ! 
> --rcheck --seconds 60 -m recent --hitcount 4 --set --name SSH -j RETURN
> iptables v1.2.9: Unknown arg `4'
> Try `iptables -h' or 'iptables --help' for more information.
> [root@ns root]#

I'm betting that you don't have the "recent" match extension compiled in to the kernel directly or as a module.  Try "iptables -m recent -h" to see if you get any output talking about recent at the bottom or if it complains.  I don't think that the recent extension is in the base kernel and thus you will have to apply some patches via p-o-m to the kernel and iptables and recompile your self.  Once you have support for the recent match extension you should be able to do what I have suggested.  If you need help just ask.



Grant. . . .

Re: SSH Brute force attacks

[Pete Toscano]

Taylor, Grant wrote:
>> iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds
>> 60 -m recent --hitcount 4 --set --name SSH -j RETURN
>>
>> this what I get back:
>> =====================
>> [root@abc root]# iptables -A SSH_Brute_Force -m recent --name SSH !
>> --rcheck --seconds 60 -m recent --hitcount 4 --set --name SSH -j RETURN
>> iptables v1.2.9: Unknown arg `4'
>> Try `iptables -h' or 'iptables --help' for more information.
>> [root@ns root]#
> 
> 
> I'm betting that you don't have the "recent" match extension compiled in
> to the kernel directly or as a module.  Try "iptables -m recent -h" to
> see if you get any output talking about recent at the bottom or if it
> complains.  I don't think that the recent extension is in the base
> kernel and thus you will have to apply some patches via p-o-m to the
> kernel and iptables and recompile your self.  Once you have support for
> the recent match extension you should be able to do what I have
> suggested.  If you need help just ask.

I get the error Brent gets above, but I do have the recent module:

From the iptables -m recent -h command you suggest:

ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>.
http://snowman.net/projects/ipt_recent/

and "--hitcount" is referenced in the help:

--hitcount hits             For check and update commands above.
                                Specifies that the match will only occur
if source address seen hits times.

FWIW, I'm using iptables 1.2.11 in Fedora Core 3.

pete

Re: SSH Brute force attacks

[Taylor, Grant]

> I get the error Brent gets above, but I do have the recent module:

> ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>.
> http://snowman.net/projects/ipt_recent/
> 
> and "--hitcount" is referenced in the help:
> 
> --hitcount hits             For check and update commands above.
>                                 Specifies that the match will only occur
> if source address seen hits times.
> 
> FWIW, I'm using iptables 1.2.11 in Fedora Core 3.

Hmm, you may need / want to update your iptables and apply the most recent p-o-m patch for the recent match extension.  Here is what I get as output when I do "iptables -m recent -h":

recent v1.3.1-20050422 options:
[!] --set                       Add source address to list, always matches.
[!] --rcheck                    Match if source address in list.
[!] --update                    Match if source address in list, also update last-seen time.
[!] --remove                    Match if source address in list, also removes that address from list.
    --seconds seconds           For check and update commands above.
                                Specifies that the match will only occur if source address last seen within
                                the last 'seconds' seconds.
    --hitcount hits             For check and update commands above.
                                Specifies that the match will only occur if source address seen hits times.
                                May be used in conjunction with the seconds option.
    --rttl                      For check and update commands above.
                                Specifies that the match will only occur if the source address and the TTL
                                match between this packet and the one which was set.
                                Useful if you have problems with people spoofing their source address in order
                                to DoS you via this module.
    --name name                 Name of the recent list to be used.  DEFAULT used if none given.
    --rsource                   Match/Save the source address of each packet in the recent list table (default).
    --rdest                     Match/Save the destination address of each packet in the recent list table.
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>.  http://snowman.net/projects/ipt_recent/




Grant. . . .

Re: SSH Brute force attacks

[Pete Toscano]

Taylor, Grant wrote:

> recent v1.3.1-20050422 options:
> [!] --set                       Add source address to list, always matches.
> [!] --rcheck                    Match if source address in list.
> [!] --update                    Match if source address in list, also
> update last-seen time.
> [!] --remove                    Match if source address in list, also
> removes that address from list.
>    --seconds seconds           For check and update commands above.
>                                Specifies that the match will only occur
> if source address last seen within
>                                the last 'seconds' seconds.
>    --hitcount hits             For check and update commands above.
>                                Specifies that the match will only occur
> if source address seen hits times.
>                                May be used in conjunction with the
> seconds option.
>    --rttl                      For check and update commands above.
>                                Specifies that the match will only occur
> if the source address and the TTL
>                                match between this packet and the one
> which was set.
>                                Useful if you have problems with people
> spoofing their source address in order
>                                to DoS you via this module.
>    --name name                 Name of the recent list to be used. 
> DEFAULT used if none given.
>    --rsource                   Match/Save the source address of each
> packet in the recent list table (default).
>    --rdest                     Match/Save the destination address of
> each packet in the recent list table.
> ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>. 
> http://snowman.net/projects/ipt_recent/

Freaky.  My output is the same as yours with the exception of the 1.2.11
string.

recent v1.2.11 options:
<snip same stuff that you have>
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>.
http://snowman.net/projects/ipt_recent/

I'm a little confused about the difference between "recent v1.2.11" and
"ipt_recent v0.3.1"  Is one a kernel component and the other the
userspace part?

I'm also a little confused about p-o-m.  Is this something I can apply
without recompiling my (modular) kernel?  Are there any good docs on how
to use p-o-m?  I didn't see any immediately obvious on the netfilter
site and the p-o-m section seems to end mid-

;)

Thanks,
pete

Re: SSH Brute force attacks

[Jason Opperisano]

On Wed, May 11, 2005 at 03:30:16PM -0400, Pete Toscano wrote:
> Freaky.  My output is the same as yours with the exception of the 1.2.11
> string.
> 
> recent v1.2.11 options:
> <snip same stuff that you have>
> ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>.
> http://snowman.net/projects/ipt_recent/
> 
> I'm a little confused about the difference between "recent v1.2.11" and
> "ipt_recent v0.3.1"  Is one a kernel component and the other the
> userspace part?

yes, ipt_recent == kernel module.  the 1.2.11 is the version of the
iptables userspace utility.

> I'm also a little confused about p-o-m.  Is this something I can apply
> without recompiling my (modular) kernel? 

no.

> Are there any good docs on how
> to use p-o-m?  I didn't see any immediately obvious on the netfilter
> site and the p-o-m section seems to end mid-

basic recipe:

- download/extract kernel src
- download/extract iptables src
- download/extract p-o-m
- apply patches from p-o-m
- recompile kernel
- recompile iptables
- reboot, rinse, repeat.

-j

--
"Stewie: Soooo Broccoli, mother says you're very good for me. But I'm
 afraid I'm no good for you."
        --Family Guy

okay, I admit confusion here;

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I have moved from a p-p-p dialup serivce to a rr business class service 
<and learned to hate verizion>.  Anyways, rr brings in a router, and 
gives me the /28 block <router takes an address>.  how do I setup  eht0 
and eth1 to share the same block?  Is this a case for interface bridging 
and ip2route?



router  <->   eth1 <external>   <->   eth0 <internal, connects to the home
      							hub/switch>


router = xxx.xxx.xxx.17

eth1 = xxx.xxx.xxx.18

eth0 = xxx.xxx.xxx.19


Rest of the home net gets IP's 20-30


Thanks,


Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              admin & senior security consultant:  sysinfo.com
                              http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                      -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFChRyfst+vzJSwZikRAqknAJ90TrPyC6SULCWlisOkEzDCkGV3VwCcDpb/
DEk9BSElkhK3zulClwzKAcA=
=KHwY
-----END PGP SIGNATURE-----

Re: okay, I admit confusion here;

[Jason Opperisano]

On Fri, May 13, 2005 at 05:31:06PM -0400, R. DuFresne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I have moved from a p-p-p dialup serivce to a rr business class service 
> <and learned to hate verizion>.  Anyways, rr brings in a router, and 
> gives me the /28 block <router takes an address>.  how do I setup  eht0 
> and eth1 to share the same block?  Is this a case for interface bridging 
> and ip2route?
> 
> router  <->   eth1 <external>   <->   eth0 <internal, connects to the home
> 
> router = xxx.xxx.xxx.17
> 
> eth1 = xxx.xxx.xxx.18
> 
> eth0 = xxx.xxx.xxx.19
> 
> Rest of the home net gets IP's 20-30

sounds like a job for bridging.  how's about:

router	= .17

br0	= .18

where br0 is a bridge device containing member ports eth0 and eth1.

rest of the home net can use .19 - .30 and use .17 as their default
gateway.  the only reason the bridging linux firewall needs an IP at all
would be for SSH mgmt.

-j

--
"Pearl Burton: What is this, spit soup?
 Brian: It's tomato bisque.
 Pearl Burton: What is this, snot soup?
 Brian: It's tomato bisque!
 Pearl Burton: What is this, diarrhea soup?"
        --Family Guy

Re: okay, I admit confusion here;

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 13 May 2005, Jason Opperisano wrote:

> On Fri, May 13, 2005 at 05:31:06PM -0400, R. DuFresne wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I have moved from a p-p-p dialup serivce to a rr business class service
>> <and learned to hate verizion>.  Anyways, rr brings in a router, and
>> gives me the /28 block <router takes an address>.  how do I setup  eht0
>> and eth1 to share the same block?  Is this a case for interface bridging
>> and ip2route?
>>
>> router  <->   eth1 <external>   <->   eth0 <internal, connects to the home
>>
>> router = xxx.xxx.xxx.17
>>
>> eth1 = xxx.xxx.xxx.18
>>
>> eth0 = xxx.xxx.xxx.19
>>
>> Rest of the home net gets IP's 20-30
>
> sounds like a job for bridging.  how's about:
>
> router	= .17
>
> br0	= .18
>
> where br0 is a bridge device containing member ports eth0 and eth1.
>
> rest of the home net can use .19 - .30 and use .17 as their default
> gateway.  the only reason the bridging linux firewall needs an IP at all
> would be for SSH mgmt.
>

- From what I have seen of the bridging abilities and ebtables this gets 
ugly as we are reduced to layer 2 filtering and have a lack of control of 
the higher level protocols, which is basically useless here.

The only work about I note would be to bridge and then 'untransparent' the 
whole thing by putting IP's on both bridged eht cards and then filtering 
and all is reduced to eth1 and eth0 kind of rules.  All of it again ugly, 
and wasteful...

Course, others might have a better understanding of the capabilities of 
bridging and ebtables that I'm missing.  here's the setup in more detail;




                                  ______________________________
                                 |                              |
                                 |       rr router              |
                                 |                              |
                                 |      three nets off it       |
                                 |                              |
                                 |______________________________|
                                         |       |       |
                                         |       |       |
                                 ________|       |       |________
                                 |               |               |
                                 |               |               |
                         public /28      private  /24        private class 
C dhcp


                         |
                         |
                         |
                         |
                        eth1
                         |
                  darkstar.sysinfo.com
                         |
              ______________________
              |                    |
              |     home fw        |
              |                    |
              |                    |
              |____________________|
                         |
                         |
                       eth0
                         |
                 blackhole.sysinfo.com
                 mail.sysinfo.com
                 www.sysinfo.com
                    sysinfo.com
                         |
                         |



                 internal network

                 with public IP's_




Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCiNs0st+vzJSwZikRAvlfAJ4xSd1NQqBv2Ups2nuC9hGqu3GNagCg2ndx
ICPAl3aB9Uo9VphwjEAk7Fo=
=WrHm
-----END PGP SIGNATURE-----

Re: okay, I admit confusion here;

[Taylor, Grant]

> - From what I have seen of the bridging abilities and ebtables this gets 
> ugly as we are reduced to layer 2 filtering and have a lack of control 
> of the higher level protocols, which is basically useless here.

This is not quite the case.  Bridging has a unique ability to be set up to only bridge specific traffic.  Take a look at my reply (https://lists.netfilter.org/pipermail/netfilter/2005-May/060531.html) to the "Bridging selected MACs" thread.  The EBTables portion of the kernel is firewalling / filtering on layer 2 which has a special table called broute with a special chain called BROUTING which is used to have the kernel decide if it is going to bridge (ACCEPT) traffic (in the the bridging code) or if it is going route (DROP) traffic (up in to the routing code).  With this you could easily have a bridging router.  I think if you take a look at the afore mentioned thread you will see that this can fairly easily be done.  If you do want some help with it please start a new thread (this for some reason showed up as a reply to the SSH brute force thread) and I'll be glad to offer any and all
  help that I can.



Grant. . . .

Re: okay, I admit confusion here;

[Taylor, Grant]

> I have moved from a p-p-p dialup serivce to a rr business class service 
> <and learned to hate verizion>.  Anyways, rr brings in a router, and 
> gives me the /28 block <router takes an address>.  how do I setup  eht0 
> and eth1 to share the same block?  Is this a case for interface bridging 
> and ip2route?
> 
> router  <->   eth1 <external>   <->   eth0 <internal, connects to the home
>                                  hub/switch>
> 
> router = xxx.xxx.xxx.17
> eth1 = xxx.xxx.xxx.18
> eth0 = xxx.xxx.xxx.19
> 
> Rest of the home net gets IP's 20-30

Are you REALLY wanting the rest of the (computers in your) home to have globally routable IPs?  If you are wanting such I would REALLY suggest that you take a look at the NETMAP target where you would do mass translation of the IP addresses to private IPs or look at a lot of port forwarding.  Why did you get a /28 block of IPs?  Do you have 13 (plus the router) pieces of equipment that need to have globally routable IPs or is this just what they gave you (and are billing you for) because you have multiple computers at your house that will be using the cable modem?  I have not dealt with RR in a long time so I don't know their current politics, though from what I remember they wanted to charge per system that would be accessing the net via the CM.  If this is just simple home LAN internet access (IMHO) you should REALLY think about dropping back to one IP address from RR and do the same t
 ype of NATing that you were doing on your PPP.



Grant. . . .

Re: SSH Brute force attacks

[Georgi Alexandrov]

Jason Opperisano wrote:

>On Wed, May 11, 2005 at 03:30:16PM -0400, Pete Toscano wrote:
>  
>
>>Freaky.  My output is the same as yours with the exception of the 1.2.11
>>string.
>>
>>recent v1.2.11 options:
>><snip same stuff that you have>
>>ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>.
>>http://snowman.net/projects/ipt_recent/
>>
>>I'm a little confused about the difference between "recent v1.2.11" and
>>"ipt_recent v0.3.1"  Is one a kernel component and the other the
>>userspace part?
>>    
>>
>
>yes, ipt_recent == kernel module.  the 1.2.11 is the version of the
>iptables userspace utility.
>
>  
>
>>I'm also a little confused about p-o-m.  Is this something I can apply
>>without recompiling my (modular) kernel? 
>>    
>>
>
>no.
>  
>
I don't agree Jason. You can compile only the needed modules.
Here's a tutorial (in bulgarian sorry, but you can get the idea from the 
comments/commands) how to do that with fedora core 3:
http://hardtrance.blogspot.com/2005/04/fedora-core-3-patch-o-matic-ipttimeko.html

>  
>
>>Are there any good docs on how
>>to use p-o-m?  I didn't see any immediately obvious on the netfilter
>>site and the p-o-m section seems to end mid-
>>    
>>
>
>basic recipe:
>
>- download/extract kernel src
>- download/extract iptables src
>- download/extract p-o-m
>- apply patches from p-o-m
>- recompile kernel
>- recompile iptables
>- reboot, rinse, repeat.
>
>-j
>
>--
>"Stewie: Soooo Broccoli, mother says you're very good for me. But I'm
> afraid I'm no good for you."
>        --Family Guy
>
>
>  
>
regards,
Georgi Alexandrov

Re: SSH Brute force attacks

[Jason Opperisano]

On Sat, May 14, 2005 at 10:02:52AM +0300, Georgi Alexandrov wrote:
> Jason Opperisano wrote:
> 
> >On Wed, May 11, 2005 at 03:30:16PM -0400, Pete Toscano wrote:
> > 
> >
> >>Freaky.  My output is the same as yours with the exception of the 1.2.11
> >>string.
> >>
> >>recent v1.2.11 options:
> >><snip same stuff that you have>
> >>ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>.
> >>http://snowman.net/projects/ipt_recent/
> >>
> >>I'm a little confused about the difference between "recent v1.2.11" and
> >>"ipt_recent v0.3.1"  Is one a kernel component and the other the
> >>userspace part?
> >>   
> >>
> >
> >yes, ipt_recent == kernel module.  the 1.2.11 is the version of the
> >iptables userspace utility.
> >
> > 
> >
> >>I'm also a little confused about p-o-m.  Is this something I can apply
> >>without recompiling my (modular) kernel? 
> >>   
> >>
> >
> >no.
> > 
> >
> I don't agree Jason. You can compile only the needed modules.

that's a *very* dangerous piece of advice.  i'm sure you can find
examples of PoM modules that are completely self-contained code that you
can just compile as a module and copy into your /lib/modules/`uname -r`
tree.  hell--'recent' may even be an example of such a module.  general
advice; however, is that if you add patches from PoM, you recompile both
your kernel and your iptables userspace.  this is true for more patches
in PoM than it is untrue for.  i (for one), prefer not to have a rash of
ppl follow this ill advice and start posting messages of why none of
their nat rules will apply any more.

my 2c...from experience...and from trying to support the
inexperienced...

-j

--
"Peter: You all know how observant I am.
 TV Announcer: And now back to Star Trek.
 Peter: Holy crap. Uhura's black?"
        --Family Guy

Re: SSH Brute force attacks

[Patrick Nelson]

Georgi Alexandrov wrote:

> Jason Opperisano wrote:
>
>> On Wed, May 11, 2005 at 03:30:16PM -0400, Pete Toscano wrote:
>>  
>>
>>> Freaky.  My output is the same as yours with the exception of the 
>>> 1.2.11
>>> string.
>>>
>>> recent v1.2.11 options:
>>> <snip same stuff that you have>
>>> ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>.
>>> http://snowman.net/projects/ipt_recent/
>>>
>>> I'm a little confused about the difference between "recent v1.2.11" and
>>> "ipt_recent v0.3.1"  Is one a kernel component and the other the
>>> userspace part?
>>>   
>>
>>
>> yes, ipt_recent == kernel module.  the 1.2.11 is the version of the
>> iptables userspace utility.
>>
>>  
>>
>>> I'm also a little confused about p-o-m.  Is this something I can apply
>>> without recompiling my (modular) kernel?   
>>
>>
>> no.
>>  
>>
> I don't agree Jason. You can compile only the needed modules.
> Here's a tutorial (in bulgarian sorry, but you can get the idea from 
> the comments/commands) how to do that with fedora core 3:
> http://hardtrance.blogspot.com/2005/04/fedora-core-3-patch-o-matic-ipttimeko.html 
>
>
>>  
>>
>>> Are there any good docs on how
>>> to use p-o-m?  I didn't see any immediately obvious on the netfilter
>>> site and the p-o-m section seems to end mid-
>>>   
>>
>>
>> basic recipe:
>>
>> - download/extract kernel src
>> - download/extract iptables src
>> - download/extract p-o-m
>> - apply patches from p-o-m
>> - recompile kernel
>> - recompile iptables
>> - reboot, rinse, repeat.
>>
>> -j
>>
>> -- 
>> "Stewie: Soooo Broccoli, mother says you're very good for me. But I'm
>> afraid I'm no good for you."
>>        --Family Guy
>>
>>
>>  
>>
> regards,
> Georgi Alexandrov
>
As I read through the link of hardtrance.blogspot.com and I was 
wondering if anyone has rebuilt the RPM so I can try this.  I am getting 
inundated with SSH hits and I would love to try Grant's Method.  But we 
do not do Kernel building.  Is there anyway Grant's method can be tried 
without rebuilding the Kernel and IPTables.  It seems that:

iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 60 
-m recent --hitcount 4 --set --name SSH -j RETURN

is a integral part of his method.  I have the same output to the command 
iptables -m recent -h as others here:
<snip>
recent v1.2.11 options:
[!] --set                       Add source address to list, always matches.
[!] --rcheck                    Match if source address in list.
[!] --update                    Match if source address in list, also 
update last-seen time.
[!] --remove                    Match if source address in list, also 
removes that address from list.
    --seconds seconds      For check and update commands above.
                                      Specifies that the match will only 
occur if source address last seen within the last 'seconds' seconds.
    --hitcount hits             For check and update commands above.
                                     Specifies that the match will only 
occur if source address seen hits times.
<snip>

And I get the same output from Grant's recent command of:

iptables v1.2.11: Unknown arg `4'
Try `iptables -h' or 'iptables --help' for more information.

Is there a way to do this without doing Grant's "-m recent" step and the 
recompiling thing?  Or some work around?  I really want to do tar 
pitting of these SSH brute force losers.

Thank!

Re: SSH Brute force attacks

[Charlie Brady]

On Sun, 15 May 2005, Patrick Nelson wrote:

> iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 60 -m 
> recent --hitcount 4 --set --name SSH -j RETURN
>
> is a integral part of his method.  I have the same output to the command 
> iptables -m recent -h as others here:
> <snip>
> recent v1.2.11 options:
> [!] --set                       Add source address to list, always matches.
> [!] --rcheck                    Match if source address in list.
> [!] --update                    Match if source address in list, also update 
> last-seen time.
> [!] --remove                    Match if source address in list, also removes 
> that address from list.
> --seconds seconds      For check and update commands above.
>                                     Specifies that the match will only occur 
> if source address last seen within the last 'seconds' seconds.
> --hitcount hits             For check and update commands above.
>                                    Specifies that the match will only occur 
> if source address seen hits times.
> <snip>
>
> And I get the same output from Grant's recent command of:
>
> iptables v1.2.11: Unknown arg `4'
> Try `iptables -h' or 'iptables --help' for more information.

If the doc is to be believed then --hitcount is only valid with --remove 
and --update. IOW, it's not valid with --set and --rcheck.

Re: SSH Brute force attacks

[Łukasz Hejnak]

Taylor, Grant wrote:
>> Thanks to Grant for the info above, but for some funny reason I cant 
>> get the following to work
>>
>> iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 
>> 60 -m recent --hitcount 4 --set --name SSH -j RETURN
>>
>> this what I get back:
>> =====================
>> [root@abc root]# iptables -A SSH_Brute_Force -m recent --name SSH ! 
>> --rcheck --seconds 60 -m recent --hitcount 4 --set --name SSH -j RETURN
>> iptables v1.2.9: Unknown arg `4'
>> Try `iptables -h' or 'iptables --help' for more information.
>> [root@ns root]#
> I'm betting that you don't have the "recent" match extension compiled in 
> to the kernel directly or as a module.  Try "iptables -m recent -h" to 
> see if you get any output talking about recent at the bottom or if it 
> complains.  I don't think that the recent extension is in the base 
> kernel and thus you will have to apply some patches via p-o-m to the 
> kernel and iptables and recompile your self.  Once you have support for 
> the recent match extension you should be able to do what I have 
> suggested.  If you need help just ask.

Hi
I just thought I'll join in, cause I have a similar problem, but the 
rest of this discussion doesn't solve it.
Like in above I have
#iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 
60 -m recent --hitcount 4 --set --name SSH -j RETURN
iptables v1.3.1: Unknown arg `4'
Try `iptables -h' or 'iptables --help' for more information.

and the iptables -m recent --help gives

#iptables -m recent --help
iptables v1.3.1

Usage: iptables -[AD] chain rule-specification [options]
        iptables -[RI] chain rulenum rule-specification [options]
<cut here>
[!] --version   -V              print package version.

recent v1.3.1 options:
[!] --set                       Add source address to list, always matches.
[!] --rcheck                    Match if source address in list.
<cut again>
     --rdest                     Match/Save the destination address of 
each packet in the recent list table.
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>. 
http://snowman.net/projects/ipt_recent/


I have the 'recent match' compiled into the kernel as a module
and I had recompiled the kernel and then the iptables, and still the 
above apears when executing.
Any ideas to what can be wrong here?
I'm on a HLFS system (april svn) and my kernel is now 2.6.11.9-grsec,
as I updated it to see if it's related to the problem.
The iptables I use was downloaded yesterday via svn

Also I understand that a `iptables -N SSH_Brute_Force` is mutedly 
assumed? or maybe I'm missing something bigger here?

--
With regards
£ukasz Hejnak

Re: SSH Brute force attacks

[Taylor, Grant]

> I have the 'recent match' compiled into the kernel as a module
> and I had recompiled the kernel and then the iptables, and still the 
> above apears when executing.
> Any ideas to what can be wrong here?
> I'm on a HLFS system (april svn) and my kernel is now 2.6.11.9-grsec,
> as I updated it to see if it's related to the problem.
> The iptables I use was downloaded yesterday via svn

Silly question, have you insmoded or modprobed your recent module in to the kernel?  Do an lsmod to see if you see the recent module the loaded modules list.  Sorry I can't be more specific on this as I run unmodularized kernels for various reasons and thus can't really help all that much with modules.  If you would like I'd be happy to send you a copy of my .config file for you to look at and see the differences.

> Also I understand that a `iptables -N SSH_Brute_Force` is mutedly 
> assumed? or maybe I'm missing something bigger here?

Hmm, I don't know about that.  I do know that I have had to explicitly create new chain(s) any time I wanted to use a user defined chain.



Grant. . . .

Re: SSH Brute force attacks

[Łukasz Hejnak]

>> I'm on a HLFS system (april svn) and my kernel is now 2.6.11.9-grsec,
> Silly question, have you insmoded or modprobed your recent module in to 
> the kernel?  Do an lsmod to see if you see the recent module the loaded 
> modules list. 
Yes it is loaded, and partly works fine (I described it below)

> If you would like I'd be happy to send you a 
> copy of my .config file for you to look at and see the differences.
If You can, please do so, cause I'm in a '-j TARPIT' here myself ;]

I mean now I know a bit more, but still some bits are missing.
I found info on the TARPIT, and it seems that it's not fully supported 
in the 2.6.x kernels yet. So here I'm left with DROP.
But as for the recent module itself it's a werid one, cause it looks 
like my iptables don't accept lines like
`iptables -m recent ... -m recent ...`
I mean no matter what I put after the second -m recent, it get's 
rejected with a 'Unknown arg' msg, altrough the first one works fine :\
Can't figure this one out, anybody has an idea?

Szift

Re: SSH Brute force attacks

[Charlie Brady]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 756 bytes --]


On Mon, 16 May 2005, [ISO-8859-2] Łukasz Hejnak wrote:

> But as for the recent module itself it's a werid one, cause it looks like my 
> iptables don't accept lines like
> `iptables -m recent ... -m recent ...`
> I mean no matter what I put after the second -m recent, it get's rejected 
> with a 'Unknown arg' msg, altrough the first one works fine :\
> Can't figure this one out, anybody has an idea?

Stick with one "-m recent".

Instead of this:

iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 60 \
   -m recent --hitcount 4 --set--name SSH -j RETURN

try this:

iptables -A SSH_Brute_Force -m recent --name SSH ! --update --seconds 60
  --hitcount 4 -j RETURN

I think that might be what the OP intended.

Re: SSH Brute force attacks

[Łukasz Hejnak]

Charlie Brady wrote:
> On Mon, 16 May 2005, [ISO-8859-2] £ukasz Hejnak wrote:
>> But as for the recent module itself it's a werid one, cause it looks 
>> like my iptables don't accept lines like
>> `iptables -m recent ... -m recent ...`
>> I mean no matter what I put after the second -m recent, it get's 
>> rejected with a 'Unknown arg' msg, altrough the first one works fine :\
>> Can't figure this one out, anybody has an idea?
> 
> Stick with one "-m recent".
> try this:
> iptables -A SSH_Brute_Force -m recent --name SSH ! --update --seconds 60
>  --hitcount 4 -j RETURN

I tried this way but it doesn't work..
I can send more then 4 ssh login requests even within 10 seconds, and it 
still let's me trough, and of course I'm not trying from a white listed IP.

:\

--
with regards
£ukasz Hejnak

Re: SSH Brute force attacks

[Łukasz Hejnak]

£ukasz Hejnak wrote:
> Charlie Brady wrote:
> Stick with one "-m recent".
> try this:
> iptables -A SSH_Brute_Force -m recent --name SSH ! --update --seconds 60
>  --hitcount 4 -j RETURN

ok, now I got it.. I mindlessly copied the set Taylor Grant sent to the 
list, and didn't think enough about it. Now I found the missing piece, 
the packets going in wheren't marked with --name SSH, so here's why the 
above didn't work, now it works :]
Thanks for the help and the patience :)

-- 
with regards
£ukasz Hejnak

Re: SSH Brute force attacks

[Łukasz Hejnak]

Brent Clark wrote:
> Would you be so kind as to copy and paste your ruleset for this.
No problem, here's my variation, based on Taylor Grant's ruleset

$ipt -N SSH_Brute_Force
$ipt -A INPUT -p tcp --dport 22 -m state --state NEW -s ! $MyIP -j 
SSH_Brute_Force
$ipt -A SSH_Brute_Force -m recent --set --name SSH
$ipt -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60 
--hitcount 3 -j RETURN
$ipt -A SSH_Brute_Force -m recent --name SSH --update
$ipt -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
$ipt -A SSH_Brute_Force -j DROP

I am forced to use DROP here instead of TARPIT as the TARPIT isn't
supported yet for the 2.6.x kernel branch

--
with regards
£ukasz Hejnak

Re: SSH Brute force attacks

[Brent Clark]

£ukasz Hejnak wrote:
> Brent Clark wrote:
> 
>> Would you be so kind as to copy and paste your ruleset for this.
> 
> No problem, here's my variation, based on Taylor Grant's ruleset
> 
> $ipt -N SSH_Brute_Force
> $ipt -A INPUT -p tcp --dport 22 -m state --state NEW -s ! $MyIP -j 
> SSH_Brute_Force
> $ipt -A SSH_Brute_Force -m recent --set --name SSH
> $ipt -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60 
> --hitcount 3 -j RETURN
> $ipt -A SSH_Brute_Force -m recent --name SSH --update
> $ipt -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
> $ipt -A SSH_Brute_Force -j DROP
> 
> I am forced to use DROP here instead of TARPIT as the TARPIT isn't
> supported yet for the 2.6.x kernel branch

Hi £ukasz

Thanks for this.

I managed to get TARPIT in my kernel.
But I decided it against using it.

Doesnt TARPIT use / create unnecessary overhead

Kind Regards
Brent Clark

Re: SSH Brute force attacks

[Sadus .]

$ipt -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60 
> --hitcount 3 -j RETURN

-j RETURN didn't work here. It was blocking all my ssh connections, so i
used ACCEPT and its working now.

On Tue, 2005-05-17 at 15:20 +0200, Brent Clark wrote:
> $ipt -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60 
> > --hitcount 3 -j RETURN

Re: SSH Brute force attacks

[Łukasz Hejnak]

Sadus . wrote:
> $ipt -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60 
>--hitcount 3 -j RETURN
> -j RETURN didn't work here. It was blocking all my ssh connections, so i
> used ACCEPT and its working now.

yes, because most probably by default all packets get dropped at the end
of Your INPUT chain, thus If You wan't to perform any other checks of
the ssh packet You need a -j RETURN, and a -j ACCEPT later,
if not a -j ACCEPT here is ok :)

--
With regards
£ukasz Hejnak

Re: SSH Brute force attacks

[Taylor, Grant]

> I managed to get TARPIT in my kernel.
> But I decided it against using it.
> 
> Doesnt TARPIT use / create unnecessary overhead

No, quite the contrary TARPIT takes a connection directly in to the connected state (SYN, SYN-ACH, ACH-ACH) and releases all resources used in the kernel for the connection to prevent a resource DoS on your system.  The only thing that you need to be aware of is that if you are using connection tracking that conntrack will by default keep track of any connection that you TARPIT.  To get arround this I would recommend that you match the traffic that you are wanting to TARPIT in the raw table PREROUTING chain and send it to the NOTRACK target to prevent connection tracking from consuming resources.

Here is a snipit from the kernel source about TARPIT:

"Adds a TARPIT target to iptables, which captures and holds incoming TCP connections using no local per-connection resources.  Connections are accepted, but immediately switched to the persist state (0 byte window), in which the remote side stops sending data and asks to continue every 60-240 seconds.  Attempts to close the connection are ignored, forcing the remote side to time out the connection in 12-24 minutes."

I sent a new version of the original script to the list early this morning that fixed some (major (gulp)) gubs.  I'll take a look at it again and see if I can't incorporate some code that will catch the traffic in the raw table's PREROUTING chain to be able to NOTRACK the traffic.



Grant. . . .

Re: SSH Brute force attacks

[Brent Clark]

£ukasz Hejnak wrote:
> $ipt -N SSH_Brute_Force
> $ipt -A INPUT -p tcp --dport 22 -m state --state NEW -s ! $MyIP -j 
> SSH_Brute_Force
> $ipt -A SSH_Brute_Force -m recent --set --name SSH
> $ipt -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60 
> --hitcount 3 -j RETURN
> $ipt -A SSH_Brute_Force -m recent --name SSH --update
> $ipt -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
> $ipt -A SSH_Brute_Force -j DROP

Hi all

Would it not be possible to base the the ruleset, based on connection 
suceeded.

For example, At my home I have a dialup account (dynamic ip). So if I 
need to SSH in my hosting box, I cant, because of the ruleset ( $myip 
will be the works static ip) .

Is there not a away to have iptables look at if the connection was 
succesful or not (not based on source ip of $myip). So if I am able to 
ssh (logged in etc)in to my box, then doesnt iptables see that as 
ESTABLISED and RELATED (Normally placed as one of the first entrys in 
your ruleset). But if Ive I not been successful then connection attempt 
again will be considered as NEW.

So my question is, cant we make iptables see the number of NEW 
connections / attempts (Basically dictionary attack) given in a time 
frame. And if the number of NEW connections exceed a certain time frame. 
Then start DROP or TARPIT.

Just something I was thinking

Kind Regards
Brent Clark

Re: SSH Brute force attacks

[Taylor, Grant]

> So my question is, cant we make iptables see the number of NEW 
> connections / attempts (Basically dictionary attack) given in a time 
> frame. And if the number of NEW connections exceed a certain time frame. 
> Then start DROP or TARPIT.

This *IS* based the number of NEW connections in a given time frame.  Note the "--seconds 60" parameter.  This is designed to see if there have been less than x number of NEW connections in the 60 second period.  If there have been less than x number of NEW connections in y time (seconds) then RETURN back to the calling chain and do not continue to parse this chain and ultimately TARPIT or DROP.

NOTE:  Take a look at https://lists.netfilter.org/pipermail/netfilter/2005-May/060570.html as this email has a newer (functioning) version of this script.



Grant. . . .

Re: SSH Brute force attacks

[Brent Clark]

Taylor, Grant wrote:
> 
> This *IS* based the number of NEW connections in a given time frame.  
> Note the "--seconds 60" parameter.  This is designed to see if there 
> have been less than x number of NEW connections in the 60 second 
> period.  If there have been less than x number of NEW connections in y 
> time (seconds) then RETURN back to the calling chain and do not continue 
> to parse this chain and ultimately TARPIT or DROP.
> 
> NOTE:  Take a look at 
> https://lists.netfilter.org/pipermail/netfilter/2005-May/060570.html as 
> this email has a newer (functioning) version of this script.
> 
> 
> 
> Grant. . . .
> 

HI all

Grant thanks for this.

I understand what you are saying, but what was hoping for. Was a 
solution whereby the src ip is not part of my whitelist.

For example, I have a dialup account (dynamic ip) at home. If I need to 
SSH into my linux box from home. I cant because the ip I have been 
allocted will not be in the whitelist.

Just something I was thinking.

Kind Regards
Brent Clark.

P.s. I am glad the ruleset does work (tried it from one of my foreign 
accounts) - THANKS FOR THIS. Really appreciate it.

May 19 09:46:46 ns kernel: [INPUT  DROP]: IN=eth0 OUT= 
MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=196.36.161.230 
DST=217.199.186.118 LEN=60 TOS=0x10 PREC=0x00 TTL=49 ID=36165 DF 
PROTO=TCP SPT=52939 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT 
(020405B40402080A5C847EF80000000001030300)
May 19 09:46:49 ns kernel: [INPUT  DROP]: IN=eth0 OUT= 
MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=196.36.161.230 
DST=217.199.186.118 LEN=60 TOS=0x10 PREC=0x00 TTL=49 ID=36166 DF 
PROTO=TCP SPT=52939 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT 
(020405B40402080A5C8480240000000001030300)
May 19 09:46:55 ns kernel: [INPUT  DROP]: IN=eth0 OUT= 
MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=218.83.155.71 
DST=217.199.186.118 LEN=422 TOS=0x00 PREC=0x00 TTL=44 ID=0 DF PROTO=UDP 
SPT=59537 DPT=1027 LEN=402
May 19 09:46:55 ns kernel: [INPUT  DROP]: IN=eth0 OUT= 
MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=196.36.161.230 
DST=217.199.186.118 LEN=60 TOS=0x10 PREC=0x00 TTL=49 ID=36167 DF 
PROTO=TCP SPT=52939 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT 
(020405B40402080A5C84827C0000000001030300)
May 19 09:47:07 ns kernel: [INPUT  DROP]: IN=eth0 OUT= 
MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=196.36.161.230 
DST=217.199.186.118 LEN=60 TOS=0x10 PREC=0x00 TTL=49 ID=36168 DF 
PROTO=TCP SPT=52939 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT 
(020405B40402080A5C84872C0000000001030300)
May 19 09:47:31 ns kernel: SSH Brute Force Attempt:  IN=eth0 OUT= 
MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=196.36.161.230 
DST=217.199.186.118 LEN=60 TOS=0x10 PREC=0x00 TTL=49 ID=36169 DF 
PROTO=TCP SPT=52939 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

Re: SSH Brute force attacks

[Taylor, Grant]

> I understand what you are saying, but what was hoping for. Was a 
> solution whereby the src ip is not part of my whitelist.
> 
> For example, I have a dialup account (dynamic ip) at home. If I need to 
> SSH into my linux box from home. I cant because the ip I have been 
> allocted will not be in the whitelist.

Can I ask why you would not be able to get in from your dynamic IP at home?  The rule set will allow (how ever many NEW attempts you designate) to connect for a specified number of times in a specified amount of time.  You don't have to have your dynamic IP in the list as any IP will still be able to initiate NEW connections a few times before the rule starts TARPITing / DROPing the connection.  There is also the fact that you could configure your SSH server to listen on a (2nd) port at a higher port number that you would know about that most people would not.  This port would not be processed by this script and thus you would be able to connect from anywhere.



Grant. . . .

Re: SSH Brute force attacks

[Brent Clark]

Taylor, Grant wrote:
>> I understand what you are saying, but what was hoping for. Was a 
>> solution whereby the src ip is not part of my whitelist.
>>
>> For example, I have a dialup account (dynamic ip) at home. If I need 
>> to SSH into my linux box from home. I cant because the ip I have been 
>> allocted will not be in the whitelist.
> 
> 
> Can I ask why you would not be able to get in from your dynamic IP at 
> home?  The rule set will allow (how ever many NEW attempts you 
> designate) to connect for a specified number of times in a specified 
> amount of time.  You don't have to have your dynamic IP in the list as 
> any IP will still be able to initiate NEW connections a few times before 
> the rule starts TARPITing / DROPing the connection.  There is also the 
> fact that you could configure your SSH server to listen on a (2nd) port 
> at a higher port number that you would know about that most people would 
> not.  This port would not be processed by this script and thus you would 
> be able to connect from anywhere.

Hi all

Below is what I have. I basically copied and pasted the original from 
Grant Taylor

So... I cant see why I cant connect from a dynamically assigned ip.

Kind Regards
Brent Clark

===========================================

#!/bin/sh -
IPT=/sbin/iptables

echo 0 > /proc/sys/net/ipv4/ip_dynaddr
echo 0 > /proc/sys/net/ipv4/ip_forward

$IPT --flush
$IPT --flush INPUT              #Flush the INPUT chain
$IPT --flush OUTPUT             #Flush the OUTPUT chain
$IPT --flush FORWARD            #Flush the FORWARD chain
$IPT -t nat --flush             #Flush the nat table
$IPT -t mangle --flush          #Flush the mangle table
$IPT --delete-chain             #Delete any pre-existing chains
$IPT -t nat --delete-chain      #Delete any pre-existing chains from nat 
table
$IPT -t mangle --delete-chain   #Delete any pre-existing chains from the 
mangle table

$IPT --policy INPUT DROP        #Setting the default policy for INPUT chain
$IPT --policy FORWARD DROP      #Setting the default plicy for FORWARD chain
$IPT --policy OUTPUT DROP       #Setting the default policy for the 
OUTPUT chain

$IPT -t nat --policy PREROUTING ACCEPT
$IPT -t nat --policy OUTPUT ACCEPT
$IPT -t nat --policy POSTROUTING ACCEPT
$IPT -t mangle --policy PREROUTING ACCEPT
$IPT -t mangle --policy POSTROUTING ACCEPT

$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

$IPT -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -t filter -A INPUT -m state --state INVALID -j LOG --log-prefix 
"INVALID input: " --log-tcp-options --log-ip-options
$IPT -t filter -A INPUT -m state --state INVALID -j DROP
$IPT -t filter -A INPUT -p tcp  --dport 113 -j REJECT --reject-with 
icmp-host-unreachable
$IPT -t filter -A INPUT -d 217.199.186.255 -j DROP
$IPT -t filter -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 20 -m state --state NEW -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT
#$IPT -t filter -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

$IPT -N SSH_Brute_Force
#$IPT -A INPUT -p tcp --dport 22 -m state --state NEW -s ! 196.31.9.82 
-j SSH_Brute_Force
#$IPT -A SSH_Brute_Force -m recent --set --name SSH
#$IPT -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60 
--hitcount 3 -j RETURN
#$IPT -A SSH_Brute_Force -m recent --name SSH --update
#$IPT -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
#$IPT -A SSH_Brute_Force -j DROP

$IPT -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_Brute_Force
$IPT -A SSH_Brute_Force -s 196.31.9.82 -j RETURN
$IPT -A SSH_Brute_Force -m recent --set --name SSH --rsource
$IPT -A SSH_Brute_Force -m recent ! --update --seconds 60 --hitcount 8 
--name SSH --rsource -j RETURN
$IPT -A SSH_Brute_Force -m recent --update --name SSH --rsource
$IPT -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
$IPT -A SSH_Brute_Force -p tcp -j DROP

$IPT -t filter -A INPUT -p tcp --dport 10000 -m state --state NEW -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 135 -j DROP
$IPT -t filter -A INPUT -p tcp  --dport 113 -j REJECT --reject-with 
icmp-host-unreachable
$IPT -t filter -A INPUT -p icmp --icmp-type source-quench -j ACCEPT
$IPT -t filter -A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT
$IPT -t filter -A INPUT -p icmp --icmp-type destination-unreachable -j 
ACCEPT
$IPT -t filter -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
$IPT -t filter -A INPUT -p icmp --icmp-type ! echo-request -j LOG
$IPT -t filter -A INPUT -j LOG --log-prefix "[INPUT  DROP]: " 
--log-tcp-options --log-ip-options
$IPT -t filter -A INPUT -j DROP

$IPT -t filter -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -t filter -A OUTPUT -m state --state INVALID -j LOG --log-prefix 
"INVALID output: " --log-tcp-options --log-ip-options
$IPT -t filter -A OUTPUT -m state --state INVALID -j DROP
$IPT -t filter -A OUTPUT -m state --state NEW -j ACCEPT
$IPT -t filter -A OUTPUT -j LOG --log-prefix "[OUTPUT DROP]: " 
--log-tcp-options --log-ip-options
$IPT -t filter -A OUTPUT -j DROP

Re: SSH Brute force attacks

[Taylor, Grant]

> So... I cant see why I cant connect from a dynamically assigned ip.

Brent, I'll have to take a closer look at your script later on (complete flow analysis vs just the SSH_Brute_Force chain).  But for now it looks like you have both versions (original and updated one) in your firewall, this could be causing a few problems as I don't think it would take more than one attempt in a 60 second period to get your self to the point that you would be TARPITed / DROPed.  However I think that you would be able to connect at least 1 time from any dynamic remote IP in the 60 second period.  Also keep in mind that the recent module (in the updated version) is using an --update option which will keep track of the number of times that you have tried to connect for 60 seconds after the last connection attempt.

> $IPT -N SSH_Brute_Force
> #$IPT -A INPUT -p tcp --dport 22 -m state --state NEW -s ! 196.31.9.82 
> -j SSH_Brute_Force
> #$IPT -A SSH_Brute_Force -m recent --set --name SSH
> #$IPT -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60 
> --hitcount 3 -j RETURN
> #$IPT -A SSH_Brute_Force -m recent --name SSH --update
> #$IPT -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
> #$IPT -A SSH_Brute_Force -j DROP
> 
> $IPT -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_Brute_Force
> $IPT -A SSH_Brute_Force -s 196.31.9.82 -j RETURN
> $IPT -A SSH_Brute_Force -m recent --set --name SSH --rsource
> $IPT -A SSH_Brute_Force -m recent ! --update --seconds 60 --hitcount 8 
> --name SSH --rsource -j RETURN
> $IPT -A SSH_Brute_Force -m recent --update --name SSH --rsource
> $IPT -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
> $IPT -A SSH_Brute_Force -p tcp -j DROP



Grant. . . .

Re: SSH Brute force attacks

[Brent Clark]

Taylor, Grant wrote:
>> So... I cant see why I cant connect from a dynamically assigned ip.
> 
> 
> Brent, I'll have to take a closer look at your script later on (complete 
> flow analysis vs just the SSH_Brute_Force chain).  But for now it looks 
> like you have both versions (original and updated one) in your firewall, 
> this could be causing a few problems as I don't think it would take more 
> than one attempt in a 60 second period to get your self to the point 
> that you would be TARPITed / DROPed.  However I think that you would be 
> able to connect at least 1 time from any dynamic remote IP in the 60 
> second period.  Also keep in mind that the recent module (in the updated 
> version) is using an --update option which will keep track of the number 
> of times that you have tried to connect for 60 seconds after the last 
> connection attempt.
> 

Hi Grant

If you look carefully on the left, you will see I have hashed out the 
original rules.

Thanks

Kind Regards
Brent Clark

Re: SSH Brute force attacks

[Sadus .]

Is there a way to parse the attacker's IP and block it permanantly via:
iptables -A INPUT -s $IP -j DROP
and cat > /etc/hosts.deny ?

something close to what portsentry does, but using that SSH iptables
Brute force script.

This thread went big and confusion reigned on the latest version of the
Brute Force script, kindly post the latest/best iptable rules :)

thanks

On Mon, 2005-05-23 at 18:31 +0200, Brent Clark wrote:
> Taylor, Grant wrote:
> >> So... I cant see why I cant connect from a dynamically assigned ip.
> > 
> > 
> > Brent, I'll have to take a closer look at your script later on (complete 
> > flow analysis vs just the SSH_Brute_Force chain).  But for now it looks 
> > like you have both versions (original and updated one) in your firewall, 
> > this could be causing a few problems as I don't think it would take more 
> > than one attempt in a 60 second period to get your self to the point 
> > that you would be TARPITed / DROPed.  However I think that you would be 
> > able to connect at least 1 time from any dynamic remote IP in the 60 
> > second period.  Also keep in mind that the recent module (in the updated 
> > version) is using an --update option which will keep track of the number 
> > of times that you have tried to connect for 60 seconds after the last 
> > connection attempt.
> > 
> 
> Hi Grant
> 
> If you look carefully on the left, you will see I have hashed out the 
> original rules.
> 
> Thanks
> 
> Kind Regards
> Brent Clark
> 
-- 
Sadus . <sadus@swiftbin.net>
Swiftbin.net

Re: SSH Brute force attacks

[Taylor, Grant]

Sadus . wrote:
> Is there a way to parse the attacker's IP and block it permanantly via:
> iptables -A INPUT -s $IP -j DROP
> and cat > /etc/hosts.deny ?

The closest thing that I can think of at the moment would be to LOG the packet with a custom "--log-prefix" that is being watched for by a user space daemon and have this daemon add the IP in question to an ipset set list and /etc/hosts.deny.  To take advantage of the ipset set list you would have to use the set match extension to see if the IP was in the set list or not and take action based on that.  If you would like I could ponder this for a while and get back to you on how I would go about doing this.

> something close to what portsentry does, but using that SSH iptables
> Brute force script.

I'm not familiar with port sentry, can you tell me more about it or give me a URL to look at?  I'll Google for it and take a look when I have some more time to spare to see if I can better answer your question(s).

> This thread went big and confusion reigned on the latest version of the
> Brute Force script, kindly post the latest/best iptable rules :)

I will repost the script as it is presently in a new reply to the original message so that it is at the bottom of the thread.  I'll also include a version number in the subject line to make this easier to look at in the future.  For now you can see the most current version of the script in this message available here https://lists.netfilter.org/pipermail/netfilter/2005-May/060734.html .  I'll post a friarly lengthy email with the basic script in a couple of different forms and the various pros and cons to each form.  For now the main difference is that I'm not jumping to the SSH_Brute_Force chain the way that is posted in the list for various reasons I'll explain in the forthcoming email.

> thanks

No problem.



Grant. . . .

Re: SSH Brute force attacks

[Sadus .]

Portsentry listens to a set of ports you set. when someone nmaps your
machine or do some kind of scanning on certain ports, portsentry blocks
that IP via the method you prefer (ipchain, iptables...) and it can echo
the IP to /etc/hosts.deny thus droping all connections with the
attacker. I want to expand the SSH Brute force script to enable this
feature.
It is not important to know if an IP is already in the /etc/hosts.deny
list because since the IP is droped and denied from accessing, the IP
won't reach the brute force script, so normaly you won't have repetition
of IPs.

 


On Thu, 2005-06-02 at 11:43 -0500, Taylor, Grant wrote:
> Sadus . wrote:
> > Is there a way to parse the attacker's IP and block it permanantly via:
> > iptables -A INPUT -s $IP -j DROP
> > and cat > /etc/hosts.deny ?
> 
> The closest thing that I can think of at the moment would be to LOG the packet with a custom "--log-prefix" that is being watched for by a user space daemon and have this daemon add the IP in question to an ipset set list and /etc/hosts.deny.  To take advantage of the ipset set list you would have to use the set match extension to see if the IP was in the set list or not and take action based on that.  If you would like I could ponder this for a while and get back to you on how I would go about doing this.
> 
> > something close to what portsentry does, but using that SSH iptables
> > Brute force script.
> 
> I'm not familiar with port sentry, can you tell me more about it or give me a URL to look at?  I'll Google for it and take a look when I have some more time to spare to see if I can better answer your question(s).
> 
> > This thread went big and confusion reigned on the latest version of the
> > Brute Force script, kindly post the latest/best iptable rules :)
> 
> I will repost the script as it is presently in a new reply to the original message so that it is at the bottom of the thread.  I'll also include a version number in the subject line to make this easier to look at in the future.  For now you can see the most current version of the script in this message available here https://lists.netfilter.org/pipermail/netfilter/2005-May/060734.html .  I'll post a friarly lengthy email with the basic script in a couple of different forms and the various pros and cons to each form.  For now the main difference is that I'm not jumping to the SSH_Brute_Force chain the way that is posted in the list for various reasons I'll explain in the forthcoming email.
> 
> > thanks
> 
> No problem.
> 
> 
> 
> Grant. . . .
> 
-- 
Sadus . <sadus@swiftbin.net>
Swiftbin.net

Re: SSH Brute force attacks

[Taylor, Grant]

Sadus . wrote:
> Portsentry listens to a set of ports you set. when someone nmaps your
> machine or do some kind of scanning on certain ports, portsentry blocks
> that IP via the method you prefer (ipchain, iptables...) and it can echo
> the IP to /etc/hosts.deny thus droping all connections with the
> attacker. I want to expand the SSH Brute force script to enable this
> feature.
> It is not important to know if an IP is already in the /etc/hosts.deny
> list because since the IP is droped and denied from accessing, the IP
> won't reach the brute force script, so normaly you won't have repetition
> of IPs.

I'm working on a re-write of the SSH_Brute_Force chain on my home firewall.  This rewrite will be VERY different and should be the foundation for much growth and adaptation in to other things as well.  The basic idea behind it is to use a multi level triggering system.  Restated in english if you trigger the first level you are banned for a specific amount of time.  If you trip the first level and are banned for the specified amount of chem and then re trip the first level you are then banned at the second level and banned for a longer time.  At present my levels are as follows, 1 minute, 1 hour, 1 day, 1 week, 1 month, 1 year and then permanent ban.  I'm also adding IPs to a recent list that can be checked by other chains early on in the chain set out side of the SSH_Brute_Force chain.  Needless to say it's very complex and I'm doing some testing to make sure that it works the way that 
 I want it to.  Once I get it working I'll either post it to this thread or start a new one
 with an appropriate subject.  I'm trying to include some functionality or the capability of the functionality of Portsentry as you have requested.

I'm not sure if /etc/hosts.deny will prevent packets from entering IPTables or not as I thought that the file was read by user space daemons as a list of IPs to never talk to, not necissarly to the IP table to deny access to.  I could be wrong on this though.



Grant. . . .

Re: SSH Brute force attacks

[Patrick Nelson]

Taylor, Grant wrote:

>>I'm working on a re-write of the SSH_Brute_Force chain on my home firewall.  This rewrite will be VERY different and should be the foundation for much growth and adaptation in to other things as well.  The basic idea behind it is to use a multi level triggering system.  Restated in english if you trigger the first level you are banned for a specific amount of time.  If you trip the first level and are banned for the specified amount of chem and then re trip the first level you are then banned at the second level and banned for a longer time.  At present my levels are as follows, 1 minute, 1 hour, 1 day, 1 week, 1 month, 1 year and then permanent ban.  I'm also adding IPs to a recent list that can be checked by other chains early on in the chain set out side of the SSH_Brute_Force chain.  Needless to say it's very complex and I'm doing some testing to make sure that it works the way that I want it to.  Once I get it working I'll either post it to this thread or start a new one
>> with an appropriate subject.  I'm trying to include some functionality or the capability of the functionality of Portsentry as you have requested.
>>
>>I'm not sure if /etc/hosts.deny will prevent packets from entering IPTables or not as I thought that the file was read by user space daemons as a list of IPs to never talk to, not necissarly to the IP table to deny access to.  I could be wrong on this though.
>>
>>
>>
>>Grant. . . .
>>
If you would...  Please post to this thread (or subject) as well.  I've 
been tracking the progress and like the sound of what your working on as 
well.  Thanks for all your efforts!

Patrick

Re: SSH Brute force attacks

[/dev/rob0]

On Monday 13 June 2005 09:39, Taylor, Grant wrote:
> I'm not sure if /etc/hosts.deny will prevent packets from entering
> IPTables or not as I thought that the file was read by user space
> daemons as a list of IPs to never talk to, not necissarly to the IP
> table to deny access to.

No, yes. The user space daemon is tcpd(8), but other services might be 
linked against the library too, so they would read the hosts_access(5) 
files without consulting tcpd.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: SSH Brute force attacks

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 13 Jun 2005, Taylor, Grant wrote:

> Sadus . wrote:
>> Portsentry listens to a set of ports you set. when someone nmaps your
>> machine or do some kind of scanning on certain ports, portsentry blocks
>> that IP via the method you prefer (ipchain, iptables...) and it can echo
>> the IP to /etc/hosts.deny thus droping all connections with the
>> attacker. I want to expand the SSH Brute force script to enable this
>> feature.
>> It is not important to know if an IP is already in the /etc/hosts.deny
>> list because since the IP is droped and denied from accessing, the IP
>> won't reach the brute force script, so normaly you won't have repetition
>> of IPs.
>
> I'm working on a re-write of the SSH_Brute_Force chain on my home firewall.  This rewrite will be VERY different and should be the foundation for much growth and adaptation in to other things as well.  The basic idea behind it is to use a multi level triggering system.  Restated in english if you trigger the first level you are banned for a specific amount of time.  If you trip the first level and are banned for the specified amount of chem and then re trip the first level you are then banned at the second level and banned for a longer time.  At present my levels are as follows, 1 minute, 1 hour, 1 day, 1 week, 1 month, 1 year and then permanent ban.  I'm also adding IPs to a recent list that can be checked by other chains early on in the chain set out side of the SSH_Brute_Force chain.  Needless to say it's very complex and I'm doing some testing to make sure that it works the way tha
 t I want it to.  Once I get it working I'll either post it to this thread or start a new !
 one
> with an appropriate subject.  I'm trying to include some functionality or the capability of the functionality of Portsentry as you have requested.
>
> I'm not sure if /etc/hosts.deny will prevent packets from entering IPTables or not as I thought that the file was read by user space daemons as a list of IPs to never talk to, not necissarly to the IP table to deny access to.  I could be wrong on this though.

if tcpd is enabled for the service inquestion <and most sshd's are tcpd 
compliant as well as some sendmails on some dists now> then yes, this will 
prevent the packets from reaching iptables or the system as a whole.  Took 
me awhile once to figure out what was getting hit first, and it appears 
that tpd picks up prior to iptables, though, it does not really matter 
about order, if either is set to drop, reject, not accept the packet then 
the packet will nat make it to the application layer.  Another show 
stopper and the main point of where this control rests and shoud rest and 
be configg'ed for sshd is the sshd_conf file.  One can limit sshd such 
that once a bad passwd is presented the connection drop and the other end 
has to start from scratch.  One can also place in limits as to whait 
hosts/IP's are allowed to conenct to the sshd on the server.  the main 
control for an application should reside in that applications control 
mechinisms whereeve possible.  this does not mean that one can not also 
the place in other mechnics to take up if the main controling mechinism 
fails, but, let the app, if it is capable control it;s own.  From there 
laye in the rest of the security layers one is shimming into the mix. 
Remember if there is a /etc/hosts.deny, there should also be a 
/etc/hosts.allow, the deny should be a default deny all, the allow should 
place limits.

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCrde5st+vzJSwZikRAry6AKCbAQ61tcdWUoaIG/FiZuz6i5WzgwCgsQK8
DIH2EtBl0SPjFbVMvQEkbOE=
=cOl+
-----END PGP SIGNATURE-----

RE: SSH Brute force attacks

[Jim Miller]

> Brent Clark wrote:
> > Would you be so kind as to copy and paste your ruleset for this.
> No problem, here's my variation, based on Taylor Grant's ruleset
>
> $ipt -N SSH_Brute_Force
> $ipt -A INPUT -p tcp --dport 22 -m state --state NEW -s ! $MyIP -j
> SSH_Brute_Force
> $ipt -A SSH_Brute_Force -m recent --set --name SSH
> $ipt -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60
> --hitcount 3 -j RETURN
> $ipt -A SSH_Brute_Force -m recent --name SSH --update
> $ipt -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
> $ipt -A SSH_Brute_Force -j DROP
>
> I am forced to use DROP here instead of TARPIT as the TARPIT isn't
> supported yet for the 2.6.x kernel branch
>


Is this true that Tarpit does not work with 2.6 kernels?  I was going to
give it a try on one of my no-production firewalls.



Thanks,
Jim

Re: SSH Brute force attacks

[Łukasz Hejnak]

Jim Miller wrote:
> Is this true that Tarpit does not work with 2.6 kernels?  I was going to
> give it a try on one of my no-production firewalls.

so it seems, I tried compiling the kernel with the current ipt_TARPIT.c
version available in svn, but while loading the rulset, the -j TARPIT
returned 'invalid arg()'
here's some more info:
http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng/TARPIT/info?rev=3733&view=markup

Title: iptables TARPIT target
Author: "Aaron Hopkins" <lists@die.net>
Status: Works for me
Repository: extra
Requires: linux < 2.6.0

Hope that this last line will change soon :]

--
With regards
£ukasz Hejnak

Re: SSH Brute force attacks

[Taylor, Grant]

>>I am forced to use DROP here instead of TARPIT as the TARPIT isn't
>>supported yet for the 2.6.x kernel branch
> 
> Is this true that Tarpit does not work with 2.6 kernels?  I was going to
> give it a try on one of my no-production firewalls.

No, this is not true at all.  I'm using a 2.6.10 kernel to do the testing of this very script on.  I have patched the kernel via patch-o-matic so it is possible that the TARPIT target is one of the things that I patched in to the kernel.  I can't recall at the moment as there have been a LOT of things patched in to this kernel.



Grant. . . .

Re: SSH Brute force attacks

[Пётр Волков Александрович]

Hello Taylor and Łukasz.

Can anybody explain me you are using such combination of rules.

17 Май 2005 16:44 Łukasz Hejnak wrote:
> No problem, here's my variation, based on Taylor Grant's ruleset
> $ipt -A SSH_Brute_Force -m recent --set --name SSH
> $ipt -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60
> --hitcount 3 -j RETURN 

Why this update here (see below)?

> $ipt -A SSH_Brute_Force -m recent --name SSH --update
> $ipt -A SSH_Brute_Force -j DROP
	
Every time packet passed --set rule it updates SSH. So if drop this rule, 
nothing changes. Or am I wrong? Is there any idea behind this that I missed.

Thank you for you attention,
-- 
Peter.

Re: SSH Brute force attacks

[Taylor, Grant]

> Why this update here (see below)?
> 
> $ipt -A SSH_Brute_Force -m recent --name SSH --update
> 	
> Every time packet passed --set rule it updates SSH. So if drop this rule, 
> nothing changes. Or am I wrong? Is there any idea behind this that I missed.

The "--set" rule is required because the testing that I did the "--update" rule would not effectively do the same thing as "--set" because there was no initial "--set" to be updated.  It's sort of a chicken and egg problem where you can not successfully have one with out having the other in this scenario.  The only draw back to having the "--set" that I'm aware of is that the hit count is incremented once per "--set" and "--update" thus you have to double the "--hitcount" value that you want to match against.



Grant. . . .

Re: SSH Brute force attacks

[Пётр Волков Александрович]

Thank you for your answer Grant.

22 Май 2005 02:37 Taylor, Grant wrote:
> > Why this update here (see below)?
> >
> > $ipt -A SSH_Brute_Force -m recent --name SSH --update
> >
> > Every time packet passed --set rule it updates SSH. So if drop this rule,
> > nothing changes. Or am I wrong? Is there any idea behind this that I
> > missed.
>
> The "--set" rule is required because the testing that I did the "--update"
> rule would not effectively do the same thing as "--set" because there was
> no initial "--set" to be updated.  It's sort of a chicken and egg problem
> where you can not successfully have one with out having the other in this
> scenario.  The only draw back to having the "--set" that I'm aware of is
> that the hit count is incremented once per "--set" and "--update" thus you
> have to double the "--hitcount" value that you want to match against.

I feel myself stupid. I'll try to explain my question again, so if you have 
some time to pay me attention, may be you can help me. Any way thank you for 
your time.

 I'd like to comment already posted on the list scenario step by step to make 
my question a bit clearer.

Here we create chain and put all ssh syn trafic there:
1. $ipt -N SSH_Brute_Force
2. $ipt -A INPUT -p tcp --dport 22 -m state --state NEW -s ! $MyIP -j 
SSH_Brute_Force

Now in our SSH_Brute_Force chain we need to add source address in list with 
--set command:
3. $ipt -A SSH_Brute_Force -m recent --set --name SSH

The rule above also updates last seen time. So now we can --rcheck list to see 
how many matches were there (--hitcount ) in the last --seconds.
4. $ipt -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60 
--hitcount 3 -j RETURN

As we have negative (!) in the previous rule, so we are comming here. My 
question is. As we already updated list of matches in 3. why we need to 
--update list again? Did I missed something? May be there are some unknow to 
me problems people experince without next rule:
5. $ipt -A SSH_Brute_Force -m recent --name SSH --update

And of course we drop all unwanted packets...
6. $ipt -A SSH_Brute_Force -j DROP

I'm sorry for boring details. I just want to check that I did not missed 
anything. I've check that rules above are working without 5. But I saw two 
scripts here with this rule. Why you are using it?

-- 
Peter.

Re: SSH Brute force attacks

[Marius Mertens]

On Sunday, May 22, 2005 12:37 AM,
Taylor, Grant wrote:

>> Why this update here (see below)?
>>
>> $ipt -A SSH_Brute_Force -m recent --name SSH --update
>>
>> Every time packet passed --set rule it updates SSH. So if drop this
>> rule, nothing changes. Or am I wrong? Is there any idea behind this
>> that I missed.
>
> The "--set" rule is required because the testing that I did the
> "--update" rule would not effectively do the same thing as "--set"
> because there was no initial "--set" to be updated.  It's sort of a
> chicken and egg problem where you can not successfully have one with
> out having the other in this scenario.  The only draw back to having
> the "--set" that I'm aware of is that the hit count is incremented
> once per "--set" and "--update" thus you have to double the
> "--hitcount" value that you want to match against.

I might be misunderstanding something, but, Peter, is it correct that you 
wanted the "--update" rule to be removed?
In that case I also think it can be safely removed, for it also usually even 
does not seem to match anyway. It should rather match only when there are 
already too frequent connections, so "-j RETURN" won't hit, right? But i'd 
rather like to also hear the opinion of somebody more experienced with 
"recent" match than I am, for the helpfile did not say if the "--set" is 
updated if it already exists. (Though I expect that, and I admit it could be 
easily tested if "--set" updates an already existing "--set" or not, but I 
have to leave right now. I think I'll examine that when I'm back if nobody 
is faster ;-) )

Greetings,

Marius 

Re: SSH Brute force attacks

[Łukasz Hejnak]

Marius Mertens wrote:
> and I admit it could be easily tested if "--set" updates an already 
> existing "--set" or not, but I have to leave right now. I think I'll 
> examine that when I'm back if nobody is faster ;-) )

well in fact I just run a test to see if it's true, and I had already 
writen a long post to ask why is it so, as the ruleset with --hitcount 3 
dropped normally the third connection (it doesn't have to be set to 6),
and then it hit me (--hitcount 1 ;) that the --update is AFTER the "-j 
RETURN"

and it runs ok now, the --update rule can be easily removed, as the 
--set does the trick the way it should.
My ruleset is now something like this below, and works as I intended it 
to, 2 connections ok, third one drops.

ipt=/usr/local/sbin/iptables

$ipt -N SSH_Brute_Force
$ipt -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set 
--name SSH
$ipt -A INPUT -s ! $MyIP -m recent --rcheck --name SSH -j SSH_Brute_Force
$ipt -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60 
--hitcount 3 -j RETURN
$ipt -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
$ipt -A SSH_Brute_Force -j DROP
# do any other checks on the returned ssh packets
$ipt -A INPUT -m recent --rcheck --name SSH -j ACCEPT

--
With regards
£ukasz Hejnak

Re: SSH Brute force attacks

[Taylor, Grant]

> ipt=/usr/local/sbin/iptables
> 
> $ipt -N SSH_Brute_Force
> $ipt -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
> $ipt -A INPUT -s ! $MyIP -m recent --rcheck --name SSH -j SSH_Brute_Force
> $ipt -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60 --hitcount 3 -j RETURN
> $ipt -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
> $ipt -A SSH_Brute_Force -j DROP
> $ipt -A INPUT -m recent --rcheck --name SSH -j ACCEPT

Are you sure that your two INPUT rules are doing what you want the way that you want?  As I read this your first input rule "$ipt -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH" sets every (NEW) packet that is inbound to port 22 in the SSH recent list.  The very next rule "$ipt -A INPUT -s ! $MyIP -m recent --rcheck --name SSH -j SSH_Brute_Force" checks to see if the packet has been set in the SSH recent list.  To me this is a bit on the redundant side unless there is something that I'm missing.  The only thing that I can see to gain by doing this would be that every packet other than the NEW packets would have fewer rules to traverse in the chain?  Is this what you are after?

Also, a comment on the way that you are testing for $MyIP:  What you are doing is ok if you have only one IP that you want to ""white list but how would you ""white list multiple IP, say your friends house that you go over to and hang out once and a while or how about your parent's house where you have to work on their computer once a year (we all have been there).  This is the reason that I jumped in to the SSH_Brute_Force chain and then put multiple RETURN lines at the very top of it.  If you jump in to the SSH_Brute_Force chain to immediately call one of a few RETURN rules you can have as many ""white listed IPs as you would like with very little extra processing on the part of the firewall.



Grant. . . .

Re: SSH Brute force attacks

[Taylor, Grant]

> Stick with one "-m recent".

I have just recently learned that it is only possible to have one match type per IPTables rule.  Sorry for the confusion, I typed up my idea late one evening with out testing it to see if it would work.  Fortunately the people on this list have helped to turn my idea in to a working product.

> Instead of this:
> 
> iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 60 \
>   -m recent --hitcount 4 --set--name SSH -j RETURN
> 
> try this:
> 
> iptables -A SSH_Brute_Force -m recent --name SSH ! --update --seconds 60
>  --hitcount 4 -j RETURN
> 
> I think that might be what the OP intended.

Yes this is indeed what I was trying to do.  I was (at the time) no aware that --update would do the equivalent of --set for an IP address that was not already in the recent list.  Nor was I aware that you could only have one of each match type per line.  With these updates in mind here is a repost of the original script that I have tested and found to work successfully:

# Let's jump to the SSH_Brute_Force chain if this is a new connection that is not from my IP address.
# This will prevent processing these rules for non SSH traffic.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_Brute_Force
# Let's white list some IP addresses.
iptables -A SSH_Brute_Force -s $My_IP_Address -j RETURN
iptables -A SSH_Brute_Force -s $My_Friends_IP_Address -j RETURN
iptables -A SSH_Brute_Force -s $Any_other_IP_that_I_want_to_white list -j RETURN
# We have to manually add the IP address that we want to block to our SSH recent set.
iptables -A SSH_Brute_Force -m recent --set --name SSH --rsource 
# If there have not been 4 NEW connection attempts from this source IP address in the last 60 seconds let's return to the INPUT chain.
# Our hitcount has to be set to twice the number of SSH connection attempts that we want to allow b/c of the previous --set rule will match each and every pass.
iptables -A SSH_Brute_Force -m recent ! --update --seconds 60 --hitcount 8 --name SSH --rsource -j RETURN 
# Well, the NEW connection has been seen so let's update the SSH recent list.
iptables -A SSH_Brute_Force -m recent --update --name SSH --rsource
# I like to log on a line by it's self so I don't have to remember to do it on my last line prior to the end of my script.
iptables -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
# Let's send the person that is trying to SSH in to us to the TARPIT target and make them think twice before they try again.
# TARPIT will force the site that is SSHing in to us to timeout the connection.  Sure stick you hand in my port, I'll grab hold of it and not let go,
# you will have to chew your arm off and grow a new one and try again.  I'll hold your new arm again and again and again and...  This should slow you down.
iptables -A SSH_Brute_Force -p tcp -j TARPIT
# I can be a mean vindictive SoB (Sweet Old Buzzard.  NOT!)

Sorry for the confusion and trouble that this caused.  I am now personally using a slight deviation (pkttype unicast and addrtype unicast matches) of this script with 5 allowed SSH connection attempts (hitcount of 10) in 1 minute.  I also found a bug in the "-j TARPIT" line as you can only TARPIT TCP traffic, hens the "-p tcp" on the line now.  :)



Grant. . . .

Re: SSH Brute force attacks

[Taylor, Grant]

> When this is done, fully working, can you post your full iptables script 
> that prevents brute forcing.

No problem, I'd be glad to.

What I posted early this morning should be functioning code as I did (this time) test it on my router at the house.  I was able to successfully control the number of SSH connection attempts that came in to my router at the house with it.  That being said the code should be ready for use.  If any one wants to test it and report any problems to me I'd be more than happy to try to resolve them.  I do however plan on adding some code to the script to send the traffic that will be TARPITed to the NOTRACK target in the raw table to prevent connection tracking from using up unnecessary resources.



Grant. . . .

Re: SSH Brute force attacks

[Taylor, Grant]

Would this version be more to your liking?  I'm just trying to evolve this script to answer as many of the questions / concerns that are being posed on the list.

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

I have tested this script on my home firewall and have found it to work the way that it is intended, so give it a try and see what you think.  Any and all feedback is welcome and appreciated.



Grant. . . .

Re: SSH Brute force attacks

[Marius Mertens]

On Monday, May 23, 2005 6:53 PM,
Taylor, Grant wrote:


> I have tested this script on my home firewall and have found it to
> work the way that it is intended, so give it a try and see what you
> think.  Any and all feedback is welcome and appreciated.  
 
Great Version! I really like it a lot! Thank you Grant :-)

Marius

Re: SSH Brute force attacks

[Brent Clark]

Taylor, Grant wrote:
> Would this version be more to your liking?  I'm just trying to evolve this script to answer as many of the questions / concerns that are being posed on the list.
> 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
> I have tested this script on my home firewall and have found it to work the way that it is intended, so give it a try and see what you think.  Any and all feedback is welcome and appreciated.

Hi all

For some funny reason I still cant seem to get this right.
I tried connecting from home (dynamic assigned ip) and I still cant connect.

I can connect to my other two server 100%, but the one im trying this on.
I still cant seem to get it right.

Brent

======================================================================

May 25 06:21:51 ns kernel: [INPUT  DROP]: IN=eth0 OUT= 
MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=165.146.144.131 
DST=217.199.186.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=40576 DF 
PROTO=TCP SPT=30066 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 OPT 
(0204055001010402)
May 25 06:21:54 ns kernel: [INPUT  DROP]: IN=eth0 OUT= 
MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=165.146.144.131 
DST=217.199.186.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=40578 DF 
PROTO=TCP SPT=30066 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 OPT 
(0204055001010402)
May 25 06:22:00 ns kernel: SSH Brute Force Attempt:  IN=eth0 OUT= 
MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=165.146.144.131 
DST=217.199.186.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=40585 DF 
PROTO=TCP SPT=30066 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0

$IPT -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -t filter -A INPUT -m state --state INVALID -j LOG --log-prefix 
"INVALID input: " --log-tcp-options --log-ip-options
$IPT -t filter -A INPUT -m state --state INVALID -j DROP
$IPT -t filter -A INPUT -p tcp  --dport 113 -j REJECT --reject-with 
icmp-host-unreachable
$IPT -t filter -A INPUT -d 217.199.186.255 -j DROP
$IPT -t filter -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 20 -m state --state NEW -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT

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

$IPT -t filter -A INPUT -p tcp --dport 10000 -m state --state NEW -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 135 -j DROP
$IPT -t filter -A INPUT -p tcp  --dport 113 -j REJECT --reject-with 
icmp-host-unreachable
$IPT -t filter -A INPUT -p icmp --icmp-type source-quench -j ACCEPT
$IPT -t filter -A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT
$IPT -t filter -A INPUT -p icmp --icmp-type destination-unreachable -j 
ACCEPT
$IPT -t filter -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
$IPT -t filter -A INPUT -p icmp --icmp-type ! echo-request -j LOG
$IPT -t filter -A INPUT -j LOG --log-prefix "[INPUT  DROP]: " 
--log-tcp-options --log-ip-options
$IPT -t filter -A INPUT -j DROP

Re: SSH Brute force attacks

[Marius Mertens]

Hi Brent, Hi List,

On Wednesday, May 25, 2005 7:35 AM,
Brent Clark wrote:

> For some funny reason I still cant seem to get this right.
> I tried connecting from home (dynamic assigned ip) and I still cant
> connect.

From having a short look over your ruleset, I can't find a rule that finally 
accepts NEW ssh connections after the packet successfully passed the 
bruteforce section. Perhaps you want to append an ACCEPT rule for that, so 
the whole block about ssh looks like the following:

[...]
$IPT -N SSH_Brute_Force
[...]
$IPT -A SSH_Brute_Force -j DROP
# Now finally accept NEW ssh traffic
$IPT -t filter -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
[...]

An alternative way might be replacing the RETURN targets with ACCEPT. Though 
I think the way with RETURN is cleaner. For if you append other DROP rules 
to your ruleset later, you might wonder why some ssh connections are 
magically accepted.
Speaking of cleanliness: maybe you also want to remove the final DROP rule 
and set the policy of the INPUT chain to DROP instead. But this should not 
affect functionality ;-)
Oh, almost forgot: sometimes the reason for strange behaviour is your rules 
not getting flushed. Don't think it's the case here, but if it still does 
not work after adding the ACCEPT rule... ;-)

Good Luck!

Marius 

Re: SSH Brute force attacks

[Taylor, Grant]

Brent Clark wrote:
> For some funny reason I still cant seem to get this right.
> I tried connecting from home (dynamic assigned ip) and I still cant
> connect.

Hmm, there must be something else going on.

> May 25 06:21:51 ns kernel: [INPUT  DROP]: IN=eth0 OUT=
> MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=165.146.144.131
> DST=217.199.186.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=40576 DF
> PROTO=TCP SPT=30066 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 OPT
> (0204055001010402)
> May 25 06:21:54 ns kernel: [INPUT  DROP]: IN=eth0 OUT=
> MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=165.146.144.131
> DST=217.199.186.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=40578 DF
> PROTO=TCP SPT=30066 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 OPT
> (0204055001010402)
> May 25 06:22:00 ns kernel: SSH Brute Force Attempt:  IN=eth0 OUT=
> MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=165.146.144.131
> DST=217.199.186.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=40585 DF
> PROTO=TCP SPT=30066 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0

Based on the fact that you are getting a log entry with the "SSH Brute Force Attempt:  " in the log line I think that your SSH packets are some how having more than 3 hits by the time the packets make it to the "iptables -A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN" rule.  This makes me think that there are other rules in your filter chains that are setting packets and thus making them continue through the afore mentioned rule and not be returned thus being DROPed.  Try doing an iptables-save and looking at the output to see if it agrees with what you are expecting based on your iptables script, I'm betting that there is something going on in the SSH_Brute_Force chain from previous test that have slipped your mind.  If you still want / need help please include the results of an iptables-save in your reply.



Grant. . . .

Re: SSH Brute force attacks

[Brent Clark]

Taylor, Grant wrote:
> Brent Clark wrote:

> Based on the fact that you are getting a log entry with the "SSH Brute Force Attempt:  " in the log line I think that your SSH packets are some how having more than 3 hits by the time the packets make it to the "iptables -A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN" rule.  This makes me think that there are other rules in your filter chains that are setting packets and thus making them continue through the afore mentioned rule and not be returned thus being DROPed.  Try doing an iptables-save and looking at the output to see if it agrees with what you are expecting based on your iptables script, I'm betting that there is something going on in the SSH_Brute_Force chain from previous test that have slipped your mind.  If you still want / need help please include the results of an iptables-save in your reply.
> 
> 
> 
> Grant. . . .
> 

Hi Grant, and list

I have done as advised hope this helps.

A big thanks to all for enduring me on this list for this thread, I can 
only imagine how im making a nuisance of my self to all.
My apologies for this.

Again to all thanks.

Kind Regards
Brent Clark


# Generated by iptables-save v1.2.9 on Thu May 26 11:35:50 2005
*mangle
:PREROUTING ACCEPT [27:6779]
:INPUT ACCEPT [1804907:969471155]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [563791:72378022]
:POSTROUTING ACCEPT [16:1132]
COMMIT
# Completed on Thu May 26 11:35:50 2005
# Generated by iptables-save v1.2.9 on Thu May 26 11:35:50 2005
*nat
:PREROUTING ACCEPT [14:5635]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Thu May 26 11:35:50 2005
# Generated by iptables-save v1.2.9 on Thu May 26 11:35:50 2005
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:SSH_Brute_Force - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j LOG --log-prefix "INVALID input: " 
--log-tcp-options --log-ip-options
-A INPUT -m state --state INVALID -j DROP
-A INPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with 
icmp-host-unreachable
-A INPUT -d 217.199.186.255 -j DROP
-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set 
--name SSH --rsource -j SSH_Brute_Force
-A INPUT -p tcp -m tcp --dport 10000 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 135 -j DROP
-A INPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with 
icmp-host-unreachable
-A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -p icmp -m icmp ! --icmp-type 8 -j LOG
-A INPUT -j LOG --log-prefix "[INPUT  DROP]: " --log-tcp-options 
--log-ip-options
-A INPUT -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state INVALID -j LOG --log-prefix "INVALID output: 
" --log-tcp-options --log-ip-options
-A OUTPUT -m state --state INVALID -j DROP
-A OUTPUT -m state --state NEW -j ACCEPT
-A OUTPUT -j LOG --log-prefix "[OUTPUT DROP]: " --log-tcp-options 
--log-ip-options
-A OUTPUT -j DROP
-A SSH_Brute_Force -s 196.36.10.114 -j RETURN
-A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount 3 --name 
SSH --rsource -j RETURN
-A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
-A SSH_Brute_Force -p tcp -j DROP
COMMIT
# Completed on Thu May 26 11:35:50 2005

############################################################

#!/bin/sh -

IPT=/sbin/iptables

# Rules for gateway

#This may help if you have a dynamic IP address \(e.g. slip, ppp, dhcp\)
echo 0 > /proc/sys/net/ipv4/ip_dynaddr

# If you do need to forward packets from one interface to another
echo 0 > /proc/sys/net/ipv4/ip_forward

#Clear \ Flush all the rules from the different chains and tables

$IPT --flush
$IPT --flush INPUT		#Flush the INPUT chain
$IPT --flush OUTPUT		#Flush the OUTPUT chain
$IPT --flush FORWARD		#Flush the FORWARD chain
$IPT -t nat --flush		#Flush the nat table
$IPT -t mangle --flush		#Flush the mangle table
$IPT --delete-chain		#Delete any pre-existing chains
$IPT -t nat --delete-chain	#Delete any pre-existing chains from nat table
$IPT -t mangle --delete-chain	#Delete any pre-existing chains from the 
mangle table

#Setting the default Policies for the chains
$IPT --policy INPUT DROP	#Setting the default policy for INPUT chain
$IPT --policy FORWARD DROP	#Setting the default plicy for FORWARD chain
$IPT --policy OUTPUT DROP	#Setting the default policy for the OUTPUT chain

#Setting Nat and mangle to default policy ACCEPT
$IPT -t nat --policy PREROUTING ACCEPT
$IPT -t nat --policy OUTPUT ACCEPT
$IPT -t nat --policy POSTROUTING ACCEPT
$IPT -t mangle --policy PREROUTING ACCEPT
$IPT -t mangle --policy POSTROUTING ACCEPT

#Accepting traffic for and to internal interface
$IPT -A INPUT -i lo -j ACCEPT		#Allowing unlimited loopback traffic
$IPT -A OUTPUT -o lo -j ACCEPT		#Allowing unlimited loopback traffic

$IPT -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -t filter -A INPUT -m state --state INVALID -j LOG --log-prefix 
"INVALID input: " --log-tcp-options --log-ip-options
$IPT -t filter -A INPUT -m state --state INVALID -j DROP
$IPT -t filter -A INPUT -p tcp  --dport 113 -j REJECT --reject-with 
icmp-host-unreachable
$IPT -t filter -A INPUT -d 217.199.186.255 -j DROP
$IPT -t filter -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 20 -m state --state NEW -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT

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

$IPT -t filter -A INPUT -p tcp --dport 10000 -m state --state NEW -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 135 -j DROP
$IPT -t filter -A INPUT -p tcp  --dport 113 -j REJECT --reject-with 
icmp-host-unreachable
$IPT -t filter -A INPUT -p icmp --icmp-type source-quench -j ACCEPT
$IPT -t filter -A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT
$IPT -t filter -A INPUT -p icmp --icmp-type destination-unreachable -j 
ACCEPT
$IPT -t filter -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
$IPT -t filter -A INPUT -p icmp --icmp-type ! echo-request -j LOG
$IPT -t filter -A INPUT -j LOG --log-prefix "[INPUT  DROP]: " 
--log-tcp-options --log-ip-options
$IPT -t filter -A INPUT -j DROP

$IPT -t filter -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -t filter -A OUTPUT -m state --state INVALID -j LOG --log-prefix 
"INVALID output: " --log-tcp-options --log-ip-options
$IPT -t filter -A OUTPUT -m state --state INVALID -j DROP
$IPT -t filter -A OUTPUT -m state --state NEW -j ACCEPT
$IPT -t filter -A OUTPUT -j LOG --log-prefix "[OUTPUT DROP]: " 
--log-tcp-options --log-ip-options
$IPT -t filter -A OUTPUT -j DROP

############################################################

Chain INPUT (policy DROP 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 ACCEPT     all  --  lo     *       0.0.0.0/0 
0.0.0.0/0
   122 10964 ACCEPT     all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state RELATED,ESTABLISHED
     0     0 LOG        all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state INVALID LOG flags 6 level 4 prefix `INVALID 
input: '
     0     0 DROP       all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state INVALID
     0     0 REJECT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:113 reject-with icmp-host-unreachable
    38 17821 DROP       all  --  *      *       0.0.0.0/0 
217.199.186.255
     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:80 state NEW
     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:20 state NEW
     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:21 state NEW
     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:25 state NEW
     0     0 SSH_Brute_Force  tcp  --  *      *       0.0.0.0/0 
    0.0.0.0/0           tcp dpt:22 state NEW recent: SET name: SSH side: 
source
     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:10000 state NEW
     0     0 DROP       tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:135
     0     0 REJECT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:113 reject-with icmp-host-unreachable
     0     0 ACCEPT     icmp --  *      *       0.0.0.0/0 
0.0.0.0/0           icmp type 4
     0     0 ACCEPT     icmp --  *      *       0.0.0.0/0 
0.0.0.0/0           icmp type 12
     0     0 ACCEPT     icmp --  *      *       0.0.0.0/0 
0.0.0.0/0           icmp type 3
     0     0 ACCEPT     icmp --  *      *       0.0.0.0/0 
0.0.0.0/0           icmp type 11
     0     0 LOG        icmp --  *      *       0.0.0.0/0 
0.0.0.0/0           icmp !type 8 LOG flags 0 level 4
     1   412 LOG        all  --  *      *       0.0.0.0/0 
0.0.0.0/0           LOG flags 6 level 4 prefix `[INPUT  DROP]: '
     1   412 DROP       all  --  *      *       0.0.0.0/0 
0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 ACCEPT     all  --  *      lo      0.0.0.0/0 
0.0.0.0/0
   124 13260 ACCEPT     all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state RELATED,ESTABLISHED
     0     0 LOG        all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state INVALID LOG flags 6 level 4 prefix `INVALID 
output: '
     0     0 DROP       all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state INVALID
     0     0 ACCEPT     all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state NEW
     0     0 LOG        all  --  *      *       0.0.0.0/0 
0.0.0.0/0           LOG flags 6 level 4 prefix `[OUTPUT DROP]: '
     0     0 DROP       all  --  *      *       0.0.0.0/0 
0.0.0.0/0

Chain SSH_Brute_Force (1 references)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 RETURN     all  --  *      *       196.36.10.114 
0.0.0.0/0
     0     0 RETURN     all  --  *      *       0.0.0.0/0 
0.0.0.0/0           !recent: CHECK seconds: 60 hit_count: 3 name: SSH 
side: source
     0     0 LOG        all  --  *      *       0.0.0.0/0 
0.0.0.0/0           LOG flags 0 level 4 prefix `SSH Brute Force Attempt:  '
     0     0 DROP       tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0

Re: SSH Brute force attacks

[Taylor, Grant]

First I'd like to apologize for taking so long to bet back to you.

> Hi Grant, and list
> 
> I have done as advised hope this helps.
> 
> A big thanks to all for enduring me on this list for this thread, I can 
> only imagine how im making a nuisance of my self to all.
> My apologies for this.

You are welcome.  There is no need to apologize for asking for help.  This is what this list is for.  :)

> # Generated by iptables-save v1.2.9 on Thu May 26 11:35:50 2005

<snip>

> *filter
> :INPUT DROP [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT DROP [0:0]
> :SSH_Brute_Force - [0:0]
> -A INPUT -i lo -j ACCEPT
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -m state --state INVALID -j LOG --log-prefix "INVALID input: " 
> --log-tcp-options --log-ip-options
> -A INPUT -m state --state INVALID -j DROP
> -A INPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with 
> icmp-host-unreachable
> -A INPUT -d 217.199.186.255 -j DROP
> -A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 20 -m state --state NEW -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 21 -m state --state NEW -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set 
> --name SSH --rsource -j SSH_Brute_Force
> -A INPUT -p tcp -m tcp --dport 10000 -m state --state NEW -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 135 -j DROP
> -A INPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with 
> icmp-host-unreachable
> -A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
> -A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT
> -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
> -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
> -A INPUT -p icmp -m icmp ! --icmp-type 8 -j LOG
> -A INPUT -j LOG --log-prefix "[INPUT  DROP]: " --log-tcp-options 
> --log-ip-options
> -A INPUT -j DROP
> -A OUTPUT -o lo -j ACCEPT
> -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A OUTPUT -m state --state INVALID -j LOG --log-prefix "INVALID output: 
> " --log-tcp-options --log-ip-options
> -A OUTPUT -m state --state INVALID -j DROP
> -A OUTPUT -m state --state NEW -j ACCEPT
> -A OUTPUT -j LOG --log-prefix "[OUTPUT DROP]: " --log-tcp-options 
> --log-ip-options
> -A OUTPUT -j DROP
> -A SSH_Brute_Force -s 196.36.10.114 -j RETURN
> -A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount 3 --name 
> SSH --rsource -j RETURN
> -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
> -A SSH_Brute_Force -p tcp -j DROP
> COMMIT
> # Completed on Thu May 26 11:35:50 2005

I thin I have found your problem.  In short the problem is that you are using the suggested "RETURN" target which is not quite right for your environment.  From the logs that you (previously) posted:

> May 25 06:21:51 ns kernel: [INPUT  DROP]: IN=eth0 OUT= MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=165.146.144.131 DST=217.199.186.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=40576 DF PROTO=TCP SPT=30066 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204055001010402)
> May 25 06:21:54 ns kernel: [INPUT  DROP]: IN=eth0 OUT= MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=165.146.144.131 DST=217.199.186.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=40578 DF PROTO=TCP SPT=30066 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204055001010402)
> May 25 06:22:00 ns kernel: SSH Brute Force Attempt:  IN=eth0 OUT= MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=165.146.144.131 DST=217.199.186.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=40585 DF PROTO=TCP SPT=30066 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 

The first two LOG & DROPs are from the default LOG and DROP of your INPUT chain.  For the packet to make it to this point in your input chain the packet had to traverse the SSH_Brute_Force chain where the source address was set in the SSH recent list.  Seeing as how the source address has not been seen 3 times via the recent match extension and thus qualify for a RETURN to the input chain it is thus LOGed and DROPed by the default LOG and DROP targets of your input chain.  Upon the third packet coming in to your firewall the packet will traverse the SSH_Brute_Force chain and no match the (inverse) "--hitcount 3" recent check and thus not get RETURNED to the input chain and subsequently get LOGed and DROPed by the SSH_Brute_Force chain.  This explains the three log entries with the staggered times and the different log prefix based on where they are getting dropped.  As such I think the s
 olution to your particular situation is to use a target of ACCEPT, not RETURN on your 2nd 
SSH_Brute_Force rule that matches the "--hitcount 3".

Give that a try and let me know if that works for you please.



Grant. . . .

Re: SSH Brute force attacks

[Brent Clark]

Taylor, Grant wrote:

> The first two LOG & DROPs are from the default LOG and DROP of your 
> INPUT chain.  For the packet to make it to this point in your input 
> chain the packet had to traverse the SSH_Brute_Force chain where the 
> source address was set in the SSH recent list.  Seeing as how the source 
> address has not been seen 3 times via the recent match extension and 
> thus qualify for a RETURN to the input chain it is thus LOGed and DROPed 
> by the default LOG and DROP targets of your input chain.  Upon the third 
> packet coming in to your firewall the packet will traverse the 
> SSH_Brute_Force chain and no match the (inverse) "--hitcount 3" recent 
> check and thus not get RETURNED to the input chain and subsequently get 
> LOGed and DROPed by the SSH_Brute_Force chain.  This explains the three 
> log entries with the staggered times and the different log prefix based 
> on where they are getting dropped.  As such I think the solution to your 
> particular situation is to use a target of ACCEPT, not RETURN on your 
> 2nd SSH_Brute_Force rule that matches the "--hitcount 3".
> 
> Give that a try and let me know if that works for you please.
> Grant. . . .
> 

AHHH it work

THANKS SOOOO much Grant

Really appreiate this

I did as you advised:

$IPT -N SSH_Brute_Force
$IPT -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name 
SSH --set --rsource -j SSH_Brute_Force
$IPT -A SSH_Brute_Force -s 196.36.10.114 -j ACCEPT
$IPT -A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount 3 
--name SSH --rsource -j ACCEPT
$IPT -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
$IPT -A SSH_Brute_Force -p tcp -j DROP

I can ssh in and look a this bugger

May 31 10:50:25 ns sshd[13099]: Failed password for root from 
62.123.184.40 port 22646 ssh2
May 31 10:50:26 ns kernel: SSH Brute Force Attempt:  IN=eth0 OUT= 
MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=62.123.184.40 
DST=217.199.186.118 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=2712 DF 
PROTO=TCP SPT=22755 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
May 31 10:50:29 ns kernel: SSH Brute Force Attempt:  IN=eth0 OUT= 
MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=62.123.184.40 
DST=217.199.186.118 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=2713 DF 
PROTO=TCP SPT=22755 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
May 31 10:50:35 ns kernel: SSH Brute Force Attempt:  IN=eth0 OUT= 
MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=62.123.184.40 
DST=217.199.186.118 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=2714 DF 
PROTO=TCP SPT=22755 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

Damn him for trying HEHEHEEH.

Thanks again Grant and all

Kind Regards
Brent Clark

Re: SSH Brute force attacks

[Taylor, Grant]

> AHHH it work

Good.

> THANKS SOOOO much Grant

You are welcome.

> Really appreiate this

I'm glad that I could help.

> I did as you advised:
> 
> $IPT -N SSH_Brute_Force
> $IPT -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name
> SSH --set --rsource -j SSH_Brute_Force
> $IPT -A SSH_Brute_Force -s 196.36.10.114 -j ACCEPT
> $IPT -A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount 3
> --name SSH --rsource -j ACCEPT
> $IPT -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
> $IPT -A SSH_Brute_Force -p tcp -j DROP

I might suggest that you seriously think about TARPIT as a target to seriously SLOW DOWN the attacker.  If he / she is going through a list of IPs you could cause him / her to get hung up on your system (in such a way as to ensure your safety) and help secure others by delaying the attack on them.

> I can ssh in and look a this bugger
> 
> May 31 10:50:25 ns sshd[13099]: Failed password for root from
> 62.123.184.40 port 22646 ssh2
> May 31 10:50:26 ns kernel: SSH Brute Force Attempt:  IN=eth0 OUT=
> MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=62.123.184.40
> DST=217.199.186.118 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=2712 DF
> PROTO=TCP SPT=22755 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
> May 31 10:50:29 ns kernel: SSH Brute Force Attempt:  IN=eth0 OUT=
> MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=62.123.184.40
> DST=217.199.186.118 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=2713 DF
> PROTO=TCP SPT=22755 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
> May 31 10:50:35 ns kernel: SSH Brute Force Attempt:  IN=eth0 OUT=
> MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=62.123.184.40
> DST=217.199.186.118 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=2714 DF
> PROTO=TCP SPT=22755 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

Hmm, interesting.  Now all you need to do is verify that 62.123.184.40 is not a valid user and wait until you have 20 - 50 such log entries and then report him / her to the appropriate authorities.  This bot / script kiddie will quickly regret doing such things as she / he has been doing.

> Damn him for trying HEHEHEEH.
> 
> Thanks again Grant and all




Grant. . . .

Re: SSH Brute force attacks

[Sebastian Siewior]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 23 May 2005 11:53:59 -0500
"Taylor, Grant" <gtaylor@riverviewtech.net> wrote:

> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent
> --name SSH --set --rsource -j SSH_Brute_Force iptables -A

I don't know if this ever came up, maybe I overlooked it but I have a
problem with the anti-brute-force-thing:
My server has this little feature and its IP is X and mine is A.
Here the interresting part: The bad guy Tom. 
To make it short: Tom does 

hping2 --syn --spoof A --destport 22 --fast X

I could put A in my $whitelist but I hing you got the point :)

- -- 
Regards
Sebastian Siewior
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCmP2ZmNVcHP4/RwYRAp8bAJ4jUGbvzgKmNDg6VRbFY+XvY7I8ZgCfTKMP
OyUVGfuLJnVHSsa685TtmPY=
=1oFA
-----END PGP SIGNATURE-----

Re: SSH Brute force attacks

[Taylor, Grant]

> I don't know if this ever came up, maybe I overlooked it but I have a
> problem with the anti-brute-force-thing:
> My server has this little feature and its IP is X and mine is A.
> Here the interresting part: The bad guy Tom. 
> To make it short: Tom does 
> 
> hping2 --syn --spoof A --destport 22 --fast X
> 
> I could put A in my $whitelist but I hing you got the point :)

I see what you are saying.  My immediate (before I really sit down and think about this) answer would be to add the "--rttl" option to the recent match.  The idea behind this would be to make the recent match TTL aware and thus hopefully able to differentiate from various hosts spoofing the source IP based on the TTL that the packets come in to the host with.  You would probably also want to not have a white list and just know that you can not connect more than a specified number of NEW connections with in the specified amount of time.  Something else that could be done would be to find out how many packets (on average) or number of byes (on average) pass one way or the other or both in an SSH connection to determine that the user has successfully logged in, thus not brute forcing.  With this number you could do a packet / byte count on any given SSH connection and then do a "--remove" o
 n the recent match extension thus allowing you to create more than the specified number of
 NEW connections with in the specified amount of time.  We could also extend this idea to add source IPs (and possibly TTLs) of presumed good SSH connections to a 2nd recent list that would be checked against to override the specified number of NEW connections with in the specified amount of time.  Do any of these ideas sound like they might address your problem?  I would be more than willing to try to modify the SSH_Brute_Force chain to accommodate this, just let me know.



Grant. . . .

Re: SSH Brute force attacks

[Taylor, Grant]

> One one of my hosted boxes, my logwatch scripts continuously pipe out my 
> ssh and auth log of unsuccessful dictionary attacks
> 
> I came across this link : http://blog.andrew.net.au/2005/02/17/

Not a bad idea, but I think there is a little bit of room for growth.

# Let's jump to the SSH_Brute_Force chain if this is a new connection that is not from my IP address.
# This will prevent processing these rules for non SSH traffic.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_Brute_Force
# Let's white list some IP addresses.
iptables -A SSH_Brute_Force -s $My_IP_Address -j RETURN
iptables -A SSH_Brute_Force -s $My_Friends_IP_Address -j RETURN
iptables -A SSH_Brute_Force -s $Any_other_IP_that_I_want_to_white list -j RETURN
# If there have not been 4 NEW connection attempts from this source IP address in the last 60 seconds let's return to the INPUT chain.
iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 60 -m recent --hitcount 4 --set --name SSH -j RETURN
# Well, the NEW connection has been seen so let's update the SSH recent list.
iptables -A SSH_Brute_Force -m recent --name SSH --update
# I like to log on a line by it's self so I don't have to remember to do it on my last line prior to the end of my script.
iptables -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
# Let's send the person that is trying to SSH in to us to the TARPIT target and make them think twice before they try again.
# TARPIT will force the site that is SSHing in to us to timeout the connection.  Sure stick you hand in my port, I'll grab hold of it and not let go,
# you will have to chew your arm off and grow a new one and try again.  I'll hold your new arm again and again and again and...  This should slow you down.
iptables -A SSH_Brute_Force -j TARPIT
# I can be a mean vindictive SoB (Sweet Old Buzzard.  NOT!)

I tried putting in comments to explain the logic of what is going on, if you have any questions please let me know.



Grant. . . .

Re: SSH Brute force attacks

[Alistair Tonner]

On May 7, 2005 01:32 am, Taylor, Grant wrote:
> > One one of my hosted boxes, my logwatch scripts continuously pipe out my
> > ssh and auth log of unsuccessful dictionary attacks
> >
> > I came across this link : http://blog.andrew.net.au/2005/02/17/
>
> Not a bad idea, but I think there is a little bit of room for growth.


	Grant:  
		I think you've put together the basis for a FAQ on recent/TARPIT here -- and 
I like yer attitude *grin*

	Oskar A:
		
		If you'd like I can buff the following up some, but I think this deserves a 
mention in the iptables tutorial:

>
> # Let's jump to the SSH_Brute_Force chain if this is a new connection that
> is not from my IP address. # This will prevent processing these rules for
> non SSH traffic.
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_Brute_Force
> # Let's white list some IP addresses.
> iptables -A SSH_Brute_Force -s $My_IP_Address -j RETURN
> iptables -A SSH_Brute_Force -s $My_Friends_IP_Address -j RETURN
> iptables -A SSH_Brute_Force -s $Any_other_IP_that_I_want_to_white list -j
> RETURN # If there have not been 4 NEW connection attempts from this source
> IP address in the last 60 seconds let's return to the INPUT chain. iptables
> -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 60 -m recent
> --hitcount 4 --set --name SSH -j RETURN # Well, the NEW connection has been
> seen so let's update the SSH recent list. iptables -A SSH_Brute_Force -m
> recent --name SSH --update
> # I like to log on a line by it's self so I don't have to remember to do it
> on my last line prior to the end of my script. iptables -A SSH_Brute_Force
> -j LOG --log-prefix "SSH Brute Force Attempt:  " # Let's send the person
> that is trying to SSH in to us to the TARPIT target and make them think
> twice before they try again. # TARPIT will force the site that is SSHing in
> to us to timeout the connection.  Sure stick you hand in my port, I'll grab
> hold of it and not let go, # you will have to chew your arm off and grow a
> new one and try again.  I'll hold your new arm again and again and again
> and...  This should slow you down. iptables -A SSH_Brute_Force -j TARPIT
> # I can be a mean vindictive SoB (Sweet Old Buzzard.  NOT!)

	I like that in an admin. *grin*

	Alistair Tonner
>
> I tried putting in comments to explain the logic of what is going on, if
> you have any questions please let me know.
>
>
>
> Grant. . . .

Re: SSH Brute force attacks

[Dwayne Hottinger]

Cool.  Ive been having the same issue for quite some time.  Im going to look
hard at this.

ddh


Quoting Alistair Tonner <Alistair@nerdnet.ca>:

> On May 7, 2005 01:32 am, Taylor, Grant wrote:
> > > One one of my hosted boxes, my logwatch scripts continuously pipe out my
> > > ssh and auth log of unsuccessful dictionary attacks
> > >
> > > I came across this link : http://blog.andrew.net.au/2005/02/17/
> >
> > Not a bad idea, but I think there is a little bit of room for growth.
>
>
> 	Grant:
> 		I think you've put together the basis for a FAQ on recent/TARPIT here --
> and
> I like yer attitude *grin*
>
> 	Oskar A:
>
> 		If you'd like I can buff the following up some, but I think this deserves a
> mention in the iptables tutorial:
>
> >
> > # Let's jump to the SSH_Brute_Force chain if this is a new connection that
> > is not from my IP address. # This will prevent processing these rules for
> > non SSH traffic.
> > iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_Brute_Force
> > # Let's white list some IP addresses.
> > iptables -A SSH_Brute_Force -s $My_IP_Address -j RETURN
> > iptables -A SSH_Brute_Force -s $My_Friends_IP_Address -j RETURN
> > iptables -A SSH_Brute_Force -s $Any_other_IP_that_I_want_to_white list -j
> > RETURN # If there have not been 4 NEW connection attempts from this source
> > IP address in the last 60 seconds let's return to the INPUT chain. iptables
> > -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 60 -m recent
> > --hitcount 4 --set --name SSH -j RETURN # Well, the NEW connection has been
> > seen so let's update the SSH recent list. iptables -A SSH_Brute_Force -m
> > recent --name SSH --update
> > # I like to log on a line by it's self so I don't have to remember to do it
> > on my last line prior to the end of my script. iptables -A SSH_Brute_Force
> > -j LOG --log-prefix "SSH Brute Force Attempt:  " # Let's send the person
> > that is trying to SSH in to us to the TARPIT target and make them think
> > twice before they try again. # TARPIT will force the site that is SSHing in
> > to us to timeout the connection.  Sure stick you hand in my port, I'll grab
> > hold of it and not let go, # you will have to chew your arm off and grow a
> > new one and try again.  I'll hold your new arm again and again and again
> > and...  This should slow you down. iptables -A SSH_Brute_Force -j TARPIT
> > # I can be a mean vindictive SoB (Sweet Old Buzzard.  NOT!)
>
> 	I like that in an admin. *grin*
>
> 	Alistair Tonner
> >
> > I tried putting in comments to explain the logic of what is going on, if
> > you have any questions please let me know.
> >
> >
> >
> > Grant. . . .
>


--
Dwayne Hottinger
Network Administrator
Harrisonburg City Public Schools

Re: SSH Brute force attacks

[Alexander Samad]

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

How efficient is recent, I currently scan my log files for 'evil'
activity and build up a list of around 2000s ip addresses which I place
into a BLOCKED chain, there is about 2 lines per entry cause I TARPIT
tcp sessions.  But I could more easily manage it with recent as I can
just use the test of are they in the list !

I am presuming it is more efficient to use recent cause it hashes the
address ! can any one confirm this ?

A

On Sun, May 08, 2005 at 02:51:24PM -0400, Dwayne Hottinger wrote:
> Cool.  Ive been having the same issue for quite some time.  Im going to look
> hard at this.
> 
> ddh
> 
> 
> Quoting Alistair Tonner <Alistair@nerdnet.ca>:
> 
> > On May 7, 2005 01:32 am, Taylor, Grant wrote:
> > > > One one of my hosted boxes, my logwatch scripts continuously pipe out my
> > > > ssh and auth log of unsuccessful dictionary attacks
> > > >
> > > > I came across this link : http://blog.andrew.net.au/2005/02/17/
> > >
> > > Not a bad idea, but I think there is a little bit of room for growth.
> >
> >
> > 	Grant:
> > 		I think you've put together the basis for a FAQ on recent/TARPIT here --
> > and
> > I like yer attitude *grin*
> >
> > 	Oskar A:
> >
> > 		If you'd like I can buff the following up some, but I think this deserves a
> > mention in the iptables tutorial:
> >
> > >
> > > # Let's jump to the SSH_Brute_Force chain if this is a new connection that
> > > is not from my IP address. # This will prevent processing these rules for
> > > non SSH traffic.
> > > iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_Brute_Force
> > > # Let's white list some IP addresses.
> > > iptables -A SSH_Brute_Force -s $My_IP_Address -j RETURN
> > > iptables -A SSH_Brute_Force -s $My_Friends_IP_Address -j RETURN
> > > iptables -A SSH_Brute_Force -s $Any_other_IP_that_I_want_to_white list -j
> > > RETURN # If there have not been 4 NEW connection attempts from this source
> > > IP address in the last 60 seconds let's return to the INPUT chain. iptables
> > > -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 60 -m recent
> > > --hitcount 4 --set --name SSH -j RETURN # Well, the NEW connection has been
> > > seen so let's update the SSH recent list. iptables -A SSH_Brute_Force -m
> > > recent --name SSH --update
> > > # I like to log on a line by it's self so I don't have to remember to do it
> > > on my last line prior to the end of my script. iptables -A SSH_Brute_Force
> > > -j LOG --log-prefix "SSH Brute Force Attempt:  " # Let's send the person
> > > that is trying to SSH in to us to the TARPIT target and make them think
> > > twice before they try again. # TARPIT will force the site that is SSHing in
> > > to us to timeout the connection.  Sure stick you hand in my port, I'll grab
> > > hold of it and not let go, # you will have to chew your arm off and grow a
> > > new one and try again.  I'll hold your new arm again and again and again
> > > and...  This should slow you down. iptables -A SSH_Brute_Force -j TARPIT
> > > # I can be a mean vindictive SoB (Sweet Old Buzzard.  NOT!)
> >
> > 	I like that in an admin. *grin*
> >
> > 	Alistair Tonner
> > >
> > > I tried putting in comments to explain the logic of what is going on, if
> > > you have any questions please let me know.
> > >
> > >
> > >
> > > Grant. . . .
> >
> 
> 
> --
> Dwayne Hottinger
> Network Administrator
> Harrisonburg City Public Schools
> 
> 

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

Re: SSH Brute force attacks

[Taylor, Grant]

Alexander Samad wrote:
> How efficient is recent, I currently scan my log files for 'evil'
> activity and build up a list of around 2000s ip addresses which I place
> into a BLOCKED chain, there is about 2 lines per entry cause I TARPIT
> tcp sessions.  But I could more easily manage it with recent as I can
> just use the test of are they in the list !
> 
> I am presuming it is more efficient to use recent cause it hashes the
> address ! can any one confirm this ?
> 
> A

I'm not sure how ""efficient the recent match extension is as I have not pushed it this far.  Give it a try and let us know.  I know that I personally can now write a lot of code (be it because of lack of trying or other reasons) but I do know that I can help the various developers by using and testing and trying to break their code.  Oh, wait a moment, isn't that what the OSS community is about?  ;)

You might want to check out SnowMan's web page at http://snowman.net/projects/ipt_recent/ on the IPTables recent match.  I'm sure he would be happy to try to answer your question(s) there.  If you do contact SnowMan (via his "About" page, be sure to congratulate him on his (new) baby.)

Re: SSH Brute force attacks

[Taylor, Grant]

> 	Grant:  
> 		I think you've put together the basis for a FAQ on recent/TARPIT here -- and 
> I like yer attitude *grin*

Thank you.  Feel free to use my work any where.  After all we are just trying to help the community.  All I ask is that you say something along the lines that the idea was posted to the netfilter mailing list, for more info or comments look for Grant there.  :)

As far as the attitude goes I'm probably (or at least I'd like to think that I am) one the nicest / easiest to get along with systems administrators you will find.  However if you are trying to break in to my network I could be one of the meanest too....

> 	Oskar A:
> 		
> 		If you'd like I can buff the following up some, but I think this deserves a 
> mention in the iptables tutorial:

Do what ever you would like.  If you would like some more attitude or slightly reworded attitude drop me a line (on or off the list) and I'll be glad to give you some.  :)



Grant. . . .

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.

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/

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

[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

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