Защита малой сети с помощью OpenBSD, Часть 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

to

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

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

  or

  # /usr/sbin/tcpdump -q

• Display only packets related to a specific port

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

  or

  # /usr/sbin/tcpdump port 80

• Display only packets related to a specific host

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

  or

  # /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.