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=72588&t=72463 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
