How to Use Syslog To record UNIX and Windows logs

In large-scale network applications or applications with certain security requirements, you usually need to classify and review system logs. By default, each system will record its own logs on the local hard disk. Although there are also logs, there are many disadvantages: first, it is inconvenient to manage. When the number of servers is large, it is inconvenient to log on to each server to manage and analyze logs, followed by security issues. Once an intruder logs on to the system, he can easily delete all logs, system Security Analysts cannot obtain any intrusion information.

Therefore, it is ideal to arrange a dedicated log server in the network to record system logs. This document uses the syslog in FreeBSD as an example to describe how to use the syslogd of freebsd to record log information from UNIX and windows.

1. Record the log information of UNIX-type hosts

First, you must configure Freebsd syslog so that it can receive log information from other servers.

Add the following to/etc/rc. conf:

Syslogd_flags = "-4-A 0/0 :*"

Note: The syslogd parameter settings of freebsd are placed in the syslogd_flags variable in the/etc/rc. conf file.

Freebsd's default parameter for syslogd is syslogd_flags = "-s", which can be seen in/etc/defaults/rc. conf)

The default parameter-s indicates that the UDP port listener is enabled, but only the UDP port of the local machine is listened, and the log information from other hosts is rejected. If there are two ss (-ss), it means that no UDP port is opened, and logs are recorded only on the/dev/log Device of the current machine.

Description of modified parameters:

-4 only listens to IPv4 ports. If your network is an IPv6 protocol, you can change it to-6.

-A 0/0: * accept the log information sent from all ports in all CIDR blocks.

If you only want syslogd to receive log information from a specific network segment, write-a 192.168.1.0/24 :*

-A 192.168.1.0/24:514 or-a 192.168.1.0/24 indicates that only the log information from port 514 of the CIDR block is received, which is also the default setting of the syslogd process of freebsd, that is to say, freebsd determines the port on which the sender sends information when receiving log information from other hosts. If the sender does not send the information on port 514, freebsd's syslogd rejects the message. That is, by default, port 514 of the remote IP address must be sent to port 514 of the local IP address,

Add * to the parameter to allow receiving log information from any port. In this case, when recording UNIX host information, you do not feel any difference because UNIX hosts use port 514 to send and receive syslogs. But it is very important to receive windows information. Because the syslog software in windows does not need to send information on port 514, this will cause the default syslogd to refuse to receive information. I also used syslogd in linux to configure the log server. I found that syslogd in linux does not have so many restrictions. I only need to add the-r parameter to syslogd, it can receive syslog information from any port on any host. In this regard, freebsd's default configuration is more secure than linux.

After modifying the syslogd parameter, we need to modify the/etc/syslog. conf file to specify the storage path of log information,

For example, if you want to record the remote login and logout information of other systems and specify the log storage path, you need to modify the following lines:

Authpriv. */var/log/testlog

This means that the system login and logout logs include the local system login and logout logs) are stored in the/var/log/testlog file.

Of course, this is the most simple practice, because it will store the login and logout information of all servers in a file, which is inconvenient to check. The common practice is to use a script, sort the received information and send it to different files.

The following settings:

Authpriv. * |/var/log/filter_log.sh

Adding "|" before the record target indicates that the received information is handed over to the subsequent program for processing. This program can be a specialized log processing software, it can also be a small script compiled by yourself, for example:

#! /Bin/sh

Read stuff

SERVER = 'echo $ stuff | awk' {print $4 }''

Echo $ stuff>/var/log/login_log/$ SERVER. log

This simple script uses IP addresses as the basis for classification. read the log information first and use awk to retrieve the fourth field, that is, the field where the IP address or host name is located ), store logs of the host using this field as the file name.

In this way, logs from 192.168.1.1 are recorded in the 192.168.1.1.log file, and logs from 192.168.1.2 are recorded in the 192.168.1.2.log file, which makes analysis and classification easier. Of course, this is the simplest example. Readers can write better scripts based on their own needs, and even classify log information and insert it into the database. This makes log management and analysis easier.

Finally, restart the syslogd service to make the configuration take effect:

/Etc/rc. d/syslogd restart

OK. The server configuration is complete. Now configure the client:

The client here refers to sending its own logs to the host on the remote log server.

Modify the/etc/syslog. conf file:

For example, if you only need to record the system login and logout logs to the remote log server, you only need to modify the following line:

Authpriv. * @ 192.168.10.100

192.168.10.100 is the IP address of the log server. The "@" symbol indicates that the IP address is sent to the remote host.

OK. Restart the syslog service:

Linux:/etc/init. d/syslogd restart

BSD:/etc/rc. d/syslogd restart

Use logger to test whether the configuration is successful:

Logger-p authpriv. notice "Hello, this is a test"

Go to the log server and check that "Hello, this is a test" should have been recorded. Finally, log in and log out several times on the client to check whether the real authpriv information is successfully recorded.

Ii. Windows Logging

For logs recorded between UNIX hosts, the Protocol, software, and log information formats are similar, so the implementation is simple, but the windows System Log formats are different, the logging software, methods are different. Therefore, we need third-party software to convert windows logs into syslog logs and forward them to the syslog server.

Introduction to third-party software evtsys (evntlog to syslog)

There are only a few K files, which are very clever. After decompression, there are two files: evtsys.dlland evtsys.exe.

Copy the two files to the c: \ windows \ system32 directory.

Open the Windows command prompt and start-> Run and Enter CMD)

C: \> evtsys-I-h 192.168.10.100

-I indicates that the service is installed as a system service.

-H: Specify the IP address of the log server

If you want to uninstall evtsys, then:

Net stop evtsys

Evtsys-u

Start the service:

C: \> net start evtsys

Open the windows Group Policy Editor (START-> Run and enter gpedit. msc)

Go to windows Settings> Security Settings> Local Policies> Audit Policy to open the windows logs you need to record. Evtsys checks whether a new windows Log is generated in real time, converts the new log to a recognizable syslogd format, and sends it to the syslogd server through UDP port 3072.

OK. All windows configurations are complete. Now configure the syslogd configuration file,

The parameter configuration is the same as above. The difference is that evtsys sends the information to syslogd log as a daemon device. Therefore, you need to add the following to/etc/syslog. conf:

Daemon. notice |/var/log/filter_log.sh

For more information about syslog recording devices and record levels, see the syslog documentation.

OK. All configuration settings are complete.

System logs on Linux, BSD, and windows can be recorded on a single log server for easy management.

Related Articles]

• How to Use LogMiner to analyze database logs

• How to restore binary logs of MySQL Databases in Linux

• Efficient logging using cyclic buffers in multi-threaded applications