The default firewall is as good as a firewall can be (for the general use case): it does not protect you against everything, but it protects you against everything that a firewall is supposed to protect.
What would BCP38 do for you?
You're not initiating traffic on multiple IPs and/or from multiple subnets (are you?). This is something an ISP or a customer with a BGP connection would use. BCP38 specifies blocking OUTBOUND IPs based on invalid source addresses. It would be implemented as an:
- output DROP; or
- forward DROP - for
any IPs != <issued_subnet>
I think the phrase you mean to use is "blocking bogon addresses."
- http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt
- https://en.wikipedia.org/wiki/Bogon_filtering
- https://tools.ietf.org/html/bcp38
# in /etc/rc.local
#######################BOGON FILTER ########################
ipset create bogons hash:net
# BOGON LIST
# SEE http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt
ipset -A bogons 0.0.0.0/8
ipset -A bogons 10.0.0.0/8
ipset -A bogons 100.64.0.0/10
ipset -A bogons 127.0.0.0/8
ipset -A bogons 169.254.0.0/16
ipset -A bogons 172.16.0.0/12
ipset -A bogons 192.0.0.0/24
ipset -A bogons 192.0.2.0/24
ipset -A bogons 192.168.0.0/16
ipset -A bogons 198.18.0.0/15
ipset -A bogons 198.51.100.0/24
ipset -A bogons 203.0.113.0/24
ipset -A bogons 224.0.0.0/4
ipset -A bogons 240.0.0.0/4
# in /etc/config/firewall
config rule
option name 'Drop-Bogons_In_WAN'
option family 'ipv4'
option proto 'all'
option src 'wan'
option extra '-m set --match-set bogons src'
option target 'DROP'
(There are some trolls who visit this forum - who like to use bogons as valid IPs. So I'll simply note here - for anyone who inquires, to refer to the links above for more information as to why those subnets are listed and considered bogons.)
1 Like
It will give you the warm feeling that your network will in all likelihood not participate in DOS attacks the spoof the sending address; if all "leaf" networks would do that spoofing as an attack technique would be pretty much dead. So will it help to make your network safer immediately or directly? No, but it will contribute to making the internet a safer place for a very small cost in CPU cycles.
Perhaps my point was missed. ISPs are supposed to implement this at the border to their AS.
If a customer endpoint was able to perform a BCP38 spoofing, then I would suggest there's a larger issue with the ISP. I only know of BGP customers able to spoof such packets. They, and those issued tunnels with public subnets, should definitely consider such filtering, if their upstream device does not do so.
E.G. - I am issued a /24 from AMPRNet, it is advised to use BCP38 filtering on our borders not to leak RFC1918 traffic to the Global Internet router.
2 Likes
@root-r If your question is answered, please consider marking this topic as [Solved]. (Click the pencil behind the topic...)
bogon egress... and ingress would serve the distribution well out of the box....
or at the very least.... a built in checkbox for it... with or without ipsets.
nice improvement. too much rubbish on the access segment... at least down under...... HFC "optimisations" leave many exposed ......
So, what if your upstream WAN network has a RFC1918 or CGN IP address?
That could be a dangerous checkbox for n00bs.
1 Like
It seems like it'd be harmless to have this edited set of bogons:
ipset -A bogons 0.0.0.0/8
ipset -A bogons 127.0.0.0/8
ipset -A bogons 169.254.0.0/16
ipset -A bogons 172.16.0.0/12
ipset -A bogons 192.0.0.0/24
ipset -A bogons 192.0.2.0/24
ipset -A bogons 192.88.99.0/24
ipset -A bogons 198.18.0.0/15
ipset -A bogons 198.51.100.0/24
ipset -A bogons 203.0.113.0/24
ipset -A bogons 224.0.0.0/4
ipset -A bogons 240.0.0.0/4
ipset -A bogons 255.255.255.255/32
coming from or going to anything in the WAN zone.
(based on https://en.wikipedia.org/wiki/Reserved_IP_addresses and removing CGNAT and private network address spaces such as 10.0.0.0/32 which are sometimes used in ISP deployments)
we could do it without ipsets, but ipsets are probably the best way. could name it "wanbogons" rather than just bogons
1 Like
This scares me, what does an edited bogon list do?
- You still have autoconfigured addresses listed.
- Multicast is listed, you cannot use that for a DST filter, as it's valid
To be clear, bogons are IPs that have no valid use as a SOURCE IP on the Global Interent.
Therefore, a bogon list works as intended - on a WAN port that has a public IP address, in that zone, ALL-SRC_IPs != bogon.
1 Like
Yes you're right the bogon src and bogon dst addresses are a separate set.
In fact, on WAN a good rule would be to never let a packet leave the WAN interface that isn't from an IP address we use (either our WAN address if we're masquerading, or WAN + LAN networks if we're not). But more than that, it should also not output DST addresses to places like 127.0.0.0/8 and other bogons like that. Sure an ISP should drop those, but there are reasons to also not send to them at all.
It's a complicated topic though. ideally you'd set up several ipsets and then have several checkboxes, hidden behind an "advanced config" reveal tab in LUCI, and with a sensible set of defaults.
The goal would be to make it harder to attack routers by hijacking reserved addresses for botnet command and control for example.
1 Like
Yeah, loosly used "bogon" to mean "non-legitimate-wan" addresses.
Additionally ( in the same "zone" ) and half at what I was getting at....
The automajic wan route;
1xx.1xx.76.0/22 dev eth0.2 scope link src 1xx.1xx.78.18
Not so happy with the ISP on that one....... Tick that box and it becomes /32 like it should be....
the "wan_no-non-public_no-non-gw-route_no-not-mypublicip".... that's exactly what I need..........hmmmmm......
The linux kernel is good at isolating the 127.0.0.0/8 IP space I think. You can't even DNAT/SNAT to/from 127.0.0.0/8.
As long as there are instructions for how a user can access the management interface of their modem from the OpenWrt box. Those interfaces, even when in bridge/transparent mode, are often on a 192.168.x.0/24
2 Likes
Many OpenWrt users are also forced (or at least feel forced) to use their OpenWrt router behind an ISP branded router (VoIP, etc.) in a router cascade, which will require the use of RFC1918 addresses on WAN.
2 Likes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.