3. Determine the WWW Service Type

There was a stage for analyzing the target host before the intrusion target. Now let's talk about how to analyze the target host before the invasion of the server (that is, the data collection before the intrusion, of course, the more detailed the collected information, the more helpful it will be.) Although some cool people have developed useful tools, we cannot rely on fully automated analysis such as X-Scan and streamer, scan tool. To become a master and a hero, you should also learn not to rely on tools. This technology has been improved. At the same time, because conditional servers also have professional IDS systems, if you use this type of tool blindly, the IDS system of the other party will keep ringing. At that time, your X-Scan or streaming progress bar may be 10% complete, the cyber police just pushed the doorbell of your house. So how should we collect data before the intrusion?

First, analyze the response message of the WWW server, that is, check the BANNER of the server (read here only for cainiao, and leave this opportunity to the disciples ). This method was commonly used and accurate in the past. For more information, I would like to mention it here. It is best to use NC to analyze such reports. Friends who like the graphic interface can also use the tool "WSockExpert.

HTTP/1.1 200 OK

Date: Sun, 20 Feb 2005 00:43:03 GMT

Server: Apache/2.0.48 (Win32) PHP/4.3.1

Accept-Ranges: bytes

X-Powered-By: PHP/4.3.1

Transfer-Encoding: chunked

Content-Type: text/html; charset = gb2312

This line of "Server: Apache/2.0.48 (Win32) PHP/4.3.1" responds to the Server-related information. It uses a Windows operating system. Unfortunately, this method is not accurate in the current era. Because the Banner can modify it at will, you can change MS's IIS to * NUX's APACHE, or change it to your own IIS, As long as Gates does not oppose you. Then how can we tell the right server?

Method 2: access the server directory to see how the server responds. Generally, the system that directly accesses the server can be roughly analyzed as * NUX or Windows. For example, a website is displayed by a product. Generally, images are used to increase the color of a website. You can access the image directories on the website. For example, http: // localhost/images/a.jpg, you can access it through "http: // localhost/images" in your browser. If the other side is MS's IIS, the following statements are generally returned: "Directory Listing Denied" and "This Virtual Directory does not allow contents to be listed. If a Directory Index is configured for the file, the file is listed.

The IIS response is like this. What if it is an Apache response? The Apache server generally responds with a list of IIS Access prohibited or file indexes. However, its response is different from that of IIS. The figure below shows the information returned by Apache. Access the corresponding directory in the same way. If the directory does not contain the default file list index, the system will respond to "403 Forbidden" and the server version information of the file will be returned:

This also tells us that its server is Apache and the version is Win32 2.048, that is, the WWW server of the other party is running APACHE on Windows, which is easy to understand! However, some network administrators do not want to send such error information to visitors. They usually take the error page to a normal page, such as the homepage or the previous page or the error report page. Generally, it is difficult for new users to determine what tricks the other party is playing! Next we will reference a more rational analysis.

Third: Use differences in file names. People who know the operating system may know the file name problem. For example, in a Windows system, the file name is usually composed of 26 letters and 10 digits. * The Relationship Between NUX and Windows is the same, but the difference is that the letters in the file names on Windows are not case sensitive. That is, "ABC. eXe" and "abC. ExE" are regarded as the same file. In * NUX systems, this kind of thing is not allowed. Based on the differences between the two systems, we can perform targeted analysis in a targeted manner. For example, the URL of the webpage accessed by the browser is changed. For example, http: // localhost/index is displayed in the address bar of the browser. php URL, put "/" behind the Page name ". php "to". phP ", if it is a Windows system, it will also access this page normally. If it is * NUX system, it will prompt that this file cannot be found. In this way, you can know what the other party is.

As long as the server analysis is flexibly combined with the above three methods, 95% of the systems can be analyzed. I did not intend to write this because I think these methods are more effective, and I have worked hard to give fans or network administrators a better understanding of the system. If you have a better solution, welcome to the anti-DDoS Forum!