Detecting attacks on network environments has become an unfortunate necessity of modern IT. With cyber criminals devising new techniques to infiltrate unsuspecting networks, sniffing out these activities before damage can be done is a top priority. Unfortunately, successfully monitoring system activity and preventing these attacks is often considered difficult and prohibitively expensive.
If you thought protecting your network was beyond your means, I've got good news for you: It's not as difficult (or costly) as you might think. Being able to deny network attacks before they're successful is all about visibility. Here are a few helpful tips for using syslog to increase visibility and improve your ability to detect malicious activity.
Syslog, at its core, is simply a standard for logging system messages. In practice, it allows us to abstract these messages and separate the source software from the systems that will ultimately store and analyze them. This gives us greater control and flexibility over detailed, low-level communication within our environments.
When it comes to monitoring infrastructure, the sheer number of devices generating log messages can be overwhelming to say the least. When you have printers, desktops, servers, storage and network appliances all churning out cryptic logs, the first question is often "where do I start?".
The answer goes right back to the heart of what syslog is all about: increasing visibility. To get the most visibility out of your logging environment, you need to deploy one or more centralized log repositories. These will act as dynamic managers and organizers of all the system messages flowing through your environment. As a recent DZone article explains, aggregating and analyzing system logs will not only help you address problems in real time, but it can also help you collect the information you need to predict future threats.
While we won't get into the specifics of setting up a remote logging server here, the process is straightforward. Once initialized, all you need to do is edit the ~/etc/syslog.conf~ configuration file on critical devices to point to your newly created repository. It's important to note that syslog messages are transmitted in plain text, so tunneling the transmission of these logs through SSH — typically port 514 — is often a good idea.
Sniffing Out Malicious Behavior
Once your system messages are happily piling up in a central location, the next logical step is to set up an automated method of analysis. Since these messages are all tagged with a facility (source system/device) and severity, automatically sorting them is a straightforward affair. By using a homebrew script or third-party logging system, you can filter logs from network appliances such as routers and switches for dropped packets, suspicious IPs, port scanners and many other signs of malicious activity.
You can then configure messages describing packet floods and suspicious IPs to trigger automatic notifications and resolutions. If you're using third-party log analyzers, these triggers are typically built in and can alert appropriate personnel via email, phone and text message. Additionally, corresponding resolution measures (such as IP blocking, port switching and firewall alterations) can be made to ensure attacks are resolved in a timely manner.
Prioritizing Is Critical
The effectiveness of a solution like this depends entirely on its configuration. As you assign each device or facility a priority, think carefully about the usefulness of the information it will generate. For example, you'll likely get more actionable messages from your firewall than your router. In general, the more outward facing a device is, the higher its priority should be.
As you continue aggregating logs and filtering the flood of syslog messages, be sure that your high-priority devices remain the most visible as well. This means configuring your log management dashboards, emails and alerts to focus on messages from these sources with real-time alerting capabilities for severe items.
When it comes down to it, your network environment is likely already generating the critical information you need to protect your infrastructure. All that's needed is a little organization and added visibility. By pointing system messages at a central repository for automated analysis, your chances of uncovering malicious behavior before any damage is done increases immensely.