[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] 1.1 is out!
 Date:  Mon, 23 Aug 2004 21:18:01 -0700 (PDT)
On Mon, 23 Aug 2004, Frederick Page wrote:
> Manuel Kasper wrote on Sun, Aug 22 2004:
> 
> >>The color on the php-page is always red, ipfw always shows "block".
> 
> >This happens when you select neither "TCP" nor "UDP" as the protocol
> >and is explained on the rule edit page.
> 
> Sorry for the stupid question, I'm really ashamed that I did not read
> the text carefully enough. Of course you're right, it works fine now.
> 
> >>2. I'd like to have a distinction for ICMP sub-types. I e.g. want to
> >>allow type 3 (DF needed, PMTU discovery) and disallow type 5 (ICMP
> >>redirect).
> 
> >Will be considered.

While that would be useful, blocking ICMP Redirect isn't as important as
you might think, for a couple of reasons:

1) Most implementations are pretty picky about honoring ICMP Redirect,
since it's only meaningful when coming from the next-hop gateway.  I agree
that it's better not to forward those, but even if you do they'll most
likely be ignored unless the attacker can get spoofed IP addresses
through.

2) If you'e using NAT, ICMP Redirect (like any other ICMP error) won't
even get through the router unless the embedded IP header matches an
existing NAT mapping.  Anyone in a position to forge a plausible embedded
header is in a position to do much nastier things than forge ICMP
Redirects. :-)

> Thank you. I realize that it might be a "geek" feature and too
> complicated for normal users, since they probably wouldn't know what
> to configure here.
> 
> Maybe a simple (optional) flag "strip DF flag on outgoing packets"
> would be
> 
> 1. more easy to implement in e.g. "advanced setup" and
> 2. not as complicated, meaning less impact on user-friendliness?

Aarrgh.  No, no, no.  That would break the cases where PMTUd works fine,
and force fragmentation on things that are trying to avoid it.

> Then one could completely ignore/drop ICMP without being a bad
> netizen. It might be even a good idea, to enable such a "strip DF"
> flag by default, since most people probably have no explicit ICMP
> rules (meaning they drop ICMP-type 3).

No explicit rules are needed.  The stateful filter automatically passes
ICMP errors associated with established flows, regardless of rules.  The
only effect of blocking or passing ICMP in the rules is to determine
whether incoming ICMP *requests* (e.g. pings) are accepted.

Fragmentation Needed errors aren't the only useful ones - e.g. the only
non-timeout way of determining that a UDP-based service isn't available is
via ICMP.  And there's traceroute, of course.

					Fred Wright