 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > Networking Tips > Network Security > DBA or CIA? Protect your database server, part 2 |
| |
|
|
|
| Networking Tips: |
|
|
|
|
|
|
|
|
||||||||||||||||||
|
NETWORK SECURITY DBA or CIA? Protect your database server, part 2Luis F. Medina 08.22.2002 Rating: -4.00- (out of 5)
|
[IMAGE] | ||||||||||||||||||
Avoid letting database passwords become common knowledge with administrators
As the database administrator, you must restrict your database passwords from becoming common knowledge with network administrators. This task will be difficult to achieve if you decide to use Windows Authentication Mode, because the account name and password will not be stored on the database server.
Windows Authentication Mode vs. Mixed Mode (SQL authentication)
During SQL 2000 setup, Windows Authentication Mode is the default choice. This mode is recommended by Microsoft because it supports trusted (relies on authentication at the AD or Domain level) connections between the client and the database server. Mixed Mode -- AKA SQL authentication -- supports non-trusted connections; that is, the log-in name and password are stored locally on the database server and a connection from a non-trusted client will be accepted, as long as the correct account name and password is provided.
If you choose Mixed Mode, you will also notice that the password for the SA account is optional. Regardless of which mode you choose, you will need to set a unique password for the SA account. My preference is to use SQL authentication. I'll explain why:
The problem I see with using Windows Authentication Mode is that if -- or when -- a hacker obtains your domain administrator password, he or she will also have access to your database server. In the meantime, the database passwords will be common knowledge and shared among network administrators.
I suggest that this password be limited to a primary and secondary DBA. Therefore, I prefer the extra level of protection by enforcing a separate complicated password for the SA account, one that is not shared with network administrators, to avoid the "too many hands in the cookie jar" syndrome. Depending on your environment, you may choose to go with SQL authentication instead of Windows authentication.
Implement intermediary security between your clients and database server
One of the main advantages of using Windows Authentication Mode is that only authenticated clients can establish a trusted connection to your database server. But, the mode is not designed or intended to protect your database server, as would the implementation of a secondary firewall, or a router with appropriate ACL.
The absence of an intermediary security device between your clients and database server is an overlooked security area that should be addressed by your database administrator and IT staff, sooner rather than later. In the absence of security, there's an opportunity for intrusion.
Data Sources (ODBC) and Data Source Name (DSN) configuration
Creating a User or System DSN in Microsoft ODBC Administrator on your Web servers is a straightforward process. The important thing here is to configure, in Client Configuration, each DSN with TCP and the non-default port of your database server (other than port 1433) and enter the appropriate account name and password. Make sure you are using the most stable and secured version of MDAC and record the version number (see About). Select the box "Change the default database to" and enter your database name. If you want to test your access to your database server using Microsoft's NorthWind database, select it form the list of databases and enter the password for the SA account. If you are using NamedPipes, your client will require an IPC connection to the database server, which I don't recommend for security reasons. If you recall, in part one of "Protecting your database server," I covered the importance of disabling unnecessary ports, especially in your production servers.
Define a value other than the default unlimited value
One of the most overlooked settings is the Maximum Concurrent User Connections; the default value of zero represents unlimited connections. The problem is that your database server most likely can't handle unlimited user connections, and if a hacker (or erratic procedure) managed to initiate these connections, it would bypass the security of your server and render your database useless. Accepting unlimited connections also implies that your staff does not have a proper understanding or realistic estimation about the existing capacity or future expectations for user connections.
The goal is to secure your server using realistic values and not default values, which often defeat the purpose of having security in the first place. Performance benchmarks of your existing application should provide the statistics you need to determine the maximum number of user connections that your database server can reliably handle.
Enterprise Manager -- Defining your security configuration
Select Properties for your database server listed in SQL Server Group in Enterprise Manager. Go to the Security tab and set Failure on Audit level to record failed log-in attempts; then go to the Connections tab and disable Remote Server Connections, which by default allows other SQL servers to connect via Remote Procedure Call (RPC) to your database server. Enter a value in Maximum Concurrent User Connections and don't accept the default unlimited value. Go to Server Settings tab and select the appropriate behavior of your server, then go to the Active Directory tab and add the instance, if you elect to integrate SQL with AD.
Below is the second part of my SQL Security Checklist. In my third part of the "Protect your database server" mini-series, we will focus on role-based security, SID and GUID, permissions and delegation.
SQL security check list, part two
Remember that the purpose of my articles is to explore the various areas in your network and bring to the surface any security vulnerabilities that have been overlooked. My intention with this article is not to tell you how to set up a database server, but to point out the areas you should be aware of when configuring a SQL server.
Did you pass the test? Does your SQL server configuration already include the security tips in this article? If yes, kudos! It's been my experience that some of these basic steps have often been overlooked by experienced IT professionals. If you're serious about security, you must pay attention to details and leave no room for hackers.
Please write to me and let me know if this article has brought to light any potential weak links in your network. Luis Medina is the author of "The Weakest Link Series," which offers network managers an opportunity to identify ongoing network security issues. Luis also answers security questions in SearchNetworkings Ask the Expert section. Submit a security question to Luis here or view his previously answered Ask the Expert questions.
|
DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk. |
|
|||
| Networking Solutions for Business
Alcatel-Lucent Network Business Communications Solutions |
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
