I'm finally caving in...

...and sitting the CISSP exam. I mentioned this to a few people today and got one of two reactions:

1. They immediately lost all respect for me, or
   
2. Ok, I lied. There was only one reaction.
   

I admit this was based on a rather limited sample, but wow. People really seem to hate the CISSP, all it stands for, it's dog and the horse it rode in on.

I've read some of Richard Bejtlich's thoughts on the matter (which made quite the splash when they were originally published). I agree with him that the ISC(2) code of ethics is pretty much all the CISSP has going for it, but I don't think that explains the vituperousness of the reactions I see whenever CISSP is mentioned. Nor do I necessarily think it's jealousy, because most of the people I get this from could easily pass the exam (if they were willing to pony up the $500 fee).

It seems to me as though I've detected a bit of a pattern, though: the more comfortable a person is working with technical matters, the less likely they are to respect the CISSP. Is it just our geeky tendency to look down upon those things which can be done by any suit and tie lackey? Is the perception that
CISSP == management == PHB? I don't think it's really that simple, but maybe us geeks just need someone to love to hate and Bill Gates wasn't available today.

If anyone has any theories they'd like to share, or if you hate people who hold CISSPs and would be kind enough to let me know why, please leave a comment.

March HRSUG meeting

Hi, all. I just want to remind everyone that the March meeting of the Hampton Roads Snort Users Group (HRSUG) is coming up:

Date:  Wednesday, 8 March 2006
Time:  7:00PM
Place: Williamsburg Regional Library
       515 Scotland Street
       Williamsburg, VA
       (757) 259-4040

As of this moment, there is no topic assigned to the meeting. I'll work on that, but if anyone has a suggestion or would like to volunteer to talk about something, please let me know.

Weird Cisco attacks happening all over the world

On February 4th, I started seeing small numbers of the following Snort alert:

Cisco IOS HTTP configuration attempt

Here's a breakdown of the number of alerts per day for the first couple of weeks of the month:

| 2006-02-04 |        6 |
| 2006-02-05 |        4 |
| 2006-02-13 |        2 |
| 2006-02-14 |        1 |
| 2006-02-15 |       30 |
| 2006-02-16 |       26 |

There were two things that drew my attention to this activity. First, it's an old exploit (detailed in this advisory. Second, there was a sharp spike in activity starting on the 15th.

Around the same time as I noticed this, the SANS ISC Handler's Diary posted an entry about it, and they didn't know what was going on either. I contacted them about it, and have since heard nothing in reply.

I didn't think too much about this at first, but after collecting a few more days' worth of data, I noticed the following: Each source IP only attacked one destination IP, and while is usually a steady stream of 3 or 4 alerts per hour, there are some periods where I go for several hours without seeing anything. These things tend to suggest that the attacks are coordinated, probably through a single botnet.

Today, I heard from several other analysts around the planet who have seen similar traffic. I got the IPs and timestamps from a few of them and am in the process of analyzing some of the data. What I can see so far is that we've got around 280 individual attacks from ~250 unique IPs. Each of the three sites reporting has at least a few IPs in common with the others, further supporting my idea that this is all due to one big botnet.

I don't have much information yet, but big thanks to fellow #snort-gui regulars David Lowless and hewhodoesnotwishtobenamedbutknowswhoheiseventhoughIrefusetousehiscodenameJesus for providing data and sharing thoughts & ideas about this. It may all just turn out to be nothing, but the coordination and stealth involved make it interesting if nothing else.

Update 2006-02-24 15:53: I asked around on the #shadowserver channel, and have found that attacks like the ones I observed have been found in at least one active botnet (not sure if the scattered sightings are from different botnets or not).

Why they are probing for 5 year old vulnerabilities in Cisco routers is still a mystery. Maybe they just want to use them as proxies for IRC/spam/other attacks. I hope that's the extent of their ambitions.

Update 2006-03-06 11:41: Based on conversations I've had with others who are experiencing these sorts of attacks, I've concluded that the most likely scenario is that the perpetrator is hoping to gain access to Cisco devices in order to use them as IRC proxies to hide their true network address while trading credit card numbers and other illicit info. In other words, they can log on to the devices and initiate outbound network connections to IRC servers. One analyst speculated that there may be an IRC client plugin of some sort to facilitate this, and that seems like a reasonable assumption.

BTW, if this technique is used to disguise IRC, it may also be used to disguise connections to other services as well (HTTP?). This all seems like a pretty roundabout way to achieve the hypothesized goal, but certainly in keeping with technology that existed at the time the original exploit was discovered. Maybe someone is just using some old scripts they found online somewhere?

Update 2006-03-07 06:53: The Philippine Honeynet Project (which I reached via this SANS ISC diary entry) has also noticed these probes. Their analysis includes the name of the tool they believe responsible (ciscoscanner). Unaccountably, though, they're suggesting that the tool is looking for the vulnerability listed in this advisory, which doesn't seem to fit the observed data. It's good to read that some other people have finally noticed this, at least. They kind of stick out like a sore thumb if you're paying attention.

Dshield for IDS systems?

Most of us are probably familiar with the Dshield project, which collects firewall logs from users around the planet. They process this data to extract attack trends and produce reports we can use to help evaluate the potential "hostileness" (my term) of a given IP address.

While going through my morning sguil operations, I thought to myself, "Why haven't we done this for IDS events yet?"

My idea is very simple. Sguil requires an analyst to assign each event to a different category (e.g., "successful admin compromise", "attempted compromise", "virus activity", "no action required", etc). For those categories which correspond to confirmed malicious intention, why not collect data about the alerts and forward them to a central clearinghouse?

Of course, you wouldn't want to collect all the data, for privacy reasons. You'd probably only want the attacker's IP, the timestamp and a common reference number to show what event occurred (the snort sid, for example, though that only applies to a single IDS). You could further apply some basic rules to the data before submission, to delete all records originating from your own network, for example.

So what would be some of the benefits of this system? First, the clearinghouse would be in a position to notice hosts which were attacking large segments of the Internet. This determination would be based on confirmed data submitted by human analysts and would therefore be more inherently trustworthy than data garnered from firewall logs. Second, the clearinghouse could directly observe and report on the types of attacks being seen in the wild, something the existing Dshield project cannot do. Finally, this data could be fed back down into the IDS analysis tools to help adjust the severity of observed events based on how similar events were previously categorized by other analysts. Sort of a Cloudmark for IDS.

I'm not suggesting that there's anything wrong with Dshield. They're providing a great service that I rely upon to help me make decisions every day. It's just that they're only capturing one type of data (firewall logs). I think their model could logically be extended to IDS operations, to the benefit of the entire community.

Update 02/14/2006 11:36: Someone on the #dshield IRC channel mentioned that this idea also sounds similar to Shadowserver. True enough, though they're using their own net of mwcollect and Nepenthes collectors to track malware distribution, and so they're not capturing IDS data. Great for tracking automated attacks and generating high-quality blacklists of sites actually distributing malware. Not quite what I had in mind, but also a very valuable dshield-esque service. Check them out, but keep in mind that they haven't gone public with their data yet. If you ask nicely, though, they might give you access to the IRC channel that keeps track of the botnet reports in realtime. I'm going to check it out.

Sguil 0.6.1 released

There's a new Sguil release to start your morning. 0.6.1 features an updated client that's more responsive to large data sets. It also has some major new features, like:

• The use of UNION in the MySQL queries is now the default. This has led to at least an order of magnitude decrease in the search time in my own (huge) SANCP database.
  
• There's a new panel that displays snort statistics for each sensor. This finally allows you a semi-realtime view of packet loss and traffic/session statistics for each sensor.
  
• Communication between the sensors and the server can now be encrypted with OpenSSL/TLS, using the same mechanism that protects the traffic between the client and server.
  
• Numerous important bug fixes
  

I've been using the prerelease version of this code for a little while now, and it works a heck of a lot better than 0.6.0p1 did.

One thing that I did notice is that it's not quite a drop-in replacement for the old version. If you are using TclTLS to encrypt client/server communications, you will need to add the "-o" command line flag to your startup script to turn this feature on. In previous versions, specifying the TLS library location with "-O" was enough, but now two subsystems can use the same library (the client and the sensor communication paths) so you have to explicitly tell sguild which one(s) you want to encrypt.

This small caveat aside, if you're using sguil, you probably should upgrade at your earliest convenience.

Packet fragmentation issues in the Snort IDS

One of the features that will eventually make it into Snort is a new processor for handling fragmented IP packets (the "frag3 preprocessor"). Sourcefire's Judy Novak has written a paper outlining the challenges to doing proper fragmentation reassembly, entitled Target-Based Fragmentation Reassembly.

It just so happens that Judy is speaking on this topic tonight at our HRSUG meeting, so if you're looking for more information about frag3 issues, now you have the link.

Update 2006-02-14 08:53: As Joel Esler pointed out, I got this whole topic badly wrong. I'm not really sure why, since I'm pretty familiar with frag3 and have been using it for some time. Maybe I was just rushed. Yeah, that's it.

Anyway, the actual topic was the new stream5 TCP stream reassembly preprocessor, and it's application of target-based stream reassembly policies. It was, by the way, and awesome presentation! Thanks, Judy, and come back to see us any time!

DDoS bot owner's story

A web server managed by fellow #snort-gui regular Chas Tomlin was recently attacked and turned into a DDoS zombie. Chas wrote up his experience and shows how he used a combination of network (sguil) and host forensics to track down the source of the problem. A good read, and he includes code, too. My favorite part is the IRC log where he secretly captured two of the bot operators chatting about the how they got in.

Disabling IPv6 under Linux

I set up a sguil sensor at home this weekend, and decided to have it monitor outside my firewall, just because I wanted to know what things looked like out there. This was a version of Linux, and I followed the standard host hardening prescription of turning off unecessary services and interfaces. Since I'm not using IPv6, I wanted to turn support for it off entirely.

Being too lazy to compile my own kernel (good bye, easy updates) I wanted to find a good way to disable IPv6 globally. It turns out that the easiest thing to do is to add the following to your /etc/modules.conf file, then reboot.

           alias net-pf-10 off

This prevents the kernel from loading the module that supports IPv6 (called, "ipv6"). This is a CentOS 4.2 box, and I could find no easier way of accomplishing the same thing.

February HRSUG Meeting Reminder

Just a reminder that the February meeting of the Hampton Roads Snort Users' Group is this week:

Date:  8 Feb 2006
Time:  7:00PM
Place: Williamsburg Regional Library
       515 Scotland Street
       Williamsburg, VA
       (757) 259-4040

Our guest speaker is Sourcefire's Judy Novak, who will be speaking about target-based fragment reassembly in Snort. Judy's bio and presentation abstract can be found in the original meeting announcement.

BackTrack Security LiveCD Beta

I don't watch football (Superbowl? What's that?) so while the entire US is shut down to watch an East Coast/West Coast smackdown, of course I'm playing with the new BackTrack LiveCD.

In case you're not familiar with this project, this is the first beta release of the projects formerly known as Auditor and WHAX, merged into a single distribution that looks, on first glance, like a really strong offering.

I never used WHAX, but I have followed Auditor for about a year. It was a really nice collection of pre-installed security tools, mostly hacking and cracking packages like network scanners, vulnerability assessment tools, bluetooth utils, password crackers and the like. Not only did the OS offer reliable hardware autodetection, but the Auditor team went through a lot of trouble to add run-time autoconfiguration to many of the included tools (think: no more editing kismet.conf).

This version of BackTrack will look very familiar to Auditor users. It preserves much of Auditor's look-and-feel, including the task-oriented launch menu that made it so easy to find the right tool for the situation. There are still an awful lot of tools available, though I haven't compared the lists to see which were added or dropped in the conversion to BackTrack.

While the old Auditor releases were monolithic CD images, BackTrack is based on the SLAX Slackware LiveCD, and now offers easy GUI-based ISO customization. This was originially a feature of WHAX/SLAX. This customization feature makes it easy to create a specialized BackTrack ISO for whatever you have in mind.

For example, even though the beta was just released today, I found that there were already three patches available. You read that right: patches for a LiveCD ISO. I downloaded the three module files from the BackTrack website as well as the Windows-based SLAX customization tool, MySLAX Creator. Within about 1 minute, I had remastered the ISO to include the new patches. Sure enough, at boot time it recognized the additional modules and loaded them into the running image.

Although the software on the beta release is not itself modularized, this is planned for the future, giving users the ability to strip out things they won't need. Users can already create additional modules to add to their ISO images, and I may try this with the Sguil and InstantNSM software.

Tomorrow, I hope to find time to play with some of the included tools some more, especially the bluetooth utilities. In the meantime, if you're at all interested in a security tools LiveCD, you really should give BackTrack a try.

My experience with m0n0wall

My home LAN's firewall router died last night. I had an old Linksys with which I was fairly satisified. It's cheap, quiet, doesn't use much power, and of course, keeps people off my network. When it died, I was kind of annoyed (I've only had it about 18 months) but I've seen this coming for a few days now. Firewall crashes, DHCP problems and the unexplained inability to access the management port while Internet access is working had been the normal state of affairs. This is all to say that I'd been looking around.

Since I'm a hands-on kinda guy, I have been looking around at some of the specialized firewall OS distributions, all Open Source. The leader here seems to be m0n0wall, which is a stripped down OpenBSD. When my firewall finally died, I had already downloaded the distribution CD image (about 5MB), but hadn't tried it out yet. So of course, I figured "no time like the present."

I was very pleasantly surprised to learn that the whole installation and configuration experience took me only about 20 minutes. About half that time was spent removing a network card from an older system and adding it to the firewall box and burning the ISO image to a CDR.

I started by booting the CDROM and configuring the NICs. Not being a BSD user, I would never have guessed that my interfaces were named things like dc0 or xl0, but fortunately m0n0wall has a nifty autodetection routine that will detect which cards you have available and which is plugged into the LAN or the WAN side of your network. I didn't have to know anything about BSD NICs, so that was nice.

After that, everything was done via the web interface. I plugged in my powerbook (yay for the magic no-crossover-cable-required Ethernet port!) and started configuring. If you're used to consumer grade products like my old Linksys, you'll be glad to hear that m0n0wall supports HTTPS connection security, although not by default. In what is probably the only gotcha in the whole process, m0n0wall will not generate a unique SSL certificate for you, so you're sharing the same cert used by every other m0n0wall owner. If you haven't changed the certificate, you have no security. There is a GUI interface to upload your own certificate, but you have to generate it yourself. M0n0wall won't do this for you.

Shortly thereafter, I had the whole thing up and running. NTP, DHCP server & client, Dynamic DNS and traffic shaping. I even had the chance to try out some of the snazzy statistics features, like the interface usage graphs, which are very impressive. Take that, Linksys!

Overall, I'm very impressed with the software. The hardware is a stock PC, though, which eats power and generates noise. The m0n0wall software also supports the Soekris 45xx and 48xx series systems, which seems like a good platform for this application. I'll probably try this eventually, but in the meantime I'm loving the creamy m0n0wall goodness.

Update 2006-02-02 09:21 Sorry, m0n0wall is a stripped down version of FreeBSD, not OpenBSD as I mentioned above.

One of the best I've seen

We all know that seemingly innocuous email can hide all manner of nasties. Somehow, we still have the misconception that "I can tell a fake when I see it." Think so? Check out this email purportedly from F-Secure.

I don't meant to gush over the efforts of malware writers, but this is one of the best email social engineering attempts I've ever seen. The email is well written and literate. It purports to address a legitimate problem and offers assistance in solving it. More importantly, it triggers almost none of the usual heuristics users use to identify malicious email. The sender has even chosen the spoofed "From:" address carefully, so as to allay any fears that there might be a unwelcome payload. Who could possibly expect bad things from one of the world's leading anti-virus companies?

I say these things not to praise the spammers (who are, after all, greedy scumbags), but to point out that the bar for this sort of attack has been raised. Are your users prepared for this?