Securing Small Networks with OpenBSD, Part 4

Listen Print

Securing Small Networks with OpenBSD, Part 4
Pages: 1, 2

Which Packets Do You Want to Capture?

Why do some packets get written to /var/log/pflog and some do not? It all boils down to the way pf works.

Packets are written to /var/log/pflog, when the last pf rule they match includes the log keyword. Packets that are not caught by rules with the log keyword won't be logged. Therefore, if you want to capture all traffic, you need to add the log keyword to all in and out rules in your /etc/pf.conf, save for the lo0 loopback device. On the flip side, if you want to limit logging to a smaller group of packets, add the log keyword only to those rules that catch the packets you want to log. For example, to log all inbound packets sent to your networks from the outside, add the log keyword to all pass in and block in rules for the external interface. Therefore, the rules for the tun0 (ExtIF) interface, described in the second installment of this series, would now look like this:

################################################################# # Internet (tun0) # block and log spoofing non-routable addresses block in log quick on $ExtIF from $NoGoIPs to any block out quick on $ExtIF from any to $NoGoIPs # block and log all incoming packets block in log on $ExtIF all pass in log on $ExtIF inet proto tcp from any to $rdrIPs port $rdrPorts keep state pass in log on $ExtIF inet proto udp from any to $rdrIPs port $rdrPorts keep state # block all outgoing packets block out on $ExtIF all # allow TCP IPv4 connections to the outside world, keep state pass out on $ExtIF inet proto tcp all flags S/SA modulate state pass out on $ExtIF inet proto { udp, icmp } all keep state

Two special cases we have not discussed yet are the keep state and modulate state rules. We have a choice of using either of the log or log-all keywords here, depending on which packets we want to log. The log keyword will only log those packets that make state, while log-all will log all packets. Therefore, to capture all packets matching state rules, you'd need to change:

pass in log on $ExtIF inet proto tcp from any to $rdrIPs port $rdrPorts keep state pass in log on $ExtIF inet proto udp from any to $rdrIPs port $rdrPorts keep state

pass in log-all on $ExtIF inet proto tcp from any to $rdrIPs port $rdrPorts keep state pass in log-all on $ExtIF inet proto udp from any to $rdrIPs port $rdrPorts keep state

To log all traffic on ExtIF, we'd need to add the log keyword to the out rules.

################################################################# # Internet (tun0) # block and log spoofing non-routable addresses block in log quick on $ExtIF from $NoGoIPs to any block out log quick on $ExtIF from any to $NoGoIPs # block and log all incoming packets block in log on $ExtIF all pass in log-all on $ExtIF inet proto tcp from any to $rdrIPs port $rdrPorts keep state pass in log-all on $ExtIF inet proto udp from any to $rdrIPs port $rdrPorts keep state # block and log all outgoing packets block out log on $ExtIF all # allow TCP IPv4 connections to the outside world, keep state pass out log-all on $ExtIF inet proto tcp all flags S/SA modulate state pass out log-all on $ExtIF inet proto { udp, icmp } all keep state

Previously in this series:

Securing Small Networks with OpenBSD, Part 1 -- Small networks are often more vulnerable than large ones because they lack the money to implement good security. Artymiak Jacek explains how to secure a small network on a tight budget.

Securing Small Networks With OpenBSD, Part 2 -- OpenBSD switched from using IPFilter as its default firewall to PF, or Packet Filter, as the new default. Jacek Artymiak explains how to make a smooth transition from ipf to pf.

Securing Small Networks With OpenBSD, Part 3 -- In the third installment of our series on OpenBSD networking, Jacek Artymiak examines pf rules and potential sendmail problems.

But if we are really concerned about security, shouldn't we be logging all packets arriving and leaving on all interfaces on the firewall? Ideally, yes, because that is the only way to ensure that you know what goes on over the boundary between your network and the rest of the world. But in such cases, you need to construct an efficient system for automated log analysis and management. Log files grow fast and take up a lot of storage space; it is essential that you gather only as much data as you can analyze.

OK, suppose that you decide to log all traffic on all interfaces. The first thing you need to do is turn global logging on by adding the log or log-all keywords (where appropriate) to every rule for every external interface on the firewall (ne0, ne1, tun0, or whatever the names of the interfaces that you are telling pf to monitor are). Load those new rules into pf, as described earlier in this article, and check that the packets are being logged into /var/log/pflog with:

# /usr/sbin/tcpdump -r /var/log/pflog

Rather than being a real time display, this command updates in short intervals. If all goes well, you are now monitoring all traffic passing, and attempting to pass, through the firewall. There is a lot of data to munch through, and if you are to manage it, you need to learn how to use tcpdump. The man page for tcpdump (man tcpdump) provides plenty of information, so instead of repeating it all, I'll only point you in the right direction.

You can decide which packets are displayed by tcpdump using one of many options and expressions:

Display information in a more compact way

# /usr/sbin/tcpdump -q -r /var/log/pflog

# /usr/sbin/tcpdump -q

Display only packets related to a specific port

# /usr/sbin/tcpdump -r /var/log/pflog port 80

# /usr/sbin/tcpdump port 80

Display only packets related to a specific host

# /usr/sbin/tcpdump -r /var/log/pflog host chumbawamba

# /usr/sbin/tcpdump host chumbawamba

Display only packets related to a specific network (or network segment)
```
# /usr/sbin/tcpdump -r /var/log/pflog net xxx.xxx.xxx.xxx
```
or
```
# /usr/sbin/tcpdump host chumbawamba net xxx.xxx.xxx.xxx
```
Additional expressions allow us to filter packets by their destination and protocol (see man tcpdump for details). Even more elaborate filtering can be achieved by combining tcpdump expressions, e.g.:
```
# /usr/sbin/tcpdump -r /var/log/pflog "host chumbawamba and port 80"
```
or
```
# /usr/sbin/tcpdump "host chumbawamba and port 80"
```

Remember that you can safely experiment with filtering expressions, because they do not affect the contents of /var/log/pflog. Try different tcpdump options and expressions and try to make sense of them with the help of the already mentioned "Tools of the Trade " article by Carl Constantine. I also recommend that you read Dru Lavigne's "TCP Protocol Layers Explained," "Capturing TCP Packets," "IP Packets Revealed," and "Examining ICMP Packets," all on the O'Reilly Network.

You've go a lot of reading to do this time, so I'll leave you now to learn a few things, and will return soon to tackle the problem of managing pf logs and intrusion detection.

Until next time.

Jacek Artymiak started his adventure with computers in 1986 with Sinclair ZX Spectrum. He's been using various commercial and Open Source Unix systems since 1991. Today, Jacek runs devGuide.net, writes and teaches about Open Source software and security, and tries to make things happen.

Return to the BSD DevCenter.

Which Packets Do You Want to Capture?

Sponsored Resources