nettime's_roving_reporter on Wed, 9 Feb 2000 23:10:51 +0100 (CET)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

<nettime> Denial of Service Attacks: How they work



Source: http://www.wired.com/news/technology/0,1282,9506,00.html (Jan 7, 1998)

<...>
A smurf begins when a single malicious user sends a stream of Internet
Control Message Protocol, or ping, packets - used to determine if a machine
is alive - to a target network's central "directed broadcast" address,
which is rarely used, but easily obtained. This address pings all the
machines - often 255 boxes or more - on the target network.

Each of the hundreds of hosts on that target network will dutifully respond
with a "yes, I'm here" answer packet back to what they understand to be the
ping's origin address. But the cracker has forged the source address of the
originating ping packets.

"The [faked originating address] is the poor hapless victim of the smurf,"
explained Nielsen. Instantly, the target network is hopelessly clogged, as
Nielsen outlined with a typical smurf scenario.

"Assume that someone on a 28.8k modem can safely send out 42 64-byte ping
packets... per second," said Nielsen. "When sent to a fully loaded
broadcast network, this becomes 10,626 packets, or 5.2Mbits of data per
second."

"That's easily enough to kill off a T1," said Nielsen. "If the person
originates the smurf from a faster link, and uses multiple relay networks,
they can easily kill off a 10Mbit fractional [T3]. This is why it's so
incredibly bad."

Further, there is nothing a victim can do to regain connectivity other than
ask upstream network providers, usually national service providers such as
UUNET, Sprint, and MCI, to filter the ICMP packets. But so far, according
to Nielsen's own experiences - and those of others on ISP mailing lists -
"Very few of the backbone providers seem to be concerned."

<....>




Source: http://users.quadrunner.com/chuegen/smurf.txt (8.2.2000)

<....>
The "smurf" attack, named after its exploit program, is one of the most
recent in the category of network-level attacks against hosts. A
perpetrator sends a large amount of ICMP echo (ping) traffic at IP
broadcast addresses, all of it having a spoofed source address of a victim.
If the routing device delivering traffic to those broadcast addresses
performs the IP broadcast <....> most hosts on that IP network will take
the ICMP echo request and reply to it with an echo reply each, multiplying
the traffic by the number of hosts responding. On a multi-access broadcast
network, there could potentially be hundreds of machines to reply to each
packet.

The "smurf" attack's cousin is called "fraggle", which uses UDP echo
packets in the same fashion as the ICMP echo packets; it was a simple
re-write of "smurf".

Currently, the providers/machines most commonly hit are IRC servers and
their providers.

There are two parties who are hurt by this attack... the intermediary
(broadcast) devices--let's call them "amplifiers", and the spoofed address
target, or the "victim". The victim is the target of a large amount of
traffic that the amplifiers generate.

Let's look at the scenario to paint a picture of the <...> nature of this
attack. Assume a co-location switched network with 100 hosts, and that the
attacker has a T1. The attacker sends, say, a 768kb/s stream of ICMP echo
(ping) packets, with a spoofed source address of the victim, to the
broadcast address of the "bounce site". These ping packets hit the bounce
site's broadcast network of 100 hosts; each of them takes the packet and
responds to it, creating 100 ping replies out-bound. If you multiply the
bandwidth, you'll see that 76.8 Mbps is used outbound from the "bounce
site" after the traffic is multiplied. This is then sent to the victim (the
spoofed source of the originating packets).

<...>


#  distributed via <nettime>: no commercial use without permission
#  <nettime> is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: [email protected] and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: [email protected]