HomeCalendarFAQSearchRegisterMemberlistUsergroupsLog in

Share | 

 Making Your Network Safe for Databases

Go down 

Number of posts : 1850
Age : 55
Registration date : 2008-03-08

PostSubject: Making Your Network Safe for Databases   Sun 6 Apr - 17:19

Databases are critical components of an information infrastructure today. It is doubtful that you will ever encounter a commercial web site that does not communicate with a database server behind the scenes. And it is almost certain that any e-commerce site or any other web site that collects information from visitors stores information in a back-end database server.

The problem with databases however, is that they may be easily overlooked when security procedures are implemented. Often, the focus is targeted towards securing the web server and little thought goes into how the database may be vulnerable because all of the 'front-end' security has been implemented. But databases usually contain a company's most valuable information assets, and if compromised, could wreak havoc. While much press is given to denial-of-service attacks and web-site defacements, attacks on database servers can result in even more severe consequences than just a public relations problem or lost revenue because of downtime. To illustrate this point, below are some examples of several high-profile organizations that have had their databases compromised over the past few years.

If you are charged with administering a network that contains a database server, there are a number of steps you can take to help protect the data from being compromised. Properly configured, you can help prevent your organization's information assets from falling into the wrong hands.

If it could happen to them.

Over the past few years, there have been many documented cases of organizations that have reported their databases compromised. In most cases, the theft of data has resulted in more than just embarrassment. At best, a company will lose time and money due to expenses occurred from conducting forensics to determine the extent of the theft. Companies have been blackmailed, or threatened with blackmail, and in some cases, have had to discontinue providing services to consumers due to lack of confidence in the system. Depending on the sensitivity of the data that is stolen, companies could face damaging lawsuits.

In December 2000,, a computer products retailer, announced that its customer database may have been compromised and that up to 3.7 million credit card accounts may have been stolen [1]. Egghead later claimed that its customers' credit cards were not compromised, but the investigation to determine the extent of the breach cost millions [2].

Nearly a year previously, an intruder thought to be from Russia and known as "Maxus" attempted to blackmail cdUniverse, an online music retailer, after he exploited a security hole on their web site and stole credit card information from the database. He posted thousands of users' credit card details on the Internet after his extortion demands were refused [3]. To see a copy of the credit card black market website that Maxus ran, visit .

In November 2001, was hacked, and intruders stole the credit card information of visitors, and proved it by sending threatening email messages to the customers that displayed all of their credit card information [4].

It was announced in the spring of 2001 that 98,000 people had their credit card information compromised when criminals broke into Bibliofind, division of that assisted users in locating rare and out-of-print books. To make matters worse, they managed to maintain their free access to the database for 4 months before being discovered [5]. As a result, Bibliofind ended up refraining from acting as a financial transaction service for its clients, and instead continued as a matching service only [6].

The FBI reported in March of 2001 that over 40 banking and retailer's web sites were attacked and compromised by Russian and Ukrainian hackers. Blackmail was usually involved after the theft of credit cards [7].

At two different times during 2001, Indiana University's computers were hacked and private individual information was stolen, including social security numbers and addresses [8].

James Middleton reported for in January of 2002 that Evans Data, a U.S. market research firm, conducted a study and found that 10 percent of databases had been compromised during 2001, based on 750 companies surveyed. Over forty percent of banking and financial services "reported incidences of unauthorized access and data corruption, while 18 per cent of medical/healthcare and telecoms firms reported similar breaches." [9]

All of these incidents illustrate that databases are treated as treasures for hackers to steal. While denial-of-service attacks and web site defacements can be very costly to a company that relies on e-commerce for revenue, these sorts of attacks provide very little financial incentive to hackers. Database theft, on the other hand, can be quite lucrative for an enterprising hacker who doesn't get caught. Once they steal the data, as illustrated in a few examples above, hackers may attempt to blackmail a company by threatening to post customers' credit cards online.

But another even more disturbing development has begun to gain publicity, which is organized cyber-crime. There is a growing black market for stolen credit card numbers, just as there has been with physical cards. Only now hackers can sell their stolen 'goods' online and make a profit without having to physically snatch a purse or break into a glove box.

If you think these incidents are anomalies that gained a lot of publicity because the companies are high profile, just take a look at and enter the default port for whichever database you are running. The biggest target is Microsoft SQL Server. On some days there are over half a million reports of attacks upon servers running Microsoft's database products. Not even coming close are other databases, but there have been days when there have been over 600 reported attempts on MySQL databases. And if you punch in their respective port numbers on, you will see that Sybase and Oracle are not exempt, either.

Following are some guidelines that should be followed if you are implementing a database-driven web site. They start with most simple and work their way up to the most paranoid. If you find yourself in a situation where you cannot implement every one of these guidelines, at least attempt to implement as much as possible. Most of these guidelines are relatively inexpensive and easy to implement, and should be seriously considered if your organization covets the security and confidentiality of it's data.

1: Give the database server and the web server their own hardware

One of the biggest mistakes that can be made when implementing a web site with a back-end database is to install the database server on the same box as the web server. While there may be a seemingly good argument for doing so, the risks should always outweigh the advantages. It may be done for convenience, lack of resources to procure a separate server for the database, or for performance reasons.

Whether it is full-fledged database application, like Microsoft SQL Server, Sybase or Oracle, or just a Microsoft Access database, if a hacker gains control of your web server, then they will also have access to your database resources. And a special note should be made regarding Microsoft Access. Many web sites use Microsoft Access databases. Considering the security flaws found in Microsoft's Internet Information Server (IIS) recently, and how worms like Nimda and Code Red could open a back door and provide administrator privileges and file system access to the entire server, special care should be given to using Microsoft Access, which is essentially a flat file, and could be easily stolen if somebody broke into the web server.

The bottom line is if a hacker breaks into the web server, then they will have access to your database. If the cost of purchasing a separate computer for your database outweighs the risks and consequences if your data is stolen, then by all means, go ahead and put the web server and the database server on the same box.

Some may also argue that desirable performance is obtained by co-locating the web server on the database server on the same computer. But this argument is doesn't hold much water when considering bandwidth models. Most internal network segments operate (at the very least) 10Mb per second; more commonly at 100Mb. Gigabit service is even available. So consider that while most Internet connections operate at less than 10Mb per second, your web server should have much more available bandwidth to perform fast queries. If there is to be a bottleneck, it is more likely to occur between the browser client and the web server rather than the web server and the database server [10].

2: Don't put the database server in the DMZ

Chances are that you have a demilitarized zone (DMZ) configured for your web server and any other resources that you need to make available for public access. It may seem logical at first to just install your database server in the DMZ and trust your firewall to prevent attacks against it. If you configure your firewall to only allow certain traffic to hosts that you want to be public, and drop any traffic directed towards the database server, then you may feel confident that your database is safe.

But are you positive that the database server is 100% safe from other servers in your DMZ? Just because the firewall is configured to drop packets directed towards the database server, the reality is that some forms of outside traffic are being allowed into your DMZ. Are you confident that your mail server is so secure that it could not be compromised and used as a launch pad to attack your database server? Depending on the size of your company, you may not have control over all of the servers in your DMZ, so you may be relying on basic trust that the administrators of the mail servers, the web servers, the DNS servers and any other servers in the DMZ have done their job to secure their boxes.

"But I'm using network address translation (NAT), and the database server doesn't even have a public IP address," you may say. It doesn't matter if one of the other servers behind your firewall is compromised. The hacker now has access to the same network with private IP addresses as your database server. This may seem, in essence, admitting that your own network is 'untrusted'. It is a matter of perspective. Some may argue that, in reality, any network is, to a certain degree, untrusted; i.e., there is always a certain degree of threat and vulnerability once you plug a computer into any network. No network or resource is invulnerable.

So what are the options if you want to follow this suggestion, and remove your database server from the DMZ?

The first option would be to install a second firewall and configure it to protect a separate network that is separated from your DMZ. By configuring it to allow only very restricted traffic from privileged resources, the database server can be secured against attacks staged from a compromised server in the DMZ that should never have access to the database server in the first place (such as the DNS or mail server).
Back to top Go down
View user profile
Making Your Network Safe for Databases
Back to top 
Page 1 of 1
 Similar topics
» Dialog 4G network to be powered soon!
» Neural Network Approach for Market Prediction : Inputs
» Network marketing/pyramid marketing=scam?
» New network marketing scams spread their wings countrywide
» Companies listed under Investment Trust sector

Permissions in this forum:You cannot reply to topics in this forum
Job98456 :: Databases-
Jump to: