Active Directory SPOF

We had a great example of an AD SPOF (single point of failure) recently.  A vbscript had been written by someone with no malicious intent to (for some reason) hook into AD and check service accounts.  What this script ended up doing though was locking out said service accounts.  Within the span of 30 minutes we were well on our way to locking out 400+ service accounts in the enterprise, irrespective of environment.  This took production out of commission.
Seems like a bit of a hole to me.

Network isolation

For the second time this week, production has gone down for an extended period of time. This time it was because of this bug introduced by McAffee. It was proliferated through all of our environments (apparently) by SSCM. I'm not sure why we are putting McAffee fixes right into production without testing them in a staging environment first. Seems to me like there is a wrong process there somewhere - Either on our side, McAffee's side, or both.
Before we realized this was a McAffee bug, it seemed that this 'virus' got propagated to production from lower environments. Having the production environment on an isolated network from the rest of our development and test environments would have protected us to some degree from this kind of propagation. I have (officially) suggested this more than once, but resourcing and other priorities have gotten in the way of making it a reality.
For future reference though, here's just another reason to have a production environment on an isolated network.

Log parsing/network security tools

I discovered some new tools today that are useful for network security. QRadar from Q1 labs (http://www.q1labs.com/) is a really slick log parsing tool for organizations that are looking to implement a distributed log management offering to collect, archive, and analyze network and security event logs. It then parses this information into graphs and data that you can tune to alert you when things go awry. You can configure it to look at firewall logs, web server access logs, event logs, etc.
Splunk (http://www.splunk.com/) seems like it might be a competitor. At a glance, I'd say that QRadar has a lot more features and might be a lot more expensive.

IT Security

Over the past few years I've seen sensitive information exposed in some very interesting places on enterprise networks and servers. Sometimes this leftover information can be super helpful if you're trying to debug problems or get an idea of what happened on the box in the past. In other cases, it just plain bad. Here's some of what I've seen:

• Shared drives mapped all over the enterprise. Shared drives mapped on production boxes with access to files that contain sensitive info like passwords for production users.
• Kickstart configuration files with username and passwords for domain users in clear text forgotten on servers
• Passwords and sensitive information exposed in .bash_history files. Bash_History files are a treasure trove of information. They'll show you all kinds of things - where the db server is located, what the connection string is, where http servers are installed, how to shut them down and start them up....etc.
• *.udl files - Microsoft specific. They store connection information in clear text for db servers. Don't leave them lying around and exposed.
• Installations for UPS (Universal Power Supply) systems left with their default configured administrator username and password. I happened to find a login page for a UPS console one day and logged in on the first try using the first password I could think of. The dashboard I subsequently found myself on gave me the power to shut down the entire enterprise.

Here's some simple ways to make your network/enterprise more secure:

• Don't allow a plethora of undocumented mapped drives.
• Do searches for text like 'password' on any boxes, drives, etc that you might be concerned about. If you get results, take steps to either encrypt or delete those files or references.
• Change default installation passwords
  

Schema Crawler

I got back to using schema crawler this week, trying to make sure we can explain the inconsistencies we see in the metadata between our different environments. I found this cool little script to do port scanning so I could discover which ports our DB's were using.

HOST=127.0.0.1;
for((port=1;port<=65535;++port)); do echo -en "$port \n"; if echo -en "open $HOST $port\nlogout\quit" | telnet 2>/dev/null | grep 'Connected to' > /dev/null;
then echo -en "\n\nport $port/tcp is open\n\n";
fi;
done

Stealing the Network

Last week a friend at work handed me a book to check out. It was called Stealing the Network. Boy did I enjoy it. It's basically a collection of 'fictional' hacker/security consultant stories. The stories cover the whole gammit of hacking, from social engineering to deconstructing worms, to stealing a 0-day exploit. I found it super interesting.

In their stories, the authors go into detail with the kinds of tools they use. Netcat, Snort, John the Ripper, and Ethereal all make an appearance, as well as many others. It's interesting to compare the list of tools used in this book with the list at sectools.org.

I'd highly recommend the book if you're familiar with any of these tools or have an interest in secure networks.