SQL server2000 database application is very extensive, once the security problems, the loss is often difficult to estimate! Precautions should be taken in advance. Here, we talk mainly about the security configuration of the SQL Server2000 database and some related security and usage issues.
Before you make a secure configuration of your SQL Server 2000 database, you must first configure your operating system securely to ensure that your operating system is in a secure state. Then you want to use the operation of the Database software (program) to carry out the necessary security audits, such as ASP, PHP and other scripts, which is a lot of web-based Web applications often appear security risks, for the script is mainly a filtering problem, need to filter some similar '; @/and other characters to prevent the attacker from constructing malicious SQL statements. Then, after installing the SQL Server2000, patch SP1 and the latest SP2.
The download address is http://www.microsoft.com/sql/downloads/2000/sp1.asp and http://www.microsoft.com/sql/downloads/2000/sp2.asp.
After you have finished the three steps above, we will discuss the security configuration of SQL Server.
1, the use of Secure password policy
We put the password policy in all security configuration of the first step, please note that many database account password is too simple, and the system password is too simple is a truth. You should be more aware of the SA, and do not allow the SA account password to be written in the application or script. A robust password is the first step in security!
SQL Server2000 installation, if you are using mixed mode, then you need to enter the SA password, unless you confirm that you must use a blank password. This is an improvement over previous versions.
At the same time develop a good habit of changing passwords regularly. The database administrator should periodically see if there are any accounts that do not meet the password requirements. For example, use the following SQL statement:
Use master
Select Namepassword from syslogins where password is null
2, the use of security account policy
Since SQL Server cannot change the SA user name and cannot remove the superuser, we must protect the account most strongly, including, of course, using a very strong password, preferably not using the SA account in the database application, only if there is no other way to log on to SQL Server Instance (for example, when another system administrator is unavailable or forgets a password) to use the SA. It is recommended that the database administrator create a new superuser with the same permissions as SA to manage the database. The security account policy also includes not allowing administrator privileges to overflow the account.
SQL Server Authentication mode has both Windows identity authentication and mixed identity authentication. If the database administrator does not want the operating system administrator to access the database through the operating system, you can delete the system account "Builtinadministrators" in the account management. But the result is that once the SA account forgets the password, there is no way to recover it.
Many hosts use database applications only to do query, modify, and other simple functions, according to the actual needs of the allocation of accounts, and give only to meet the application requirements and needs of the permissions. For example, as long as the query function, then use a simple public account can select the.
3, strengthen the record of the database log
Audit the "failure and success" of the Database logon events, select Security in the instance properties, and select the audit level as a whole, so that in the database system and the operating system log, the logon events for all accounts are recorded in detail.
Check the SQL Server log periodically to see if any suspicious logon events have occurred, or use a DOS command.
FINDSTR/C: "Login" D:microsoft SQL servermssqllog*.*
4. Managing extended Stored Procedures
Perform a major operation on the stored procedure and be cautious about the permissions that the account calls extended stored procedures. In fact, in most applications there is not much use of the system's stored procedures, while so many system stored procedures of SQL Server are only used to meet the needs of the broad masses of users, delete unnecessary stored procedures, because some of the system's stored procedures can easily be used to elevate permissions or damage.
If you do not need to extend the stored procedure xp_cmdshell please remove it. Use this SQL statement:
Use master
sp_dropextendedproc ' xp_cmdshell '
xp_cmdshell is the best way to get into the operating system, which is a big back door for the database. If you need this stored procedure, please use this statement to recover.
Sp_addextendedproc ' xp_cmdshell ' Xpsql70.dll '
If you do not need to discard OLE automatic stored procedures (which can cause certain features in the manager to not be used), these procedures include the following:
sp_OACreate sp_OADestroy sp_oageterrorinfo sp_oagetproperty
sp_OAMethod sp_OASetProperty
Removing unwanted registry access stored procedures, the registry stored procedure can even read out the password of the operating system administrator as follows:
xp_regaddmultistring xp_regdeletekey xp_regdeletevalue xp_regenumvalues
xp_regread Xp_regremovemultistring RegWrite
There are other extended stored procedures that you might want to check.
When dealing with stored procedures, be sure to avoid causing damage to the database or the application.
5, the use of Protocol encryption
SQL Server 2000 uses the tabular data stream protocol for network exchange, if not encrypted, all network transmission is plaintext, including passwords, database content, etc., this is a great security threat. Can be intercepted in the network what they need, including database accounts and passwords. Therefore, in the case of conditions, it is best to use SSL to encrypt the protocol, of course, you need a certificate to support.
6, do not let people casually detect your TCP/IP port
By default, SQL Server uses 1433-port monitoring, and many people say that the port is changed when SQL Server is configured so that no one can easily know what port is being used. Unfortunately, Microsoft's undisclosed 1434-port UDP probes make it easy to know what TCP/IP ports are used by SQL Server (refer to the in-depth exploration of security issues with SQL Server network Connections).
But Microsoft is still considering this problem, after all, open and open port will cause unnecessary trouble. Select the properties of the TCP/IP protocol in the instance properties. Choose to hide the SQL Server instance. If you hide an instance of SQL Server, you are prevented from responding to broadcasts from clients attempting to enumerate existing instances of SQL Server on the network. This way, others cannot use 1434来 to detect your TCP/IP port (except with Port Scan).
7. Modify the port used by TCP/IP
On the basis of the previous configuration, change the original default port 1433. Select the properties of the TCP/IP protocol in the network configuration in the instance properties to change the default port used by TCP/IP to a different port.
8. Reject probes from 1434 ports
Because 1434-port probes are not limited, can be detected by others to the database information, but also may be a Dos attack to the database server CPU load, so for the Windows 2000 operating system, in the IPSec filter rejected 1434-port UDP traffic, You can hide your SQL Server as much as possible.
9. IP Restrictions on network connections
The SQL Server 2000 database system itself does not provide a secure solution for network connectivity, but Windows 2000 provides such security. The security of IP packets can be achieved by using the operating system's own IPSec. Limit the IP connection to ensure that your IP is accessible and that other IP ports are connected, and that security threats from the network are effectively controlled.
For the use of IPSec, refer to Http://www.microsoft.com/china/technet/security/ipsecloc.asp
The security configuration of some of the SQL Server described above, with the above configuration, gives SQL Server sufficient security capabilities. Of course, the more important is to strengthen the internal security control and security training for administrators, and security issues is a long-term solution, but also need to do more security maintenance.