Re: ICMP pokes holes in firewalls...
In some mail from H D Moore, sie said:
>
> Only if these systems are running kernel version 2.2, the 2.4 NAT system
> has been rewritten and is not vulnerable.
Depending on what you're referring to...
Having quickly (and I emphasise, quickly) looked at icmp_error_track()
in ip_conntrack_core.c, it does not impose any kind of limit on the
number of ICMP messages allowed back in, meaning for one UDP packet
sent out, you could send back 100,000 ICMP messages saying "time exceeded"
or however many will go through until the entry expires (which may be
never if an ICMP error message updates the time.) Anyway, I've only
spent 5 minutes finding what looks like a likely suspect of a function
and not what calls it, etc, where other checking may exist.
I'm not completely convinced that the original poster knew very much
about what they were writing nor understood what is meant to happen
very well either, leaving us with a somewhat confused and scattered
analysis. The threat here is extremely low unless a vendor happens
to do a very bad implementation of allowing ICMP errors back in.
Darren
> On Friday 26 September 2003 04:55 am, Lucio wrote:
> > > This also applies to Linux NAT gateways.
> >
> > I'm rellay not an expert in building a firewall with a Linux box, but
> > I've tried twice and now I have two customers happy of their
> > unexpensive Linux based firewall. These firewalls offer also NAT
> > functionality to the respective LANs they protect and use iptables
> > rules with stateful inspection to filter the packets. Both customers
> > have a DNS in between the linux firewall and the ISP's router. Are they
> > vulnerable to any of those attacks?