fail2ban / iptables problem

[RandomUsername]

A couple of months ago I installed and configured fail2ban. It was been working fine until I had to shutdown my server B3 last week. Since then, it appears that, whilst fail2ban-server is running and logs bans etc, it stops updating iptables after about 15 minutes. I've found a couple of bug reports that might explain this but I've installed the latest deb in which these bugs should have been fixed. Also, there is nothing in the fail2ban logs that might suggest what is happening.

My current theory is that something might be re-loading the Bubba's default iptables rules on a regular basis (perhaps a cron job) but I can't find anything. I know Excito have done something funky with regards to saving iptables rules on shutdown but is anyone aware of anything else that might explain my problem?

For example, these are my iptables chains when first starting fail2ban with just the default ssh jail enabled:

Code: Select all

Chain INPUT (policy DROP)
target     prot opt source               destination
fail2ban-ssh  tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 22
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x12/0x12 state NEW reject-with tcp-reset
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 11
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 3 code 4
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:143
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:993
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpts:10000:14000
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:25
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:666

Chain FORWARD (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 3 code 4

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain fail2ban-ssh (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

And this is them a few minutes after (note the missing fail2ban-ssh chain at the end):

Code: Select all

Chain INPUT (policy DROP)
target     prot opt source               destination
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x12/0x12 state NEW reject-with tcp-reset
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 11
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 3 code 4
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:143
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:993
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpts:10000:14000
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:25
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:666

Chain FORWARD (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 3 code 4

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

TIA.

[RandomUsername]

OK, found it - http://forum.excito.net/viewtopic.php?f ... ables+dhcp

The problem is not per se because I shutdown my server, it is because of the reason I shut down the server which was I got a new internet connection. Previously, the Bubba had a static IP address on the WAN as it was behind an ADSL modem/router. Now the WAN port has my public, dynamic IP assigned as it's plugged straight into a modem/bridge type device. Doesn't seem to be a fix in that thread though

[RandomUsername]

Triple post - I'm a bad boy.

So I'm thinking that adding

Code: Select all

/sbin/iptables-save > /etc/network/firewall.conf

before the sed command in the firewall_rewrite script should resolve this. I'd be grateful for any thoughts though.

[Gordon]

If you don't have any rules that contain your eth0 IP address, then the sed command does nothing and there is no point in restarting the firewall. Personally I think what you're proposing can be very dangerous - if you make just the slightest mistake in your firewall config it will no longer take a simple reboot to recover from it.

As far as a solution goes the first step will have to be to change that script. I say get rid of the iptables-restore line. If you think you'll ever need such rules (which would be about forwarding traffic from the outside to a specific internal server - aka DNAT-ing) my advise is to put them in a user chain - rather than having the IP number in all the rules just let the first rule in that chain use that IP address to control if a packet should be allowed to process the DNAT rules in that chain.

[RandomUsername]

Personally I think what you're proposing can be very dangerous - if you make just the slightest mistake in your firewall config it will no longer take a simple reboot to recover from it.

Noted. However, I'm don't (and don't intend to) manually edit any iptables rules. The only things I use to edit them are the B3 web interface and fail2ban. Of course, it's always possible that one or the other could go haywire and cause a problem.

As far as a solution goes the first step will have to be to change that script. I say get rid of the iptables-restore line. If you think you'll ever need such rules (which would be about forwarding traffic from the outside to a specific internal server - aka DNAT-ing) my advise is to put them in a user chain - rather than having the IP number in all the rules just let the first rule in that chain use that IP address to control if a packet should be allowed to process the DNAT rules in that chain.

I don't do any DNAT-ing at the moment, but that's not to say I won't in the future but for the moment it's probably safe for me to disable that script. I just hope I remember to enable it again in the future if I do start to use DNAT.

[Gordon]

There's an extension to this. The point being that for simple DNAT rules for inbound traffic you will also not need to specify your public IP in the rule. These rules would only be required for outbound traffic that needs to become inbound traffic. This is a very specific configuration that I doubt many B3 users will ever use, if even one.

[RandomUsername]

Could someone who understands this stuff better than me tell me if removing the firewall-rewrite rule is likely to cause me problems with connecting to my work VPN?

Experience suggests it does in that I've had problems connecting for a couple of weeks (sometimes it would, sometimes it wouldn't, sometimes I'd get kicked off after a few minutes). I've just put this rule back in and it connected first time.

[Gordon]

I guess that would depend on your type of VPN. Some of these create a new virtual interface and that will require you to redefine the rules for that specific interface if traffic along this is not included in generic rules. There's one specific issue in this case that I can think of and that is that Excito didn't include DHCP traffic in the standard rules of the firewall (UDP 67:68), so it is very possible that your problem is the result of not getting a (valid) IP on your VPN interface.

[RandomUsername]

That sounds logical. It's a standard PPTP VPN that connects to a Watchguard Firebox. It does connect using a virtual interface (PPTP WAN mini port) so what you say makes sense.

Thanks.