BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


Securing Small Networks With OpenBSD, Part 2

by Jacek Artymiak
04/11/2002

Welcome back.

I'd like to thank you for your feedback on the first part of "Securing Small Networks with OpenBSD." You asked many interesting questions that prompted me to write another article in which I'll try to answer questions regarding the new packet filter, pf, introduced in OpenBSD 3.0.

How do I use pf?

That's easy: Download and install OpenBSD 3.0 or 3.1 and it's there. :-) To control pf, use the pfctl tool.

    *
    * Start pf  pfctl -e
    * Stop pf  pfctl -d
    * Upload new pf rules  pfctl -R /etc/pf.conf
Upload new nat rules  pfctl N /etc/nat.conf

As you can see, the names of the configuration files have changed as well: packet filtering rules are now stored in the pf.conf file located in the /etc directory. The network address translation rules are stored in the nat.conf file located in the same directory. When pfctl complains about syntax errors, use the -v option to display the rules as they are processed by pfctl. For example, when the packet filtering rules contain errors, use pfctl v R /etc/pf.conf | less to browse the output and locate lines with errors; then edit the configuration file and try uploading the new rules again.

Note that pfctl will complain if you try to upload new configuration rules while pf is not running. When that happens, start pf as described earlier and try again.

For more information about pfctl, read man pfctl.

How do I translate ipf rules into pf rules?

Administrators new to pf will be glad to know that its syntax is very similar to that of ipfilter. Simple rules can be translated without any changes whatsoever, while more complicated statements will have to be slightly adjusted to match the new syntax. This is only a small inconvenience, as the new rule syntax is easier to read and manage. In general, you can expect to halve the length of the configuration file while retaining all previous functionality.

Let's have a closer look at what changes have been made. First, a simple example using the design described in the original article:

lo0: all inbound and outbound packets can pass through ()

ipfilter:

pass out quick on lo0 all

pass in quick on lo all

pf:

pass out quick on lo0 all

pass in quick on lo all

As you can see, nothing has changed here. Such simple rules can be copied verbatim. The situation changes when we try to rewrite more complex rules, like the ones shown below. (The tun0 interface connects our network to the Internet.)

tun0: outbound packets sent from any network address to the private address space cannot pass through

ipfilter:

block out quick on tun0 from any to 192.168.0.0/16
block out quick on tun0 from any to 172.16.0.0/12
block out quick on tun0 from any to 127.0.0.0/8
block out quick on tun0 from any to 10.0.0.0/8
block out quick on tun0 from any to 0.0.0.0/8
block out quick on tun0 from any to 169.254.0.0/16
block out quick on tun0 from any to 192.0.2.0/24
block out quick on tun0 from any to 204.152.64.0/23
block out quick on tun0 from any to 224.0.0.0/3

pf:

block out quick on tun0 from any to { 192.168.0.0/16, 172.16.0.0/12, 127.0.0.0/8, 10.0.0.0/8, 0.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 204.152.64.0/23, 224.0.0.0/3 }

Now, that's a refreshing change! We've just shrunk nine lines into one. As you can see, we listed all network addresses inside a pair of curly braces: {}. This simple trick can be used to list multiple arguments for the proto, from, to, port, and icmp-type keywords.

The rest of the syntax is unchanged, but watch out for the port and proto syntax.

tun0: incoming packets sent from any network address to port 80 can pass through to the mail and HTTP servers located in the DMZ

ipfilter:

pass in quick on tun0 proto tcp/udp from any to x.x.x.x/32 port = 25 pass in quick on tun0 proto tcp/udp from any to 192.168.2.4/32 port = 25pass in quick on tun0 proto tcp/udp from any to x.x.x.x/32 port = 80 pass in quick on tun0 proto tcp/udp from any to 192.168.2.3/32 port = 80

pf:

pass in on tun0 inet proto { tcp, udp } from any to x.x.x.x/32 port { 25, 80 }

pass in on tun0 inet proto { tcp, udp } from any to 192.168.2.3/32 port 80

pass in on tun0 inet proto { tcp, udp } from any to 192.168.2.4/32 port 25

As you can see, in pf rules there is no = character after the port keyword. We do not use the tcp/udp notation to specify both tcp and udp protocols, but we list them in curly braces instead. Forgetting to change this is a common mistake when transferring rules from ipfilter to pf. Fortunately, pfctl spots such mistakes and refuses to upload them to pf.

The name of the port can be replaced by the name of the service assigned to that port. For example:

pass in on tun0 inet proto { tcp, udp } from any to x.x.x.x/32 port { smtp, www }

The names of services can be found in /etc/services.

Other interesting changes include the scrub action, which normalizes malformed packets. This action uses additional CPU cycles, but it's well worth using to ensure that the packets arriving in our network are well formed and won't cause problems to applications running on your internal network. Should you use it? You decide. Try running your firewall with and without scrub and see if there is a difference in network performance. The following rule tells pf to normalize all incoming packets on all interfaces; add it at the beginning of your pf ruleset.

scrub in all

Further improvements made to pf include enhanced stateful filtering. Not only can you ask pf to keep state, the same feature available in ipfilter, but you can also improve security by generating more secure initial sequence numbers with modify state. To enable this feature, replace keep state with modify state. This feature puts additional load on the firewall machine, and you might want to compare firewall performance with and without modify state to see if and how it affects performance. To use it, replace keep state with modify state in your ruleset (using modify state implies keep state). state modification works only with TCP packets.

Pages: 1, 2

Next Pagearrow





Sponsored by: