0

We're hoping to make use of IPSet to manage temporary IP blocking from sources (CSF+LFD, fail2ban, wherever relevant). The purpose would be that routers using Shorewall at the edges would make use of these to block traffic from malicious remotes temporary. Nothing out of the ordinary.

Our routers are running Shorewall 5.2.3.4 and IPSet 7.10 (protocol version 7).

Shorewall is referencing IPSet lists "blocklist" and "blocklist6" via Shorewall's "blrules" for IPv4 and IPv6 listings respectively:

#ACTION     SOURCE      DEST    PROTO   DPORT
DROP:info   all:+blocklist  all
DROP:info   net:+blocklist  $FW
#ACTION     SOURCE      DEST    PROTO   DPORT
DROP:info   all:+blocklist6 all
DROP:info   net:+blocklist6 $FW

The IPSets were created as "hash:net" type:

create blocklist hash:net comment family inet hashsize 1024 maxelem 65536
create blocklist6 hash:net comment family inet6 hashsize 1024 maxelem 65536

However if an IP address is added to "blocklist" or "blocklist6", for example "93.184.216.34" and for "example.com" it's still pingable and HTTPS accessible both by the router itself and nodes behind it:

$ ipset add blocklist $(dig +short example.com A) comment "Testing block for example.com."
$ ping $(dig +short example.com A)
PING 93.184.216.34 (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=55 time=79.2 ms
$ ipset add blocklist6 $(dig +short example.com AAAA) comment "Testing block for example.com."
$ ping $(dig +short example.com AAAA)
PING 2606:2800:220:1:248:1893:25c8:1946(2606:2800:220:1:248:1893:25c8:1946) 56 data bytes
64 bytes from 2606:2800:220:1:248:1893:25c8:1946: icmp_seq=1 ttl=55 time=83.1 ms

To test this further I've added the following to Shorewall's "rules":

#ACTION     SOURCE  DEST                PROTO   DPORT

# Block listed
DROP        all:+blocklist  all
DROP        net:+blocklist  $FW
#ACTION     SOURCE  DEST                        PROTO   DPORT

# Block listed
DROP        all:+blocklist6 all
DROP        net:+blocklist6 $FW

Cleared, updated, and restarted both Shorewall IPv4 & IPv6, still contactable.

Shorewall's configuration has the following options set that appear to be relevant:

BLACKLIST="NEW,INVALID,UNTRACKED"
BLACKLIST_DEFAULT="Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
BLACKLIST_DISPOSITION=DROP
DYNAMIC_BLACKLIST=Yes
IPSET_WARNINGS=Yes
SAVE_IPSETS=Yes

What have we missed to get this working? The expectation would be that any traffic to/from IP addresses (or CIDRs) listed is dropped.

Thanks, Adam

Adambean
  • 156
  • 1
  • 1
  • 9

1 Answers1

1

Your configuration snippets contain only the "from" rules, so the IPSets currently have effect only on the incoming connections. If you want to block outgoing packets as well, you need to include a line in your config where the IPSet is a target, like this:

DROP  all  all:+blocklist
Lacek
  • 6,585
  • 22
  • 28
  • Thank you for your response. Very interesting. I'll try this out and inspect syslog again in a few hours time to see how many drops are being mandated. If this works I would question what the purpose of "blrules" is at all. – Adambean Jun 13 '22 at 22:00
  • Forgot about this until today... I can safely say that it's been working though. What a strange design, `blrules` seems to do nothing at all. – Adambean Jun 27 '22 at 19:05