Web-Server security settings and security policies for data intrusion

Zhou minyao Jin Li Sheng Yang qishou
(College of Manufacturing Science and Engineering, Sichuan University, Chengdu 610065, China)

Abstract: This paper uses a variety of network security technologies to analyze the security risks of typical configurations (Win 2000 SERVER + SQL + IIS5.0), and puts forward corresponding countermeasures. Focuses on the security configuration of the system and the prevention of SQL Injection against data,
Key words: network security; SQL Injection; system; Data

I. Introduction
With the popularization and development of networks, various Internet-based systems also play an increasingly important role in all walks of life. However, due to the diversity of Connection forms, unevenly distributed terminals, openness and interconnectivity of the computer network, the WEB system is vulnerable to attacks by hackers, malware, and other malformed behaviors. In addition, it is important to improve network security when it involves private information about personal identities, sensitive data of various groups such as companies and schools, or even commercial data. This article takes the typical configuration in the WEB System (Win2000 server + SQL + IIS5.0) as an example to focus on the system security settings of the WEB server and the security policies of SQL Injection.

2. Network Security Risk Analysis and Security Technology
In general, network security refers to the protection of hardware, software, and data in the network system, which will not be damaged, changed, or leaked by accidental or malicious attacks, the system can operate continuously, reliably, and normally without interrupting network services. Therefore, network security usually includes system security and data security. Likewise, malicious attacks on the Internet can be divided into system-type attacks and data-type attacks. In network security, various hardware facilities and firewalls are essential. In addition, the security settings of the system and the data security of the Code cannot be ignored. This article will discuss this in depth. The specific analysis is as follows:
1. System Security Settings
Take Windows 2000 server + SQL Server 2000 + IIS5.0 as an example: this is our most common network server configuration. However, Microsoft's vulnerabilities emerge one after another. Therefore, it is extremely important to reinforce system security.
First, select a dedicated Web Server as much as possible, disconnect the network connection of the Server when installing the system, and install the Service Pack 3 patch on this basis.
After patching, modify the Registry. First, disable default sharing. In Windows 2000, there is a "default share". This is to automatically share the system installation partition when installing the server. Even though the Super User Password is required for access to the server, however, this is a potential security risk. We recommend that you disable this "default share" to ensure system security. Bind the key value:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserverparametersautoshareserver is changed to 0.
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserverparameters auto1_wks is changed to 0. If you do not have these two key values, create a new one. Note: select "double byte value" when creating the instance ".
In addition, the IPC $ null connection should be disabled, and the key value
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaestrictanonymous is changed to 1.
IPC $ (Internet Process Connection) is a named pipe open for inter-Process communication. You can obtain the relevant permissions by verifying the user name and password, used to remotely manage computers and view shared resources of computers. Using IPC $, the connector can even establish an empty connection with the target host without the user name and password (of course, the host must be shared with ipc $, otherwise it cannot be connected ), with this empty connection, the connector can also obtain a list of users on the target host.
Next, for IIS, try to avoid installing IIS on the master Domain Controller in the network. After IIS is installed, an anonymous IUSR_Computername account is generated on the computer on which it is installed. This account will be added to the domain user group to grant the access permissions applied to the domain user group to each anonymous user accessing the Web server. This does not guarantee IIS security, it also threatens the master domain controller. After installation, run IISLOCKD. EXE, a software released by Microsoft to fill in IIS vulnerabilities. However, this is not enough to ensure IIS security. Further reinforcement should be made to IIS:
A. Delete and disable the demo programs and directories of IIS. This is a program and file that comes with IIS and a way for attackers to attack the web system.

Screen. width-300) this. width = screen. width-300 "border = 0>

B. to prevent the attacker from modifying the website content by using the FTP settings and MAIL sending functions of the server, if the server does not need FTP or MAIL sending, you can delete the ftproot and mailroot folders, disable related services.
C. To avoid modifying or overwriting log files, you must set the IIS Log File Access Control permission. By default, IIS logs are stored in the "% systemroot % system32logfiles" directory. If possible, you can change the Log Path to another location. Recommended access Control permissions: Administrators (Full Control); System (Full Control); Everyone (RWC ). this step prevents malicious users from hiding their records by deleting log information.
D. Delete dangerous scripts:
For example, a heap overflow vulnerability exists in request processing for the ing of. htr files. Remote attackers can exploit this vulnerability to gain access permissions to common users on the host. For idq. dll, there is an unchecked buffer when processing some URL requests. If an attacker provides a URL in a special format, a buffer overflow may occur. By carefully constructing and sending data, attackers can change the Program Execution Process and execute arbitrary code. Attackers can exploit this vulnerability to remotely obtain the "Local System" permission. Therefore, deleting unnecessary scripts can minimize the possibility of exploiting vulnerabilities:

Screen. width-300) this. width = screen. width-300 "border = 0>

2. Data attacks
The following mainly summarizes the security policies for SQL Injection and the settings for SQL Server. The so-called SQL Injection refers to the use of some external interfaces of the database to insert user data into the actual database operating language, so as to intrude into the database and even the operating system. In a Web system that uses WEB scripting language (ASP, PHP) as the front-end + database as the backend, in order to achieve the purpose of interacting with users, it is inevitable that some items are information submitted by the user, such as the user's login information, query strings, or information that the user can modify remotely. Attackers may exploit this information to tamper SQL statements into other combined statements for attack purposes.
Here is a simple example:
<Html> <Title> text </title>
</Head>
<Body>
<%
Dim conn
Dim rst
Username = request. querystring ("username ")
Password = request. querystring ("password ")
Set conn = Server. createObject ("ADODB. Connection ")
Conn. open strConn database connection string omitted
Set rst=conn.exe cute ("select * from login where username =" & username & "and password ="
& Password "")
If not rst. eof then
Response. write "log in"
Else
Response. write "failed"
End if
Rst. close
Conn. close
%>
</Body>
</Html>

The key code for implementing SQL Injection is as follows:
Set rst=conn.exe cute ("select * from login where username =" & username & "and password =" & password "")
In the database, we define username = user and password = pwd In the table login. If you enter the correct username and password in the logon interface, the username and password are embedded in the SQL statement. The URL is:
H t p: // localhost/test. asp? Username = username & password = password
What if intruders submit such a URL?
H t p: // localhost/test. asp? Username = username & password = any or 1 = 1 --
Result: The SQL statement is as follows:
Select * from login where username = username and password = any or 1 = 1 --
And 1 = 1 is always true, -- the following things will be ignored. Therefore, no matter what the correct password is, this statement returns login.
This is the most typical SQL Injection, which is also a relatively simple one. SQL Injection is more threatening than that. It also includes obtaining background database information, reading data from the database, obtaining system information, and modifying the registry.
Based on the above features, we propose the following preventive measures:
First, SQL Injection usually occurs when interacting with users. Therefore, it is very important to strictly filter user input, especially for single quotation marks, double quotation marks, and "-" symbols. In addition, it not only filters the QUERY_STRING environment variables, but also filters the data submitted by all forms and all interactive data such as the drop-down menus and buttons that can be controlled by users through modifications. At the same time, considering that many malicious attacks may combine some data combinations to bypass this filtering method. Therefore, a safer method can be used for some security replacement. For example, replace single quotes with two single quotes.
Input = replace (input ,"","")
However, filtering only from the perspective of the program is not enough. It also needs to be combined with other security measures, such: use the firewall to filter out special characters such as single quotes, double quotation marks, and "-" That enter port 80.
In addition, you must perform necessary security configurations on SQL Server to delete some stored procedures:
1. directly run the stored procedure of the system command: xp_mongoshell. Xp_mongoshell is the best way to enter the operating system and a large backdoor left by the database to the operating system.
2. Delete the stored procedures for accessing the Registry. Some Registry Stored Procedures can even read the password of the Operating System Administrator: xp_regaddmultistring, xp_regdeletekey, xp_regdeletevalue, xp_regenumvalues, xp_regread, expires, xp.
3. OLE stored procedure: Sp_OAcreate, Sp_OADestroy, Sp_OAGetErrorInfo, Sp_OAGetProperty, Sp_OAMethod, Sp_OASetProperty, Sp_OAStop
4. Other stored procedures with certain security risks, such as xp_servicecontrol, xp_stopmail, xp_startmail, xp_perfmonitor, listener, xp_perfend, sp_sdidebug, listener, xp_deletemail, listener, xp_dropwebtask, xp_dsninfo, etc.
In fact, most applications do not use many systems at all.