What I would like to do is to set up a linux box as a syslog server.
There's a couple of documents i've read which say the logs can be sent to a database, viewed over a web interface using PHP, this sounds great.just what I need ( see attached doc.).However, due to my lack of linux skills this doc is not easy to follow.Is this something anyone has done before?,
What do I want to achieve?, I have some cisco switches I would like to monitor ie who last logged on, what changes were made, etc & would like to view these events via web browser.Is there an easier way to achieve this without the comlexity of the attached document.
I've managed to get my linux box to listen on port 514 by editing the file /etc/sysconfig/syslog adding -r to the line SYSLOGD_OPTIONS="-m 0 -r" .
Hope you can help .
"-m 0" disables the timestamp mark in the syslog file, /var/log/messages on Linux systems.
The configuration below is the only client configuration needed. The rest of the article pertains only to the central syslog server.
Each client's syslog.conf file is then configured to send alerts to the central syslog server, by adding the line:
*.* means to send all syslog messages to the remote syslog server, in this article named julie.
Then refresh the syslog daemon:
End client configuration.
Now on julie if you run tail -20 /var/log/messages (show the last 20 lines), you should now see the alerts sent with the hostname of the client's that have been configured to send alerts to julie.
NOTE: http://ntsyslog.sourceforge.net has a program, called NTSyslog, that enables Windows Event Logs to be sent to a Unix syslog server.
The process of reviewing multiple servers can be a lot easier using grep, awk, or perl, now that you have a central location where all the messages are sent. To take this one stop further, it can be incorporated with MySQL and PHP.
The first thing we need to do is to get the syslog messages to the MySQL server. This is where Msyslog comes into play. Msyslog is a replacement for the standard syslog daemon that comes installed with most unix systems. Msyslog also has a nice feature of cryptographically signing syslog messages to let an admin know if their syslog files have been altered. Using the cryptographic features will be discussed in the next article. For now, the focus is on sending syslog messages to a remote server, logging to a database, and viewing the logs over a web interface using PHP.
Finally, you will need to compile Apache, MySQL, and PHP support. Depending on your OS you may have a package manager that will do this work for you. Oh! You know me...I am not going to leave you hanging, my fellow readers. Here is a tutorial that explains how to setup Apache, PHP, MYSQL, and SSL. Just get the latest versions.
This was setup by downloading and installing the rpm from the msyslog website at: http://sourceforge.net/projects/msyslog/
The tarball install compiled cleanly on Red Hat 7.0-7.3.
The rpm install added a startup script named "msyslogd" to the /etc/rc.d/init.d/ directory. If you installed from source, here is a startup script you can add to your OS's startup directory.
in the "msyslog" startup script was changed by adding the switches "-i udp -p 514 -i om_mysql"
-i udp -p 514 - Listen on the standard port 514 for incoming syslog messages via udp
-i om_mysql - load the mysql support module for logging to a mysql database
This was done before the existing syslog daemon is shutdown so that when it is stopped, the settings above will immediately take affect and remote logging will continue.
The normal syslog daemon was shutdown and myslogd started up immediately:
To ensure everything is still working run "tail -f" on the /var/log/messages file to see if logs from remote servers were being received:
"tail -f" allows data to be viewed while a file is being appended.
The logging to mysql was setup by first creating a database called "logd":
Then the script supplied in the man page for the om_mysql module was loaded into the database.
The syslog.sql file contained this, I modified the supplied sql file to index the host, date, and message fields.:
The "sysloghosts" table is used as a dropdown list on the PHP search form. This is only run if new hosts are configured to log to julie. I retrieved the list from the /var/log/messages file with this command:
The mysqld owner must hsve permissions to import the file into the database.
Log into the mysql logd database as a root user (not system root), delete the current hosts, and add new hosts file:
Delete the temporary file:
The user "mysql" is used to insert the syslog data into the database. Also, the mysql user will be used to select data from the database using PHP.
Log into the database as the admin user and grant the user "mysql" rights to edit and update the "logd" database.
the mysql user is allowed to select and insert data for the logd database (GRANT SELECT,INSERT on logd.*) from the localhost (TO mysql localhost) with the password "dahbadahba" (IDENTIFIED BY ' dahbadahba ';) and then the privileges are enabled (Flush privileges;).
In order for this to work the password for the database has to be kept in the syslog.conf file. A few changes were made to prevent normal users from viewing the syslog.conf file; thus, revealing the database password. (NOTE: Never use the system's root password for a database password)
First, the default permissions, on some unix systems, for /etc/syslog.conf are readable-writeable by root and readable by the group "root" and by the world (644). This was changed to 600:
Now it is only readable and writeable by root. Test it by trying to "cat" the file as a normal user:
Hopefully, the following message will be displayed:
The options for logging to the mysql database can be added to the bottom of the /etc/syslog.conf file:
-s - hostname
-u - user to log into the database as
-p - the database password
-d - the database name
-t - the database table name
-D - delay logging to the database (prevents overloading the mysql daemon if large numbers of syslog messages are received).
Restart the myslogd daemon:
Watch the directory where your mysql databases are located and see if the file grows.
Restricting access to julie:
By default, the syslog daemon will accept syslog messages from any server. Be sure to use firewall rules to only allow syslog messages from the servers that should be logging to it. If your firewall supports it, use a threshold for logging to prevent a Denial-of-Service (DoS) attack. Also, the clients will listen on port 514 when sending log messages to the syslog server so be sure to firewall incoming requests to the client's syslog port, as well. No one should be connecting to the client's syslog port.
Only the system adminstrators should have access to julie. One reason is that root passwords and other user's passwords could be echoed into the syslog files because of those with fast fingers may type the password in the "username" or "Login:" field and hit "Enter". Yes I am guilty.. That's the only time I have stopped the syslog daemon, opened /var/log/messages and mnaully deleted an entry. (NOTE: For sanity be sure your syslog files are chmod 600 and owned by root.)
The following rules restrict access to particular hosts: (NOTE: the policy is to DENY ALL)
The logs should also be reviewed via the web on julie over a secure connection. Your firewall can block or redirect incoming port 80 requests so access to the server is granted only over a secure connection.
Viewing syslog messages
Logs are viewed on julie using php to extract the data from the mysql database.
Create a directory under your root directory called "web-syslog"
Be sure this file is owned by the owner of the httpd daemon and readable-writeable by only that user. If you put this file somewhere else on your filesystem, be sure the owner of the httpd daemon has read access to the directory where it is located. This file will contain the password for the logd database. Add the following:
You can also find this script at http://www.sukkha.info/tap/gsyslog.txt.
A side note (special thanks to Steve Reed): For those of you running older versions of php, you might need to make the following modifications to syslog-search.php:
Point your browser to: https://julie.domain.com/web-syslog/syslog-index.php. Hopefully you should see a page where you can select the hosts to retreive records for and an optional date and message field.
Disable the standard syslog daemon from starting during bootup. You'll have to check your OS documentation for starting a stopping services during bootup. On Red Hat you can use the "chkconfig" program or "ntsysv":
Uncheck the syslog option. If you upgrade your system then you will have to be sure that the msyslogd daemon starts up and not the standard syslog daemon on julie.
Centralized logging and viewing of logs is very valuable, especially when you have dozens of servers to monitor. It can also serve as a place to look for errors if a server has crashed and can't be broke back on line. Take care to ensure that only necessary people are allowed to view the logs and if at all possible view the logs only over a secure connection. A database backend whether mysql, postgres, or whatever database gives you more power and control of how to display and manipulate the data that is being stored.
Duane Dunston is a Computer Security Analyst at STG Inc. for the National Climatic Data Center in Asheville, NC. He received his B.A. and M.S. degrees from Pfeiffer University and he has his G SEC certification from SANS. He hangs out at Old Europe Cafe, Early Girl's eatery, Anntony's, and any place with good tea and hot choc olate.
Duane has been working in security for 5 years and wishes he had the funding for a "Basic Security Tour" so he could provide the wo rld with hands-on training on how to implement the security recommendations from the Sans Top 20 List of the most common vulnerabiliti es. He knows that applying these recommendations to any network can minimize the most common types of attacks. Not only does he enjoy his work in computer security, he also likes to get involved in its ever-growing technologies. Duane says, "Security is one of those jobs where you have to stay abreast of new technologies and new ways that attackers are compromising computer systems. Security keeps evolving and the industry has to keep up with it, that is why we need well-trained, evolving security professionals supportive manag ers to help us with this ongoing process".
Previous Articles Duane has done for LinuxSecurity.com.