Trapping intruders in Linux (3)

Article title: trapping intruders in Linux (3 ). Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
Author: Hong Xiaoye
　　
Configuration
　　
After installing SNARE and running it, you need to configure it. Just as the syslogd monitoring program has syslog. conf, the auditd monitoring program also has the audit. conf file. After the installation is complete, the file will be placed in the/etc/audit directory. It should be said that the file is intuitive, but to ensure its format is correct, it is recommended to modify it only through the GUI. To configure the file, go to the "Setup, Audit Configuration" menu. You can modify the following parameters here:
　　
AuditType: The default value is "Objective". Another option is "Event ".
　　
HostID: you can specify the name of the remote host to display its SNARE log file.
　　
Objectives: The level to be reviewed.
　　
Events: all auditable kernel calls.
　　
Output: The location where you want to store log files. the default value is/var/log/audit. log.
　　
The Audit. conf file also consists of the same content. If Objective audit is selected, the displayed rule file will be applied. If the Events log is selected, the call list in the Event section displays 0 or 1 to indicate whether the log is recorded. Note that you can select Objective logs or Kernel logs here, but you cannot select both.
　　
The flexibility of SNARE is mainly reflected in rule configuration through Objective logs. Of course, the type we choose to use depends mainly on the reason we use the tool, but if you want to have more control over the content under review, it is best to use the Objective review method.
　　
When you Add a target rule (click "Add an Objective" on the Current Objectives tab of Audit Configuration), you can see the options for configuring the rule (see ).
　　
Options when configuring rules
　　
SNARE has five steps:
　　
1. advanced configuration;
　　
2. filters to be reviewed;
　　
3. check whether the filter of successful, failed, successful, or failed events is reviewed;
　　
4. whether to review all events in use, or choose to review events of a user;
　　
5. when this event occurs, select an alert level for it.
　　
The warning level includes from Critical to Clear. Clear indicates that it does not matter. it only prompts that something has happened. When the information prompts, if a good thing happens, green is used; Warning is yellow; Priority is orange; Critical is red.
　　
Objective log
　　
In fact, the default Objective configuration already covers the basic content to be reviewed, it monitors read/write or creates/etc/shadow files, reads or creates/etc/passwd files, reads/writes, or creates audit files. In addition, the use of the/sbin,/usr/sbin,/bin, and/usr/bin directories, and the use of the su program accept a new connection, switching to the/etc and/var/log directories, opening an external connection will be monitored. For a more comprehensive review system, it is recommended that other files be monitored. This mainly depends on available resources and disk space.
　　
I am concerned about whether someone has modified, added, or used some important files in my system. These files include: login, telnet, ftp, netstat, ifconfig, ls, ps, ssh, find, du, df, sync, reboot, halt, and shutdown. You can set a rule to monitor the operations on each file. In addition, pay attention to the operations on file writing and creation in the/sbin,/usr/sbin,/bin, and/usr/bin directories. This seems a little troublesome, but it is quite necessary. Because the default rule set does not monitor the content, some potential problems are easily ignored.
　　
In addition, the other files that we may want to monitor the modification behavior are/etc/lilo. conf,/etc/syslog. conf,/etc/resolv. conf and/etc/sendmail. cf file. If the lilo. conf file is modified, pay attention to it, especially if the kernel has not been upgraded recently. If the resolv. conf file is modified, it is very likely that someone tries to make your host a DNS server that is not what you expected. If an attacker wants to conceal its traces, he may need to modify your syslog. conf file. Also, if Sendmail is running on your server, we recommend that you set a filter for Sendmail. cf. If someone modifies this file, it is very likely that someone wants to enable some services (such as VRFY and EXPN) that you don't want to enable in your Sendmail environment ), this will directly cause information leakage of many email accounts.
　　
Maybe you want to monitor all the client application files of non-local applications running on your Linux server, then you need to perform the test first when setting the rule set, check whether your hardware platform has sufficient load processing capabilities. Of course, this depends on the number of monitored files.
　　
Event (Kernel) log
　　
As mentioned above, if kernel logs are used, pay attention to the available disk space and kernel logs. Because there are many options to choose whether to log, and it is more sensitive at the kernel level.
　　
At this level, the content monitored by SNARE includes resource access and security, command execution, and resource creation and deletion. Resource access and security, including setuid, open, rename, chmod, and chown. Command execution includes chroot, reboot, and socket call. Resource creation and deletion include symlink, create_module, and mknod. User reviews are not considered for these calls, that is, all users must be reviewed. You can select all of them, but it is actually necessary to set the logs at this level only on the server.
　　
Test configuration
　　
We test the Objective and Kernel logs to observe the functions implemented by the two. In reality, no matter how confident we are, we need to test our settings. We will perform the minimal test (the Objective uses the default settings of audit. conf and the selective kernel call is used for the test Event) to get a feel of the SNARE operation process. Then, log on as a user and perform some random tasks on the system. observe the effect of auditd on information transmission.
　　
First, I tried to find the audit. conf file and tried to use telnet for external connections. In the audit. conf file, both actions are set to be monitored. Then I checked the review log and found that there were very few records, mainly about some content of the telnet session (such as what type of call, program permission, and response code ), however, this completely records the corresponding process of my operations.
　　
Then, perform more tests, such as changing the user password. This behavior is not recorded, because in the configuration rules, this row is executed as root. Then I changed my password (recorded) and tried to copy the ls program to/tmp. I was not only allowed to do this, but only recorded in the log that the mv program was executed. I added the/bin/ls modification to the rule and moved the file again. The result was recorded this time.