Building Firewalls With OpenBSD And PF, 2nd Edition (2003)

Appendix A

Manual Pages

Unlike online help distributed with other operating systems, the OpenBSD manual pages truly are the best source of information related to almost every component of this Œne piece of software.

A.1 Using the OpenBSD Manual

The OpenBSD system manual is available from the command line, all you have to do is type the man command followed by the name of man page:

$ man dhcp

As you might have noticed, this book contains names of many manual pages that end with a number enclosed in parentheses. That number indicates the section number the page in question belongs to, e.g. ls(1) is a reference to the manual page for the ls command stored in section 1. Such notation is used, because there may exist more than one page with the same name. To specify which page you want to see, precede the name of the page with the section number:

$ man 1 ls

What if you don't know which page contains the information you are looking for, let alone the section number? Use the apropos(1) command:

$ apropos dhcp

dhclient(8) - Dynamic Host Configuration Protocol + (DHCP) Client

dhclient-script(8) - DHCP client network configuration + script

dhclient.conf(5) - DHCP client configuration file dhclient.leases(5) - DHCP client lease database

268 Appendix A: Manual Pages

dhcp(8) - configuring OpenBSD for DHCP dhcp-options(5) - Dynamic Host Configuration Protocol + options

dhcpd(8) - Dynamic Host Configuration Protocol Server dhcpd.conf(5) - dhcpd configuration file dhcpd.leases(5) - DHCP client lease database

When apropos(1) returns more results that can Œt on a single screen, use this set of commands:

$ apropos dhcp | less

What if the page you read did not answer your questions? Have a look at the pages in the SEE ALSO section found near the end of almost every manual page and at the pages referred to in the main text of the page you are reading.

The truly determined can use the following command to dig deeper into the bowels of the manual:

$ grep -r bridge /usr/share/man/

What you'll see is a list of lines showing the names of Œles where the bridge keyword was found. The numbers at the end of the Œle names shown in the output are the manual section numbers.

A.1.1 Reading the OpenBSD Manual Pages on the Web

It is possible to read the OpenBSD manual pages online with your browser, which is very handy when you don't have OpenBSD up and running, or when you saved disk space and did not install the man34.tgz. They are available on the following page:

A.2 Pages Related to PF

There are several manual pages describing pf and its components:

ƒauthpf(8) Š the authenticating gateway user shell. Discussed in Chapter 12, Using authpf.

ƒpf(4) Š Daniel Hertmeier's Packet Filter.

ƒpf.conf(5) Š a long description of the pf conŒguration Œle.

ƒpf.os(5) Š description of the format of the operating systems' Œngerprint database.

ƒpfctl(8) Š the pf management tool. Discussed in Chapter 16, Firewall

Management.

ƒp•ogd(8) Š the pf logging daemon. Discussed in Chapter 11, Logging and Log Analysis.

ƒpfsync(4) Š the pf states table logging interface. Discussed in Chapter 15, Testing Your Firewall.

ƒspamd(8) Š the anti-spam daemon. Discussed in Chapter 13, Using spamd.

ƒspamd-setup(8) Š the tool for parsing and loading spammer's addresses. Discussed in Chapter 13, Using spamd.

ƒspamd.conf(5) Š spamd(8) conŒguration Œle syntax. Discussed in Chapter 13, Using spamd.

A.3 Other Pages of Interest

The following pages are good starting points when you are learning the OpenBSD operating system or the pf packet Œlter:

ƒafterboot(8) Š things you need to do after installing OpenBSD.

ƒbpf(4) Š the Berkeley Packet Filter.

ƒintro(4) Š a concise introduction to special Œles and devices.

ƒintro(7) Š a list of most important pages in section 7 (miscellaneous).

ƒintro(8) Š a short description of the contents of section 8 (system management).

ƒnetworking(8) Š a concise introduction to the OpenBSD networking facilities. Since the topic is huge, it is only a general overview, but nonetheless useful. If you are looking for speciŒc answers, read other pages related to devices, protocols, services, and tools. Still lost? Read [Stevens 1994].

270

Appendix B

Rules for Popular (and Less Popular)

Services

So, you want to know how to write a rule for service x?

Is there a table of rules you can use? The answers are here.

Writing a rule for a service begins with a look at the contents of /etc/services. When you Œnd a name and a matching port number, you have most of the information you need to write your rule. If the service is not listed in /etc/services, it may be listed in this Œle:

http://www.iana.org/assignments/port-numbers

When you Œnd them there, use the port number, not the name of the service. Note that the port numbers are not guaranteed to be what you expect them to be, because administrators are free to conŒgure them as they wish, although ports lower than 1024 tend to be quite stable.

Another important piece of information is the transport protocol used, which often is TCP or UDP. UDP-based services are often problematic and care must be taken when you are dealing with them. The rule here is to use TCP unless you explicitly need UDP.

ƒI want to block connections from external hosts to a speciŒc port on the host running pf(4). Start with (remember to use the proto keyword followed by tcp, or udp, or both). This is important, because ports are Only deŒned in TCP and UDP protocols; ICMP, RSVP, and others that do not use TCP or UDP for transport do not use ports:

#if -- the interface on which packets arrive

#block both TCP and UDP IPv4

block in on $if inet proto {tcp, udp} \ from any to ($if) port $blocked_port

# block both TCP and UDP IPv6

block in on $if inet6 proto {tcp, udp} \ from any to ($if) port $blocked_port

ƒI want to pass connections from certain external hosts to a speciŒc port on the Œrewall, but block them from other hosts. Start with:

#if -- the interface on which packets arrive

#block both TCP and UDP IPv4

block in on $if inet proto {tcp, udp} \ from any to ($if) port $blocked_port

pass in on $if inet proto {tcp, udp} from $OK_address \ to ($if) port $blocked_port

# block both TCP and UDP IPv6

block in on $if inet6 proto {tcp, udp} \ from any to ($if) port $blocked_port

pass in on $if inet6 proto {tcp, udp} from $OK_address \ to ($if) port $blocked_port

When you only want to pass IPv4 packets, remove the pass ... inet6 rule.

ƒI want to redirect connections from external hosts from one port to another.

#ext_if -- the external interface rdr in on $ext_if inet \

from any to ($ext_if) port $target_ports \ -> $target_host $redirected_port

rdr in on $ext_if inet6 \

from any to ($ext_if) port $target_ports \ -> $target_host $redirected_port

ƒI want to redirect connections from internal hosts to proxy.

#ext_if -- the external interface

273

# int_if -- the internal interface rdr in on $int_if \

from any to any port $target_port \ -> $proxy_host $redirected_port

ƒHow do Œnd out which ports are opened by a particular piece of software? Consult the relevant documentation, but if that doesn't help, do some detective work. Run the software, then run nmap on the hosts running that software. Also, run tcpdump(8) on the Œrewall host and Œlter out trafŒc to and from the host running that software.

ƒWhy some protocols need two or more ports? Some protocols are just designed that way, for better or worse. They usually open two connections at different ports, one for data and one for control. In such cases, it is difŒcult to write Œltering rules for them, unless you can know the numbers of these ports beforehand. What you can do is proxy them like you proxy the FTP described in Chapter 4, ConŒguring OpenBSD

ƒWhat's the difference between nat and rdr proxy? The main difference is the fact that rdr rules do not change the source address of a packet.

ƒI tried everything, and still don't get it. Read the protocol speciŒcation. Use nmap and tcpdump(8). Ask around, no shame in learning.

B.1 Dealing with ICMP

The Internet Control Message Protocol (ICMP) is a very important tool for IP network diagnostics. Tools like ping(8) use it to Œnd out whether the host you are trying to ping is running, down, or rejecting connections; routers use it to perform some automatic administrative tasks, etc. Unfortunately, ICMP is being abused by hackers, and it is often advised to block it, which makes tools like ping(8) inoperable.

Rather than completely block it, you could let some types of ICMP responses pass through your Œrewall, with some caution. The following rules are for a screened network Œrewall conŒguration.

ƒEcho Request & Echo Reply Š let administrators ping (send Echo Request and accept Echo Reply) external hosts:

#prv_if -- the interface that private hosts connect

#to the firewall

pass in on $prv_if inet proto icmp \ from $admin_hosts \

to any icmp-type 8 code 0 keep state

ƒEcho Request & Echo Reply Š let private hosts ping (send Echo Request and accept Echo Reply) the Œrewall host:

#prv_if -- the interface that private hosts connect

#to the firewall

pass in on $prv_if inet proto icmp \ from $prv_if:network \

to ($prv_if) icmp-type 8 code 0 keep state

ƒEcho Request & Echo Reply Š let your ISP network ping (send Echo Request and accept Echo Reply) the Œrewall host:

#ext_if -- the interface that firewall host connects

#to the outside world

pass in on $ext_if inet proto icmp \ from $ISP_net_address \

to ($ext_if) icmp-type 8 code 0 keep state

ƒDestination Unreachable Š block outbound Destination Unreachable messages except for Fragmentation Needed, pass inbound Destination Unreachable messages:

#ext_if -- the interface that firewall host connects

#to the outside world

#prv_if -- the interface that private hosts connect

#to the firewall

pass in on $ext_if inet proto icmp \ from any \

to any icmp-type 3

pass out on $ext_if inet proto icmp \ from any \

to any icmp-type 3 code 4 keep state pass in on $prv_if inet proto icmp \

from prv_if:network \ to any icmp-type 3

B.2 Fixing FTP

FTP and other protocols that open two or more connections are always problematic, because they need proxy software to operate correctly through the Œrewall.

A solution to FTP client access to external servers is shown in Chapter 4, ConŒguring OpenBSD. What about FTP servers? You need to know which ports does the server open for connections besides port 21. In case of ftpd(8) the are in range 49152 through 65535, while the Windows 2000 FTP server opens ports 5000 through 65534. When the server is running on the same host as pf(4), use:

pass in on $ext_if proto tcp from any \ to any port 21 keep state

pass in on $ext_if proto tcp from any \ to any port > 49151 keep state

When the FTP server is running in a DMZ, use the reverse ftp-proxy solution described in Chapter 4, ConŒguring OpenBSD.

B.3 Template Rules for Services Using TCP and UDP

The long ruleset presented later in this chapter contains examples of rules for passing or blocking certain services based on TCP. It is also very easy to adapt them to Œlter services using UDP, although we generally block it when it is not absolutely necessary, for safety. These example were written for a few typical Œrewall conŒgurations described in Chapter 2, Firewall Designs. The service Œltered in these rules is the Secure Shell (SSH). SSH servers are listening on port 22,and that's the assumption the ruleset is based on.

Adapting rules for other TCP services is very easy and often involves a mere change of the target port number. More information about doing this can be found in the next section of this appendix.