Table of Contents
The UFW filter (filter.d/ufw-probe.conf)
This really is the core of the entire set up, so we'll review how it works. First starting with how F2B decides to enact a ban and then looking at the ignore entry.
Address to block
When F2B is parsing ufw.log, it has to be told what entry denotes a failure and increments the retry counter toward a ban. This is done via a regular expression (REGEX):
failregex = .*\[UFW BLOCK\] IN=.* SRC=<HOST>
Specifically, this matches any line containing '[UFW BLOCK]', incoming from any host and reads the source address as the 'HOST' to block.
Address to ignore
When F2B finds an entry that matches the failregex as above, it can also be told to further look at that entry to see if it should be ignored. This is the ignoreregex. Specifically here, I have set it up to ignore LAN addresses that are communicating via multicast. Let's look at the regex first and then get into the reasoning after.
ignoreregex = SRC=(10\.|172\.1[6-9]\.|172\.2[0-9]\.|172\.3[0-1]\.|192\.168\.|fe\w*\:).* PROTO=UDP.* DPT=(1900|3702|5353|5355) LEN=\d*\s\s$
Breaking this down, we're telling F2B to ignore anything that matches the following conditions in an otherwise blockable event:
- Source address starts with '10.' OR
- Source address starts with anything in the range '172.16-31.' OR
- Source address starts with '192.168.' OR
- Source address starts with 'fe??:'; AND
- Packet is UDP; AND
- Packet has been received on any of ports 1900, 3702, 5353 or 5355
Reasoning
For the first 3 rules, we are specifying IPv4 private address spaces. Specifically those address spaces are:
| CIDR subnet | IP address range |
|---|---|
| 10.0.0.0/8 | 10.0.0.0 - 10.255.255.255 |
| 172.16.0.0/12 | 172.16.0.0 - 172.31.255.255 |
| 192.168.0.0/16 | 192.168.0.0 - 192.168.255.255 |
The fourth rule is a little trickier since it takes into account the RFC specs and not just common practice. IPv6 link-local addresses nearly always start with FE80 but the rules state that the actual subnet is FE80::/10. That 10 makes this tricky because it maps over the last four bits of the first octet (last two characters). Therefore the actual range is FE80:: - FEBF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF. This means that the only thing we can check in a regex and be sure it's correct is the first two characters, in this case 'FE' since that will always be included. In this case, we check for 'FE' followed by 1 or more alphanumeric characters since we know it's at least 'FE8' and remember that 'FE80' could be contracted to 'FE8::'.
What about the ports? Here's where the overall reasoning of this entire exclusion comes into play. In a typical home/SOHO LAN setup, there is a lot of cross-talk between systems that ends up getting machines banned by Fail2Ban. Most of this traffic is multicast traffic for things like DLNA devices, Chromecasts or really any UPnP devices. Home routers are notorious for this as are media centers and even all installations of Google Chrome (yes, your browser!) since it checks every few minutes for any Chromecasts on the network. In addition, many people have WSD capable printers which also advertise. Finally, anyone running Windows Vista or later machines is nearly 100% using IPv6 at least on the machine itself and that results in link-local multicast name resolution packets being sent out. Here's a list of the ports I have just talked about
| Port | IANA registered function |
|---|---|
| 1900 | Simple Service Discovery Protocol (SSDP) -- used by UPnp devices to advertise their existance |
| 3702 | Web Services for Devices (WSD) -- used to advertise and coordinate activities |
| 5353 | Multicast Domain Name Service (mDNS) -- name resolution without a formal DNS server |
| 5355 | Link-Local Multicast Name Resolution (LLMNR) -- IPv4 & IPv6 name resolution on the same link |
So what does this all mean? Virtually all LAN devices send these packets out to check if clients want to access services they offer or if they could be using services other systems are offering. Also, just to check out the names of systems they might need to contact at some point. However, when these packets hit a UFW protected system, it generates a [UFW BLOCK] and then our F2B filter thinks this is a bannable offence. The result? Our LAN machines get banned. The typical reaction, 'ignore the LAN address range'. However, that is an overreaction and it's better to just ignore this normal, innocuous multicast traffic instead. If we just ignore the entire LAN subnet, then actual malicious port-probing from a compromised machine would not get blocked. Hence, the creation of this rule and the genesis of this long write-up. I'm sure you've figured this out, but we go through the trouble of checking that the source is on the LAN so that we can still ban internet machines that are tying to use/spoof traffic on these ports.