Date: Fri, 5 Feb 1999 10:16:39 -0800
From: John Bashinski <jbash@CISCO.COM.>
To: [email protected]Subject: Re: Widespread Router Access Port DoS
[cust-security-announce people: The quoted paragraph is from a posting
on "[email protected]"]
Yet again, I have to remind y'all that sending these to BUGTRAQ will
not get you as fast a response as sending them in directly. At least
not from Cisco; can't speak for 3Com or anybody else.
This is very preliminary information for Cisco routers; I just saw the
message I'm responding to about an hour ago. There may be more going on
than this. We'll continue to test and characterize this, and will send
out updates as appropriate.
> The tcp access / configuration ports on most routers can be disabled
> remotely. These sit on port numbers like 23,2001,4001,6001, and 9001.
> The attack simply consists of shoving a few thousand bytes of any
> character down the connection, a couple times may be needed for some
> routers, with the length of time of the DoS related to the amount of
> bytes you send down the initial connection. Some Cisco's would have to
> be reset manually to fix this, others will recover by themselves given a
> few minutes, hours, or days. ComOS seems to be in the manual-reset
> category, as I haven't found one yet that recovers from a 1 minute
> attack onto thier access ports. Normal operation continues, only in a
> few freak cases did the router drop the entire network / reset
> connections as a result.
I was able to reproduce something like this. At least in my tests, it
appears that the router isn't noticing that the TCP connection is being
shut down by the initiating end. I don't yet know why; it could be
a bug on either end. I'll assume it's a Cisco bug, and report it as such,
but it would be interesting to know what sort of machine you were
using for your testing. I'm using Linux 2.0.x with netcat as the
traffic-sending program.
Since the TCP connection isn't deleted, the virtual TTY (VTY) is not
being released. If you run a bunch of attacks, you eventually end up
with all your VTYs hung up on nonexistent connections. If you can
reach the router at all, you can reclaim them with the "clear line"
command, but if they're all hung up, you may not have a way to get
in and do that.
Although the router's getting into this state under these circumstances
is very probably caused by a bug, and we will address that bug, it's
very important that everybody understand that it would be possible to
create the same condition *without* any bug. The easiest way would be to
keep opening (and not closing) TELNET sessions to the router, until it
refused to accept any more, then simply turn off the power on the
initiating system, so that the sessions were never closed properly.
That's just the way TCP works. It affects any system that accepts TELNET
connections and doesn't use TCP keepalives. It may be aggravated by a bug
in this case, but you can definitely make it happen without having a bug.
There are several ways to mitigate this vulnerability in your Cisco
configuration:
1. Don't accept TELNET connections from just any old host on the network.
Do something like this:
access-list 1 permit host <trusted-host-1>
access-list 1 permit host <trusted-host-2>
...
access-list 1 deny any
line vty 0 4 ! Select all 5 VTYs
transport input telnet ! Don't accept non-TELNET connections
access-class 1 in ! ... and only from listed machines
We very strongly recommend this configuration for *all* Cisco devices,
regardless of this particular issue. It's just plain bad practice to
let everybody on the Internet make interactive connections to your
router.
This is known to work, and should be the primary defense.
2. Configure "service tcp-keepalives-in". This will make the router detect
dropped TCP connections. By default, it won't detect a dropped session
unless it has output to send to that session... which it usually won't
have for a long time, if ever.
I have not fully verified that this one works against the "shoving
bytes into the connection" attack; I can't reproduce the failure
reliably enough to be sure that I've eliminated it. I would expect
this to work. Even if it doesn't end up being a solution for this
situation, it's a good idea in general.
3. Configure timeouts on the VTY lines, so that an idle session can't
permanently occupy a line. You might do:
line vty 0 4
exec-timeout 10 ! Disconnect if no commands for 10 minutes
session-timeout 10 ! Disconnect if outgoing session and no input
I don't think that this one will work with this particular problem, because
the failure is at the login prompt. It's a good idea, though, if you want
to keep your VTYs from being eaten up over time by dead sessions.
It may be a few days before we have more information than this.
-- J. Bashinski
Cisco Systems
Product Security IRT
