|
|||
PF: non-routables
Has anyone successfully incorporated a ban on non-routable addresses in their pf.conf, behind a LAN?
This list would go into the macros section, I assume. http://home.nuug.no/~peter/pf/en/unrouteables.html |
|
|||
Yes.
You want to do this with a table, not a macro. While it is "safe" to have a static table of just RFC-1918 space, if you want to blackhole the entire "bogon" network space, more care is needed, as ARIN will occasionally allocate addresses out of historically invalid address ranges. One way to play it safe is to use a cron job to automatically download the updated 'bogon' list and populate a table. A better explanation, along with links to the bogon lists, can be found here: http://www.team-cymru.org/Services/Bogons/ |
|
|||
Quote:
|
|
|||
I've set up a table containing bogons. However, I can no longer use ssh to access the server.
My LAN is configured for a 192.168.0.0/24 range, which is not on the bogon list. I thought pf would filter by subnet with the 192.168.0.0/16 range being listed. (I have a pass quick rule to allow in 192.168.0.0/24) |
|
|||
conf help
Code:
# macros ext_if="fxp0" int_if="lo0" router="192.168.1.1" # tables table <lan> { 192.168.1.1/24 } table <abusive_hosts> persist table <bogons> persist file "/home/jon/bogon-bn-nonagg.txt" # options set block-policy drop set loginterface $ext_if set skip on lo # scrub scrub in all # queuing # translation # filters block in all block in quick from <abusive_hosts> block in quick from <bogons> pass out all keep state pass quick on $int_if no state antispoof quick for { lo $int_if } antispoof for $ext_if # internal [lan] pass quick on $ext_if proto { tcp icmp } from <lan> to any pass quick on $ext_if proto { tcp udp } from $router to any # external [web] once up |
|
||||
As mentioned, change
Code:
# filters block in all block in quick from <abusive_hosts> block in quick from <bogons> Code:
# filters block in all block in quick on $ext_if from <abusive_hosts> block in quick on $ext_if from <bogons>
__________________
Never argue with an idiot. They will bring you down to their level and beat you with experience. |
|
||||
Code:
pass out all keep state pass quick on $int_if no state Code:
pass in log quick on $int_if inet \ from ($int_if:network) to any \ tag OKPKTS keep state # pass out log quick on $ext_if inet \ tagged OKPKTS keep state
__________________
Never argue with an idiot. They will bring you down to their level and beat you with experience. Last edited by s2scott; 25th May 2008 at 04:40 AM. |
|
||||
Worth considering,
Code:
pass in log quick on $ext_if inet \ from !<bogons> to ($ext_if:0) \ tag OKOUTSIDE2INSIDE keep state # pass out log quick on $int_if inet \ tagged OKOUTSIDE2INSIDE keep state
__________________
Never argue with an idiot. They will bring you down to their level and beat you with experience. |
|
|||
Thanks, but I'm a bit confused by $ext_if here; doesn't my internal LAN need access to this? If I block 192.168.*.*, what use is blocking bogons if I need a LAN?
|
|
||||
Sorry, which message are you replying to?
There are two places where a bogon list is usefull. First, you want to drop all packets arriving at your network stating bogus source addresses. Secondly, you might like to drop packets that state bogus source addresses, produced by missconfigured hosts on your network, or by a failure of NAT. The first is done by the simple rules that I stated above. the second would be a similar rule (block quick out on $ext_if from <bogons> The other, more compex rules are interesting - They verify that the packets are good, and then flag them so they quickly pass on the way out of the internal interface. Edit: the reason for specifying the external interface is that the local, private network needs to contact the server, and the private netspaces are on the bogon lists. There are ways to block bogons on the internal interface (Use a rule to flag valid local packets, then add an exception to your bogon filter), but it is not really worth it. (What this message really says is, "Uh, What you say??")
__________________
The only dumb question is a question not asked. The only dumb answer is an answer not given. Last edited by robbak; 25th May 2008 at 08:58 AM. |
|
|||
When I adopt the rule to
Code:
block in quick on $ext_if from <bogons> So, what I'd like is the protection of banning bogons from the outside internet, but leave my server free for ssh internally on the LAN (because I don't have a console) -- I don't want to remove the 192.168.*.* entry as any kind of 'fix', but I'm stumped here. |
|
|||
Also, I've always understood $int_if to be something only for loopback purposes, not for 'talking' to other machines, even on a LAN
|
|
||||
Oh, I didn't see that you had misnamed int_if and ext_if.
these macros are used for routers: int_if is for the internal facing interface, and ext_if is the external interface. Like this: Code:
########################## Internet-----#ext_if Router int_if#-------{Internal Network} ########################## One wonders why bogon filtering is needed on a box that has no direct connection - this should be done on your router - but, if you do, then you will, of course, need an exception for your local networks. I don't do enough of this to feel confident about writing out a ruleset, but, first, use $loopback (or just lo0 - everyone knows what the loopback is) for the loopback, and anything other than ext_if for the other interface, so you don't confuse us. Something like Code:
local=192.168.1.1/24 pass on $interface from $local tag LOCAL block quick on $interface from <bogons> not tagged LOCAL
__________________
The only dumb question is a question not asked. The only dumb answer is an answer not given. Last edited by robbak; 26th May 2008 at 01:17 AM. |
|
|||
Quote:
My initial worry was that any open port, even forwarded, could be a 'portal' for bogons to exploit. |
|
|