DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 20th May 2008
erehwon erehwon is offline
Port Guard
 
Join Date: May 2008
Location: Cascadia
Posts: 34
Thanked 0 Times in 0 Posts
Default 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
Reply With Quote
  #2   (View Single Post)  
Old 20th May 2008
Nonesuch Nonesuch is offline
New User
 
Join Date: May 2008
Location: Chicago, IL
Posts: 6
Thanked 1 Time in 1 Post
Post

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/
Reply With Quote
  #3   (View Single Post)  
Old 20th May 2008
erehwon erehwon is offline
Port Guard
 
Join Date: May 2008
Location: Cascadia
Posts: 34
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by Nonesuch View Post
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/
Thanks. So perhaps pull in the unaggregated bogons list and have the table reference that? Seems like that could work nicely.
Reply With Quote
  #4   (View Single Post)  
Old 21st May 2008
erehwon erehwon is offline
Port Guard
 
Join Date: May 2008
Location: Cascadia
Posts: 34
Thanked 0 Times in 0 Posts
Default

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)
Reply With Quote
  #5   (View Single Post)  
Old 22nd May 2008
s2scott's Avatar
s2scott s2scott is offline
Package Pilot
 
Join Date: May 2008
Location: Toronto, Ontario Canada
Posts: 198
Thanked 9 Times in 8 Posts
Default

Post your pf.conf in whole. (Help the readers by using the # code tag.)

/S
__________________
Never argue with an idiot. They will bring you down to their level and beat you with experience.
Reply With Quote
  #6   (View Single Post)  
Old 25th May 2008
erehwon erehwon is offline
Port Guard
 
Join Date: May 2008
Location: Cascadia
Posts: 34
Thanked 0 Times in 0 Posts
Default 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
Reply With Quote
  #7   (View Single Post)  
Old 25th May 2008
robbak's Avatar
robbak robbak is offline
Real Name: Robert Backhaus
VPN Cryptographer
 
Join Date: May 2008
Location: North Queensland, Australia
Posts: 366
Thanked 40 Times in 39 Posts
Default

192.168.0/24 is on the bogon list: it is part of 192.168/16. (basic IP theory) 'block in quick from <bogons>" will drop all 192.168.*.* traffic.

You do not want the bogon filter on your internal interface, as your private netspace must be on the bogon list. That line should be "block in quick on $ext_if from <bogons>"
__________________
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:46 AM. Reason: spelling.
Reply With Quote
  #8   (View Single Post)  
Old 25th May 2008
s2scott's Avatar
s2scott s2scott is offline
Package Pilot
 
Join Date: May 2008
Location: Toronto, Ontario Canada
Posts: 198
Thanked 9 Times in 8 Posts
Default

As mentioned, change
Code:
# filters
block in all
block in quick from <abusive_hosts>
block in quick from <bogons>
to be
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.
Reply With Quote
  #9   (View Single Post)  
Old 25th May 2008
s2scott's Avatar
s2scott s2scott is offline
Package Pilot
 
Join Date: May 2008
Location: Toronto, Ontario Canada
Posts: 198
Thanked 9 Times in 8 Posts
Default

Code:
pass out all keep state
pass quick on $int_if no state
Is better written,
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.
Reply With Quote
Old 25th May 2008
s2scott's Avatar
s2scott s2scott is offline
Package Pilot
 
Join Date: May 2008
Location: Toronto, Ontario Canada
Posts: 198
Thanked 9 Times in 8 Posts
Default

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.
Reply With Quote
Old 25th May 2008
erehwon erehwon is offline
Port Guard
 
Join Date: May 2008
Location: Cascadia
Posts: 34
Thanked 0 Times in 0 Posts
Default

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?
Reply With Quote
Old 25th May 2008
robbak's Avatar
robbak robbak is offline
Real Name: Robert Backhaus
VPN Cryptographer
 
Join Date: May 2008
Location: North Queensland, Australia
Posts: 366
Thanked 40 Times in 39 Posts
Default

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.
Reply With Quote
Old 25th May 2008
erehwon erehwon is offline
Port Guard
 
Join Date: May 2008
Location: Cascadia
Posts: 34
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by robbak View Post

(What this message really says is, "Uh, What you say??")
When I adopt the rule to
Code:
block in quick on $ext_if from <bogons>
, I can no longer manage my server from within the LAN (ssh is blocked), same result as the rule without naming $ext_if.

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.
Reply With Quote
Old 25th May 2008
erehwon erehwon is offline
Port Guard
 
Join Date: May 2008
Location: Cascadia
Posts: 34
Thanked 0 Times in 0 Posts
Default

Also, I've always understood $int_if to be something only for loopback purposes, not for 'talking' to other machines, even on a LAN
Reply With Quote
Old 26th May 2008
robbak's Avatar
robbak robbak is offline
Real Name: Robert Backhaus
VPN Cryptographer
 
Join Date: May 2008
Location: North Queensland, Australia
Posts: 366
Thanked 40 Times in 39 Posts
Default

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}
             ##########################
Bogon filtering is used on the external interface to keep bogus packets out of your 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
I have no idea if that would work, but it should give you a start for troubleshooting.
__________________
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.
Reply With Quote
Old 26th May 2008
erehwon erehwon is offline
Port Guard
 
Join Date: May 2008
Location: Cascadia
Posts: 34
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by robbak View Post
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}
             ##########################
I have no idea if that would work, but it should give you a start for troubleshooting.
Thanks, my fault here though. I did not explain that PF is 'self-protecting' my server behind a router (off-the-shelf hardware not running OpenBSD). The router blocks all incoming traffic by default now except for my www ports. So in my setup, int_if is actually the loopback device only, whereas ext_if is what faces the router.

My initial worry was that any open port, even forwarded, could be a 'portal' for bogons to exploit.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 11:08 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick