Routers and DOS Re: Possible DoS attack (?)

["Alex P. Rudnev" <alex () virgin relcom eu net>]

The real problem is much more serious than it's used to think; I believe the
only reason why we did not seen a lot of chain network failures caused by the
different DOS attacks is just the same why _no one can catch the John - because
no one want to do it_.

Seriously, 90% of this attacks was caused by those who'd like to drop off their
virtual enemies from the IRC or the CHAT server, or want to compromise some WWW
server, or want to fraud some information in the network. No one of this tasks
could be solved by the DOS against the routers.

But if someone decide to break down the network attacking the routers, it more
than possible. I think all of us know about some exploits used SYSLOG failure in
the CISCO routers; it's many ways to slow router down by the data stream caused
the router to use the processor switching (may be CEF can help here, I do not
know). Moreover, I had a few very strange accidents here in Russia, when one
dark night a chain of Cisco-7206 routers failed and appeared to be without the
NVRAM config due to some uninvestigated scanning. And more complex the router's
OS became, the more volurentable this routers became... 

Of course, routers usually have well designed IP stack and are not affected by
the simple TEARDROP and so on programs; on the other hand, a lot of TCP and UDP
services just as (for example) GRF tunnelling etc could be used to break the
routers... No, there is a little chance to get access to the network, but the
chance to slow network down or to torture it to the (virtual) death is very
high.

Of course, some new features are doing this attacks less effective. CEF
switching, reverse-path address control, etc etc... But the danger of such
attacks really exists, and is not limited by the ICMP attacks only.

Alex Roudnev.


On Tue, 9 Nov 1999, Martin Cooper wrote:

> Date: Tue, 09 Nov 1999 15:03:52 +0000
> From: Martin Cooper <mjc () cooper org uk>
> To: Clifton D. McKinney <clift () alltel net>
> Cc: nanog () merit edu
> Subject: Re: Possible DoS attack (?)
>
>
> "Clifton D. McKinney" <clift () alltel net> wrote:
>
> > Is this something that the "no ip directed-broadcast" command
> > would prevent?
>
> Nope (unfortunately)...
>
> I think I should clarify what the problem is again, since I've
> had a few private emails that suggest that what I originally
> wrote was confusing.
>
> The route-cache (fast-switching) speeds up switching by building
> a simple lookup table of IP-prefix/output-interface pairs by
> doing a routing table lookup (process-switching) for the first
> packet it sees that is addressed to any destination prefix.
>
> The problem is that to implement ICMP redirects, Ciscos have
> to do process-switching to figure out that the source and
> destination addresses are both out of the same interface and
> can therefore talk to each other directly (i.e. without
> pointlessly bouncing traffic off the router and causing the
> same traffic to go over the same network twice, wasting
> bandwidth).
>
> This would be fine and dandy if when they sent a redirect,
> the host that received it listened to it, and stopped bouncing
> traffic off the router, but if it doesn't (either stupidly
> or maliciously) then all traffic that is being bounced off
> the router has to carry on being process-switching, burning
> CPU cycles like it's going out of fashion.
>
> If you turn on 'ip route-cache same-interface' the router
> will still send a redirect for the first packet addressed
> to a particular prefix that it sees because it has to
> process-switch it to figure out what to put in the route-
> cache, but after that it will use the cache, and not look
> at the source addresses of packets to that destination at
> all (try turning on 'debug ip icmp' to see this behaviour).
>
> Whether you use the command or not is a trade-off based on
> whether you want redirects to work properly (stopping traffic
> being bounced off the router unnecessarily if other hosts
> listen to them), or if you would rather not burn CPU when
> other hosts don't listen to them and you have to switch the
> traffic back out of the same interface anyway.
>
> M.

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)