iptables deny brute force

qwertyjjj · 08-07-2009, 03:54 PM

the sudo lines are supposed to deny brute force attacks by locking out bots for a while after 8 attempts. When I restart iptables I get a failed line. Should the sudo lines be somewhere else?

Code:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [24:1764]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
#-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT
#-A INPUT -p udp -m udp --dport 69 -m state --state NEW -j ACCEPT
#-A INPUT -p tcp -m tcp --dport 69 -m state --state NEW -j ACCEPT
#-A INPUT -p tcp -m tcp --dport 110 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3306 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 3306 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5555 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8002 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9001 -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp --dport 3128 -j ACCEPT
-A INPUT -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP
COMMIT

salasi · 08-07-2009, 05:28 PM

There are some things about the format of this thaqt seem a bit unfamiliar, so forgive me if I have misinterpreted. Just looking at the relevant stuff (the input chain), you seem to be doing this:

Code:

:INPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3306 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 3306 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5555 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8002 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9001 -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp --dport 3128 -j ACCEPT
-A INPUT -j DROP
sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP

You seem to be specifying to drop twice. Once as a policy at the top, and once before the two 'sudos'.

this is unnecessary
(assuming something 'clever' isn't happening and the rules are being added in the obvious order - you should check the ruleset actually produced, rather than generating script) any packet that hits the unconditional '-A INPUT -j DROP' will be dropped, and never hit any of the subsequent rules. So, they won't do anything. You can just drop, or comment out, the '-A INPUT -j DROP' rule and the others should start doing something.

I'm not at all sure why/how those rules need a 'sudo' if the others don't.

Also, you seem to be doing the kind of thing that fail2ban does. Have you considered that?

qwertyjjj · 08-08-2009, 12:22 AM

It was a basic file provided by the host company that I edited.
I will use fail2ban instead though I guess that uses up memory?
It seems to be working so doesn't the final DROP command have to do with something else?

qwertyjjj · 08-08-2009, 12:26 AM

I have got as far as this but it says not available?

Code:

[root@localhost ~]# wget http://dag.wieers.com/rpm/packages/fail2ban/fail2ban-0.                                                                                                 6.0-1.el4.rf.i386.rpm
--06:25:25--  http://dag.wieers.com/rpm/packages/fail2ban/fail2ban-0.6.0-1.el4.r                                                                                                 f.i386.rpm
Resolving dag.wieers.com... 62.213.193.164
Connecting to dag.wieers.com|62.213.193.164|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://rpmforge.sw.be/redhat/el4/en/i386/rpmforge/RPMS/fail2ban-0.6.0-                                                                                                 1.el4.rf.i386.rpm [following]
--06:25:25--  http://rpmforge.sw.be/redhat/el4/en/i386/rpmforge/RPMS/fail2ban-0.                                                                                                 6.0-1.el4.rf.i386.rpm
Resolving rpmforge.sw.be... 130.133.35.16
Connecting to rpmforge.sw.be|130.133.35.16|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 43748 (43K) [application/x-rpm]
Saving to: `fail2ban-0.6.0-1.el4.rf.i386.rpm'

100%[=======================================>] 43,748      --.-K/s   in 0.1s

06:25:25 (341 KB/s) - `fail2ban-0.6.0-1.el4.rf.i386.rpm' saved [43748/43748]

[root@localhost ~]# rpm -Uvh fail2ban-0.6.0-1.el4.rf.i386.rpm
warning: fail2ban-0.6.0-1.el4.rf.i386.rpm: Header V3 DSA signature: NOKEY, key I                                                                                                 D 6b8d79e6
Preparing...                ########################################### [100%]
   1:fail2ban               ########################################### [100%]
[root@localhost ~]# yum install fail2ban
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirrors.ukfast.co.uk
 * updates: mirrors.ukfast.co.uk
 * addons: mirrors.ukfast.co.uk
 * extras: mirrors.ukfast.co.uk
Excluding Packages in global exclude list
Finished
Setting up Install Process
Parsing package install arguments
Package fail2ban-0.6.0-1.el4.rf.i386 installed and not available
Nothing to do
[root@localhost ~]#

qwertyjjj · 08-08-2009, 01:23 AM

is fail2ban better than this:
-A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP

salasi · 08-08-2009, 02:11 AM

Quote:

Originally Posted by qwertyjjj

I will use fail2ban instead though I guess that uses up memory?

It will use some memory, but should be a more flexible solution. (Although i hadn't seen the solution that you were using before, which looks ingenious.)

Quote:

It seems to be working so doesn't the final DROP command have to do with something else?

I can't see what else it could do. If it were conditional on port number or protocol or something, that would be different.

Quote:

Package fail2ban-0.6.0-1.el4.rf.i386 installed and not available

Don't understand the 'not available' part. This is on a Centos or RedHat type box? And you are doing this as root?

By the way, if there is any danger of you re-running this script, you should be flushing the existing rules at the top.

qwertyjjj · 08-09-2009, 05:25 AM

Quote:

Originally Posted by salasi

By the way, if there is any danger of you re-running this script, you should be flushing the existing rules at the top.

The iptables script?
I just restart after any changes, which seems to flush it.
Is there code I could add to the iptables script for this?

settntrenz · 08-10-2009, 01:06 AM

Quote:

Originally Posted by qwertyjjj

the sudo lines are supposed to deny brute force attacks by locking out bots for a while after 8 attempts. When I restart iptables I get a failed line. Should the sudo lines be somewhere else?

Code:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [24:1764]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
#-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT
#-A INPUT -p udp -m udp --dport 69 -m state --state NEW -j ACCEPT
#-A INPUT -p tcp -m tcp --dport 69 -m state --state NEW -j ACCEPT
#-A INPUT -p tcp -m tcp --dport 110 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3306 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 3306 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5555 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8002 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9001 -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp --dport 3128 -j ACCEPT
-A INPUT -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP
COMMIT

2 problems.

1. you need to remove the "sudo iptables" from the

Code:

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP

lines

The example you grabbed was probably for a system that doesn't save the iptables file in the same format. Ie.. a shell script that loads the iptables rules instead of a file read by the iptables daemon at start.

2. the order needs to be changed. You should insert the lines:

Code:

-A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
-A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP

before the

Code:

-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT

line

I'm pretty sure that the last line

Code:

-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT

will be necessary to allow traffic that hasn't breached the threshold in.

NOTE* If you are remotely working on this system I would encourage you add a cronjob to disable iptables after a few minutes in case you lock yourself out. This has saved me from having to either drive or call someone to undo changes from the console.