Re: scrub blocking SF, but not logging
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
Re: scrub blocking SF, but not logging
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) -- Cam
scrub blocking SF, but not logging
I've got a fairly simple test ruleset: WAN_IF="em0" LAN_IF="em1" set block-policy return set state-policy if-bound set require-order yes set debug urgent set loginterface $WAN_IF set skip on lo0 scrub all no-df random-id fragment reassemble block log all # allow routed packets to flow pass out on $LAN_IF inet proto icmp from any to any keep state tagged IN pass out on $LAN_IF inet proto tcp from any to any flags S/SA modulate \ state tagged IN # allow the fw to talk on WAN pass out on $WAN_IF inet proto tcp from ($WAN_IF) to any flags S/SA \ modulate state pass out on $WAN_IF inet proto udp from ($WAN_IF) to any keep state pass out on $WAN_IF inet proto icmp from ($WAN_IF) to any keep state # allow the fw to talk on LAN pass out on $LAN_IF inet proto tcp from ($LAN_IF) to any flags S/SA \ modulate state pass out on $LAN_IF inet proto udp from ($LAN_IF) to any keep state pass out on $LAN_IF inet proto icmp from ($LAN_IF) to any keep state # allow to-be routed traffic in pass in on $WAN_IF inet proto tcp from $WAN_IF:network to any flags \ S/SA modulate state tag IN pass in on $WAN_IF inet proto icmp from $WAN_IF:network to any keep \ state tag IN # I've read the code, re-read the FAQs and read the archives, and everything indicates that with bad or ambiguous TCP flags, scrub attempts to make life better. With SF, it will strip the FIN and pass the packet. With SR, it drops the packet. I've proven this to be true, however the one odd thing I'm seeing is that when pf scrubs a packet with SR, it does get droped but not logged. pf_normalize_tcp() does do things a bit differently than others in pf_norm.c, but I don't see any particular problems there. This particular build is a little old (OpenBSD 3.8-current (GENERIC) #200: Tue Oct 18 05:06:23 MDT 2005), but I don't see any changes that should've affected this particular section of code. I'm also seeing this on another box with a considerably larger rule set. Any ideas why this is not logged, or is this operator error? Thanks, -jon
