Bizarre iptables issue, would like to resolve it.

[Steven E. Protter]

I'm betting Stuart or Ivan can fix this pretty easily.

I implemented fail2ban on a system.

Basically it reacts to log entries with temporary bans based on ip address. Its great at thwarting DoS attacks. My firewalls, which are firestarter based have become much mores stable since implementing fail2ban.

Internal systems don't have firestarter but implement a feature firestarter does not provide. ban lists.

An IP address pisses me off, makes my feel blue, whatever the reason, I add it to the ban list.

# Generated by iptables-save v1.2.11 on Mon Oct 8 04:07:20 2007
*filter
:INPUT ACCEPT [18971486:1251615142]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [41127689:57413048430]
-A INPUT -s 58.50.213.173 -j DROP
-A INPUT -s 222.213.93.92 -j DROP
-A INPUT -s 218.0.168.179 -j DROP
-A INPUT -s 211.52.78.2 -j DROP
.....
-A OUTPUT -d 220.134.178.0/255.255.255.0 -j DROP
COMMIT

Obviously this non-standard implementation is making fail2ban unhappy.

I don't understand how these name tags that fail2ban wants to use should be implemented.

I belive my configuration is not compatible with fail2ban and would like if possible to make my implementation compatible. I'm guessing a couple of simple commands and a service iptables save will do it.


fail2ban errors:

2007-10-06 17:01:09,652 ERROR: 'iptables -D INPUT -p tcp --dport http -j fail2ban-Apache
iptables -F fail2ban-Apache
iptables -X fail2ban-Apache' returned 256
2007-10-06 17:01:09,667 ERROR: 'iptables -D INPUT -p tcp --dport ssh -j fail2ban-SSH
iptables -F fail2ban-SSH
iptables -X fail2ban-SSH' returned 256
2007-10-06 17:01:09,679 ERROR: 'iptables -D INPUT -p tcp --dport ftp -j fail2ban-VSFTPD
iptables -F fail2ban-VSFTPD
iptables -X fail2ban-VSFTPD' returned 256

Who wants to earn a bunny?

SEP

[Steven E. Protter]

Interesting.

The working firewall implementation has this:

fail2ban-SSH tcp -- anywhere anywhere tcp dpt:ssh
Chain fail2ban-SSH (1 references)


Chain, thats the term I was looking for.

SEP

[Ivan Ferreira]

I'm not sure if you already fixed the problem, but can you attach the output of service iptables status?

I can't find a reference for the "256" exit code in the iptables source or man pages, maybe the chain does not exists. iptables -N could fix it.

If you use clean iptables chains for each table, fail2ban works correctly?

[Steven E. Protter]

Shalom,

Table: filter
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- 58.50.213.173 0.0.0.0/0


.... lots and lost of entries.

DROP all -- 200.162.240.141 0.0.0.0/0

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP all -- 0.0.0.0/0 206.161.120.39
DROP all -- 0.0.0.0/0 202.101.165.136

... few more.


Can you restate this question, I don't understand it. Too much Hebrew in my brain.

If you use clean iptables chains for each table, fail2ban works correctly?

What I started out with was an empty iptables configuration.

Then my scripts found some bad people and said:

iptables -A INPUT -s 1.1.1.1 -j DROP

At the end of the day we did:

service iptables save

Thats how I ended up with this.

I'm muttering about the error codes too, makes no sense. Here is what I think the codes mean.

iptables -D Delete chain ???
iptables -F iptables [-t table] -[LFZ] [chain] [options]
iptables -X Chain command (maybe I need to make the chain for fail2ban ?

I don't understand -F, also deals with chains. Problem not solved. Perplexed.

SEP

[Steven E. Protter]

Shalom,

Anybody undertand french?

http://www.dedibox-news.com/sujet-1810-fail2ban-probleme-lancement

SEP

[Steven E. Protter]

Reading the configuration file is always helpful.


# NOTE: Interpolations
#
# fwstart, as well as fwend, fwcheck, fwban, fwunban, use interpolations
# so %(__name__)s will be substituted by a name of each section
# (unless the option is overriden in a section).
# If you are going to use interpolations in your setup, please make
# sure that you specified options port and protocol (which also has
# an option in DEFAULT).



# Option: fwstart
# Notes.: command executed once at the start of Fail2Ban.
# Values: CMD Default:
#
fwstart = iptables -N fail2ban-%(__name__)s
iptables -A fail2ban-%(__name__)s -j RETURN
iptables -I INPUT -p %(protocol)s --dport %(port)s -j fail2ban-%(__name__)s

# Option: fwend
# Notes.: command executed once at the end of Fail2Ban
# Values: CMD Default:
#
fwend = iptables -D INPUT -p %(protocol)s --dport %(port)s -j fail2ban-%(__name__)s
iptables -F fail2ban-%(__name__)s
iptables -X fail2ban-%(__name__)s

Still hard to know why this is happening. Looks like the fwend sequence is failing.

SEP

[Steven E. Protter]

This thread may be a red herring.

[root@shalom1 ~]# service iptables status | grep fail2ban
fail2ban-VSFTPD tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
fail2ban-SSH tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
Chain fail2ban-Apache (0 references)
Chain fail2ban-SSH (1 references)
Chain fail2ban-VSFTPD (1 references)


Seems to be operating normally.

I didn't do anything.

Regards,

SEP

[Yogeeraj_1]

Hi SEP,

the "french" URL simply says:

try fail2ban 0.7.2

and

try to start with only SSH enabled and them open the other required services one by one...


Anyway, i am sure you have already tried these...

good luck!

kind regards
yogeeraj

[Stuart Browne]

Ah, another tool to do this! The last one I tried wasn't terribly successful, and would create new chains which had obscenely long names!

*shuffles off to take a look into it further*

[Jimmy Vance]

Most of the attacks I see are brute force against ssh. I use the these rules to block and IP address if it hits ssh 4 times within a minute

iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set
--name SSH_PROBER

iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --rche
ck --seconds 60 --hitcount 4 --name SSH_PROBER --rsource -j LOG --log-prefix "SSH_brute_force "

iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --rche
ck --seconds 60 --hitcount 4 --name SSH_PROBER -j DROP

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

[Steven E. Protter]

Jimmy, I was aware of your option.

These systems are not vulnerable to ssh attacks because they lie behind a firewall that accepts and deals with all ssh traffic. I have a few odd numbered ports forwarded to ssh but as yet in three years have yet to see a single bad login from the outside that was not a traced to myself or one of my customers.

You do remind me however that I don't need to use fail2ban at all for my vsftpd problem. vsfptd is forwarde from the firewall and attacks are frequent and involve sometimes over 100,000 login attempts. A few nice lines of firewall code would fix that and I'm going to do that tonight (afternoon us time).

I do appreciate you reinitializing my brain pathway, I've got the code sitting in an email right now.

Stuart, fail2ban is a pretty good tool, configurable and you can even have it monitor custom log files and customize the sequences it is looking for to deal with new attacks. On my firewalls it works seamlessly with firestarter and has annoyed the ssh script kiddes very nicely. I rarely see the same IP address in the fail2ban log more than once or twice. The get frustrated and go away while on timeout. I choose that last language deliberately.

SEP