Hi,
I have fail2ban up and running on my Fedora 15. root 1026 0.0 0.3 189936 6724 ? S 13:52 0:00 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -x
I use it for banning IPs that try to connect to my host via SSH. Here's below is a snip of jail.local: --- [jail.local] --- [ssh-iptables]
enabled = true filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] sendmail-whois[name=SSH, dest=sguazt, sender=fail2ban@localhost] logpath = /var/log/secure maxretry = 3 --- [/jail.local] ---
However I can't see it in the iptables status (like I could until Fedora 14). So I think it is not working properly.
Here's my iptables status:
--- [iptables status] --- Table: nat Chain PREROUTING (policy ACCEPT) num target prot opt source destination
Chain INPUT (policy ACCEPT) num target prot opt source destination
Chain OUTPUT (policy ACCEPT) num target prot opt source destination
Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 MASQUERADE tcp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 2 MASQUERADE udp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 3 MASQUERADE all -- 192.168.122.0/24 !192.168.122.0/24
Table: mangle Chain PREROUTING (policy ACCEPT) num target prot opt source destination
Chain INPUT (policy ACCEPT) num target prot opt source destination
Chain FORWARD (policy ACCEPT) num target prot opt source destination
Chain OUTPUT (policy ACCEPT) num target prot opt source destination
Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 CHECKSUM udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:68 CHECKSUM fill
Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 2 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 3 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67 4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 5 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 6 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 7 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 8 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 9 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 2 ACCEPT all -- 192.168.122.0/24 0.0.0.0/0 3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 4 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 6 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT) num target prot opt source destination --- [/iptables status] ---
Any idea?
Thank you very much!
Best,
-- Marco
On Sun, May 29, 2011 at 3:30 PM, sguazt marco.guazzone@gmail.com wrote:
Hi,
I have fail2ban up and running on my Fedora 15.
... [cut] ...
I use it for banning IPs that try to connect to my host via SSH. Here's below is a snip of jail.local:
... [cut] ...
However I can't see it in the iptables status (like I could until Fedora 14). So I think it is not working properly.
Here's my iptables status:
... [cut] ...
Any idea?
Hi, Still have problems. Under /var/log/messages I've this message:
fail2ban.comm : WARNING Invalid command: ['add', 'ssh-iptables', 'auto']
Don't know if it is related to my problem.
Anyway, I am the only one that has this problem (or that runs fail2ban ;) )?
Best,
-- Marco
On Fri, Jun 3, 2011 at 4:05 AM, sguazt marco.guazzone@gmail.com wrote:
On Sun, May 29, 2011 at 3:30 PM, sguazt marco.guazzone@gmail.com wrote:
Hi, Still have problems. Under /var/log/messages I've this message:
fail2ban.comm : WARNING Invalid command: ['add', 'ssh-iptables', 'auto']
Don't know if it is related to my problem.
Anyway, I am the only one that has this problem (or that runs fail2ban ;) )?
Hi there. Although I do not use fail2ban this sure looks like a bug. You should probably file a bug report.
If you want some protection from ssh intruders here are a couple of iptables rules you can use until the fail2ban problem is resolved.
-A local_input_filter -p tcp -m tcp --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -m recent --set --name SSH --rsource -A local_input_filter -m recent --update --seconds 40 --hitcount 3 --name SSH --rsource -j DROP
If someone tries to login to your system via ssh more than 3 times in 40 seconds any further packets will be dropped. I've been using these rules for about 5 years and they work well.
Mike
On Fri, 2011-06-03 at 09:08 -0400, Mike Williams wrote:
On Fri, Jun 3, 2011 at 4:05 AM, sguazt marco.guazzone@gmail.com wrote: On Sun, May 29, 2011 at 3:30 PM, sguazt marco.guazzone@gmail.com wrote:
Hi, Still have problems. Under /var/log/messages I've this message: fail2ban.comm : WARNING Invalid command: ['add', 'ssh-iptables', 'auto'] Don't know if it is related to my problem. Anyway, I am the only one that has this problem (or that runs fail2ban ;) )?
Yes I had this exact problem.
It's an SELinux problem. Put SELinux into permissive mode # setenforce 0 and then restart F2B. It should start up, but you'll get a bunch of SEL AVCs. From these you can build a policy and turn SEL back to Enforcing.
F2B and SEL have always caused me problems. With the help of the selinux mailing list I once tried to get to the bottom of it. Now I just give up and create a policy allowing everything that audit2allow says it needs...
Mark
On Fri, Jun 3, 2011 at 3:49 PM, Arthur Dent misc.lists@blueyonder.co.uk wrote:
On Fri, 2011-06-03 at 09:08 -0400, Mike Williams wrote:
On Fri, Jun 3, 2011 at 4:05 AM, sguazt marco.guazzone@gmail.com wrote: On Sun, May 29, 2011 at 3:30 PM, sguazt marco.guazzone@gmail.com wrote:
Hi, Still have problems. Under /var/log/messages I've this message:
fail2ban.comm : WARNING Invalid command: ['add', 'ssh-iptables', 'auto']
Don't know if it is related to my problem.
Anyway, I am the only one that has this problem (or that runs fail2ban ;) )?
Yes I had this exact problem.
It's an SELinux problem. Put SELinux into permissive mode # setenforce 0 and then restart F2B. It should start up, but you'll get a bunch of SEL AVCs. From these you can build a policy and turn SEL back to Enforcing.
F2B and SEL have always caused me problems. With the help of the selinux mailing list I once tried to get to the bottom of it. Now I just give up and create a policy allowing everything that audit2allow says it needs...
Mike and Arthur, thank you for your feedback.
Under F14, if I'm not wrong, SEL did not cause problems to fail2ban.
Arthur, I don't know how to create such a policy. Could you tell me how?
Thank you very much!
Best,
-- Marco
On Fri, 2011-06-03 at 16:25 +0200, sguazt wrote:
On Fri, Jun 3, 2011 at 3:49 PM, Arthur Dent misc.lists@blueyonder.co.uk wrote:
On Fri, 2011-06-03 at 09:08 -0400, Mike Williams wrote:
On Fri, Jun 3, 2011 at 4:05 AM, sguazt marco.guazzone@gmail.com wrote: On Sun, May 29, 2011 at 3:30 PM, sguazt marco.guazzone@gmail.com wrote:
Hi, Still have problems. Under /var/log/messages I've this message: fail2ban.comm : WARNING Invalid command: ['add', 'ssh-iptables', 'auto'] Don't know if it is related to my problem. Anyway, I am the only one that has this problem (or that runs fail2ban ;) )?Yes I had this exact problem.
It's an SELinux problem. Put SELinux into permissive mode # setenforce 0 and then restart F2B. It should start up, but you'll get a bunch of SEL AVCs. From these you can build a policy and turn SEL back to Enforcing.
F2B and SEL have always caused me problems. With the help of the selinux mailing list I once tried to get to the bottom of it. Now I just give up and create a policy allowing everything that audit2allow says it needs...
Mike and Arthur, thank you for your feedback.
Under F14, if I'm not wrong, SEL did not cause problems to fail2ban.
Arthur, I don't know how to create such a policy. Could you tell me how?
I don't know if this is the best way, but this is how I do it:
I'm assuming you have the SELinux troubleshooting tools installed (I think they are installed by default - do you get SELinux alerts?)
1) su to root # su -
2) Create a working directory # mkdir ~/selinux_testing # cd ~/selinux_testing
3) Put SEL into permissive mode # setenforce 0
4) Start F2B # service fail2ban start
5) Collect the AVC denials # grep fail2ban /var/log/audit/audit.log | audit2allow -M myf2b This will collect any AVCs related to fail2ban and create a draft policy called myf2b in your working directory. There will be several files, one of which will be called myf2b.te.
Open this with an editor: # gedit myf2b.te & and have a look at it. It will look something like this: =========8<=============================================== module myf2b 1.0;
require { type tmp_t; type tmpfs_t; type fail2ban_t; class dir { read write remove_name add_name }; class file { write getattr read create unlink open execute execute_no_trans }; }
#============= fail2ban_t ============== allow fail2ban_t tmp_t:dir { read write remove_name add_name }; allow fail2ban_t tmp_t:file { write getattr execute read create unlink open }; allow fail2ban_t tmpfs_t:dir write; =========8<===============================================
I normally edit the module number at the top and create a numbering schema that suits me (I use 15.0.1 for Fedora 15, first minor version of the policy) and save it.
6) Build the policy: # make -f /usr/share/selinux/devel/Makefile myf2b.pp Note: it *IS* .pp (not .te)
7) Install the module # semodule - myf2b.pp (Again .pp)
8) Restart F2B and see if you get any more AVCs
9) If you do, repeat steps 5,6 & 7, but this time change # grep fail2ban /var/log/audit/audit.log | audit2allow -M myf2b to something like # grep fail2ban /var/log/audit/audit.log | audit2allow -M temp
Then look at the "temp.te" file in your editor and carefully add anything that is new, to your myf2b.te file. Change the module number (I'm on version 15.0.5 at the moment! 5 Iterations). Save it an continue with step 6+
10) Rinse, repeat... (until you're happy that everything is working)
11) Put SEL back into enforcing mode # setenforce 0
Hope that helps
Mark
On Fri, Jun 3, 2011 at 4:58 PM, Arthur Dent misc.lists@blueyonder.co.uk wrote:
On Fri, 2011-06-03 at 16:25 +0200, sguazt wrote:
On Fri, Jun 3, 2011 at 3:49 PM, Arthur Dent misc.lists@blueyonder.co.uk wrote:
On Fri, 2011-06-03 at 09:08 -0400, Mike Williams wrote:
On Fri, Jun 3, 2011 at 4:05 AM, sguazt marco.guazzone@gmail.com wrote: On Sun, May 29, 2011 at 3:30 PM, sguazt marco.guazzone@gmail.com wrote:
Hi, Still have problems. Under /var/log/messages I've this message:
fail2ban.comm : WARNING Invalid command: ['add', 'ssh-iptables', 'auto']
Don't know if it is related to my problem.
Anyway, I am the only one that has this problem (or that runs fail2ban ;) )?
Yes I had this exact problem.
It's an SELinux problem. Put SELinux into permissive mode # setenforce 0 and then restart F2B. It should start up, but you'll get a bunch of SEL AVCs. From these you can build a policy and turn SEL back to Enforcing.
F2B and SEL have always caused me problems. With the help of the selinux mailing list I once tried to get to the bottom of it. Now I just give up and create a policy allowing everything that audit2allow says it needs...
Mike and Arthur, thank you for your feedback.
Under F14, if I'm not wrong, SEL did not cause problems to fail2ban.
Arthur, I don't know how to create such a policy. Could you tell me how?
I don't know if this is the best way, but this is how I do it:
I'm assuming you have the SELinux troubleshooting tools installed (I think they are installed by default - do you get SELinux alerts?)
[cut]
Hope that helps
Thank you so much!! I'll give it a try later.
Best,
-- Marco
On Fri, Jun 3, 2011 at 5:17 PM, sguazt marco.guazzone@gmail.com wrote:
On Fri, Jun 3, 2011 at 4:58 PM, Arthur Dent misc.lists@blueyonder.co.uk wrote:
On Fri, 2011-06-03 at 16:25 +0200, sguazt wrote:
On Fri, Jun 3, 2011 at 3:49 PM, Arthur Dent misc.lists@blueyonder.co.uk wrote:
On Fri, 2011-06-03 at 09:08 -0400, Mike Williams wrote:
On Fri, Jun 3, 2011 at 4:05 AM, sguazt marco.guazzone@gmail.com wrote: On Sun, May 29, 2011 at 3:30 PM, sguazt marco.guazzone@gmail.com wrote:
Hi, Still have problems. Under /var/log/messages I've this message:
fail2ban.comm : WARNING Invalid command: ['add', 'ssh-iptables', 'auto']
Don't know if it is related to my problem.
Anyway, I am the only one that has this problem (or that runs fail2ban ;) )?
Yes I had this exact problem.
It's an SELinux problem. Put SELinux into permissive mode # setenforce 0 and then restart F2B. It should start up, but you'll get a bunch of SEL AVCs. From these you can build a policy and turn SEL back to Enforcing.
F2B and SEL have always caused me problems. With the help of the selinux mailing list I once tried to get to the bottom of it. Now I just give up and create a policy allowing everything that audit2allow says it needs...
Mike and Arthur, thank you for your feedback.
Under F14, if I'm not wrong, SEL did not cause problems to fail2ban.
Arthur, I don't know how to create such a policy. Could you tell me how?
I don't know if this is the best way, but this is how I do it:
I'm assuming you have the SELinux troubleshooting tools installed (I think they are installed by default - do you get SELinux alerts?)
[cut]
Hope that helps
Thank you so much!! I'll give it a try later.
For those interested, there are two bug reports on bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=669966 https://bugzilla.redhat.com/show_bug.cgi?id=697223
Regards,
-- Marco
-
Arthur Dent -
Marco Guazzone -
Mike Williams