onefang wrote:
> I've been using shorewall and fail2ban for a while now, but nftables is
> soon replacing iptables, so it's time to consider some options.
Fortunately through the current today's Unstable there is no problem
with the use of iptables. But I have also been wondering what I am
going to do for a firewall when at some inevitable point I must switch
from using Shorewall to something different.
> My main problem with fail2ban is that it fails to ban. Or rather it does
> ban, for that one rule I wrote myself, but not for any of the built in
> rules, but then it releases the ban, even though I have told shorewall to
> ban that particular IP. So the IP ends up being unbanned, coz fail2ban
> says so.
By default fail2ban's packaging only enables one sshd rule. All of
the others are disabled by default unless they are explicitly enabled.
Here is a look on a test system with everything just now freshly
installed.
root@turmoil:~# fail2ban-client status
Status
|- Number of jail: 1
`- Jail list: sshd
My Internet connected systems have more enabled but I only have
enabled other local rules that I have written myself.
> Right now there's a particular IP hitting that one rule, and no matter
> what I do, even completely zapping fail2ban's database and leaving it
> turned off, that IP keeps bypassing my firewall somehow.
I think something different must be happening because this doesn't
match with the way shorewall and fail2ban work with each other.
For example with both installed and active there might be the
following set of iptables rules. I set up a victim system so that I
could work through a test case.
iptables -nL | less
...
Chain INPUT (policy DROP)
target prot opt source destination
f2b-sshd tcp -- 0.0.0.0/00.0.0.0/0multiport
dports 22
net-fw all -- 0.0.0.0/00.0.0.0/0
ACCEPT all -- 0.0.0.0/00.0.0.0/0
DROP all -- 0.0.0.0/00.0.0.0/0ADDRTYPE
match dst-type BROADCAST
DROP all -- 0.0.0.0/00.0.0.0/0ADDRTYPE
match dst-type ANYCAST
DROP all -- 0.0.0.0/00.0.0.0/0ADDRTYPE
match dst-type MULTICAST
LOGall -- 0.0.0.0/00.0.0.0/0limit: up to
1/sec burst 10 mode srcip LOG flags 0 level 6 prefix "INPUT REJECT "
reject all -- 0.0.0.0/00.0.0.0/0 [goto]
Chain f2b-sshd (1 references)
target prot opt source destination
REJECT all -- 192.168.230.120 0.0.0.0/0reject-with
icmp-port-unreachable
RETURN all -- 0.0.0.0/00.0.0.0/0
Chain net-fw (1 references)
target prot opt source destination
dynamicall -- 0.0.0.0/00.0.0.0/0ctstate
INVALID,NEW,UNTRACKED
tcpflags tcp -- 0.0.0.0/00.0.0.0/0
ACCEPT all -- 0.0.0.0/00.0.0.0/0ctstate
RELATED,ESTABLISHED
ACCEPT icmp -- 0.0.0.0/00.0.0.0/0icmptype 8
ACCEPT icmp -- 0.0.0.0/00.0.0.0/0icmptype 11
ACCEPT tcp -- 0.0.0.0/00.0.0.0/0multiport
dports 22,80,443
ACCEPT udp -- 0.0.0.0/00.0.0.0/0udp dpt:123
DROP all -- 192.168.93.370.0.0.0/0
DROP all -- 0.0.0.0/00.0.0.0/0ADDRTYPE
match dst-type BROADCAST
DROP all -- 0.0.0.0/00.0.0.0/0ADDRTYPE
match dst-type ANYCAST
DROP all -- 0.0.0.0/00.0.0.0/0ADDRTYPE
match dst-type MULTICAST
LOGall -- 0.0.0.0/00.0.0.0/0limit: up to
1/sec burst 10 mode srcip LOG flags 0 level 6 prefix "net-fw DROP "
DROP all -- 0.0.0.0/00.0.0.0/0
In the above I intentionally triggered a fail2ban too many auth
failures for sshd so that there would be a f2b-sshd chain created.
Packets enter the INPUT chain. For all port 22 ssh packets they
proceed down the "f2b-sshd" fail2ban sshd rule chain. That chain has
the one IP that I explicitly triggered. Packets in that chain
matching the banned IP address are then rejected. Otherwise it falls
through to the return and continues processing down the INPUT chain.
The next chain is "net-fw" which came from my Shorewall rules file.
that chain shows a minimal set of rules to allow other ports. I added
a drop rule for IP address 192.168.93.37. It would get dropped there.
When the ban expires that IP address will be removed from the f2b-sshd
chain. That chain being empty will return immediately to continue
processing the INPUT rule chain. Which will then process through the
Shorewall definied net-fw chain hitting the expli
