DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 12th August 2012
nekoneko nekoneko is offline
New User
 
Join Date: Aug 2012
Posts: 3
Thanked 0 Times in 0 Posts
Default Configuring PF for NAT

I'm trying to set up pf on OpenBSD 5.1 to act as a router, but am having some trouble.

I have two network interfaces:
- urtw0 (internet)
- em0 (trusted internal network)

I want to route all traffic from the em0 network to the internet, and allow SSH connections from em0 to sshd on the OpenBSD box. All other ports should be closed.

My pf.conf looks like this:

block in
pass out on egress from em0:network to any nat-to (egress)
pass in on em0 proto tcp to self port 22

... But with these rules, I can't get to the internet from em0. If I change the last rule in pf.conf to:

pass in on em0

...then it works fine. I don't know much about pf (I'm more of an iptables person), but it looks like I need to actually open the ports I want to route. I don't want to open all ports on em0 - I only want port 22 to be open.

How can I do this?

Thanks!
Reply With Quote
  #2   (View Single Post)  
Old 12th August 2012
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,116
Thanked 182 Times in 149 Posts
Default

This is the pf.conf I am using on my OpenBSD firewall.Although it does not match your specifications exactly , it will give you a start.

Code:
# pf.conf for UPC

services = "{ imaps, pop3, pop3s, domain, submission, www, cddb, 8080, https, \
              whois, ssh, telnet, rsync, ftp, 5999, 6667, 1022, 5050 }"

set skip on lo0

# ---- external/egress interface
match out inet from ! egress to any  nat-to (egress)

# --- anchor for misc purposes, like temporarily allowing outgoing ftp from firewall itself
anchor 'TMP'

# --- allow outgoing TCP 
pass out quick     on egress inet proto tcp from any to any port $services label "$nr:$proto:$dstport"
pass out quick log on egress inet proto tcp from any to any port smtp      label "$nr:$proto:SMTP"

# --- ftp-proxy tags the ftp data connection packets. See /etc/rc.conf.local
# 
pass out quick     on egress inet tagged FTP_DATA                          label "$nr:$proto:FTP_DATA"

# --- allow outgoing UDP 
pass out quick on egress inet proto udp from any to any port domain keep state label "$nr:$proto:DOMAIN"
pass out quick on egress inet proto udp from any to any port ntp    keep state label "$nr:$proto:NTP"

# --- allow outgoing ICMP
#  ping and 'traceroute -P icmp' 
pass out quick on egress inet proto icmp from any to any icmp-type echoreq keep state label "$nr:$proto:ICMP"

# ---- internal network interface
anchor "ftp-proxy/*"
pass in quick on internal inet proto tcp to port ftp divert-to 127.0.0.1 port 8021
pass    quick on internal inet

# ---- default block
block log all label BLOCKED
The /etc/hostname.* files:

Code:
# cat /etc/hostname.xl0
dhcp
# cat /etc/hostname.xl1
 
inet       192.168.222.10 255.255.255.0 NONE group internal
inet alias 192.168.222.11 255.255.255.255
The ftp proxy stuff and the enabling of forwarding/routing of IPv4:

Code:
# grep ftp /etc/rc.conf.local

ftpproxy_flags="-T FTP_DATA" 

# grep forward /etc/sysctl.conf

net.inet.ip.forwarding=1        # 1=Permit forwarding (routing) of IPv4 packets
net.inet.ip.mforwarding=1       # 1=Permit forwarding (routing) of IPv4 multicast packets
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #3   (View Single Post)  
Old 12th August 2012
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,431
Thanked 214 Times in 189 Posts
Default

Hello, and welcome.

Quote:
Originally Posted by nekoneko View Post
... But with these rules, I can't get to the internet from em0.
That's because your original rule set did not have a pass rule applicable for inbound traffic arriving from em0.

The rules have pass out, but not a pass in. Your third rule, for ssh, only permits ssh traffic to the gateway (self) from em0. Traffic for other destinations, or other ports, are blocked.
Reply With Quote
  #4   (View Single Post)  
Old 13th August 2012
nekoneko nekoneko is offline
New User
 
Join Date: Aug 2012
Posts: 3
Thanked 0 Times in 0 Posts
Default

Thanks for the replies.

Correct me if I'm wrong, but wouldn't this rule in your example file simply allow all traffic on the internal interface?

pass quick on internal inet

Quote:
The rules have pass out, but not a pass in.
So does that mean that I would need to specifically open port 80, 443, etc on em0 to allow traffic to get out to the Internet? This is what I don't really want to do - I'd rather not have the router unnecessarily listening on all those ports.
Reply With Quote
  #5   (View Single Post)  
Old 13th August 2012
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,116
Thanked 182 Times in 149 Posts
Default

Quote:
Originally Posted by nekoneko View Post
Thanks for the replies.

Correct me if I'm wrong, but wouldn't this rule in your example file simply allow all traffic on the internal interface?

Code:
pass    quick on internal inet
.
Yes, in this rule set I opted for filtering only on the external interface.

Actually I intended change to filtering on the internal interface, label the allowed traffic with a tag, and only pass out the tagged traffic on the external interface. Just did not find the time to do it
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #6   (View Single Post)  
Old 13th August 2012
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,431
Thanked 214 Times in 189 Posts
Default

Quote:
So does that mean that I would need to specifically open port 80, 443, etc on em0 to allow traffic to get out to the Internet? This is what I don't really want to do - I'd rather not have the router unnecessarily listening on all those ports.
PF does not know which of your NICs connects you to the Internet, nor which is your private network. It only knows the filtering rules you set for each NIC.
  • These rules either pass or block, and may be bidirectional or for inbound or outbound traffic.
  • Inbound rules affect traffic coming in to the gateway. In this case, you have two rules that affect unsolicited inbound traffic: your first rule blocks all inbound traffic of all kinds, and then you have a pass which only permits inbound access to the gateway for ssh traffic from the em0 NIC. Your third rule, the pass out rule (when it applies), will permit return traffic inbound for active TCP sessions ("keep state" is the default).
PF is active. Your router is already "listening" to all traffic on all NICs, making decisions based upon your PF rules to pass or block. PF runs in the kernel, there is little performance impact to adding additional pass rules. There will be some memory used for state tables. The default maximum is for 10,000 state table entries -- that's 10,000 active sessions.
Reply With Quote
  #7   (View Single Post)  
Old 13th August 2012
nekoneko nekoneko is offline
New User
 
Join Date: Aug 2012
Posts: 3
Thanked 0 Times in 0 Posts
Default

Sorry, I probably didn't use very clear terminology. By listening, I meant listening and potentially accepting connections on running services.

For example, if I were setting up a router using iptables, I would configure the INPUT chain to drop all incoming connections, then set the POSTROUTING chain to do NAT between the private and Internet interfaces. Thus, the router would not accept connections on any port, even if there was a service running (e.g. httpd).

However, what I've gathered so far is that I can't do this with pf. If I want to use NAT to give Internet access to hosts on my internal network, I also need to expose any service that might be running on the router to the internal network.

I'm more concerned about this from a security perspective (best practices - no need to potentially expose services that I'm not using), not performance.

If this is the case and it's how pf works then that's fine - I just want to be clear that this is how it's intended to work, and there's not some setting that I'm missing.

Thanks
Reply With Quote
  #8   (View Single Post)  
Old 13th August 2012
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,431
Thanked 214 Times in 189 Posts
Default

Quote:
Originally Posted by nekoneko View Post
Sorry, I probably didn't use very clear terminology. By listening, I meant listening and potentially accepting connections on running services.
You misunderstood, then.

All traffic is inspected for rule matching -- to an extent. There is optimization, of course. If PF does not need to inspect, it does not. As when stateful traffic is passed, matching traffic is not inspected again while the state remains established.

Yes, you can configure PF so that your em0 traffic is blocked from services on the router. Let's look at this example:
Code:
pass in on em0 proto {tcp udp icmp} to any
block in on em0 to self
The first rule permits three protocols to be passed inbound to the gateway, headed anywhere at all. The second rule blocks inbound traffic of all protocols destined to the gateway itself. In PF, unless the quick option is used, the last matching rule wins. So in this example, individual inbound packets are inspected, and if they are of the three protocols, the pass will match. Then, the packets are tested against the block rule. If the destination is the gateway itself, the block will match. Whichever was the last matching rule for that packet will apply. All inbound traffic to "self" will be blocked. TCP/UDP/ICMP traffic to other destinations will pass. And any inbound packets of protocols other than TCP/UDP/ICMP would not match the pass rule, but they might match the block rule, if the gateway were their destination.
Quote:
For example, if I were setting up a router using iptables...
These packet filtering tools are quite different from one another.

While you may or may not be able to do exactly the same sorts of filtering with each tool ... if I understood this use case, yes, you can easily prevent em0 traffic from reaching any services on the gateway other than SSH, while still permitting unfettered access to the Internet.

---

Unrelated to your question, but ... a thought on best practices:

You do not trust the platforms on em0 to permit them access to services on your gateway. Are any of the machines on em0 Windows platforms? I ask, because you are granting em0 unfettered outbound access to the Internet.

If this were my network, and there were Windows platforms on em0, I would want to control traffic to ports 25 and 587 to prevent spambots, and I would want control of unsolicited outbound TCP and UDP traffic on non-standard ports, in order to limit access to bot C&C servers. That won't stop C&C to bot servers that use standard ports, of course.

Last edited by jggimi; 13th August 2012 at 01:00 PM. Reason: clarity
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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Configuring X with 9800gt fails. Daffy OpenBSD General 8 27th February 2012 02:21 PM
Problems configuring carp nocturnal OpenBSD General 0 23rd October 2011 01:58 PM
configuring second NIC tomp OpenBSD Installation and Upgrading 19 15th August 2011 07:25 PM
Help configuring pine cssgalactic FreeBSD General 4 29th June 2008 11:50 PM
Need Help Configuring Postfix iainnitro General software and network 6 8th June 2008 04:55 AM


All times are GMT. The time now is 12:52 AM.


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