BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


Securing Small Networks with OpenBSD, Part 4

by Jacek Artymiak
06/06/2002

Welcome back!

First of all, I'd like to thank you for all of the mail I've been receiving from you recently. Your questions and comments are a great source of inspiration! I also hope that the praises are deserved. As promised in the last installment of "Securing Small Networks with OpenBSD," today we'll have a closer look at logging packets with pf.

Packet logging is a good network administration practice, because it lets us spot problems with communication and early signs of break-in attempts. Of course, logging packets alone won't help; we need to learn how to analyze and manage log files generated by pf. But first things first.

Enabling Packet Logging in pf

Packet logging is enabled when the log keyword is included in a pf rule. Therefore, all we have to do is edit /etc/pf.conf and put the log keyword after either the in or out keywords. For example

# block all incoming packets

block  in on $ExtIF all

becomes

# block and log all incoming packets

block  in log on $ExtIF all

Next, save changes made to /etc/pf.conf and update pf rules with

# /sbin/pfctl -R /etc/pf.conf

The packets caught by the modified rule are now sent to the pflog0 interface, where they're picked up by the pflogd daemon, which stores them in /var/log/pflog.

Because pf log files are binary files unfit for viewing with human eyes, we need a tool that translates them into plain text. That tool is the venerable tcpdump utility, one of the essential UNIX network monitoring programs. We can use it to watch pf logs in real time with

# /usr/sbin/tcpdump -i pflog0

(Typing the full access path to the binary you want to run, as I do above, is a little paranoid, but it is not a bad thing to be paranoid, when it comes to security.)

The system should reply with

tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: listening on pflog0

You can ignore the warning (tcpdump prints it, because the pflog interface does not have an IP address, which it doesn't need) and wait for packets to fall into your carefully planted honey pot. It is quite likely that you will not see any packets at all, for a long time. What went wrong? Nothing, actually. You are lucky and your firewall is not a target of a port scan or a cracking attempt. A series of repeated attempts to connect to unavailable ports is a sign that somebody might be trying to "probe" your machine for open ports. They are not necessarily trying to break in (they may be network researchers, or even your ISP), but you should be alert and if such attempts occur frequently, you might need to investigate them more closely. However, before you raise an alarm and call the authorities, make sure that these attempted connections are not responses to your own connection attempts!

It's a good feeling to know that all is quiet on the blocked ports, but I bet you'd like to see some action, if only to check that everything is working right. All right, open /etc/pf.conf again and add the log keyword to the pass out rules for the external interface. We can change

# 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

to

# allow and log TCP IPv4 connections to the outside world, keep state

pass out log on $ExtIF inet proto tcp all flags S/SA modulate state
pass out log on $ExtIF inet proto { udp, icmp } all keep state

Save the changes and replace the old pf ruleset as described above. Then run tcpdump again, and point your Web browser to any external page. Now you should see a stream of packets similar to the one shown below:

22:36:04.056898 foo.foo.bar.2441 > www.oreillynet.com.www: S 24218
10635:2421810635(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:36:05.053274 foo.foo.bar.40158 > dns.barab.fof.domain: 40021+[|
domain]
22:36:05.266436 foo.foo.bar.45368 > dns.barab.fof.domain: 52038+[|
domain]
22:36:05.441504 foo.foo.bar.2442 > www.oreillynet.com.www: S 14853
23937:1485323937(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:36:34.754131 foo.foo.bar.2443 > www.oreillynet.com.www: S 66868
4617:668684617(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:36:34.755301 foo.foo.bar.2444 > www.oreillynet.com.www: S 26089
44368:2608944368(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:36:36.354114 foo.foo.bar.2445 > yyy.yyy.yyy.yyy.www: S 328279780
3:3282797803(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:36:36.355245 foo.foo.bar.2446 > yyy.yyy.yyy.yyy.www: S 134488332
8:1344883328(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:36:36.356389 foo.foo.bar.2447 > www.oreillynet.com.www: S 35794
77456:3579477456(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:36:36.359249 foo.foo.bar.2448 > www.oreillynet.com.www: S 77113
4772:771134772(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:36:36.360403 foo.foo.bar.2449 > www.oreillynet.com.www: S 58246
6425:582466425(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:36:36.443952 foo.foo.bar.2450 > yyy.yyy.yyy.yyy.www: S 257498150
5:2574981505(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:36:36.663670 foo.foo.bar.3232 > dns.barab.fof.domain: 54429+[|d
omain]
22:36:37.707556 foo.foo.bar.2451 > yyy.yyy.yyy.yyy.www: S 232656907
3:2326569073(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:36:38.858239 foo.foo.bar.2452 > yyy.yyy.yyy.yyy.www: S 891402374
:891402374(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:36:39.567365 foo.foo.bar.2453 > xxx.xxx.xxx.xxx.www: S 3151425796
:3151425796(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:36:39.872224 foo.foo.bar.19371 > dns.barab.fof.domain: 49535+[|
domain]
22:36:40.186636 foo.foo.bar.2454 > xxx.xxx.xxx.xxx.www: S 336060000:
336060000(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:37:14.783587 foo.foo.bar.2455 > xxx.xxx.xxx.xxx.www: S 2486604739
:2486604739(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
22:37:29.462583 foo.foo.bar.2456 > xxx.xxx.xxx.xxx.www: S 2059502170
:2059502170(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

What you see above is a group of packets sent from the network located behind a firewall to the O'Reilly Network servers, in a successful attempt to retrieve the previous installment of this series. The packets sent in response to that request are missing from the above list, because we did not ask pf to log them.

If you want to make sense of the data printed by tcpdump, it's a good idea to start with "Tools of the Trade," written by Carl Constantine. For your information, foo.foo.bar is the name of an imaginary host connected to the Internet, and dns.barab.fof is the name of an imaginary DNS server located outside of the network from which the lookup request was sent. The xxx.xxx.xxx.xxx and yyy.yyy.yyy.yyy strings are IP addresses of the oreillynet.com servers. In your case, all of these will have real names and numbers and be quite likely totally different from another reader's results.

If you are on a small network and only you are generating the traffic, the rate at which information will scroll before your eyes should not make it difficult to follow the flow of datagrams. But if you have more users actively surfing the Internet, then you will almost certainly not be able to catch up with the traffic. Fortunately, there are ways to manage that flood of packets.

Pages: 1, 2

Next Pagearrow





Sponsored by: