BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


FreeBSD Basics

Monitoring IPFW Logs

07/05/2001

In the last article, we were introduced to the names and the locations of the files that contain information logged by ipfw. We left off at /var/log/security which is the file I'd like to concentrate on in today's article as it wraps up this series on ipfw nicely.

We had to learn a fair bit about IP packets and some of the more common TCP/IP applications in order to correctly set up the ipfw firewall. Now as we read through the security log, we'll get to see first-hand what sort of packets do try to make their way into your FreeBSD computer.

When I first set up a firewall on a system, I like to keep an eye on the security log for the first week or so to see the amount and type of traffic which is being logged. As the superuser, I'll open up a terminal other than the console, and run the following command:

tail -f /var/log/security

This allows me to watch the log as it grows as any changes to the log will also be sent to this terminal.

As a demonstration of how to decipher what is being logged, let's take a tour of my most recent security log. You'll note that my security log has been "sanitized" as my IP address has been replaced by x.x.x.x. There are several ways to replace text on your FreeBSD system, but my favorite is to use the following Perl one-liner:

perl -pe 's/my_IP_address/x.x.x.x/g' /var/log/security > ~genisis/clean

I had to run this command as the superuser due to the permissions on the /var/log/security file. The syntax of this one-liner is fairly simple. The perl -e syntax tells Perl to run this line directly from the command prompt instead of looking for a Perl script to read. Don't forget to include the p in your -pe, or else Perl won't print its output. The 's tells Perl to look for the regular expression (regex) found between the first two slashes and replace it with the string of characters enclosed between the last two slashes. If you decide to use this command, replace /my_IP_address/ with your real IP address. The g' tells Perl to replace every occurrence of /my_IP_address/, not just the first occurrence. Finally, I told Perl to run this operation on the file /var/log/security and to send the results to a file named clean which was to be created in the home directory of the user "genisis".

As a reminder, the only rules I'm logging in my firewall are attempted TCP connections to my FreeBSD system (rule 00301) and any other packets that were denied because I didn't explicitly allow them (rule 00700):

ipfw show
<snip to just show logged rules>
00301     52     2727 deny log logamount 10 tcp from any to any in established
00700    213    14082 deny log logamount 10 ip from any to any

One of the first things I noticed when I started to read my firewall logs was that I was logging entries from the same host to port 119 (the news port) on a regular basis:

Jun  5 12:17:21 hostname /kernel: ipfw: 700 Deny TCP 24.0.0.203:58668 x.x.x.x:119 in via ed1
Jun  8 14:04:28 hostname /kernel: ipfw: 301 Deny TCP 24.0.0.203:50849 x.x.x.x:119 in via ed1
Jun  9 07:21:19 hostname /kernel: ipfw: 301 Deny TCP 24.0.0.203:37248 x.x.x.x:119 in via ed1
Jun 17 13:22:50 hostname /kernel: ipfw: 301 Deny TCP 24.0.0.203:49221 x.x.x.x:119 in via ed1
Jun 18 04:42:59 hostname /kernel: ipfw: 301 Deny TCP 24.0.0.203:39324 x.x.x.x:119 in via ed1
Jun 20 13:25:56 hostname /kernel: ipfw: 301 Deny TCP 24.0.0.203:57611 x.x.x.x:119 in via ed1
Jun 21 02:33:09 hostname /kernel: ipfw: 301 Deny TCP 24.0.0.203:53902 x.x.x.x:119 in via ed1

To find out who this mysterious host is, I'll use the -x option to the dig utility to perform a reverse DNS lookup:

dig -x 24.0.0.203

When I run this command, I'll receive about a page's worth of output; I'll find the portion that is useful for determining who this host is in the answer section:

;; ANSWER SECTION:
203.0.0.24.in-addr.arpa.  59m38s IN PTR authorized-scan1.security.home.net.

The host name in the answer section reminds me that my ISP routinely runs scans to see if any of its clients are running unauthorized news servers.

With that mystery solved, let's see if any other interesting ports are appearing in my log. I occasionally notice connection attempts to port 113 (the auth or identd port). Here is an example:

Jun  5 13:32:23 hostname /kernel: ipfw: 301 Deny TCP 216.13.25.80:47892 x.x.x.x:113 in via ed1
Jun  5 13:32:23 hostname last message repeated 3 times

And here is the result of the reverse lookup on this host:

dig -x 216.13.25.80
<snip>

;; ANSWER SECTION:
80.25.13.216.in-addr.arpa.  23h58m26s IN PTR atlas.ctsolutions.com.

The name ctsolutions.com rang a bell, and when I checked my mail reader's outbox, I saw that I had sent an email to that company about a minute before these entries appeared in my security log. It is common practice for some mail servers to do an identd lookup whenever you send them an email message. It is also common practice to make a special rule in your ruleset to respond with a TCP packet that has its reset flag set. This speeds up communications with the mail server as it doesn't have to wait for the identd request to timeout before it processes your email message.

Because the mail server is initiating the request, I'll have to ensure this new rule is numbered before my keep-state rules. I'll show the first bit of my ruleset so you can see the syntax of this new rule and where it was placed:

more /etc/ipfw.rules

#speed up email
add 00150 reset log tcp from any to any 113

#from man 8 ipfw: allow only connections I've created
add 00300 check-state
add 00301 deny log tcp from any to any in established
add 00302 allow tcp from any to any out setup keep-state
<snip>

I decided to log this new rule to see if it made any difference in my security log; the next time I sent an email to this mail server, the following entries were logged:

Jun  8 13:29:57 hostname /kernel: ipfw: 150 Reset TCP 216.13.25.80:37824 x.x.x.x:113 in via ed1
Jun  8 13:30:04 hostname last message repeated 4 times

Mail servers aren't the only types of servers that may do an identd lookup; FTP servers, POP3 servers and IRC servers may also try to send packets to port 113.

Pages: 1, 2

Next Pagearrow





Sponsored by: