- why are the lists of martians slightly different in almost every guide/tutorial?
Tutorials are meant as a guide. Following a tutorial to the letter may not fit your scenario exactly (Different paths, different options, etc.). You gotta be able to extract useful info and be able to connect it to your own setup. There's still a logical pattern that all those tutorials have in common, and yeah, it's on you to figure out how to mate that pattern to your system. Integrity of your system takes priority, BTW.
There's nothing really *wrong* with astyle's answer, but there's a little more to this, which is worth exploring a bit.
Many of the online tutorials are written by people relatively early in their journey to becoming proficient (or even experts!) in pf (or packet filtering firewalls in general).
The wide variance in the approaches to filtering martians (aka
bogons (Wikipedia: bogon filtering)) is a fascinating case study. It makes a great example because in principle *and* in practice it's relatively straightforward. This makes it a great example for learning the basics, and for *teaching* the basics, too.
Unfortunately along one particular axis, it's deceptively simple. The difference that careful observers often notice is that the *list* of martians to block is wildly variant from example to example. Even experts with years of pf firewall configuration experience will post examples that are incomplete.
How can I say with confidence that any given example is incomplete or even wrong? Let's take a closer look at the objective of the rule.
The purpose of a martians rule is to protect a network or a host from a
spoofing attack (Wikipedia), where an outside system tries to reach a host by way of forgery of the source IP address (Wikipedia:
IP address spoofing).
This type of attack can work because the networks *behind* a firewall are often mapped out in address ranges defined by the standards as *private* or sometimes in other
reserved IP address ranges (Wikipedia) which are allocated for other purposes. If you can trick the router and firewall into thinking the packet came from the inside, it stands a pretty good chance of being passed and processed by hosts on the inside.
Consider this example:
table <martians> const { 0.0.0.0/8 10.0.0.0/8 100.64.0.0/10 127.0.0.0/8 169.254.0.0/16 172.16.0.0/12 192.0.0.0/24 192.0.0.0/29 192.0.2.0/24 192.88.99.0/24 192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 203.0.113.0/24 240.0.0.0/4 255.255.255.255/32 }
This, so far as I'm able to tell, is a complete and current list of ipv4 reserved address ranges.
To start with, it's not really very easy for a beginner to make this determination of completeness. If you google your way on that, there are many highly ranked, authoritative, but incomplete (wrong) answers! Why does this happen? Because the allocations have occasionally been amended, and the amendments are, mostly, buried in an RFC that nobody has read and nobody links to and the original RFC which everybody *does* link to doesn't get updated with a big bold headline THIS IS AMENDED BY or THIS IS SUPERSEDED BY. So you can land on what *looks* like an authoritative source, and never know there exist other ranges not included.
There are two specific technical errors in this example.
1. It doesn't include reserved ipv6 ranges.
2. It does include the broadcast range (255.255.255.255/32) which I *think* would be appropriate for a gateway or border firewall, but *not* appropriate for a workstation, or host firewall. It may or may not be appropriate for a host firewall on an internet-facing web server (if it's stand-alone, probably OK, but if it's part of a cluster, probably not.)
Another thing that you'll notice is that some firewall administrators include in their martians list one or more of the several IP address ranges allocated for multicast. I'm of the opinion that this is strictly incorrect because it makes the firewall rules difficult to understand, because *some* of the IP address ranges allocated for multicast are defined in the standards as routable.
A separate rule should be used, if one wants to block multicast, for clarity, and for ease of maintenance going forward.
One last observation. Some pf experts assert that a martians rule is unnecessary or obsoleted by the pf built-in function which you can activate with a simple rule like this one:
# automatically drop spoofed packets
antispoof for $ext_if inet
I suspect the pf built-in antispoof system is more sophisticated and handles more cases than merely blocking the documented non-routable IP address ranges, but I've not looked into that. It probably blocks all of the non-routable allocations, but I haven't tested it.
I've been intrigued by this phenomenon for years, and I think a martians rule makes a great learning exercise for people new to pf or firewalls.
Thanks for humoring me in this exploration of why it's an important example of how to approach learning pf (or other packet filtering firewalls).
