Technorati Tag: Database Security
Lately, database security issues have been flooding the media and Internet news-wires. First with the Slammer worm and most recently criminals accessing over 8 million credit card numbers.

So I sit back and say to myself, "Did the sysadmins fall asleep behind the wheel?" As the internet has boomed and we've increased our reliance on the convenience and relative low cost of web-enabled information systems, we have become lazy in our implementation of basic security practices.

Now part of this problem is the pressure placed on today's system admin's by the upper-crust of corporate America. The first question to every sysadmin is, "How soon can this be up?" and not "How much of a security risk is this?". In light of current events it has become painfully obvious we need to re-adjust our thinking.

So, let me begin this article with a brief synopsis of how security policies should be implemented and then move into actual system configuration.

Basic Security Structure
Through my travels as a Network Security Specialist I have consistently come across companies with a single focus in mind, "Software Security". They place so much emphasis on this single portion of security that they loose sight of the big picture. The big picture is of course, "Without a structured security hierarchy any basic security policy will fail!"

To often system administrators are left to their own accord, managing the security of their systems with little or no oversight by a higher security administrator. This raises the following questions:

• Who ensures system administrators are following security guide-lines?
• How does an organization ensure all system administrators are applying the latest patches?
• What organization ensures that the latest patches have been tested to ensure they do not cause additional system faults
• Who performs security audits on the corporation as a whole?

Without a proper structure you begin to get chaos when it comes to such an important topic as security, chaos could be cataclismic. For example:

Jim of the East Coast Office has all of his patches up to date, but he has an insecure link with Bill on the west-coast, who has failed to properly configure his firewall. This situation would allow for a full system compromise.

To ensure a situation such as this does not occur someone or a group of someone's should be looking at the big picture.

Now that I have gotten that basic security organization rant out of my system, let me begin a technical look at database security.

Database Vulnerabilities (The many fronts of the security war!)

Basically database security can be broken down into the following key points of interest.

• Server Security
• Database Connections
• Table Access Control
• Restricting Database Access

Server Security
Server security is the process of limiting actual access to the database server itself, and in my humble opinion it is the most important angle of security and should be carefully planned.

The basic idea is this, "You can't access what you can't see". Why in the name of the Almighty (or whoever else you believe in, or if you are an Atheist, substitute your own name here) would you let your database server be visible to the world. This is not a web server here, there should be no such thing as an anonymous connection. Now some people would say, "Well, what if your database server is supplying information to dynamic web pages?", well I'll turn that around and say, "Your database back end should never be on the same machine as your web server, not just for security, but for performance!" If your database server is supplying information to a web server then it should be configure to allow connections only from that web server. Now that bring mes to the next point of discussion:

Trusted IP addresses
Every server, should be configured to only allow trusted IP addresses. You don't allow just anyone to come into your house and talk to your children. In the same respect you should know exactly who should be allowed to "talk" to your database server.

If it's a back end for a web server., then only that web server's address should be allowed to access that database server. If the database server is supplying information to a homegrown application that is running on the internal network, then it should only answer to addresses from within the internal network.

Also please none of this cheap mentality of hosting your web databases on the same server that houses internal database information. Why would you have internal information out in the DMZ, its not called the DMZ for nothing.

Database Connections
These days with the number of Dynamic Applications it becomes tempting to allow immediate unauthenticated updates to a database. I say, "Ney!" to such laziness. If you are going to allow users to make updates to a database via a web page, ensure that you validate all updates to ensure that all updates are warranted and safe. For example ensure that you are removing any possible SQL code from a user supplied input. If a normal user should never be inputting it don't allow the data to ever be submitted.

If you are one of those administrators that feels the need to use ODBC connections ensure that every connection uses it's own unique user to access the shared data. It personally makes my skin crawl when I see the user account "sa" used for every connection and data source on the server. Does every employee in your company have keys to every room in the building? I'll let you address that problem quietly if they do.

Table Access Control
Table access control is probably one of the most overlooked forms of database security because of the inherent difficult in applying it. Properly using Table access control will require the collaboration of both system administrator and database developer, and we all know that "collaboration" is a foreign word in the IT industry.

An example would be allowing read access to user imputed information to the public. If a user just imputed the information whey would they have to look at it within the same session. Or, if a table is just used for system reference why should it have any other permissions beside read available?

Unfortunately table structure and proper relational database structure and development is a little out of the scope of this article. But, keep a look out for it in my upcoming articles.

Restricting Database Access
Now being that we have completed a basic overview of database security I want to dive a little further into the specifics of server security. Mainly into the network access of the system. Specifically targeting Internet based databases, since they have been the most recent targets of attacks. All web-enabled applications have ports that they listen to ( I know this is pretty basic to most of you but, it needs to be said for the beginners!).

Most cyber criminals ( I always refrain from the media sensationalized term "Hackers" or "Crackers") are going to do a simple "port scan" to look for ports that are open that popular database systems use by default. Now I say by default, because you can change the ports a service listens on, which I personally feel is a great way to throw off a criminal.

First they will attempt to determine if a machine is even at a specific address. They will do this by pinging the system. (If you don't know what ping is quietly close this article, you need to do some studying first!) This is done by simply opening up a command line and typing "ping".

C:\ ping 127.0.0.1

or

root@localhost: ~$: ping 127.0.0.1

The response should look like this:

Pinging 127.0.0.1 with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128

Ping statistics for 127.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0%
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

The criminal now knows there is a system answering at this address. First thing to prevent this is to disable any ICMP packets. This will prevent ping requests from being replied to.

There are many ways to prevent open access from the Internet and each database system has it's own set of unique features as well as each OS. So I am merely going to touch on a few methods.

• Trusted IP addresses - UNIX servers are configured to answer only pings from a list of trusted hosts. In UNIX, this is accomplished by configuring the rhosts file, which restricts server access to a list of specific users.
• Server account disabling- If you suspend the server ID after three password attempts, attackers are thwarted. Without user ID suspension, an attacker can run a program that generates millions of passwords until it guesses the user ID and password combination.
• Special tools -Products such as RealSecure by ISS send an alert when an external server is attempting to breach your system's security.

Oracle has a wealth of authentication methods:

• Kerberos security- This popular "ticket"-based authentication system sidesteps several security risks.
• Virtual private databases- VPD technology can restrict access to selected rows of tables.
• Role-based security- Object privileges can be grouped into roles, which can then be assigned to specific users.
• Grant-execute security- Execution privileges on procedures can be tightly coupled to users. When a user executes the procedures, they gain database access, but only within the scope of the procedure.
• Authentication servers-Secure authentication servers provide positive identification for external users.
• Port access security - All Oracle applications are directed to listen at a specific port number on the server. Like any standard HTTP server, the Oracle Web Listener can be configured to restrict access.

I hope that I have broadened your view of database security, and quite possibly helped eliminate or at least lower the threat of criminals looking for the "easy kill". (I know that is a little egotistical of me) If you have any questions or wish to contact me. (Flames and praise are welcomed equally) contact me at: gso.gsecur@gmail.com

Blake Wiedman