Disclosure of Windows server intrusion detection

Win2000 server Security Configuration, a carefully configured Win2000 server can protect against more than 90% intrusion and infiltration, but system security is a continuous process, with the advent of new vulnerabilities and server application changes, the security situation of the system is also changing At the same time, because of the contradictory unity of attack and defense, the magic long and the magic is also in constant conversion, so the system administrator can not guarantee that a server is providing services for a long time will never be invaded.

So, the security configuration server is not the end of security work, but it is the beginning of a long tedious security work, I will explore the initial Win2000 server intrusion detection techniques, I hope to help you maintain the security of the server for a long time.

Intrusion detection refers to the use of the Win2000 server itself and the system administrator's own software/scripts for testing, the use of _blank "> Firewall (Firewall) or intrusion detection system (IDS) techniques are not covered in this article.

Now let's assume that we have a server with Win2000 servers and have a preliminary security configuration, in which case most of the intruders will be shut out. (Haha, my administrator can go home to sleep) Wait, I said most, not all, after the initial security configuration of the server, although it can defend the vast majority of script kid (scripting family-only use other people write the program to invade the server), met the real master, or vulnerable. Although the true master will not casually enter the other people's servers, but there are also a few misconduct of the evil experts have a crush on your server. (Do I really suck?) Moreover, the discovery of vulnerabilities and the release of patches often have a period of time between the vacuum, any person who knows the vulnerability information can be exploited, at this time, intrusion detection technology appears to be very important.

Intrusion detection is mainly based on the application, providing the corresponding services should have a corresponding detection and analysis system to protect, for the general host, the main attention should be paid to the following:

1, based on the 80-port intrusion detection

WWW service is probably one of the most common services, and because of this service to the vast number of users, the service flow and complexity are very high, so for this service vulnerabilities and intrusion techniques are the most. For NT, IIS has always been a part of the system administrator's headache (80 ports are out of the way), but fortunately, the logging capabilities of IIS can be a powerful helper for intrusion detection. IIS's own log files are stored by default in the System32/logfiles directory and are typically scrolled by 24 hours, and can be configured in IIS Manager in detail. (specifically how to match I do not care about you, but if you do not detailed records, back to find the intruder IP can not cry)

Now let's assume (how can we always assume that it's not annoying?) Don't worry, I can't really go black out a host to write this article, so let's assume that we assume a Web server, open the WWW service, you are the server's system administrator, have carefully configured IIS, use the expanded log format, and at least record the time, Client IP (clients IP), methods (method), URI resource (Uri Stem), URI lookup (URI query), protocol status (Protocol status), We use the recent more popular Unicode Vulnerabilities for Analysis: open IE window, in the Address bar input: 127.0.0.1/scripts/. %c1% 1c. /winnt/system32/cmd.exe?/c+dir By default you can see the list of directories (what?) You've made a security configuration, you can't see it? To restore the default installation, let's take a look at what the IIS logs are all about, open Ex010318.log (ex on behalf of the expansion of the format, followed by a string of numbers representing the log date): 07:42:58 127.0.0.1 get/scripts/ .. \.. /winnt/system32\cmd.exe/c+dir 200 The above line log indicates that 07:42:58 GMT (is the 23:42:58), There's a guy (intruder) using a Unicode vulnerability (%c1%1c decoded to "\") from 127.0.0.1 IP on your machine, and the actual situation will be slightly different because of the language version of Windows. Cmd.exe, parameter is/C dir, The run result was successful (HTTP 200 represents the correct return). (Wow, the record is really full, and I don't dare to play Unicode any more)

In most cases, the IIS log will faithfully record any requests it receives (there are also special attacks that are not logged by IIS, which we will discuss later), so a good system administrator should be adept at exploiting this to discover an intrusion attempt to protect his system. However, IIS logs are dozens of megabytes, large traffic site even dozens of G, manual inspection is almost impossible, the only option is to use log analysis software, in any language to write a log analysis software (in fact, text filter) is very simple, but take into account some of the actual situation (such as administrators do not write programs, Or the server is unable to find log analysis software, I can tell you a simple way, for example, you want to know if anyone from the 80 port to try to get your Global.asa file, you can use the following cmd command: Find "Global.asa" ex010318.log/i This command uses the NT Find.exe tool (so not afraid to find the emergency), you can easily find the text file you want to filter the string, "Global.asa" is the need to query the string, Ex010318.log is a text file to be filtered, and/I represents ignoring case. Since I have no intention of writing this article as a Microsoft Help document, please check out the Win2000 assistance file for the other parameters of this command and the usage of its enhanced version FindStr.exe.

Either based on the log analysis software or the Find command, you can create a list of sensitive strings containing existing IIS vulnerabilities (such as "+.HTR" and future vulnerabilities that might be invoked (such as Global.asa or Cmd.exe), by filtering this constantly updated string table, you will be able to understand the intruder's actions as soon as possible.

You need to be reminded that using any log analysis software consumes a certain amount of system resources, therefore, for IIS log analysis of such low-priority tasks, it is more appropriate to put the automatic execution at night Idle, if a script to send the filtered suspicious text to the system administrator, it is even more perfect. At the same time, if the sensitive string table is large and the filtering strategy is complex, I suggest that it is more cost-effective to write a dedicated program in C.

2, based on the security log detection

Through intrusion monitoring based on IIS logs, we can know in advance the whereabouts of the stalker (if you do not, the stalker will become an intruder at any time), but the IIS log is not omnipotent, in some cases it can not even record the intrusion from port 80, according to my analysis of the IIS log system, IIS does not write to the log until a request completes, in other words, if a request fails halfway through it, there is no trace of it in the log file (the Midway failure is not the case of a HTTP400 error, but the HTTP request is not completed from the TCP layer. For example, when a large number of data is post with an exception, it is possible for intruders to bypass the log system to perform a large number of activities.

Moreover, for a host that is not only, intruders can also access the server from other services, so it is necessary to establish a complete security monitoring system.

WIN2000 has a very strong security log system, from the user login to the use of privileges have very detailed records, unfortunately, the default installation security audit is closed, so that some hosts are black after the intruder can not be traced. So the first step is to open the necessary audits in the admin tool-Local Security policy-local policy-audit policy. In general, login events and account management is our most concerned about the event, while opening success and failure audit is necessary, the other audit to open failure audit, so that the intruder can be difficult to step , inadvertently will be revealed. Just turning on security audits does not completely solve the problem, and without a good configuration of the size and coverage of the security log, a seasoned intruder can overwrite his real whereabouts with a flood of fake intrusion requests. In general, this can be avoided by specifying the size of the security log as 50MB and allowing only logs that cover 7 days ago.

Setting the security log without checking is almost as bad as not having the security log set (the only advantage is that the intruder can be traced after being hacked), therefore, it is also very important to develop a security log inspection mechanism, as a security log, the recommended check time is every morning, which is because, Intruders like night action (fast, or you invade half of the time not even, it is crying not to come out) the first thing to go to work in the morning to see if the log is abnormal, then you can rest assured to do other things. If you like it, you can also write a script to send you a security log as a message every day (don't believe it too much, if any master to change your script, send "safe" every day ... ）

In addition to the security log, system logs and application logs are also very good auxiliary monitoring tools, in general, the intruder in addition to leaving traces in the security log (if he has access to admin permissions, then he will definitely go to clear the traces), in the system and application log also left traces, as a system administrator, It is difficult for intruders to conceal their whereabouts without any unusual attitude.

3, file access log and key File Protection

In addition to the system default security audit, for critical files, we also need to set up a file access log to record access to them.

There are many options for file access: Access, modification, execution, new, property changes ... In general, attention to access and modification can play a large role in monitoring.

For example, if we monitor changes to the system catalog, create, or even access some of the most important files (such as Cmd.exe, Net.exe,system32 directory), then, it is difficult for intruders to place the back door without our attention, it should be noted that the monitoring of key files and projects can not be too much, otherwise not only increase the system burden, but also disrupt the day-to-day log monitoring work
(Which system administrator has the patience to watch 四、五千条 garbage logs every day?) ）

Critical files not only refer to system files, but also any files that may pose a threat to system administrators/other users, such as system administrator configuration, desktop files, and so on, which may be used to steal system administrator information/passwords.

4. Process Monitoring

Process monitoring technology is the tracking Trojan back door of another powerful weapon, more than 90% of the Trojan Horse and the back door is in the form of the process, as a system administrator, to understand the server running every process is one of the responsibilities (otherwise do not say security, even system optimization can not do), It is necessary to make a list of the running processes for each server, which can help the administrator to discover the intrusion process at a glance, the abnormal user process or the unusual resource occupation may be illegal process. In addition to the process, the DLL is also dangerous things, such as the original EXE-type Trojans rewritten as DLLs, the use of Rundll32 run is more confusing.