From: Gandalf The White <gandalf@digital.net>
To: "David S. Miller" <davem@redhat.com>
Cc: Linux IPStack <netdev@oss.sgi.com>
Subject: Re: Fragmentation Attack
Date: Sun, 08 Feb 2004 15:12:36 -0600 [thread overview]
Message-ID: <BC4C0264.E3F3%gandalf@digital.net> (raw)
In-Reply-To: <20040208124528.2c667378.davem@redhat.com>
Greetings and Salutations:
On 2/8/04 2:45 PM, "David S. Miller" <davem@redhat.com> wrote:
> On Sat, 07 Feb 2004 12:00:42 -0600
> Gandalf The White <gandalf@digital.net> wrote:
>> The requirements of the attack (from the perspective of the paper I wrote)
>> was that you had taken over 20 cable modem computers. From this viewpoint
>> this could (of course) produce the required number of packets IMHO.
>>
>> Of course you could also clog up the bandwidth of just about any destination
>> network with this requirement, but that is a different DoS.
> Yes, but this very fact makes the "DoS" much much less interesting.
> If I can clog your link anyways with arbitrary traffic, who cares
> what it does as a second order effect, the machine is made unreachable
> and unusable either way.
Exactly. So I was discounting the "clog your connection" attack. What I
was looking at is if someone has a fast machine that they can send a
regulated amount of packets to and test out the fragment attack that would
be good. I suspect that this attack would still spike the CPU on a machine
at a relatively low (a few hundred) packets per second rate. On a web
server or other Internet Facing machine that has a decent load this could be
enough CPU overhead to create a DoS.
> Also, these half-complete ICMP packets are really super easy to create
> firewall rules for to block them at ingress of a major site.
The attack has ICMP, UDP and TCP. If you were seeing a specific signature
over and over again then I agree that it might be easy to block (depending
on the firewall) ... But ... If someone were sending fragments destined for
port 80 to your web server I don't see how you could differentiate between
"real" fragments going to the web server and faked fragmentation requests.
Ken
---------------------------------------------------------------
Do not meddle in the affairs of wizards for they are subtle and
quick to anger.
Ken Hollis - Gandalf The White - gandalf@digital.net - O- TINLC
WWW Page - http://digital.net/~gandalf/
Trace E-Mail forgery - http://digital.net/~gandalf/spamfaq.html
Trolls crossposts - http://digital.net/~gandalf/trollfaq.html
next prev parent reply other threads:[~2004-02-08 21:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-07 17:36 Fragmentation Attack Gandalf The White
2004-02-07 17:45 ` David S. Miller
2004-02-07 18:00 ` Gandalf The White
2004-02-08 20:45 ` David S. Miller
2004-02-08 21:12 ` Gandalf The White [this message]
2004-02-08 21:18 ` David S. Miller
2004-02-12 2:20 ` Gandalf The White
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BC4C0264.E3F3%gandalf@digital.net \
--to=gandalf@digital.net \
--cc=davem@redhat.com \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.