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 (dlairdat_private) 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
This archive was generated by hypermail 2b30 : Tue Aug 07 2001 - 15:00:38 PDT