Correct me if i am wrong but an ACl on the interface that denies all traffic DEST to your "router" will prevent this "full queue status" I haven't had time to read as much as i should. I placed 12.3 on my routers 2 weeks ago. The way i understand it is that i am ok.. I don't feel that way but that what i have heard.. Sorry for being out of the loop but i have been in class this week and haven't had time to read up on this
Thank you, Seth -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 1:49 PM To: [EMAIL PROTECTED] Subject: Re: a really big bug [7:72463] Alas, are we going to see the demise of trace-route as a useful troubleshooting and performance tracking tool? Probably would make sense. It sure makes it easy to find router addresses! :-) Good to have you back, Chuck. I hope the road is treating you well. Priscilla "Chuck Whose Road is Ever Shorte wrote: > > Nice post. a couple of thoughts in line below: > > ""Reimer, Fred"" wrote in message > news:[EMAIL PROTECTED] > > I do not agree, although I believe my own co-worker does. > Where do you > > think attacks on the Internet are launched from? Yes, there > may be some > > looser of a person (script kiddie) launching an attack from > their home > > network, but I'd guess that a fair amount of attacks are > launched from > > inside corporate networks (or universities). > > especially universities and other educational intisutions - > don't forget > your tech schools :-> > > > > > With that said, it is obvious that the first and most > important fix be on > > the outside, Internet accessible, IOS devices. However, I do > not believe > > that internal devices are immune. They will be until > easy-to-use exploit > > tools become available (how many organizations have competent > black-hats > > inside their network that will be capable of determining the > magic packets > > on their own?), but I wouldn't be willing to bet on that > timeframe. > > > > It sounds to me, from my reading of the advisory, that it's a > little more > > complicated than "simply increasing the input buffer." With > a default of > 75 > > on some routers, it wouldn't take that much traffic to > completely block > ALL > > interfaces on a device so that you couldn't even get to it to > increase the > > buffers, and it doesn't take a rocket scientist to figure > that out. > > > > In all likelihood an attack would spew out the appropriate > number of > packets > > to all router interfaces in your entire network, that's what > I would do if > I > > were launching an attack, a task likely accomplishable in a > small number > of > > seconds. Because of this, you may not even be able to > determine where the > > attack was coming from, and your entire network would be down > until you > > manually reset each IOS device, even at remote sites, which > may take quite > a > > while to do. As soon as you reset the device, its interfaces > would be > > blocked again. So, your only recourse would be to unplug the > device from > > the network entirely, upgrade the IOS, and then put it back > in the > network. > > it occurs to me that an attack of this nature requires the > patience to seek > out and record the ips of all router interfaces. the ethernet > side is > usually not to difficult. most folks use the same ip host > number on all of > their routers, all of their subnets. usually 1, 100, 101 or > 254. Discovering > WAN interface addressing would be more difficult, but > traceroute has its > purpose ;-> Which leads to the advice that a well constructed > access-list > might also include methods for suppressing reporting of this > information. > > > > > Actually, it may not be as bad as that. Wherever the attack > is > originating > > from wouldn't be able to get past their immediate default > router once it > was > > blocked. So, a successful system-wide attack would have to > start at the > > edges of the network, disabling them and then moving towards > the attacker. > > Still doable in a short amount of time, but some planning > would be > required. > > It would also mean that you would need to start rebooting / > upgrading at > > your network edge before you tackle the core (assuming the > attacker was at > > the core) because as soon as you opened up the core then the > attacker > would > > be able to disable the network again. This could be a way of > finding the > > attacker. > > this does not address the mobile user or the "trusted > consultant" both of > which many enterprises have many. > > > > > > Unless it is designed as a DDoS. Then you are screwed. > > > > In order to defend against an attack you need to imagine how > you would > > devise one. I'd be willing to bet that I could disable your > whole entire > > network if I were given access inside somehow (VPN, dial-up, > etc), and I > had > > access to the magic packets. > > don't forget your wireless, particularly those rogue access > points. > > > > > Will this doomsday scenario materialize quickly? I don't > believe so. > > However, since I build and support networks in hospitals not > doing > anything > > is not an option. Keep in mind that most hospitals have a > hard time > > scheduling time for maintenance. It will likely take a few > months to get > > all devices upgraded. (Scheduling at night is sometimes not > better than > in > > the morning, as after dark and after bars close is usually > not a good time > > to have the lab interface, or MRI devices, off-line. Shift > change is also > > usually not a good option, nor is the time that doctors make > their > rounds). > > > funny you should mention this. we were doing a wireless project > at a large > hospital recently. our work hours were 3:00 a.m. through 7:00 > a.m. bummer. > > > > > My recommendation would be to upgrade all IOS devices as > maintenance > windows > > allow. At a minimum install the ACLs that Cisco recommends > on all routers > > immediately. > > > > Fred Reimer - CCNA > > > > > > Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA > 30338 > > Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 > > > > > > NOTICE; This email contains confidential or proprietary > information which > > may be legally privileged. It is intended only for the named > recipient(s). > > If an addressing or transmission error has misdirected the > email, please > > notify the author by replying to this message. If you are not > the named > > recipient, you are not authorized to use, disclose, > distribute, copy, > print > > or rely on this email, and should immediately delete it from > your > computer. > > > > > > -----Original Message----- > > From: Robertson, Douglas [mailto:[EMAIL PROTECTED] > > Sent: Friday, July 18, 2003 10:34 AM > > To: [EMAIL PROTECTED] > > Subject: RE: a really big bug [7:72463] > > > > I would like the opinion of the group as to what they are > suggesting to > > customers or doing on there own network. I am of the opinion > that as long > as > > the network (Intranet) has been correctly protected, > firewalls/ACL on the > > perimeter and that the internal network device IP's are not > accessible > from > > the Internet there should be no immediate requirement to go > through the > > entire network upgrading the IOS. This could introduce some > new bug/issue > > into the network that will have more catastrophic > consequences than the > > remote possibility of someone attacking a router/switch and > causing a port > > to stop forwarding packets for a small time period. The work > around for > > fixing a device that has been attacked is to simply increase > the Input > > buffer (this will allow the port to start forwarding packets > again) and > > then schedule a reload. This is much more predictable than > introducing a > new > > bug (known or unknown) into the network by upgrading all the > devices. If > > there was already a project underway to upgrade the network > then obviously > > upgrade to the fixed versions. > > > > So my stand point is to ensure that the perimeter devices > offer the > required > > protection against this attack and not upgrade a stable and > functional > > network based only on this vulnerability. > > > > Again this is my opinion and I just want to find out if I am > way off base > or > > if this is what other professionals are doing. > > > > > > Thanks Doug Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72599&t=72463 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
