[ previous ] [ next ] [ threads ]
 
 From:  Francisco Reyes <lists at natserv dot com>
 To:  gr at redskycom dot net
 Cc:  "'Manuel Kasper'" <mk at neon1 dot net>, m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: Diagnostics: System logs
 Date:  Fri, 5 Mar 2004 18:56:22 +0000 (GMT)
On Sat, 6 Mar 2004 gr at redskycom dot net wrote:

> Can someone explain me how t oread the system log like ??
> 00:13:18.353203 sis0 @0:11 b 192.168.1.81,3637 -> 80.35.56.83,4662 PR
> tcp len 20 114 -AP IN

Some time back I had the same question and this is what Scott Damron sent
to me (which I found very helpfull)

http://www.obfuscation.org/ipf/ipf-howto.html#TOC_24

ipmon is also capable of showing us what packets have been logged. For
example, when using state, you'll often run into packets like this:
# ipmon -o I 15:57:33.803147 ppp0 @0:2 b 100.100.100.103,443 ->
20.20.20.10,4923 PR tcp len 20 1488 -A
What does this mean? The first field is obvious, it's a timestamp. The
second field is also pretty obvious, it's the interface that this event
happened on. The third field @0:2 is something most people miss. This is
the rule that caused the event to happen. Remember ipfstat -in? If you
wanted to know where this came from, you could look there for rule 2 in
rule group 0.

The fourth field, the little "b" says that this packet was blocked, and
you'll generally ignore this unless you're logging passed packets as well,
which would be a little "p" instead. The fifth and sixth fields are pretty
self-explanatory, they say where this packet came from and where it was
going. The seventh ("PR") and eighth fields tell you the protocol and the
ninth field tells you the size of the packet. The last part, the "-A" in
this case, tells you the flags that were on the packet; This one was an
ACK packet. Why did I mention state earlier? Due to the often laggy nature of
the Internet, sometimes packets will be regenerated. Sometimes, you'll get
two copies of the same packet, and your state rule which keeps track of
sequence numbers will have already seen this packet, so it will assume
that the packet is part of a different connection. Eventually this packet will
run into a real rule and have to be dealt with. You'll often see the last
packet of a session being closed get logged because the keep state code
has already torn down the connection before the last packet has had a chance
to make it to your firewall. This is normal, do not be alarmed. [[dagger]]
[[footnote: [[dagger]] For a technical presentation of the IP Filter
stateful inspection engine, please see the white paper Real Stateful TCP
Packet Filtering in IP Filter, by Guido van Rooij. This paper may be found
at <http://www.iae.nl/users/guido/papers/tcp_filtering.ps.gz> ]] Another
example packet that might be logged:
12:46:12.470951 xl0 @0:1 S 20.20.20.254 -> 255.255.255.255 PR icmp len 20
9216 icmp 9/0

This is a ICMP router discovery broadcast. We can tell by the ICMP type
9/0. Finally, ipmon also lets us look at the NAT table in action.