| Solaris log Introduction Assume that you are a website administrator using the Solaris operating system. One day, you accidentally saw the following similar content in the messages file on your hard disk/var/adm directory:
Apr 24 20:31:04 nmssa/usr/dt/bin/rpc. ttdbserverd [405]: _ tt_file_system: findbest
Mountpoint -- max_match_entry is null, aborting...
Apr 24 20:31:05 nmssa inetd [140]:/usr/dt/bin/rpc. ttdbserverd: segmentation faul
T-core dumped
Do you know what this means? Your system is at least 99% likely to be intruded! At present, the system administrator who uses Solaris knows that there is a directory ADM in the/var zone, which contains many log files, such as messags, syslog, sulog, and utmp, they record various message logs generated by the Solaris system. From the perspective of the system administrator, it is necessary to clearly understand the functions and functions of each log file. in the case of system security problems, these log records can help and diagnose in a certain sense. Let's look at the main files in the ADM directory in sequence.
ADM/messags
Let's take a look at the most important messages file. Messages records various running logs from the core of the system, including the messages of various elves, such as authentication and inetd processes, and the special status of the system, system messages, such as high temperature, can be said to be one of the most important logs of the system. Messages records the content determined by/etc/syslog. conf. If you are interested, you can use the man syslog. conf command to learn more. In terms of security, most of the measures used by intruders on the internet currently exploit system vulnerabilities. When intruders attempt to exploit these vulnerabilities to attack your servers, exceptions are usually left in the server's messages file, as described in the beginning of this article. the trace of the TTDBServer vulnerability attack, which is one of the most notorious Solaris system vulnerabilities. By exploiting this vulnerability, intruders can easily obtain superuser permissions from the remote end, however, this attack is not a clean intrusion attack. It will keep records under messages and generate core files under the root directory. If the careful administrator checks system logs frequently, it is not difficult to find intruders or intrusion attempts, as shown in the following record:
Apr 24 11:26:25 unix.secu.com ftpd [7261]: anonymous (bogus) Login Failed [from 11.22.33.46]
Apr 24 11:27:23 unix.secu.com ftpd [7264]: 163 (bogus) Login Failed [from 11.22.33.49]
Apr 24 11:28:44 unix.secu.com ftpd [7265]: ABC (bogus) Login Failed [from 11.22.33.46]
The administrator can clearly see from the above record that a suspicious user guessed the FTP password of the host at, and on the 24 th day, their source IP addresses are 11.22.33.46 and 11.22.33.49.
ADM/sulog
Sulog records the attempts of common users to become other users. The format is: occurrence time +/-(success/failure) PTS Number of the user to be Su
Let's take a look at some of the actual content:
Su 04/15 + pts/6 yiming-Root
Su 04/15 + pts/4 root-yiming
Su 04/17-pts/5 cheny-Root
Su 04/18-pts/4 cheny-Root
Su 04/19 + pts/11 lizhao-Root
Su 04/19 + pts/11 cyss-Root
Su 04/21-pts/4 cheny-Root
Su 04/21-pts/8 cheny-Root
Su 04/22-pts/5 cheny-Root
The administrator needs to pay close attention to the two types of users. The first is repeated su failures. For example, the preceding cheny user is suspected of having to guess the superuser password. The second is the su record at an abnormal time. For example, if the user lizhao in the sixth line above entered the correct password (with the + number in the fourth column), but the time at is suspicious, this is a time when administrators are unlikely to work. You must know that intruders may have installed software such as Sniffer and used it to steal the superuser password. In order to do further work, such as stealing sensitive host data, intruders need to perform complex operations, but the system administrator activity time during the day is more likely to be detected, so even if the intruders get a high-Permission password, the Administrator usually does not work late at night. No one will arrest him in these cases. ADM/utmp, utmpx
These two files are not readable. They record the users currently logged on to the host. The administrator can use commands such as W and WHO. The output result of who is shown below,
Yiming pts/29 Jun 12 (11.22.33.44)
Yiming pts/28 Jun 12 08:41 (11.22.33.43)
Guest pts/30 Jun 12 09: 26 (penetrate.hacker.com)
Root pts/19 Jun 12 08:19 (: 0.0)
The output is very simple. Each line contains the user, PTS, time, and source location. When the Administrator finds that the system is suspicious, the Administrator usually uses these two commands to view the current user. If there is an abnormal user name in the output or the source IP address is suspicious, the administrator should pay attention to it. For example, the above Guest user is suspicious. Although the user name guest is valid, the user's source penetrate.hacker.com does not seem very secure. It is necessary for the system administrator to monitor the user's behavior. Note that the administrator cannot fully trust the results reported by W, WHO, and the last command mentioned below, and use specific log erasure software, intruders such as zap can easily erase the traces of intruders. A smart intruder generally uploads the compiled erasure software to the victim host and immediately erases the software after the intrusion into the system, for example, if he runs zap on the affected host,
./Zap-V guest
-Wtmp:
Wtmp =/var/adm/wtmp
Removing user guest at pos: 131328
Done!
-Utmp:
Utmp =/var/adm/utmp
Removing user guest at pos: 864
Done!
-Lastlog:
Lastlog =/var/adm/lastlog
User guest has no wtmp record. Zeroing lastlog ..
-Wtmpx:
Wtmpx =/var/adm/wtmpx
Done!
-Utmpx:
Utmpx =/var/adm/utmpx
Done!
In this case, let's see what changes have taken place when we use W?
Yiming pts/29 Jun 12 (11.22.33.44)
Yiming pts/28 Jun 12 08:41 (11.22.33.43)
Root pts/19 Jun 12 08:19 (: 0.0)
We can see that the intruders have disappeared! This is good news for intruders, but for a system administrator with poor security awareness, this host is not great. We recommend that you install other system monitoring software, such as ttywatcher and ethereal, if the system does not look very promising and cannot be identified by W and last. ADM/wtmp, wtmps
These two files are equivalent to historical records. They record all users who have logged on to the host, time, source, and other content. These two files are also not readable. The last command is available as follows.
Support pts/13 11.22.33.44 Thu APR 20)
Gogo pts/12 11.22.33.45 Thu APR 20)
Root ftp secu.unix.com wed Apr 19) The Administrator should pay attention to the logon records that occur at abnormal times or from suspicious locations, such as the Gogo user in the output above. This time is not normal.
Like the above utmp and utmpx, the administrator should also be clear: Last can only give you a rough reference, do not fully trust the result of last. In addition to the above files, there is also a SYSLOG file in the/var/log directory. The content of this file is generally recorded for mail events. The Administrator should always check whether there are any exception records. Finally, Solaris is a rarely used but extremely useful feature-accounting. The Solaris operating system can set a log file to record each command of each user. This function is disabled by default, the accton file under the/usr/lib/Acct directory must be executed in the following format:/usr/lib/Acct/accton/var/adm/pacct. In The Sun manual, this is the only method, but the disadvantage of this method is obvious. Most experienced intruders will not miss the/var/adm and/var/log directories, if they see the pacct, it's strange not to delete it. There is actually a good solution to this situation. Execute/usr/lib/Acct/accton followed by another directory and file, for example,/usr/lib/Acct/accton/yiming/log/commandlog. In this way, intruders do not see pacct under/var/adm/. Intruders may delete logs such as message and syslog, however, he does not know that all his operations are actually recorded. The Administrator only needs to copy the commandlog file to/var/adm, change it to pacct, and execute the READ command lastcomm, everything is ready. For example, lastcomm hack, the following output is displayed:
Sh s hack pts/7 0.05 secs mon Jun 12
Sh F hack pts/7 0.00 secs mon Jun 12
Ls hack pts/7 0.01 secs mon Jun 12
Ls hack pts/7 0.02 secs mon Jun 12
Ls hack pts/7 0.01 secs mon Jun 12
DF hack pts/7 0.03 secs mon Jun 12
FTP hack pts/7 0.02 secs mon Jun 12
Ls hack pts/7 0.01 secs mon Jun 12
VI hack pts/7 0.02 secs mon Jun 12
Who hack pts/7 0.02 secs mon Jun 12
Is it nice to know what hack is doing from the output? In fact, you can pay attention to network security from some small aspects. If you use it properly, it will play a better role. The Administrator should start by following your log files. |
