Two quick PF questions (table/macro related)

First off, I'm adding a rule to pf for bogon filtering, and came across something I wanted to get a bit of clarification on.

I have a monthly cron set to fetch this and save it as bogon.conf in /etc, I have a pf rule
Code:
table <bogon> const file "/etc/bogon.conf"
in place for that, and then the blocking rule
Code:
block in quick on $ext_if from <bogon> to any

Thus far that works fine, but when I was checking the documentation for the syntax to use a file list in a table, I ran across this:

http://www.openbsd.org/faq/pf/tables.html said:
Specifying Addresses

<snip>

One limitation when specifying addresses is that 0.0.0.0/0 and 0/0 will not work in tables. The alternative is to hard code that address or use a macro.

So my question there is do I need a macro to block those addresses on the external interface? Something like:

Code:
nil = "{ 0.0.0.0/8 }"

with the respective blocking rules, or not? Also $ext_if is a dhcp interface, and if I recall dhcp lease communications initially originate with a IP of 0.0.0.0, so I would have to open up a hole for dhcp communications correct?



That was the first question, the second is easier. I read somewhere a while back, and cannot find it again, but I recall something about using ($ext_if) in rules with a dhcp external interface, that way rules always refer to the correct interface/IPs, in case the lease info (IP) changes. Is there any truth to that?


Thanks, hope that was clear. :)
 
1a. the bogon list has 0.0.0.0/7 (i.e. 0/8 and 1/8), which will work just fine - you just cannot use /0 (or 'every conceivable IPv4 IP address'). BTW, I use Spamhaus' bogons list, which is much more fine-grained and very up-to-date (http://www.spamhaus.org/drop/drop.lasso). Note that if you automate the retrieval of a bogons list to a file, you will need to reload pf to use the updated file. You'd normally do that from cron. I'm using this simple script called bogons-update (called once a day from cron)

Code:
#!/bin/sh

/usr/bin/fetch -o /tmp/bogons.txt http://www.spamhaus.org/drop/drop.lasso
/usr/bin/sed 's|;|#|g' /tmp/bogons.txt | /usr/bin/awk '{print $1}' > /etc/spamhaus.bogons
/sbin/pfctl -Tl -f /etc/pf.conf
/bin/rm -f /tmp/bogons.txt

It gets called by pf.conf like this:
Code:
table <bogons> persist file "/etc/spamhaus.bogons"
1b. for DHCP you can open up a relatively harmless little hole. Place these rules above your blocking rules. BTW, Spamhaus does not block that 0/7 network, so your DHCP wouldn't be affected.

Code:
pass quick on $ext_if inet proto tcp from any port 67:68 to any port 67:68 keep state flags S/SA
pass quick on $ext_if inet proto udp from any port 67:68 to any port 67:68 keep state

Note: Cymru and Spamhaus have very different definitions of bogons. What Cymru refers to as bogons others would call RFC1918 space plus not-yet-allocated IP space. What Spamhaus calls bogons are hijacked pieces of IP space (stolen by spammers who are trying to re-route neglected IP blocks, usually by using social engineering and tricking upstream ISPs). You can use both, of course. In my opinion Spamhaus bogons pose a much greater danger than Cymru's unrouted IP space which should (and probably would) be dropped by any egress filter on any router in between.

2. Yes, ($ext_if) will make pf 'poll' that interface for IP changes and adjust accordingly.
 
Vivek, thanks. I overlooked the possibility of reloading only the tables. So I'll use that.
 
Back
Top