On 27 Mar 2013 at 16:01, David Ruggiero wrote:
> Thanks to Jan for pointing out I neglected to include the macro defs
> for the nets (though they're vanilla and what you'd expect). Here's
> the full source for the first rule, the one I think should catch the
> bogon packets but doesn't:
>
> int_net = "192.168.5.128/25"
> wls_net = "192.168.10.128/25"
> ptr_net = "192.168.99.128/25"
> table <unroutable_ips> const { 10.0.0.0/8, 172.16.0.0/12,
> 192.168.0.0/16, !$int_net, !$wls_net, !$ptr_net, 169.254.0.0/16,
> 127.0.0.0/8, 192.0.2.0/24, 0.0.0.0/32, 240.0.0.0/4,
> 255.255.255.255/32
> }
> block drop in log quick on ! lo0 inet from <unroutable_ips> to any
> label "block unroutable ip"
>
> The rest of the question below remains the same.
>
> thankee much /david/
>
>
> On Wed, Mar 27, 2013 at 10:12 AM, David Ruggiero
> <thatseattle...@gmail.com> wrote:
> > The very, very first rule in my pf ruleset is part of a fairly
> vanilla anti-spoof/sanity check set, intended to catch incoming
> bogon/martian packets:
> >
> > table <unroutable_ips> const { 10.0.0.0/8, 172.16.0.0/12,
> 192.168.0.0/16, !$int_net, !$wls_net, !$ptr_net, 169.254.0.0/16,
> > 127.0.0.0/8, 192.0.2.0/24, 0.0.0.0/32, 240.0.0.0/4,
> 255.255.255.255/32 }
> > block drop in log quick on ! lo0 inet from <unroutable_ips> to any
> label "block unroutable ip"
> >
> >
> > I can see it being evaluated using "pfctl -v -s rules", but so far
> (~40hrs uptime) it hasn't matched anything yet. That would normally
> > not be of concern, except I'm seeing stuff like this in the pflog
> that I think it should have caught - but had to get caught by a
> later,
> > fail-safe rule at the bottom of the ruleset. In particular, I'm
> seeing lots of bootp packets from badly-configured Windows clients:
> >
> > Mar 26 19:22:05.85 rule 49/(match) [uid 0, pid 2590] block in on
> em0: 0.0.0.0.68 > 255.255.255.255.67: xid:0x64f14f [|bootp] (DF)
> [tos
> > 0x10] (ttl 64, id 0, len 330)
> >
> > So:
> > - Is there something wrong with my first rule that I'm not seeing
> that causes these 0.0.0.0 bootp packets to miss it, OR
> > - Is there something special about the bootp packets [remember,
> bootp uses UDP] that they won't match that rule, even
> > though the source is in the unroutable_ips table?
> >
> > Thanks for any insight, or other debugging ideas I can test.
> > /d/
> >
> > PS: Notice the "quick" keyword in the block rule - this isn't a
> "last rule that matches" issue, in case you're tempted to reply with
> > something about that - I would think a packet from 0.0.0.0 should
> hit the rule, match, and then due to "quick" undergo no further
> > evaluation, end of story.
>
>
Did you take the time to display the content of the table?
'pfctl -t unroutable_ips -Ts' should do the trick, and then you would
see that 0.0.0.0 is *not* in the table. I just ran a quick test to
verify that it is not possible to add such an "address" to a table. I
did not dig through the source code and is not an expert on the IP
stack as some devs on this list, but I do suspect that there are many
special properties attached to a null address field.
