:: Re: [DNG] nftables firewall and fai…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Bob Proulx
Fecha:  
A: dng
Asunto: Re: [DNG] nftables firewall and fail2ban replacement.
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/0            0.0.0.0/0            multiport dports 22
    net-fw     all  --  0.0.0.0/0            0.0.0.0/0           
    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
    DROP       all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type BROADCAST
    DROP       all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type ANYCAST
    DROP       all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type MULTICAST
    LOG        all  --  0.0.0.0/0            0.0.0.0/0            limit: up to 1/sec burst 10 mode srcip LOG flags 0 level 6 prefix "INPUT REJECT "
    reject     all  --  0.0.0.0/0            0.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/0            reject-with icmp-port-unreachable
    RETURN     all  --  0.0.0.0/0            0.0.0.0/0           


    Chain net-fw (1 references)
    target     prot opt source               destination         
    dynamic    all  --  0.0.0.0/0            0.0.0.0/0            ctstate INVALID,NEW,UNTRACKED
    tcpflags   tcp  --  0.0.0.0/0            0.0.0.0/0           
    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 8
    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 11
    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22,80,443
    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:123
    DROP       all  --  192.168.93.37        0.0.0.0/0
    DROP       all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type BROADCAST
    DROP       all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type ANYCAST
    DROP       all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type MULTICAST
    LOG        all  --  0.0.0.0/0            0.0.0.0/0            limit: up to 1/sec burst 10 mode srcip LOG flags 0 level 6 prefix "net-fw DROP "
    DROP       all  --  0.0.0.0/0            0.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 explicit drop I added
there.

Hopefully that helps to make some sense of things.

> So I'll eventually need a replacement for shorewall anyway, and I'd like
> something similar to fail2ban that doesn't fail to ban. So the two
> replacements have to get along with each other. None of this "bad IP can
> get through coz the two fight over it" bullshit.
>
> This has to run on my servers and desktop, so no GUI. I'm an experienced
> sysadmin, text config is good.
>
> Any suggestions?


I am not really happy with any of the programs I have looked at
either.

Ubuntu really pushes ufw but it feels too complicated to me. (Joking
because it is supposed to be the Uncomplicated Firewall.) But I don't
like that one shapes ufw in bits and pieces like crafting clay on a
pottery table. I would much rather have a file with the rules (or at
least most of them) in one place that then could get version
controlled and copied around. ufw does maintain files behind the
scenes though so perhaps one could hack at those files directly and
avoid the command line interface.

Bob