On Sat, Feb 25, 2006 at 10:07:42AM +0100, Camiel Dobbelaar wrote:
> 
> On Fri, 24 Feb 2006, Jon Hart wrote:
> > scrub all no-df random-id fragment reassemble
> > 
> > Any ideas why this is not logged, or is this operator error?
> 
> I don't think it's very well known, but you can set 'log' on the scrub  
> rule.  That will show you more info if scrub kicks in:
> 
> 10:01:06.100845 rule 0/(fragment) scrub in on sis0: 193.0.0.195 > 82.217.x.x: 
> (frag 61843:[EMAIL PROTECTED]) (DF) (ttl 61, len 630)
> 10:01:06.100972 rule 0/(fragment) scrub in on sis0: 193.0.0.195.53 > 
> 82.217.x.x.29785:  58221*-[|domain] (frag 61843:[EMAIL PROTECTED]) (DF) (ttl 
> 61, len 1500)
> 10:01:06.106046 rule 0/(fragment) scrub in on sis0: 193.0.0.195 > 82.217.x.x: 
> (frag 61844:[EMAIL PROTECTED]) (DF) (ttl 61, len 642)
> 10:01:06.106200 rule 0/(fragment) scrub in on sis0: 193.0.0.195.53 > 
> 82.217.x.x.29785:  34991*-[|domain] (frag 61844:[EMAIL PROTECTED]) (DF) (ttl 
> 61, len 1500)
> 
> (but it looks like tcpdump cannot filter on "action scrub" yet)

Good point.  The BNF indicates that this is possible.  Example: 


Feb 27 09:38:33.065473 rule 0/(normalize) scrub in on em0:
192.168.0.57.19239 > 10.0.0.3.12345: [|tcp]

Of course, depending on how verbose 'scrub log' gets, this may not be
a good option.  Even then, the log entry doesn't seem to indicate that
the packet was dropped (this was a packet with SYN and RST set).  In
this particular setup I have verified that the packet was dropped, but
this is something that should show up in the logs.

-jon

Reply via email to