Syslog Server

# Abstract

Syslog servers are important in small to large network environments. There are currently numerous commercial and open source Syslog servers available. These Syslog servers come with a multitude of configuration options. The cost of deployment for these Syslog servers is not practical for a small business with limited Information Technology staff. My objective in this project is to implement a simple yet powerful Syslog server that can be deployed without need of limitless configuration. To fortify my understanding of Syslog format, I have tested the Syslog server developed in this project against multiple routers and intrusion detection and prevention systems.

# Introduction

## Project Motivation

As a user of intrusion detection and prevention systems I have been interested in this field since my interest in network security began. During my internship with Health Solutions Plus, Inc., I was tasked with implementing network firewalls and intrusion prevention systems. This is when I felt the need for a simple Syslog Server that can be implemented out of the box.

The learning curve embarked on has been considerably steeper than previous work I have undertaken. The software component constitutes my first true software development culminating in a final product. My previous knowledge of the Visual Basic language did not cater for the scale of this work, and my skills in Python, as used in testing this software, were only of a basic level. Through the development I have learnt everything necessary about these languages and how they can be applied to creating Syslog server and clients.

From the theory aspect, I have done much research into the principles of Syslog and its related areas including networking and file storage, intrusion detection/prevention systems and firewalls and some advanced techniques used in this aspect.

## Aims and Objectives

The core objectives which have been designated as fundamental to the project are:

Identify, understand and describe a range of industry-based methods for developing and deploying Syslog servers. Information gathered from related industries as well as from other Syslog resources will be implanted in development of this project.
Suggest methods for filtering system logs received. Such filtering will be useful in reviewing system logs later.
Research, understand and describe current popular intrusion detection/prevention systems and implement techniques to help use mold this project into working with these systems.
Research socket-level programming and implement it into this project.

# Fundamentals of Syslog Servers

### Background

The syslog protocol, defined in RFC 3164, was originally written by Eric Allman. According to CISCO Press, “This protocol provides a transport to allow a device to send event notification messages across IP networks to event message collectors, also known as syslog servers” (Deveriya, 2005). This protocol simply sends logs generated from edge devices to a centralized server. These logs leave a trail of messages and alerts that can be followed in order to troubleshoot a device or to respond to an incident. This makes Syslog an integral part of systems and network administration.

## UNIX/Linux Syslog Servers

Linux Journal describes Syslog server as a server that is “used in Linux to log system messages” (Broughton, 2011). Syslog servers have been hand in hand with systems administrators for decades now. In UNIX and Linux, Kernel and other components generate system log messages and alerts which are first stored in the system itself. UNIX based systems use syslog daemon called Syslogd to handle these processes. This internal daemon comes integrated into Unix/Linux systems and does not need to be installed separately.

Windows Syslog Servers

Windows uses so called Event Viewer to log and view messages. This event viewer is system based and can be used as centralized event server within the same system. Although there is no out-of-box way of sending Windows event logs to an external Syslog server, there are many commercial and open source tools available to do so.

# Intrusion Detection/Prevention Devices

Intrusion detection and prevention devices help administrators keep intruders out of the network. According to National Institute of Standards and Technology, “Intrusion detection is the process of monitoring the events occurring in a computer system or network and analyzing them for signs of possible incidents, which are violations or imminent threats of violation of computer security policies, acceptable use policies, or standard security practices” (Scarfone & Mell, 2007). The same document goes on to describe intrusion prevention as, “the process of performing intrusion detection and attempting to stop detected possible incidents”. These devices typically gather information that relates to observed events and notify systems and network security administrators of important events. Some intrusion prevention systems are smart enough to respond to threats by using defined mechanisms.

In this document I talk about three IDPS I had a chance to work with during testing phase of this project. These IPDS are CISCO’s small business SA540 series security appliance, SonicWall TZ215 series, and open source Linux based OSSEC Host Intrusion Detection System.

### CISCO SA 540

According to the vendor, these devices are “comprehensive gateway security solutions that combine firewall, VPN, and optional intrusion prevention and web and email security capabilities” (CISCO Small Business). These devices come with CISCO’s IOS and provide an internal syslog daemon that can be configured through a web user interface. While powered with plethora of intrusion detection and prevention features, slow releases of detection signatures and updates have caused these devices to phase out. Their Syslog format is as follows:

192.168.48.1,<137>Oct 03 03:33:18 SA540 [IPS][IPS] ALERT[122:3:0] (portscan) TCP Portsweep[Priority: 3]: {PROTO:255} 192.168.48.10 -> 2.22.230.131

CISCO SA500 series devices, like other CISCO networking equipment, use severity system when describing threats. This model ranges from 0 for emergencies to 7 for debugging. Here is full list:

Level Keyword	Level	Description	Syslog Definition
emergencies	0	System unusable	LOG_EMERG
alerts	1	Immediate action needed	LOG_ALERT
critical	2	Critical conditions	LOG_CRIT
errors	3	Error conditions	LOG_ERR
warnings	4	Warning conditions	LOG_WARNING
notifications	5	Normal but significant condition	LOG_NOTICE
informational	6	Informational messages only	LOG_INFO
debugging	7	Debugging messages	LOG_DEBUG

Table 1 – CISCO Event Severity Levels

### SonicWall TZ215 UTM

Sonicwall Unified Threat Management systems are well known for their easy to configure interface, strong security infrastructure, and recent acquisition by Dell Systems. Their syslog format is given below:

192.168.48.1,<33>id=firewall sn=C0EAE41A3CD0 time=”2012-11-01 00:01:04″ fw=96.56.159.123 pri=1 c=32 m=82 msg=”Possible port scan detected” n=38 src=115.146.126.32:20290:X1 dst=96.56.159.123:40058:X1 note=”TCP scanned port list, 40057, 1058, 30058, 10058, 20059″

Sonicwall UTMs borrow their severity modeling system from CISCO and can be referenced to Table1 – CISCO Event Severity Levels.

### OSSEC HIDS

OSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and uses active response configurations to prevent future intrusions. OSSEC can be deployed on top of most operating systems including Linux, Mac OSX, and Windows. OSSEC is backed by Trend Micro.

Active Response can be configured in OSSEC HIDS to respond to future threats. Here is an example of such active response:

firewall-block

all

<rules_group>authentication_failed,authentication_failures</rules_group>

600

<repeated_offenders>30,60,120</repeated_offenders>

OSSEC’s system logs comprise of following format:

Received From: IDS->syscheck
Rule: 550 fired (level 7) -> “Integrity checksum changed.”
Portion of the log(s):

Integrity checksum changed for: ‘/usr/bin/config_data’
Size changed from ‘7243’ to ‘7224’
Permissions changed from ‘rwxr-xr-x’ to ‘r-xr-xr-x’
Old md5sum was: ‘1421b9313e4bb888b7c6bd5a2f391f7b’
New md5sum is : ‘a67e7188d4f870f913851c34946d1484’
Old sha1sum was: ‘a35fc4705c9e3661e28c8a123cefe6f3de0ec46e’
New sha1sum is : ’51d9dd1b96b4c582d3415d98709e8a7e0f3c04b8′

–END OF NOTIFICATION

# Syslog Server Implemented in this Project

When developing a syslog server to be using in this project, I took a simple approach. My aim was to build a software capable of handling system logs yet easy to be configured and deployed. Sole idea in this project is a Syslog server that listens to UPD port 514 and writes incoming messages to specified folders based on alert severity. The entire configuration can be done using app.config XML file found in the installation folder.

Problems Encountered

I encountered multiple problems while working on this problem. Here are a few examples I would like to write about.

### Bytes Conversion

All messages received on UDP port 514 were not in ASCII format. After much research, I decided to use Visual Basic’s Encoding.ASCII.GetString() method. Here is my implementation of this method:

bytesRecieved = udpcUDPClient.Receive(remoteIpEndPoint)

dataRecieved = Encoding.ASCII.GetString(bytesRecieved)

### Discarding Irrelevant Data

Next problem I encountered was to figure out how to discard irrelevant data? An intruder familiar with our networking environment might begin sending false Syslog to our Syslog server’s UDP port 514. While this might not seem like a real problem, an attacker can use this method to falsify our trail to system events and. To prevent this from happening, the Syslog server implemented in this project checks for sender’s IP.

#### Check for Sender’s IP

The Syslog server implemented in this project only processes data received from specified IP address. These IP addresses can be configured in app.config file found in the installation folder as follows:

If sender’s IP does not match any of the IP addresses configured in app.conf file, data received is discarded.

If routerIP.Contains(fromIP) Then

FillLog(dataRecieved, fromIP)

Console.WriteLine(dataRecieved)

Else

Console.WriteLine(“Discarding data not received from ” & fromIP)

End If

### Making Syslog Server Platform Independent

This project was tested using three different intrusion detection and prevention systems. While there were some similarities, not all Syslog is generated in the same format. To deal with this problem, app.config file comes to rescue. Users can configure what part of message specifies alert severity as follows:

The Syslog server then checks if message received contains any of these strings and writes log to relevant folders. For example, if message received was an alert, it would contain PRI=1 and be processed as follows:

Select Case True

Case sSyslogU.Contains(nAlert)

facility = “Alert”

End Select

### User Interaction Independence

This Syslog server can run without user interaction. Once installed, one can use Windows task scheduler to execute SyslogReceiver.exe file upon system start up.

# Conclusion and Evaluation

## Evaluation of Objectives and Aims

Throughout this project, I encountered real world problems and was able to learn something new. This not only helped me become a better programmer but also a good problem analyst. Being able to encounter a problem with a real world perspective aided the success of this project.

My aim throughout this project was to keep this Syslog server simple and easy to configure. As mentioned earlier in this report and evident from configuration files, I believe to have successfully achieved my objectives. A first look at application configuration file provided with the installation is enough for a systems administrator to deploy and maintain this Syslog server successfully.

## Evaluation of Project Management

Though natural disasters like hurricane Sandy did slow me down a little, I was able to finish this project on time. My aim was to finish this Syslog server before December 1^st and write final report by December 10^th, 2012. I not only succeeded in doing so, I also was able to deploy and test this Syslog server continuously for over 2 weeks. I am pleased to write that my employer Health Solutions Plus, Inc. is using this Syslog server actively to store logs from their external firewall.

## Future Work

I plan to continue this project if time permits. I plan to add a graphical user interface environment where user can view system logs received in real time. I have already started working on this project and following figure describes its interface:

# Bibliography

Broughton, J. (2011, 08 18). *Creating a Centralized Syslog Server*. Retrieved 08 12, 2012, from Linux Journal: http://www.linuxjournal.com/content/creating-centralized-syslog-server

CISCO Small Business. (n.d.). *Cisco SA 500 Series Security Appliances *. Retrieved 12 08, 2012, from CISCO Data Sheets: http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6032/ps6094/ps9932/data_sheet_c78-542899.pdf

Deveriya, A. (2005, 12 01). An Overview of the syslog Protocol. Retrieved 12 8, 2012, from CISCO Press: http://www.ciscopress.com/articles/article.asp?p=426638

Scarfone, K., & Mell, P. (2007). Guide to Intrusion Detection and Prevention Systems. Gaithersburg: National Institute of Standards and Technology.