Security Incidents mailing list archives

Re: Code Red II - Dead Thread


From: Dave Laird <dlaird () kharma net>
Date: Tue, 7 Aug 2001 10:22:32 -0700 (PDT)

Good morning, everyone...

I wrote the following text file for a number of clients this morning who
have *still* been seeing their Cisco 67x DSL Routers get mysteriously
punched offline by the Code Red Worm. [Standard Disclaimer] This is *not* an
"official" solution by any means, but is something that, thus far, I have
found to be working on those Cisco 67x units which still have problems, even
after upgrading to the latest CBOS. DL

***
Now, regarding the Cisco 675 DSL Router anomalies which have kept support
busy the last few days, I tentatively believe I have found a workable
solution for those systems which otherwise cannot be fixed using a simple
upgrade to CBOS Version 2.4.1, which does appear to work in some instances.

I currently am running CBOS Version 2.4.1, the latest release, which was
installed last Monday. Since that time I have had to manually power down the
675 unit eight or nine times, due to lock-ups which I believe are caused by
the Code Red Virus. In *every* instance when a power-down was mandated, at
the instant the 675 locked up, there was a scan (similar to those above)
taking place in the Apache log files. There were *no* exceptions to this
rule, which adds credibility to my belief that the two are inexorably
related to one another.

While there have been a number of parties in the various newsgroups/mail
lists that have reported that upgrading to the latest CBOS has "cured" their
lock-up problems, they are clearly not in the majority. A number of others
reported that, with the new CBOS installed, although it still locked up the
system, they were able to telnet to their 675's and thus perform a remote
reboot of the 675. Others, such as myself, found that the upgrade had little
to no discernable effect on the lock up anomaly.

I began attempting alternative solutions *only* when I had exhausted all
conventional means of addressing this problem, long after both Qwest and
Cisco more or less said "I don't know a solution to your problem", which
took place over a week ago.

Since the Web interface built into the Cisco 675 seemed to be the only
affected portion, my first attempt, within the CBOS, was to limit the IP
addresses which could connect to it, since the interface was disabled since
May of 2001.

Following up on a tip by a network engineer in one of the mailing lists, I
first tried setting my connection in the CBOS to a non-existent Class C
address, which in theory would therefore reject any other attempts to
connect to the web interface. Here is the entry screen by which you reach
that point in the CBOS:

cbos#set web
Error: Possible Parameters
disabled        Turn off application
enabled         Turn on application
port            Set Application Port Number
remote          Set Remote IP Address

There is some evidence that this reduced the number of "lock-ups", although
they did persist once this change was put in place last Thursday morning.
Further follow-ups to the mailing list also suggested that I was not the
only person for whom this technique did *not* work, and hence several
subscribers began testing the port itself, to see if perhaps there was an
additional method open to us.

Early yesterday afternoon, after a thorough discussion with various members
of the mailing lists and newsgroups, I set the port assignment for the Web
interface inside the CBOS to a non-standard, unused port from the IANA list.
In this case, port 5 is not used by my system, save for in the web interface
of my Cisco 675 unit. Due to the fact that the logging inside the CBOS unit
is marginal to almost nonexistent, there is no way to track the number of
attempts that have been made to connect to port 80 (the web default) on the
675 unit since the port assignment was changed. As a secondary precaution, I
also have firewalled port 5 in my ipchains firewall.

Thus, as of yesterday afternoon, here are the setting which I have deployed
in the 675 CBOS, which I feel have stopped the lock-up problems, at least
for the time being:

WEB Configuration
Is not enabled
Currently accepts connections only from 10.0.0.100
Currently uses port 5

Comments and/or input into this ongoing process is always gratefully
accepted.

Dave
-- 
Dave Laird (dlaird () kharma net)
The Used Kharma Lot

 Fortune Cookie:
If we do not change our direction we are likely to end up where we are headed.



----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com


Current thread: