This article primarily introduces the security configuration process for SQL Server 2000. We all know that databases are the foundation for finance, e-commerce, and ERP systems, typically storing important information about business partners and customers. The majority of electronic data for enterprises, organizations, and government departments is stored in various databases.
These databases store personal information such as employee salaries and personal profiles.
Database servers also hold sensitive financial data, including transaction records, business affairs, and account data, as well as strategic or professional information like patents, engineering data, and even market plans—information that should be protected from competitors and other unauthorized individuals. Data integrity and legitimate access can be threatened by many aspects of security, including password policies, system backdoors, database operations, and inherent security solutions. However, databases often do not receive the same level of attention to security as operating systems and networks.
Microsoft SQL Server is a widely used database, with many e-commerce websites and enterprise internal information platforms based on SQL Server. However, the security of the database has not been systematically equated with other system securities. Many administrators believe that if network and operating system security is handled properly, then all applications will also be secure.
Most system administrators are unfamiliar with databases, while database administrators pay too little attention to security issues. Additionally, some security companies overlook database security, making the issue of database security even more severe. Security vulnerabilities in database systems and improper configurations often lead to serious consequences and are difficult to detect.
Database applications are usually closely related to the highest administrator of the operating system. SQL Server databases, which are "port" type databases, indicate that anyone can attempt to connect to the database using analysis tools, thereby bypassing the operating system's security mechanisms and potentially infiltrating the system, destroying and stealing data, or even damaging the entire system.
Here, we mainly discuss the security configuration of the SQL Server 2000 database and some related security and usage issues.
Before performing the security configuration of the SQL Server 2000 database, you must first secure the operating system, ensuring it is in a safe state. Then, conduct necessary security audits on the database software (programs) you will use, such as ASP, PHP scripts, which are common security vulnerabilities in database-based web applications. For scripts, the main concern is filtering out characters like , ' ; @ / to prevent attackers from constructing malicious SQL statements. Next, after installing SQL Server 2000, apply patches sp1 and the latest sp2.
The download addresses are: http://www.microsoft.com/sql/downloads/2000/sp1.asp and http://www.microsoft.com/sql/downloads/2000/sp2.asp;
After completing these three basic steps, let's discuss the security configuration of SQL Server.
1. Use a secure password policy
We place the password policy as the first step in all security configurations. Please note, many database account passwords are overly simple, just as system passwords can be too simple. Special attention should be paid to the 'sa' account, and its password should never be written into applications or scripts. A strong password is the first step towards security!
During the installation of SQL Server 2000, if mixed mode is used, the 'sa' password needs to be entered unless an empty password is absolutely necessary. This is an improvement over previous versions.
At the same time, develop the habit of regularly changing passwords. Database administrators should regularly check for accounts that do not meet password requirements. For example, use the following SQL statement:
Use master Select name, Password from syslogins where password is null
2. Use a secure account strategy.
Since SQL Server cannot change the 'sa' username or delete this superuser, we must provide the strongest protection for this account, including using a very strong password. It is best not to use the 'sa' account in database applications. Use 'sa' only when there is no other way to log into the SQL Server instance (for example, when other system administrators are unavailable or have forgotten their passwords). It is recommended that database administrators create a new superuser with the same permissions as 'sa' to manage the database. A secure account strategy also includes avoiding the proliferation of accounts with administrative privileges.
SQL Server has two authentication modes: Windows Authentication and Mixed Authentication. If the database administrator does not want the operating system administrator to access the database through the operating system login, the system account "BUILTINAdministrators" can be deleted in account management. However, doing so means that if the 'sa' account password is forgotten, there will be no way to recover it.
Many hosts use databases only for simple functions like queries and modifications. Please allocate accounts according to actual needs and grant only the permissions required for the application. For example, if only query functionality is needed, a simple public account with SELECT permissions is sufficient.
3. Enhance database logging.
Audit both "failure and success" of database login events. In the instance properties, select "Security" and set the audit level to full. This will record detailed logs of all account login events in both the database system and operating system logs. As shown in the figure:
Please regularly review the SQL Server logs to check for any suspicious login events or use DOS commands.
findstr /C:"login" d:Microsoft SQL ServerMSSQLLOG*.*
4. Manage extended stored procedures.
Perform major surgery on stored procedures and carefully consider the permissions granted to accounts calling extended stored procedures. In fact, in most applications, very few system stored procedures are actually needed. SQL Server provides so many system stored procedures just to meet the needs of a wide range of users. Therefore, unnecessary stored procedures should be deleted because some system stored procedures can easily be exploited to escalate privileges or cause damage.
If you do not need the extended stored procedure xp_cmdshell, please remove it. Use this SQL statement:
use master sp_dropextendedproc 'xp_cmdshell'
xp_cmdshell is the best shortcut to enter the operating system and represents a large backdoor left by the database for the operating system. If you need this stored procedure, you can restore it with this statement.
sp_addextendedproc 'xp_cmdshell', 'xpsql70.dll'
If you don't need OLE automation stored procedures (which may disable certain features in the manager), discard them. These procedures include:
Sp_OACreate Sp_OADestroy Sp_OAGetErrorInfo Sp_OAGetProperty Sp_OAMethod Sp_OASetProperty Sp_OAStop
Remove unnecessary registry access stored procedures. Registry stored procedures can even read out the operating system administrator's password, as follows:
Xp_regaddmultistring Xp_regdeletekey Xp_regdeletevalue Xp_regenumvalues Xp_regread Xp_regremovemultistring Xp_regwrite
There are some other extended stored procedures that you should also check.
When handling stored procedures, make sure you confirm to avoid causing harm to the database or application.
5. Use protocol encryption
SQL Server 2000 uses the Tabular Data Stream protocol for network data exchange. If it is not encrypted, all network transmissions, including passwords and database content, will be in plain text, posing a significant security threat. Sensitive information, including database accounts and passwords, could be intercepted by others on the network. Therefore, under permissible conditions, it is best to use SSL to encrypt the protocol, though you will need a certificate to support it.
6. Don’t let people probe your TCP/IP port casually
By default, SQL Server listens on port 1433. Many people say that during SQL Server configuration, this port should be changed so that others cannot easily know which port is being used. Unfortunately, via Microsoft's undisclosed UDP port 1434, it is easy to find out which TCP/IP port SQL Server is using (please refer to "In-depth Exploration of SQL Server Network Connection Security Issues").
However, Microsoft did consider this issue since open ports can cause unnecessary trouble. In the instance properties, select the TCP/IP protocol properties. Choose to hide the SQL Server instance. If the SQL Server instance is hidden, broadcasts sent by clients attempting to enumerate existing SQL Server instances on the network will be blocked. Thus, others won't be able to probe your TCP/IP port using 1434 (unless using Port Scan).
7. Modify the TCP/IP port used
Based on the above configuration, change the original default port 1433. In the instance properties, choose the TCP/IP protocol properties in the network configuration, and change the default TCP/IP port to another port. As shown in the figure:
9. Reject probes from port 1434
Since there are no restrictions on port 1434 probes, others can discover some database information and might even suffer from DoS attacks increasing the CPU load on the database server. Therefore, for Windows 2000 operating systems, IPSec filtering can reject UDP communications on port 1434, hiding your SQL Server as much as possible.
10. Restrict network connections by IP
SQL Server 2000 itself does not provide a solution for network connection security, but Windows 2000 offers such a mechanism. Using the operating system's own IPSec can ensure the security of IP packets. Limit IP connections to ensure only your IPs can access and reject port connections from other IPs, effectively controlling security threats from the network.
For more information on using IPSec, please see: http://www.microsoft.com/china/technet/security/ipsecloc.asp;
The above mainly introduces some SQL Server security configurations. After the above configurations, SQL Server itself will have sufficient security prevention capabilities. Of course, more importantly, internal security controls and administrator security training should be strengthened, and security issues are a long-term resolution process requiring more ongoing security maintenance.
Article address: [Eden Network] http://www.edenw.com/tech/devdeloper/database/2010-07-20/4825.html