Tools for Auditing and Security

A Free Tool for Testing Your Firewalls and Routers

I see a LOT of firewall configuration files and router configuration files. It’s the bane of my auditor’s existence to read through a PIX firewall config (up to 500 pages of a text file). After the 35th page of text, you could drive a truck through that firewall while I tried to wake up.

Plus, I can’t just log on to the firewall and look at it, oh no. I’m an auditor, and we aren’t trusted with such things (probably just as well). So, when I find a tool that will look at the configuration text file, analyze it and give me a nice HTML report, I want to throw a party.

Allow me to introduce Nipper. It takes a microsecond to turn out an absolutely superb report (and found things I missed!). AND it doesn’t just do Cisco, it also handles Nortel, Sonicwall, Juniper and Nokia. I’m in love. AND I gave the guy $50.00. I hope he had a party for himself. What an awesome piece of work.

It runs in Linux or Windows, and somebody else built a GUI front end, if command line makes your eyes cross. Grab your config files and see what you might have missed.

Looking for Some Good (and FREE!) IT Policy Templates?

Thanks to an email, I’ve come across a great website to offer you when it’s time to go looking for some good policy templates.

SANS, the be-all end-all of security training, has organized a website that offers us free policy and standards templates, as well as a course, if you need it.

You’ll need to scroll down a bit to get to all the templates. There are also some nifty security awareness posters and some explanations for the difference between policy, standards, and procedures.

I downloaded over two dozen document templates. There’s some really good stuff here for Admins and Auditors.

A DAM Good Idea

(Sorry, I apologize for using an acronym, but I couldn’t resist.)

Whenever the subject comes up of logging activity in a database, immediately the complaints of “Too much overhead!” can be heard. Everybody thinks it’s a good idea in theory, but from a practical standpoint, it adds a lot of burdens to the database.

From a security standpoint, it’s really difficult to make sure that DBAs or Administrators are accurately logged AND denied access to the logs. On the database server itself, it’s next to impossible.

This isn’t really a new idea, but it has recently gained a lot of adherents: database monitoring. Quest Software has had some good products around for monitoring performance, but recently the focus (because of compliance, big surprise) has turned to access controls, logging, and monitoring activity.

For example, someone might have noticed a little sooner at Countrywide that someone was accessing a lot of customer data if a Database Activity Monitoring device had been installed.

There are two versions of this type of device. First, is the Network-based DAM, which can monitor all traffic going to and from the database server, and puts no load on the server itself. This is a great idea, unless, of course, your traffic is encrypted. Another issue is that this type of monitoring will miss activity that is local to the server itself.

Second is the host-based DAM, which is really the most effective of the two, because it can see everything you want to see via an agent installed on the server that reports back to the monitoring device elsewhere on the network. The overhead of an agent will not be as high as trying to enable auditing within the database itself, and, as much as I am not fond of agent software, in this case I would make an exception, after careful testing.

The drawback to this system is that the agent could be disabled, but the DAM should immediately alert personnel to that fact. If you are able to size your server appropriately, an agent’s overhead could be minimized. I’d love to hear from anyone using this type of configuration, and how they like it.

Securing the Security Devices

OK, so you’ve bought the glow-in-the-dark, meets all the compliance requirements and looks really shiny “security solution” from a vendor (one or many).

Or maybe your management has bought it and presented it to you as a fait accompli. (Hope I’m spelling that fancy French right!) And of course either you have to manage it (without training, “that’s too expensive, just watch the consultants put it in”), or it’s been “outsourced.”

Or as an auditor, you’ve been told to use it for all auditing functions, and not worry about doing any follow up or periodic testing because this product is such a “time-saver.”

So, how do you know (my favorite question) it’s working and doing a good job? Not what the fancy report it produces says, not what the consultant says, not what the manual says, not what the boss says. What you can actually see.

I’ve been following a discussion on the Security Focus “pen-test” mailing list about how security software has just as many issues as regular software. I don’t like thinking that the software protecting me and writing to a SQL database is using an unencrypted ODBC connection that can be captured by ARP poisoning.

So, although I am rarely asked to audit or test a firewall, IDS or host IDS, having run and learned on all of them, I have some suggestions for you to try out.

NEXT: How to Audit Your IDS/Firewall/ECM for free.

More on Cell Phone (IN)Security

I’m having very mixed feelings, I must say, on what I’ve been reading about accessing information from cell phones. On the one hand, in my line of work, which occasionally includes forensics, I’m pleased to see new tools come out that make my job that much easier. The Cell Seizure Investigator “stick” from Paraben for under $500 is a great new piece of equipment for pulling all information off of a corporate cell phone.

On the other hand, knowing that there is a quick tool to pull all the data off my phone in five minutes or so doesn’t give me warm feelings inside. Given that there isn’t really a secure delete function that is available, anything that is on my phone could be recovered in the same way we can recover deleted data from a hard drive. When will we have the ability to encrypt the storage on these things?

I have seen some early reports of cell phones that use biometric identification, but none that appear to be here in the USA.

I have run across a free tool for deleting data on your cell phone by recellular.com that offers some software based on model of phone. Not all models are covered, and I haven’t had a chance to test it out. If you do, please let me know your results.

In the meantime, review what is on your cell phone, and keep it to a minimum!

Physical Security Part II

The most secure Data Centers I’ve seen utilize electronic access cards of some type that have a good reporting mechanism, right down to which door. Of course, these systems don’t do you a bit of good if no one looks at the logs, but that seems to be the exception, rather than the rule. Thank goodness!

I’ve seen some systems that you must swipe in order to exit, as well as enter. This seems a smart way to make sure employees and cards are being utilized properly. Also, doors should alarm if they are propped open or not quite secured. Depends on how much you value your data, doesn’t it?

Camera systems can be a very good alternative to swipe cards, but ONLY if you have sufficient coverage of the area you’re trying to secure. I tested a system that could see me going up the steps to the Data Center, but didn’t capture me until I was two feet from the door. If I scuttled sideways to the right, it missed me entirely! We adjusted that camera together.
Does your system overlap all areas inside the Data Center? Can you track where someone goes throughout the area?

Finally, is your camera system secured away from the Data Center? Make sure only specific people have access, and make sure the captures are stored securely. How long should you keep them? I’d say a year, which would give you a good period of time to track back possible miscreants. But it really depends on your storage space. If you can use WORM (Write Once, Read Many) storage, even better.

Ultimately, it does come down to your employees. I can’t tell you how many times I’ve slid in the door behind someone holding an armful of books and thanking them for holding the door. If someone strange is sitting in the conference room, it could be me hacking your network. Just ’cause I’m a lady dressed in a really nice business suit doesn’t mean a thing.

How are you disposing of your physical computer equipment? Never underestimate the ability of people to be lazy and just “toss” stuff. Find a way to securely wipe your data OR transfer the risk by hiring someone that will give you a certified receipt that THEY have destroyed it for you. Expensive? Probably? More expensive? Getting your company’s name in the paper.

Auditing iSeries

IBM’s system iSeries are some of the most solid server systems around. Formerly (and by some, still called) the AS400, those servers are at the top of the food chain for reliability and stability. DB2, the native database system for iSeries, is as solid as a rock, and powers many of the banking, healthcare and service industries I get to see.

A lot of engineers will tell you that the iSeries is the most secure OS around, due to the object-level security functions. Those object levels are great, but I can tell you that I find that iSeries are incredibly easy to get into, for two reasons:

First, default services are left enabled. FTP, DDM and ODBC ports on the server are open, and unless you have an exit program, no logging of access takes place. So if I have an application ID and password, I can gain access to see what I can get into. Try a port scan and see what the server tells you.

Last year I saw an iSeries at a merchant (details fudged to protect the guilty) that had NETBIOS enabled. Sitting on a Windows 95 computer in their training room, with a guest ID access, I could see every single file on that iSeries. And I had Full Control of those files. Ooops.

And let’s talk about telnet! Many legacy “green-screen” applications that connect to an iSeries are running via telnet, which means that usernames and passwords are passed to the iSeries in clear text.

Second, special authorities are not locked down. What initial program are users accessing (UPINPG)? If the response is NONE, then they can break through to the command line. How about user classes (UPUSCL)? Have you got people that are part of the programmers group (PGMR) or SECOFR, or SYSOPR? Regular users shouldn’t be in these classes either.
UPSPAU indicates what special authorities each user has. By default, a user should only have access to their printer queue jobs (*SPLCTL), not all objects (*ALLOBJ).

Last, but not least,are the users changing their passwords? I found two with UPPWCD last week… Are there users that are using their username as a password? UPPWON will tell you the facts.

FREE Tool - Changing Local Administratior Passwords On Your Domain

I just love VBS.

And I love the folks that share their tools, AND give us a nice interface AND allow us to push a report to a .csv file. So a BIG thank-you should go out to Jeffrey Hicks, who has his own site, anjd a helpful Blog.

He has a nifty free tool for changing the local Administrator password, PWDMan. This tool also reports on the password age. I’ve been looking for a tool like this to give to the admins I “visit” so that I don’t have to hear any more excuses about how hard it is to change that password periodically.

Jeffrey also has a whole page of VBS scripts and yes, Power Shell scripts, something I’m going to learn when I grow up.

I look for tools I can offer to help admins do their jobs, detect problems and provide easy ways to assess their own systems. I teach how to fish, and try to get buy-in so that the watchfulness happens all year long, not just during an audit.

Auditing MS SQL - Roles, and Why They Matter

SQL “Server” runs on top of MS Windows, and it has groups inside of it that are not seen on the Windows server or even the Windows Domain. That’s why we have to check and make sure that inappropriate users don’t have complete access to everything inside the database. Not everyone should be looking at those payroll files!

So, to confuse us a little more, instead of calling them groups (like Users, Administrators, Power Users, etc) SQL calls them “roles.” There are roles based on SQL as a whole (the SQL “Server”) and roles based on individual databases. Kind of like Domain Admins vs Local Admins.

SQL Server roles are equal to Domain Admins inside SQL Server. They give rights to many different core functions of SQL, and the sysadmins role has rights to everything inside SQL. By default, sa is here, but you should look very carefully at any other user in this group. DBAs like to give themselves a “backdoor” into the server this way, but that should be removed. Best practices recommend always having the DBA use their Domain ID for insertion into this role. This way you can log and monitor their access, and when they leave the company and their ID is disabled, they won’t be able to access the SQL databases. It also let’s them know that you are watching, and people tend to behave better that way.

I have found that software developers LOVE to put their names in this group, and not their Domain IDs, either. If it’s a production database, they have no business having anything other than SELECT rights anywhere. Kick ‘em out!

Here’s the SQL Server roles default permissions:

Fixed Server Roles
Sysadmin – can perform any activity (and Builtin\Administrators are part of this group by default)
Serveradmin – can set SQL-server config options and shut down SQL Server.
Securityadmin – manage logins and CREATE DATABASE permissions, read error logs and change passwords (within SQL, not Windows)
Setupadmin - manages linked servers and startup procedures
Processadmin – can manage processes running in SQL server
Dbcreator- can create alter and drop databases
Diskadmin - can manage disk files
Bulkadmin - can execute BULK INSERT statements

How do you find out who is in these roles? Use the results of a stored procedure: sp_helpsrvrolemember with the results taken from the Master database.

For individual databases, there are database roles. People in these roles can be all powerful, but only within that individual database, not all of SQL. How do you know how many databases are inside one SQL Server installation? Again, a stored procedure: sp_helpdb

You’d be surprised how DBAs like to create their own little mini databases (on production boxes!) just to “do things.” They may be great “things,” but those databases need to go somewhere else.

In order to see the members of all the database roles, run another stored procedure: sp_helprolemember run from each production database in SQL Server. It’s a little tedious, but you will get the information you need.

I commonly monitor the membership in the db_owner role (equivalent to a local server Administrator). By default, the dbo, or db_owner is the only one in this role. If the DBAs are already sysadmins, they don’t need to be in this role, unless you want to be very granular in your controls (NOT a bad idea). Developers shouldn’t be in this role, or just as bad, the application ID of an application accessing data.

This is where a lot of software development falls off the security bandwagon. If the application ID is db_owner, it means that the ID has access to everything in that database. If I can acquire the application ID’s password, (and some of them don’t have one) I can get into all the data. I wouldn’t use the application, just connect directly via ODBC or even Excel.

It’s easier to write applications using the application ID as db_owner, but unless you are using middleware to vet everyone’s login via the Windows Domain, you take the risk of losing all that confidential data out the back door.

If you can acquire this information on a quarterly basis, you will go a long way towards having an easy audit and a better night’s sleep!

FREE Tools for Auditing MS SQL Server

There’s a lot of really nice application tools to audit SQL databases out there. They have lots of bells and whistles and write out a really nice report with professional formatting. If you’ve got one of those, LUCKY YOU. But most of us Admins and Auditors have to scrounge for what we can find with the budget we’ve got (read $0).

So I always like to start out with SQLPing A nice tool from SQLSecurity.com that scans the network both actively and passively, testing SQL’s default listening port 1433 and it reports on what it finds (nothing fancy, just text). This includes those desktop versions of SQL Server: MSDE, that are often configured with SA-no password. This tool will tell you what version SQL is running, and will even do a test for SA-no password. Since SA cannot be locked out, you won’t damage the server with one attempt.

NOTE: Check with your network administrator before running this test. It’s also a great test of your intrusion detection system, because, if the IDS is configured properly, it should catch it and alert for it. Make sure management knows you are using this, if that’s what you’re going to use it for. No IDS? No worries.

I also recommend SQLSecurity. com for a lot of great information and scripts for DBAs. They know all about SQL Injection (Unlike a CIO I recently interviewed three years ago) and they have lots of MS SQL information well worth your visit.

The other free tools I use are found inside SQL Server. Yes, inside the SQL database, and they are called “Stored Procedures.” This is a fancy name for pre-written sequenced query language batch files. The folks at Microsoft have done us all a great favor by writing hundreds of them. Inside the Master database are the stored procedures you want to run, or have a DBA run for you and output to .csv format files. (Each database also has stored procedures, but the Master database SPs are the ones you want.) There is a table full of them, and here are the ones I use:

sp_helpdb Names and file locations on the Windows server of all SQL databases. (And you should find out who or what has access to those files)

sp_helpuser Review usernames, groups the user belongs to, and their default login database.

sp_helplogins a. Identify and review any external users and groups; b. Look for mappings of login name to UserOrAlias or as DB Owner. c. Check AUser and ARemote columns to identify who has remote access to what database.

sp_helpsrvrolemember Users and groups assigned to each server role (More on this later)

sp_helprotect Permissions in the database. Examine this list carefully for what rights are granted and denied to whom.

Get the results of these queries, results from the last post, and SQLPing. You’ll have some very interesting items to review. and remember, Google is your friend.