Monitoring and Incident Prevention

Something popped up on the Internet Storm Center Handler's Diary entry for today that struck a chord with me. In the entry, the handler talks about corporate infrastructures, and why they continue to get hit with the various malware that seems to be rampant on the Internet.

The reason this hit home with me is a combination of my book, and the fact that I'm currently doing a technical review of Ed Skoudis's second edition of Counter Hack. In one of the chapters I just reviewed, Ed does a great job of describing warwalking and wardialing, and presents some of the usual means of locating rouge APs and modems. In the case of wardialing, for example, Ed recommends wardialing yourself. On the other hand, or perhaps in addition, I would highly recommend that sysadmins learn a little programming and use WMI to implement monitoring tools and scanners. For example, using the Win32_POTSModem class, an admin can scan systems in her domain for installed modems, using VBScript, Perl, C#...whatever works. To me, it's quick, efficient, can be done during working hours and isn't disruptive.

Okay, back to the ISC post...what interested me about this is that it's someone else saying, "we still aren't doing all that we could." I agree. For the most part, corporate environments aren't doing what they can to protect their own infrastructure and data. Why this is, I don't know. The new mysql worm has hit some folks...why TCP port 3306 is exposed to the Internet, I'll never know. I still haven't heard a convincing business case (I take that back...I haven't heard a business case, convincing or otherwise) for why MSSQL systems were exposed to the Internet back when the Slammer worm hit.

I'm not sure what I'm missing here, to be honest, because a lot of what can be done is non-disruptive and doesn't cost a lot. For example, IIS web servers that are already in place can have unnecessary script mappings disabled without affecting the function of the systems. Other things that may be a bit more disruptive, such as putting technical measures in place to require users to use strong passwords, may be a bit harder, but if upper management considers it a requirement, and documents it, what stops it from happening?

Something administrators can do is perform their own scanning. Nmap comes in a Windows-based binary, and can be used to detect rogue WAPs, identify systems running servers they shouldn't, etc. Don't want to have to comb through the glut of data returned by nmap when run against a large domain? No problem! Perl has modules for parsing the XML output of nmap, and yes, those modules install on Windows systems running ActiveState's Perl. Like I mentioned before, WMI can be used to scan for a wide variety of things, including services and device drivers that are installed, perform hardware and software inventories, etc.

The...uhm...tools are out there folks. I'm still at a loss to understand why so many systems still get hit by these admittedly "dumb" bits of malware.