PF issue since 11.2-RELEASE

ASV asv at inhio.net
Fri Feb 1 09:34:06 UTC 2019


On Thu, 2019-01-31 at 22:00 +0100, Kristof Provost wrote:
> On 31 Jan 2019, at 12:11, ASV wrote:
> > Good afternoon,
> > one good news and one bad news.
> > 
> > Good news is that it was that bloody zero missing which was
> > "freaking
> > out" PF during the reload. How could I missed that? Perhaps
> > erroneously
> > removed during the upgrade somehow or it was there but not causing
> > problems?! I'll never know. But it's fixed so thank you very much
> > for
> > the good catch!
> > 
> > The bad news is that PF is still not enforcing the rules within the
> > anchors. So fail2ban keeps populating the tables where the
> > previously
> > mentioned rules are in place (reposted below) but these IPs keeps
> > bombing me with connection attempts passing the firewall with no
> > problems at all. Killing the states, reloading, restarting (PF and
> > fail2ban) doesn't fix that.
> > 
> > # pfctl -a f2b/asterisk-udp -t f2b-asterisk-udp -s rules
> > block drop quick proto udp from <f2b-asterisk-udp> to any port =
> > sip
> > block drop quick proto udp from <f2b-asterisk-udp> to any port =
> > sip-tls
> > 
> > # pfctl -a f2b/asterisk-tcp -t f2b-asterisk-tcp -s rules
> > block drop quick proto tcp from <f2b-asterisk-tcp> to any port =
> > sip
> > block drop quick proto tcp from <f2b-asterisk-tcp> to any port =
> > sip-tls
> 
> I don’t use anchors myself, but don’t you need to call them from your
> main ruleset?
Anchors are called and the blocking rule is set within:

anchor f2b {
        anchor asterisk {
                block in quick log to any
        }
}

so the resulting tables f2b-asterisk-udp and f2b-asterisk-tcp (created
by fail2ban) belonging to the anchor f2b get populated with IP
addresses by fail2ban daemon and then rules are "supposed to" be
enforced. Sorry I've realised that previously I've posted "sip" instead
of "asterisk". I'm heavily testing this stuff through different but
identical files, just some names replaced, which is probably the reason
why you thought I wasn't "calling" them.

fail2ban is supposed to do the rest which is:
- creating the tables: which sometimes works sometimes doesn't but if
you set the tables in the same ruleset at start you'll get the
following:

pfctl: warning: namespace collisions with 2 global tables.

even when these are removed from the running config and manually
reloaded!!!

- enforcing the "ban action": these are pre-set on 
/usr/local/etc/fail2ban/action.d/pf.conf

and the default one is:
actionban = <pfctl> -t <tablename>-<name> -T add <ip>

and it works, the table(s) get populated but rules are not enforced.
Sorry again for the aforementioned typo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20190201/417c9110/attachment.sig>


More information about the freebsd-questions mailing list