Syslog configuration Log Server

Syslog configuration log server on
For large-scale network applications or applications with certain security requirements, you usually need to classify and review system logs. By default, each system records its own logs on the local hard disk.
Although logs can also be recorded, there are many disadvantages: first, management is inconvenient. When the number of servers is large, it is very inconvenient to log on to each server to manage and analyze logs, second, security issues.
Users can log on to the system and 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.
Solution. 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 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" (you can see it 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-
192.168.1.0/24 indicates that only the log information from port 514 of the CIDR block is received. This is also the default setting of FreeBSD's syslogd process, that is, FreeBSD
When receiving the log information from other hosts, the system determines the port on which the other server sends the information. If the other server does not send the information on port 514, The syslogd of FreeBSD rejects the receiving.
. 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 sends and receives syslogs. But it is very important to receive windows information. Because the syslog software in Windows does not need to send messages through port 514
This will cause the default syslogd to reject receiving information. I also use syslogd in Linux to configure the log server.
Syslogd does not have so many restrictions. if you add the-R parameter to Syslogd, you can receive syslog information from any port on any host. In this regard, FreeBSD's
The security of the default configuration is slightly higher than that of 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 (including 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
In the 192.168.1.2.log file, analysis and classification are easier. Of course, this is the simplest example. Readers can write better scripts based on their own needs, and even divide log information
After the class is inserted into the database, it is easier to manage and analyze logs.

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 log records are soft
Parts and 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)
This is a very small and free third-party logging software, as shown below:
Https://engineering.purdue.edu/E

... Cuments/Unix/evtsys
There are only a few K files, which are very clever. After decompression, there are two files: evtsys.dlland evtsys.exe.
Copy these two files to the C:/Windows/system32 directory.

Open a Windows Command Prompt (START-> RUN 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>
Go to local policy> Audit Policy to open the windows logs you need to record. Evtsys checks whether new windows logs are generated in real time, and then transfers the new logs
Switch to the recognizable syslogd format and send 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 logs 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.