At 01:37 PM 1/1/97 -0500, Michael Idengren wrote:
>
>Speaking of denial-of-service attacks, how would one go about tracing
>packets with a false IP header?
>
I assume that you mean spoofed source addresses here when you mention
'false IP headers'. This is a tough problem, and being on the receiving
end of this, there's really no much you can do at this point.
I also assume that what you refer to below as 'we have got our router
configured properly so that it doesn't let any packets leave our network
with false headers' is traffic filtering on ingress to ensure that only
traffic originating from valid downstream prefixes (ones which you are
advertizing upstream) is allowed to traverse the intermediate next hop
(your router), as described in draft-ferguson-ingress-filtering-01.txt.
My coauthor, Daniel Senie [Proteon], and I are going to be submitting
an update to this draft (and perhaps subsequent updates) so that we can
get this moving for publication as an Informational RFC. We're still
waiting to incorporate some additional text & comments into the document
on how it breaks certain technologies (such as mobile IP).
As an aside, there are several discussions surrounding the use of
bogus source addresses in any denial-of-service attack. One such
discussion involves what type of DoS attack we're talking about
here; TCP SYN or UDP flooding.
In the case of TCP SYN attacks, one might argue that if the source
address, whether bogus or not, does not exist in the routing table,
then completion of the three-way handshake should not be negotiated
by the receiver. This would appear to be a simple defense. A more
insidious attack method (also mentioned in the draft), however, is
one in which a bogus source address is used by the attacker, but
which is actually a valid, routable, reachable prefix in the routing
table, but which actually belongs to another end-system. The end
result is an exercise for the reader.
Any TCP SYN attack which uses reachable prefixes, and are bogus
source addresses of the true originator, is a hard problem to solve.
There are several devices which have been recently introduced which
proxy the SYN/ACK between originator & destination host which do not
attempt to complete the three-way handshake after 'x' number of SYN's,
however, I won't mention them by name in this forum. There will
probably be additional features such as this introduced in the near
future. Also, there are several OS vendors which have enhanced the
way their particular operating system handles this type of attack by
increasing the appropriate queue depths & decreasing the appropriate
timer values. I won't reference them either.
In any event (and back to the original question), tracing an attack
back to the true originator is tough, and requires the assistance
of network administrators within each administrative domain the
attack traverses on an autonomous system hop-by-hop basis. If you
can trace the attack on a hop-by-hop basis, gleaning previous hop
information, the attacker can be traced to its true source.
In an ideal world, one might expect the various Internet service
providers to cooperate in tracking down the perpetrator of such
an attack; in the Real World (tm), sometimes the amount of
cooperation leaves a lot to be desired. This is not to say,
however, that it cannot be done; in fact, it was successfully
done just recently to track down the perpetrator of such an
attack.
Prosecuting them is another issue entirely. ;-)
So, what can you do? Log, log, log. And more logging. And get
to know the security administrator upstream from you.
- paul
>The delimma here is that we have got our router configured properly so
>that it doesn't let any packets leave our network with false headers. But
>there's a whole slew of people out there with routers who either don't
>care or don't know how to filter bad outgoing packets. This presents a
>big problem for us if someone decides to execute a denial of service on
>us, or even do a simple IP spoof in a hacking attempt so we can't trace
>them.
>
>Any Suggestions?
>
--
Paul Ferguson || ||
Consulting Engineering || ||
Herndon, Virginia USA |||| ||||
tel: +1.703.397.5938 ..:||||||:..:||||||:..
e-mail: pferguso @
cisco .
com c i s c o S y s t e m s
|
|
