asif/fail2banUFW
1
0
Fork 0
Code Issues Pull Requests Releases 3 Wiki Activity

Update page '8. The UFW filter'

Asif Bacchus 2019-05-21 06:59:56 -06:00
parent 10edcf274c
commit 7a03d01d57
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
8.-The-UFW-filter.md

@ -31,7 +31,7 @@ Breaking this down, we're telling F2B to ignore anything that matches the follow
### Reasoning
For the first 3 rules, we specifying IPv4 private address spaces. Specifically those address spaces are:
For the first 3 rules, we are specifying IPv4 private address spaces. Specifically those address spaces are:
| CIDR subnet | IP address range |
| -------- | -------- |
@ -39,15 +39,15 @@ For the first 3 rules, we specifying IPv4 private address spaces. Specifically
| 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 are 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 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 alphanumbic characters since we know it's at least '*FE8*' and remember that 'FE80' could be contracted to 'FE8::'.
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 -- used by UPnp devices to advertise their existance|
|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 -- IPv4 & IPv6 name resolution on the same link|
|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. 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. Hence, the creation of this rule and the genesis of this long write-up.
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.