On May 18, 2006, at 4:56 PM, Daniel Hartmeier wrote:
On Thu, May 18, 2006 at 04:38:44PM -0400, Chad M Stewart wrote:
# cat /etc/pf.conf |grep -v ^# |grep block
set block-policy return
block in log all
block log quick inet proto tcp from <ssh-denied> to $ssh_servers port
ssh label accessive-ssh
Ok, so all your block rules do have the 'log' option. That rules
out the
most obvious explanation.
There are other causes for a packet to get dropped by pf, besides
matching a block rule.
The packet could be invalid (like, be too short, or have invalid
checksums), or the source-tracking limits (which I see you're
using) are
kicking in, or the packet might almost (but not quite) match a state
entry. In these cases, a ruleset evaluation is not needed (as the
packet
is dropped unconditionally), hence it can't match any block rule (with
or without 'log' option). But all such cases increment various
counters.
Run pfctl -si, note the output, reproduce the blocked packet that
doesn't get logged. Then run pfctl -si again. Compare the two outputs.
Are any counters increasing? At least a packet and byte counter should
increase, but do other counters increase as well? Reproducably,
correlating with the blocked packets that aren't logged?
Unfortunately this is a production firewall, i.e. more than just my
test traffic is going through but not a super busy one either. :)
# cat /tmp/before
Status: Enabled for 0 days 02:05:34 Debug: Urgent
Interface Stats for rl0 IPv4 IPv6
Bytes In 145632230 0
Bytes Out 9974283 0
Packets In
Passed 123136 0
Blocked 996 0
Packets Out
Passed 74352 0
Blocked 363 0
State Table Total Rate
current entries 129
searches 408328 54.2/s
inserts 5887 0.8/s
removals 5873 0.8/s
Counters
match 7512 1.0/s
bad-offset 0 0.0/s
fragment 0 0.0/s
short 0 0.0/s
normalize 0 0.0/s
memory 0 0.0/s
bad-timestamp 0 0.0/s
congestion 0 0.0/s
ip-option 0 0.0/s
proto-cksum 149 0.0/s
state-mismatch 0 0.0/s
state-insert 0 0.0/s
state-limit 0 0.0/s
src-limit 0 0.0/s
synproxy 1109 0.1/s
#
#
# cat /tmp/after
Status: Enabled for 0 days 02:05:49 Debug: Urgent
Interface Stats for rl0 IPv4 IPv6
Bytes In 145636144 0
Bytes Out 9979325 0
Packets In
Passed 123178 0
Blocked 999 0
Packets Out
Passed 74399 0
Blocked 363 0
State Table Total Rate
current entries 125
searches 408533 54.1/s
inserts 5901 0.8/s
removals 5891 0.8/s
Counters
match 7528 1.0/s
bad-offset 0 0.0/s
fragment 0 0.0/s
short 0 0.0/s
normalize 0 0.0/s
memory 0 0.0/s
bad-timestamp 0 0.0/s
congestion 0 0.0/s
ip-option 0 0.0/s
proto-cksum 150 0.0/s
state-mismatch 0 0.0/s
state-insert 0 0.0/s
state-limit 0 0.0/s
src-limit 0 0.0/s
synproxy 1109 0.1/s
#
Also, explain what packet the test with telnet you described is
expected
to cause, in what direction on what interface, with what source and
destination addresses and ports. Even better, verify that expectation
and capture the first SYN packet of that telnet test with tcpdump and
post it. Incoming packets are seen by tcpdump even when pf blocks
them.
If you don't see the packet with tcpdump at the pf box, it might
simply
never arrive there, and pf isn't blocking it at all.
The source of the test packet was 24.97.84.35 (another OBSD 3.9
box). The destination was 24.97.84.33 and the destination port was
4343 (a random port that is not allowed). The packet should arrive
on carp0 of the pf box, in the inbound direction.
# tcpdump -n -vvv -i carp0 host 24.97.84.35
tcpdump: listening on carp0, link-type EN10MB
17:04:20.729172 24.97.84.35.22969 > 24.97.84.33.4343: S [tcp sum ok]
1957914173:1957914173(0) win 16384 <mss
1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 4274751561 0> (DF)
[tos 0x10] (ttl 64, id 51518, len 64)
17:04:26.725267 24.97.84.35.22969 > 24.97.84.33.4343: S [tcp sum ok]
1957914173:1957914173(0) win 16384 <mss
1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 4274751573 0> (DF)
[tos 0x10] (ttl 64, id 13025, len 64)
^C
114 packets received by filter
0 packets dropped by kernel
#
So the packet did get there, arriving on carp0. Below is the output
from trying to see the packet logged. Clearly other packets are
there but the packet I generated did not show up.
# tcpdump -n -e -ttt -i pflog0
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: listening on pflog0, link-type PFLOG
May 18 17:05:31.223993 rule 0/(match) block in on rl0:
24.64.110.177.3605 > 24.97.84.33.445: [|tcp] (DF)
May 18 17:06:35.360653 rule 0/(match) block in on rl0:
65.80.159.50.13117 > 24.97.84.33.1026: udp 1089
May 18 17:10:10.387842 rule 0/(match) block in on rl0:
24.97.196.179.3049 > 24.97.84.33.445: [|tcp] (DF) [tos 0x40]
May 18 17:10:10.975262 rule 0/(match) block in on rl0:
24.97.196.179.3049 > 24.97.84.33.445: [|tcp] (DF) [tos 0x40]
May 18 17:10:11.483153 rule 0/(match) block in on rl0:
24.97.196.179.3049 > 24.97.84.33.445: [|tcp] (DF) [tos 0x40]
May 18 17:14:32.726996 rule 0/(match) block in on rl0:
204.16.208.74.35146 > 24.97.84.33.1027: udp 360 (DF)
May 18 17:16:15.159209 rule 0/(match) block in on rl0:
65.41.237.206.5256 > 24.97.84.33.1026: udp 1053
Hopefully this information helps.
-Chad
