Re: Stealthing

In article <4falvnF1hduldU4@xxxxxxxxxxxxxx>,
Sebastian Gottschalk <seppi@xxxxxxxxx> wrote:
Walter Roberson wrote:

There are no security features in icmp, and in particular there
is no authentication that an ICMP ECHO packet comes from the IP
that it claims to come from. If a terminal firewall or router
responds to ICMP ECHO requests directed to non-existant systems with
ICMP UNREACHABLE packets (of whatever subtype), then that firewall
or router makes a nifty contribution to DDoS (Distributed Denial
of Service) attacks.

Why? How?

Have your "owned" systems spoof icmp echo packets, addressed to
security gateways that respond with ICMP Unreachables, with the source
address set to the system one wants to DDoS. The resulting Unreachable
will not go to the system that sent out the ICMP, but instead
to the system whose IP address appeared in the ICMP. The attack
then becomes practically untraceable, and if a large group of
such intermediate security gateways are used, the attack cannot
reasonably be filtered based upon IP.


Furthermore, it takes resources on the security gateway to
ARP for the destination, hold that status until a timeout, and then
create an ICMP UNREACHABLE packet. If the security gateway has a
heavy load -- normal traffic or just a lot of random probes or a DoS
or DDoS attack -- then responding can be an unaffordable drain on
resources.

That's why rate limits are good for!

And what does one do when the rate limit is hit?

If the gateway responds with ICMP UNREACHABLE, perhaps with a subtype
about administrative policy denial, then resources are still required
for that (keep in mind that upload bandwidth might be considerably
lower or proportionately more expensive than download bandwidth.)

If the gateway just drops the ICMP ECHO packet without reply, then the
security gateway has joined the ranks of the "only a few lousy big
ISPs" (or whatever the exact wording was), as not producing
-any- ICMP UNREACHABLE HOSTUNREACHABLE is merely the same thing
as rate limiting such respones to zero.


For these reasons, -many- security gateways are set to NOT respond
to ICMP ECHO, and NOT respond to TCP or UDP packets that do not
match the local security policy.

Fine, but routers at your ISP are not primarily security gateways.

I don't see the relevance of that last remark to anything that
I had said? I made no statement about the propriety of ISPs
filtering ICMP on behalf of their customers or on behalf of the
ISPs' infrastructure: my remark was merely that failing to produce
ICMP Unreachables was common at security gateways, to which someone
counter-claimed that it was not common, in response to which I
explained why it -is- common on security gateways.
.

Relevant Pages

  • Re: 2000 server solution
    ... Definitely not on layer 2 or 3. ... Give me a reason to hide something, that is designed for public access. ... tcp-rst or icmp port unreachable is ... Yes, so please explain, why you consider ICMP echo replies und icmp echo ...
    (comp.security.firewalls)
  • Re: Domain nicht mehr erreichtbar
    ... Dieser Host antwortet nicht auf ICMP ECHO Requests. ... Verbindungsprobleme mit den GMX Servern einbrachte), ...
    (de.comp.sys.mac.internet)
  • Re: Sicherer Webserver?
    ... ICMP ECHO zu rejecten ... eher ICMP ECHO zu droppen (was die Sache zwar auch nicht wesentlich ... aber keine "Haluk'schen Schwarzlochfilter fuer ICMP". ...
    (de.comp.os.unix.linux.misc)
  • Re: Ok to let all ICMP traffic through firewall?
    ... :ICMP is throwing the baby out with the bathwater and will cause more ... :bother than not blocking anything. ... :I would suggest allowing ICMP Echo and Echo Reply, ...
    (comp.security.misc)
  • Re: Ok to let all ICMP traffic through firewall?
    ... :ICMP is throwing the baby out with the bathwater and will cause more ... :bother than not blocking anything. ... :I would suggest allowing ICMP Echo and Echo Reply, ...
    (comp.security.firewalls)