| Реклама: |
IPFilter handles ICMP states in the manner that one would expect from understanding how
ICMP is used with TCP and UDP, and with your understanding of how keep state
works. There are two general types of ICMP messages; requests and replies. When you write
a rule such as:
pass out on tun0 proto icmp from any to any icmp-type 8 keep state
to allow outbound echo requests (a typical ping), the resultant icmp-type 0 packet
that comes back will be allowed in. This state entry has a default timeout of an
incomplete 0/0 state of 60 seconds. Thus, if you are keeping state on any outbound icmp
message that will elicit an icmp message in reply, you need a proto icmp [...] keep
state rule.
However, the majority of ICMP messages are status messages generated by some failure in
UDP (and sometimes TCP), and in 3.4.x and greater IPFilters, any ICMP error status message
(say icmp-type 3 code 3 port unreachable, or icmp-type 11 time exceeded)
that matches an active state table entry that could have generated that message, the ICMP
packet is let in. For example, in older IPFilters, if you wanted traceroute to work, you
needed to use:
pass out on tun0 proto udp from any to any port 33434><33690 keep state
pass in on tun0 proto icmp from any to any icmp-type timex
whereas now you can do the right thing and just keep state on udp with:
pass out on tun0 proto udp from any to any port 33434><33690 keep state
To provide some protection against a third-party sneaking ICMP messages through your
firewall when an active connection is known to be in your state table, the incoming ICMP
packet is checked not only for matching source and destination addresses (and ports, when
applicable) but a tiny part of the payload of the packet that the ICMP message is claiming
it was generated by.