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

Re: pf security - is pf failsafe if config file invalid?



On Mon, Nov 14, 2005 at 11:49:40PM -0600, Travis H. wrote:
> 1) On UDP keep state rules, do they allow replies from other IPs?  The
> DNS spec says that servers can respond from a different IP than the
> one they received the query on.
No, only replies coming from the expected IP address and UDP port are
passed (that's how packets are matched to states). If the server is
replying from a different address/port, it won't match the outgoing
state. You can either drop it (I've never seen a real server do this),
or allow all incoming UDP (to your resolver's port). pf doesn't inspect
DNS payload to associate replies with queries.
> 2) For UDP and TCP, does it allow ICMP replies that reference this
> connection in the payload?  I seem to recall reading something that
> indicated so, but exactly how does it decide?
An ICMP error (like TTL exceeded or fragmentation needed) always
references the packet it refers to by including that packet's IP header
(and at least some beginning of the UDP header) in the ICMP payload,
i.e. such an ICMP packet looks like this
  [ outer IP header ]
  [ ICMP header ]
  [ ICMP payload, consisting of ]
    [ inner IP header ]
    [ UDP header (truncated) ]
For example, you might be getting an ICMP error
  IP 62.65.145.29 -> 10.1.2.3
  ICMP type ICMP_UNREACH code ICMP_UNREACH_NEEDFRAG
    IP 10.1.2.3 -> 62.65.145.30
    UDP sport 65001 -> dport 53
where you initially sent a UDP packet from 10.1.2.3:65001 to
62.65.145.30:53, but the intermediate router 62.65.145.29 dropped it
because it would have needed fragmentation (but had the don't-fragment
bit set).
pf will extract the source/destination addresses/ports from the inner
IP and UDP headers and match THOSE against your state entries, letting
the ICMP error pass if it matches a state.
Daniel