Stoopid MS Tricks part one:

Looking for Your Wallet Where the Light is Good

There's a joke about a drunk on his hands and knees under a street light, looking for his wallet. Guy comes by, asks where he saw it last.

"Over there in that alley."

"Why are you looking for it here?"

"The light is better."

I had a situation where that makes sense. It was the case of a Weird Cisco Malloc solved (by someone else).

We'd been having malloc errors that shut down one interface on a Cisco GSR 12008 router. Very intermittent, and started the day before Cisco announced three vulnerabilities. Also, it hit another router in the district (but did not affect two others). I found a lot of things we could do to protect the router, including recieve ACLs and requiring a TTL of 255 for BGP traffic to ensure packets actually came from a neighboring router. Didn't help. I was going nuts trying to find a way to dig out information from the linecard, including memory and cpu status. Never did find anything. I was on the point of borrowing a line card from someone else when a coworker pulled it to try blowing any dust off. Turns out there was some, but the main thing was a RAM module dangling loose. He seated the module and the problem went away.

Blows me away that two routers could fail from something like that at the same time...

Also blows me away that there would be no error messages or that the failure would be intermittent. And that line card status is so unobtainable. These things are computers in their own right. They should have status instrumentation.

The simplest troubleshooting algorhythm is sort of a problem of a binary search, divide the possibilities in half. I think I will consciously weight the expense of checking a problem vs. its likelihood. That is, in this case hardware still seems an unlikely explanation (two routers failing the same way? Experiencing the same rate of thermal creep? Not buying it!). But it's so cheap to check. If you have a spare line card. We didn't have a spare long haul GBIC but we could have looked at everything else very easily. In other words, we could have looked where the light was good rather than wade through the various contradictory and redundant Cisco MIBs trying to make the thing reveal its secrets.

D-Link AirPlusG DWL-G630 is machine washable.

That's kind of cool. Might be necessary, what with all the pr0n you internet pervs are into.

Minor Fix (?) for Snort Decoder

We deployed a sensor where it could observe traffic hitting the external interface of a border router. Every BGP packet trips an "Experimental TCP Options" alert.

Now, I could disable that with a config disable_tcpopt_experimental_alerts directive, but maybe I want to watch for really odd stuff? As far as BGP goes, RFC 2385 providing for putting an MD5 hash as a tcp option dates from August 1998, about as old as Snort itself. (http://www.ietf.org/rfc/rfc2385.txt) So is it still appropriate to treat that as experimental and alert on it? As far as I know it's standard for BGP.

I know I can suppress, too. I think it would be better not to work around it.

I changed decode.c as follows:


line 3923 in 2.7 current as of 2007-02-06
From:
case TCPOPT_MD5SIG:
experimental_option_found = 1;
code = OptLenValidate(option_ptr, end_ptr, len_ptr, TCPOLEN_MD5SIG,
&p->tcp_options[opt_count], &byte_skip);
break;

to:

case TCPOPT_MD5SIG:
experimental_option_found = 0;
code = OptLenValidate(option_ptr, end_ptr, len_ptr, TCPOLEN_MD5SIG,
&p->tcp_options[opt_count], &byte_skip);
break;

I tried it out and recompiled, seems to work. That is, it no longer alerted on tcp option 19 (MD5SIG) and did alert on other things. It's possible I broke the decoder alerts, but I doubt it.

I followed the link provided in decoder.c http://www.iana.org/assignments/tcp-parameters
to see if there was anything else I should disable alerting on. Mostly dodgy stuff, if you ask me. But BGP using MD5 to transmit passwords is not a new thing.

I'll update here if the Snort developers pimp slap me for breaking decoder.

ISOI II was very cool

http://isotf.org/isoi2.html

It was a closed gathering of security researchers, ISP reps and LEOs to which I wangled an invite. There was much cool stuff presented, but not much of operational interest. That is, I only took away ideas that would consume about 3 weeks worth of uninterrupted project time (or about 3 years job time). But the social networking was vast. I spoke with a Distinguished Engineer at Comcast, the inventor of the spanning tree protocol (http://research.sun.com/people/mybio.php?uid=28941). Various folks from Spamhaus. Botnet researchers, the Internet Storm Center (isc.sans.org), and on and on. Matt Jonkman of Bleeding Edge Threats (formerly Bleeding Snort), too. So if I have some issues, I have some people to talk to.

Golly, it's fun to be around so many smart people.

The coolest actionable idea for me (very timely, too!) was from a guy at Qwest who turned me on to filtering on TTL < 255 for communication with border routers. The idea is, you are only exchanging BGP data with neighbors. Maybe SNMP and ssh (or, gulp, telnet) from a management station. Set up pass ACLs for the management stuff, and then drop anything else with a TTL under 255. So you KNOW that any traffic directed to your router (not transit traffic, obviously) comes from a neighbor.

They can spoof addresses (hard with tcp, harder with BGP passwords) but they can't spoof the TTL. So the only place they can attack is from a neighbor (or an ip address that seems to be from a management station - and that's hard)

It rekindled my enthusiasm for this stuff. I've asked for a legal memo either authorizing or not authorizing deployment of a honeypot/honeynet. If I get the ok, I'll deploy and provide a listening post. You may need such a memo yourself as this can fall under wiretap statutes. It would suck to be prosecuted for violating an attacker's privacy!