1. Install the latest service pack
In order to improve server security, the most effective method is to upgrade to SQL Server 2000 Service Pack 3A (SP3A).
In addition, you should also install all published security updates.
2. Using the Microsoft Baseline Security Analyzer (MBSA) to evaluate the security of the server
MBSA is a tool for unsafe configuration of a variety of Microsoft products, including SQL Server and Microsoft SQL Server 2000 Desktop Engine (MSDE 2000). It can run locally or run through the network. This tool detects the SQL Server installation for the following questions:
1) Excessive SYSADMIN fixed server role members.
2) Grant other roles other than sysadmin Creating a CMDexec job.
3) Empty or simple password.
4) Vulnerability authentication mode.
5) Grant of excessive rights to the administrator group.
6) Incorrect access control tables (ACL) in the SQL Server data directory.
7) The SA password using plain text in the installation file.
8) Grant all the rights of the GUEST account.
9) Run SQL Server in the system of the domain controller.
10) The incorrect configuration of the Everyone group provides access to a specific registry key.
11) The incorrect configuration of the SQL Server service account.
12) There is no necessary service pack and security update.
Microsoft offers free download of MBSA.
5. Assign a strong SA password
The SA account should always have a strong password, even on a server configured to require Windows authentication. This will ensure that you do not have blank or fragile SA when the server is reconfigured as a hybrid mode authentication.
To assign a SA password, follow these steps:
1) Expand the server group and expand the server.
2) Expand security, then click Login.
3) In the detail pane, right click on SA, then click Properties.
4) In the password box, enter a new password.
6. Limit the permissions of SQL Server services
SQL Server 2000 and SQL Server Agent are running as a Windows service. Each service must be associated with a Windows account and derive the security context from this account. SQL Server allows SA to log in to users (sometimes other users) to access operating system features. These operating system calls are created by the security context of an account with a server process. If the server is broken, these operating system calls may be used to attack other resources, as long as the process (SQL Server service account) can be accessed. Therefore, it is important to grant the necessary permissions for the SQL Server service.
We recommend that you use the following settings:
1) SQL Server Engine / MSSQLServer
If you have a specified instance, they should be named MSSQL $ InstanceName. Run as a Windows domain user account with general user privileges. Do not run as a local system, a local administrator or a domain administrator account.
2) SQL Server Agent Service / SQLServerAgent
If you don't need it in your environment, please disable the service; otherwise, please run as a Windows domain user account with general user privileges. Do not run as a local system, a local administrator or a domain administrator account.
Key: If one of the following conditions are true, the SQL Server Agent will require a local Windows administrator privilege:
SQL Server Agent uses standard SQL Server authentication to SQL Server (not recommended).
SQL Server Agent uses a multi-server management primary server (MSX) account, and the account is connected using standard SQL Server authentication.
SQL Server Agent runs non-sysadmin fixed server role members' Microsoft ActiveX? Script or cmdexec job.
If you need to change the account associated with the SQL Server service, use SQL Server Enterprise Manager. Enterprise Manager sets the appropriate permissions for the files and registry keys used by SQL Server. Do not use the "Services" of the Microsoft Management Console (in the Control Panel) to change these accounts, as this requires manually modulating a large number of registry keys and NTFS file system permissions and MICORSOFT Windows user privileges.
Changes to account information will take effect at the next service startup. If you need to change the account associated with SQL Server and SQL Server Agent, you must make changes to both services using Enterprise Manager.
7. Disable SQL Server port on firewall
The default installation of SQL Server will monitor TCP ports 1433 and UDP ports 1434. Configure your firewall to filter out packets to these ports. Moreover, other ports associated with the specified instance should also be blocked on the firewall.
8. Using the safest file system
NTFS is the most suitable file system that is best to install SQL Server. It is more stable and more easily restored than the FAT file system. And it also includes some security options, such as files and directory ACLs, and file encryption (EFS). During the installation process, if NTFS is detected, SQL Server will set the appropriate ACL on the registry key and file. These priviles should not be changed.
With EFS, the database file will be encrypted under account identity running SQL Server. Only this account can decrypt these files. If you need to change an account running SQL Server, you must first decrypt these files under the old account and then re-encrypt under the new account.
9. Delete or protect the old installation file
SQL Server installation files may contain sensitive configuration information recorded by plain text or simple encrypted credentials and other recording during installation. The storage location of these log files depends on the installed SQL Server version. In SQL Server 2000, the following files may be affected: The
If the current system is upgraded from SQL Server 7.0, you should also check the following files: The setup.iss in the% Windir% folder, as well as SQLsp.log in the Windows Temp folder.
Microsoft released a free utility KillPwd that will find and delete these passwords from your system.
10. Audit Point to SQL Server
SQL Server can record event information for system administrators. At least you should record the failed SQL Server connection attempt and regularly view this log. In a possible situation, do not save these logs and data files on the same hard disk.
To review the failed connection in the Enterprise Manager of SQL Server, follow these steps:
1) Expand the server group. 2) Right click on the server and then click Properties.
3) In the audit level of the Security tab, click failed.
4) To make this setting take effect, you must stop and restart the server.
