On Sun, 13 Feb 2005, Quark IT - Hilton Travis wrote:
> I've forwarded this also to the monowall-dev list to see if someone on
> there can provide better answers than I can - I'm not totally clued up
> on all aspects of m0n0wall, and totally clueless on others. :)
> > -----Original Message-----
> > From: WallWatcher Support [mailto:support at wallwatcher dot com]
> > Sent: Sunday, 13 February 2005 11:46
> > Hi Hilton,
> > Your m0n0wall records are different in several respects from the
> > other samples I've seen:
> > 1. the others tended to occur in pairs: LAN-to-Router, then
> > Router-to-Remote. WW reports the first one and ignores the
> > second one. I didn't see any such pairs in your samples. It
> > doesn't affect anything, just a difference.
> This may be a result of my running 1.2b3 and your previous users running
> version 1.1 of m0n0wall. I hope someone on the m0n0wall list can
> further comment on this.
IPFilter is invoked for both incoming and outgoing packets, which means
that "itinerant" packets pass through it twice. But m0n0wall's
rule-construction philosophy does almost all filtering on the
"incoming" side, with almost anything being passed when outgoing. Any
requested logging occurs only on the incoming side, so LAN->WAN packets
appear associated with the LAN interface, while WAN->LAN packets appear
associated with the WAN interface.
> > 2. some of the "flags" that indicate what was done with the
> > packets are different in your samples than in the others. For
> > example, I don't know what your router did with the three
> > packets reported by these two log records:
He seems to use the term "flags" inconsistently, in some cases meaning the
disposition of the packet, and in others meaning the TCP flags. The
"b" in all the entries below means "blocked".
> > (1)
> > <132>Feb 13 00:08:25 ipmon: 00:08:25.040616 ng0 @0:21 b
> > 184.108.40.206,57347 -> 220.127.116.11,135 PR tcp len 20 48 -S IN
> > (2)
> > <132>Feb 13 00:08:33 ipmon: 00:08:33.866907 ng0 @0:21 b
> > 18.104.22.168,12056 -> 22.214.171.124,1026 PR udp len 20 668 IN
> > (3)
> > <132>Feb 13 00:07:40 ipmon: 00:07:40.717625 sis0 @0:19 b
> > 192.168.69.120,2753 -> 126.96.36.199,80 PR tcp len 20 40 -AF IN
> Again, this may be because of later versions of the firewalling apps in
> m0n0wall 1.2b3 compared to the 1.1 release, and again I hope someone
> with more clue than I can help out here.
> > The first two came IN from the 'net. The flag is "-S".
> > Based on previous samples, I believe the first one was dropped,
> > and WW currently reports it that way: as an Inbound.
> It was - according to the m0n0wall webGUI. As it should have been.
Yes, it's a TCP initial SYN packet, most likely from an infected Windows
system trying to infect yours via port 135. Blocking it is good. :-)
> > The second one contains neither your real IP address nor any
> > of your LAN addresses, but the "Length" fields indicate content
> > beyond just headers. There are no flags, which never occurred
> > in other people's samples. WW currently reports it as a dropped
> > Inbound.
> It, too, was and should have been dropped.
Yes, though I don't know what he means about its not having your real IP
address. It's the same destination IP as the port 135 attack.
This "no flags" comment is bizarre, since UDP has no flags.
Google is your friend. First match on "UDP port 1026":
> > The third one is an Outbound from a LAN station to a Remote
> > IP. The flags are "-AF", and I don't know what they mean. WW
> > currently reports it as a blocked Outbound.
> That's weird - it appears to be a reguler outbound packet to a web
> server, so I have no idea why this was blocked. I have also confirmed
> that I have no firewall rules with this IP, and no firewall rules
> blocking any traffic to any external web servers. Unfortunately, due to
> the limited logging capacity of m0n0wall, I cannot confirm what m0n0wall
> saw this as. :(
That's a known IPFilter bug. It's a FIN/ACK packet from the termination
of a connection, which almost certainly shouldn't be dropped. People
complain about these things over and over again without searching the
archives, but nobody ever provides information like packet traces and
> > Last year, I did review some m0n0wall documentation, but its
> > description of the status flags didn't necessary match the data
> > samples. (They never do, regardless of the router.) So, if you
> > know what the flags actually mean, or what the router actually
> > did with such records, please let me know.
> Anyone got some info on this? It'd be nice if the latest online
> documentation matched the actual packages. The issue - again - will be
> if there's a big difference between m0n0wall 1 1 and m0n0wall 1.2b3.
I don't think any of that has changed, and it's been documented on the ML
> > Another point: other people's samples had a "blocked/passed"
> > indicator; all of yours contain only a "blocked" indicator: the
> > stand-alone letter "b". ("p" would be "passed", of course).
> Maybe my m0n0wall isn't reporting "passed" packets, or maybe it is just
> a little constipated? :) I have no issues browsing or anything else,
> and don't otherwise notice blocked outbound traffic issues.
It doesn't log passed packets by default. That's usually a good thing,
especially given limited log space. You can change that if you really
want to, but be prepared to lose some log entries. Syslog doesn't fix
this, since "normal" syslog doesn't have reliable delivery.
> > Combining all of these differences, WW finds no "passed
> > Outbounds" (green "O"s) in your RAW files. Since I'm sure you
> > did some successful browsing and/or email checking while those
> > samples were being collected, this means one of two things: the
> > router is not reporting "passed" packets, or WW is not
> > recognizing them. (There aren't any "Passed Inbounds" either,
> > but that's normal unless you're running a Server.)
> We have an SMTP server here, so should be definitely seeing passed
> :25/TCP traffic. Unless, of course, m0n0wall isn't reporting these to