Malformed Packet Causes Cisco Router DoS
MoreBeer writes "Patch 'em if you've got 'em... Cisco Security Advisory: Cisco IOS Malformed OSPF Packet Causes Reload states that a malformed OSPF packet can cause a router 'reload' (reboot). Vulnerable IOS versions include 12.0S, 12.2, and 12.3 ... If you're not screening OSPF at your perimeter and using OSPF Authentication, now would be a GREAT time to start."
I notice that Cisco isn't displaying this on their front page. It seems like they should be screaming for everybody to fix the problem.
Quick walkthrough that I usually reference:
Easy example how to setup OSPF Authentication
AC
Before someone has a chance to reset my r
at the risk of stating the obvious: if you were a new customer and went to a company's site and it was splattered with all manner of warnings, update calls, and exploit workarounds....would you buy that product?
If you have a cisco, you should already know where the errata, update, exploit-watch pages are and read them everyday. You should already know this. Why would cisco put that shit on the front page?
Patch 'em if you've got 'em...
What a crock of shit. Everybody knows Cisco boxes are no route to host
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
May I recommend OpenBSD with carp as a alternative.
I had to look it up. OSPF
What a great time to post a link to www.routergod.com! Here are the two parts of Seven of Nine's lecture on OSPF:
http://www.routergod.com/sevenofnine/
http://www.routergod.com/sevenofnine/ospf_part_2.h tml
conf t
access-list 150 deny ip 10.0.0.0 0.255.255.255 any
access-list 150 deny ip 127.0.0.0 0.255.255.255 any
access-list 150 deny ip 169.254.0.0 0.0.255.255 any
access-list 150 deny ip 172.16.0.0 0.15.255.255 any
access-list 150 deny ip 192.168.0.0 0.0.255.255 any
access-list 150 deny ip 224.0.0.0 15.255.255.255 any
access-list 150 deny ip 240.0.0.0 7.255.255.255 any
access-list 150 deny ip 248.0.0.0 7.255.255.255 any
access-list 150 deny ip host 255.255.255.255 any
access-list 150 deny 89 any any
access-list 150 permit ip any any
interface
ip access-group 150 in
exit
exit
wr mem
To be honest, if this causes trouble for you then it's your own damn fault. If you accept OSPF packets from the Internet and/or you're not doing OSPF authentication then you deserve to be pwned.
1. Don't use an IGP on an exterior interface.
2. Don't send out routing updates on subnets/interfaces that don't need it. (For those of you with L3 switches that means using the passive-interface command on your vlans.)
3. If your routing protocol offers an authentication option then use it.
I used to think these things were obvious. Then I started interviewing other "senior" network engineers and realized they may not be...
(BTW, kiddies, if you say you're a "senior network engineer" and you say that you know OSPF and I ask you if OSPF uses multicast or unicast and when does it use it/them then you had better be able to answer the question...)
"Where quality is like a dead stinking rat - you just can't miss it."
Malformed color scheme Causes Eyes to Bleed
/. sections include IT and Games. If you're not already using a /. deuglifyer, you should use the fix provided here."
"Slashdot Security Advisory: Slashdot Color Scheme states that a malformed IT Color Scheme can cause a eyes to 'bleed' (fall out). Vulnerable
A few years ago I worked at a place where we had two Cisco PIX (the 1U widgets, dunno what model, sorry) in a failover configuration. For those that don't know, you can run two kinds- stateful and non-stateful failover.
In stateful failover mode, the two units share their connection state info over a dedicated ethernet crossover cable- in theory, if one unit's hardware shits the bed, the other one immediately notices and takes over, and all users will notice is maybe a few seconds pause in everything, if that. It's all very clean and good, the slave even takes over the MAC address of the failed unit (something they've patented, and hence isn't useable in Linux HA; Linux has to force an ARP announcement, which is messier. Goooooo Cisco!)
Anyway, that's great, except when you have a software defect. Oh, say...where the PIX OS (PIXes didn't run IOS or whatever, they ran a separate OS unique to the PIX family) gets into a certain situation based on state and locks up hard.
Well, guess what happens to its twin, running the same PIX OS version, and sharing the same data? Yup, it crashes too.
The pair actually did it once right in front of us- one stopped blinking its lights...the master/slave light blipped on the backup unit, and then a few seconds later, it too crashed- and everything ground to a halt.
It was terribly amusing that Cisco was incompetent enough to not include a hardware watchdog in the PIX box so that if it hung it would reboot itself; my Sonicwall SOHO has this, why can't a PIX for chrissakes? The problem only happened every few days, and would have been manageable(ie ignorable ;-) if they had both simply rebooted themselves. Instead, someone had to trundle in and power cycle both of them, until we figured out that it was state-based, and disabled stateful failover. Then someone just had to check every day to make sure one of them hadn't kicked the bucket.
Please help metamoderate.