Security Configuration for ms SQL Server

Before configuring SQL Server 2000 database security, you must configure the operating system security to ensure that your operating system is in a safe state. Then, perform necessary security audits on the database software (programs) You want to use, such as ASP and PHP scripts. This is a common security risk for many database-based Web applications, the script is mainly a filtering problem. It needs to filter characters such as '; @/to prevent attackers from constructing malicious SQL statements. Next, Install SQL Server2000 after the latest patch (ms SQL 2005 B1 has been downloaded, but this does not affect the security configuration content) sp3a.

1. Use a secure password policy

Before configuring SQL Server 2000 database security, you must configure the operating system security to ensure that your operating system is in a safe state. Then, perform necessary security audits on the database software (programs) You want to use, such as ASP and PHP scripts. This is a common security risk for many database-based Web applications, the script is mainly a filtering problem. It needs to filter characters such as '; @/to prevent attackers from constructing malicious SQL statements. Next, Install SQL Server2000 after the latest patch (ms SQL 2005 B1 has been downloaded, but this does not affect the security configuration content) sp3a.

1. Use a secure password policy

We put the password policy in the first step of all security configurations. Please note that the passwords of many database accounts are too simple, which is the same as the system password. Do not write the SA account password in an application or script. Robust passwords are the first step to security! When installing SQL Server in hybrid mode, you need to enter the SA password unless you confirm that you must use a blank password. This is better than the previous version. At the same time, develop a good habit of regularly changing passwords. The database administrator should regularly check whether there are accounts that do not meet the 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 policy

Because SQL Server cannot change the SA user name or delete this super user, we must provide the strongest protection for this account, including using a very strong password, it is recommended that you do not use the SA account in database applications. SAS is used only when no other method is available to log on to the SQL server instance (for example, when other system administrators are unavailable or forget the password. It is recommended that the database administrator create a new super user with the same permissions as SA to manage the database. Secure account policies also include preventing account flooding with administrator permissions.

SQL Server authentication modes include Windows Authentication and Hybrid Authentication. If the Database Administrator does not want the operating system administrator to log on to the database through the operating system, he or she can delete the system account "builtin/administrators" in account management. However, the result is that once the SA account forgets its password, there is no way to restore it. Many hosts use database applications for simple functions such as query and modification. Please assign accounts as needed and grant only the permissions that meet the application requirements and needs. For example, as long as the query function is available, a simple public account can be used to select.

3. Strengthen database log records

Review "failed and successful" of database logon events, select "security" in instance properties, and select all audit levels. In this way, in the database system and operating system logs, the logon events of all accounts are recorded in detail. Check SQL server logs regularly to check for any suspicious logon events or use the DOS command. Findstr/C: "login" D:/Microsoft SQL Server/MSSQL/log /*.*

4. Manage Extended Stored Procedures

Perform major operations on the stored procedure, and exercise caution when calling the account to extend the stored procedure. In fact, most applications do not use much system stored procedures. SQL Server's multi-system stored procedures are only used to meet the needs of users. Therefore, delete unnecessary stored procedures, because the stored procedures of some systems can be easily exploited to escalate permissions or destroy them. If you do not need to extend the Stored Procedure xp_mongoshell, remove it. Use this SQL statement:

Use master

Sp_dropextendedproc 'xp _ export shell'

Xp_mongoshell is the best way to enter the operating system and a large backdoor left by the database to the operating system. If you need this stored procedure, use this statement to restore it.

Sp_addextendedproc 'xp _ external shell', 'sqlsql70. dll'

If you do not need it, discard the OLE Automatic stored procedure (which will make some features in the Manager unusable ),

These processes include:

Sp_oacreate sp_oadestroy sp_oageterrorinfo sp_oagetproperty

Sp_oamethod sp_oasetproperty sp_oastop

Remove unnecessary stored procedures for registry access. The Registry Stored Procedures can even read the password of the Operating System Administrator as follows:

Xp_regaddmultistring xp_regdeletekey xp_regdeleteValue

Xp_regenumValueS xp_regread xp_regremovemultistring

Xp_regwrite

There are also some other extended stored procedures that you 'd better check. When processing the stored procedure, check to avoid damage to the database or application.

5. protocol encryption

SQL Server 2000 uses the tabular data stream protocol for network data exchange. Without encryption, all network transmission is in plain text, including passwords and database content, this is a big security threat. Attackers can intercept what they need on the Internet, including database accounts and passwords. Therefore, it is best to use SSL to encrypt the protocol when conditions permit. Of course, you need a certificate to support it.

6. Do not randomly detect your TCP/IP Port

By default, SQL server uses port 1433 for listening. Many people say that this port should be changed during SQL server configuration, so that others cannot easily know which port to use. Unfortunately, it is easy to know what TCP/IP Port is used by SQL Server through the UDP detection of port 1434 that Microsoft has not published. However, Microsoft still considered this issue. After all, open and open ports will cause unnecessary troubles. Select the TCP/IP protocol attribute from the instance attributes. Select to hide the SQL server instance. If the SQL server instance is hidden, it is prohibited to respond to broadcasts from clients that attempt to enumerate existing SQL Server instances on the network. In this way, no one else can use 1434 to detect your TCP/IP Port (unless using Port Scan ).

7. Modify the port used by TCP/IP

Modify the default port 1433 on the basis of the previous configuration. In instance properties, select the TCP/IP protocol attribute in the network configuration to change the default port used by TCP/IP to another port.

9. Reject detection from port 1434

Because there is no limit on port 1434 detection, some database information can be detected by others, and DoS attacks may also increase the CPU load on the database server. Therefore, for Windows 2000 operating systems, when using IPSec to filter out UDP communication that rejects port 1434, you can hide your SQL Server as much as possible.

10. Restrict IP addresses for Network Connections

The SQL Server 2000 database system does not provide a security solution for network connections, but Windows 2000 provides such a security mechanism. You can use the operating system's own IPSec to implement the security of IP packets. Restrict IP connections to ensure that only the IP address can be accessed, and deny port connections from other IP addresses to effectively control security threats on the network. For Ipsec usage, see: http://www.microsoft.com/china/technet/security/ipsecloc.asp

Some of the SQL server security configurations described above can enable SQL Server to have sufficient security defense capabilities. Of course, it is more important to strengthen internal security control and administrator security training. In addition, security issues are a long-term solution process and more security maintenance is required in the future.