[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Denying packets and log traffic



Randy Edwards <redwards@golgotha.net> writes:


> > Ever since I upgraded to potato my syslog and kern.log has grown to huge
> > sizes:
> > Feb  9 04:36:34 rademaker kernel: Packet log: input DENY eth0 PROTO=17
> > 130.161.65.12:138 130.161.65.127:138 L=242 S=0x00 I=7424 F=0x0000 T=128 (#6)

>    So if I could ask a few questions, in order of priority; where can I find
> documentation on what all the fields in the above log entry mean?  Does
> anyone know what specific package changed recently in potato to generate
> this (my guess is the ipmasq package, but that's a guess)?

I think ipmasq did have a rule to deny and *not* log netbios packets,
so maybe that did change -- I don't run ipmasq myself, so you'll have
to check on that.

The ipchains HOWTO explains the log output to some extent.  From
memory, L=length, I=id (serial number?), S=type of service, F=
fragment offset and flags, T=time-to-live; none of those usually
matter when trying to see why something's being denied.

What matters is the rest of it:
> ... input DENY eth0 PROTO=17 130.161.65.12:138 130.161.65.127:138 ... (#6)

So this was a packet coming in (input chain) on eth0 from 130.161.65.12
destined for 130.161.65.127, to and from UDP (protocol 17) port 138 and
was denied by ipchains input rule #6.

/etc/protocols defines the protocol numbers (17 is UDP).
/etc/services defines the port numbers (UDP 138 is "netbios datagram").

Netbios datagram is a windoze thing (samba, too, probably), and my
guess is 130.161.65.127 is the broadcast address on this subnet. So
your firewall is denying (and logging) them, which means these
incoming netbios datagrams never get seen by samba (if it's running)
on the firewall machine.

You should probably change the rule that's denying these (or add one
before it) to deny them silently (i.e. without the '-l' (log) option),
so they don't clutter your log.  Or get rid of all the windoze boxes
(or put all windoze machines on a different subnet) and you won't see
any of these.

If you *want* the firewall machine to get those packets -- i.e. if
it's running samba and wants to receive broadcasts from local windoze
machines, add a rule to allow those packets instead.
 
Hope this helps, ask more if it doesn't.


Reply to: