Mastering Syslog on small networks

By on
Mastering Syslog on small networks
Page 3 of 3  |  Single page
Follow the rules
But we’re here to get a handle on making these things actually work. It’s the eternal trickle of repeating messages that have driven almost all the commonly available Syslog servers to apply rules to the messages they collect. You can (as is common in analysing Syslog output from web servers, for example) elect to make an enormous data-history store of all the messages, or you can throw away all the messages except the ones you have your doubts about. These are set up by way of rule dialogs, as the examples from the excellent Kiwi Syslog Daemon (www.kiwisyslog.com– which is for Windows, even though “Daemon” is a name usually reserved for the Linux world) show.

These utilities will offer you a variety of message conversion and storage options. While these formats are important, don’t be distracted by the rich variety of genealogies to each format and structure. By far the most useful part of the message is inside the text narrative and, just to confuse the issue, most devices reporting via Syslog tend to put comma separations inside the text string. This double-counts the use of commas in some of the outer formats, so simpler attempts at hand-driven interpretation or cutting into columns in Excel tend to fall at the first hurdle. This has fostered a huge amount of work on the tedious process of sorting, searching and reporting on Syslog events.

Here, you’ll find a rich mix of software made up of innumerable bites at the corporate record-keeping business. Rather like the Data Protection Act in the UK, the Sarbanes-Oxley Act in the US has a prosaic definition (see the summary at cpcaf.aicpa.org/Resources/Sarbanes+Oxley) with some entirely unexpected consequences. It seems to cause a lot of US businesses to think that if they run a firewall or a spam filter, they actually have to keep every last byte of data, and Syslog is one of the chosen formats to feature heavily in this ambiguous and expensively onerous procedural requirement.

This makes it quite hard to find a Syslog message-analysis product that hasn’t been swallowed up by the Sarbanes-Oxley explosion. Fortunately, some more widespread applications that feature Syslog crunching and delivery of drill-down capability are still free of the hype zone. Of particular note are Sawmill (www.sawmill.net) and ReportGen (www.reportgen.com/index.php) – in both cases they collect up Syslog formats and slice “n” dice in response to questions you may pose. If you’re operating within the walls of an organisation whose view on Sarbanes-Oxley is from the “keep everything” school, tools like these will be vital. If, on the other hand, a degree of sanity has prevailed, you should be adopting a relatively simple strategy:
Keep a fairly shallow event pool. That means, don’t run more than about seven days of records, from all your devices, until you’re sure there’s something you need to watch.
Master the art of filtering as close to source as possible. This means, look at what your device will report and chop off as many irrelevant classes of reporting as you can possibly affect early in the chain of reporters. Picking up gigabytes of informational-level trash and then spending hours analysing for the occasional fatal error is a slow way to find you’ve asked the wrong question.
Don’t worry about thinking up triggers for situations you haven’t encountered yet. That’s what the shallow “all event” log is for, so you can go and look for things you know are actually happening, as distinct from that web-forum obsessive style of security wonk, who loads his systems up with paranoid port blocks and intrusion-detection systems based on the current flame wars between the nosiest pundits. Trawling for obscure stuff, which in all likelihood is being blocked by your ISP anyway, isn’t the point of Syslog.
Think up tests. This isn’t quite as easy for logging conditions from firewalls as it is when testing anti-virus software with the EICAR signature file. But, to borrow one friend’s loud and immediate example of why live logging is so important, you should expect to see a log entry come in when you unplug your firewall from your DSL router or leased line termination – and another when you plug it back in.

That last test sounds so simplistic as to be almost laughable. In small business networks, it should be blindingly obvious that a cable’s been unplugged and, with the way small companies rely heavily on comparatively small IT investments, it should come to light immediately. However, a lot of those smaller companies now have co-located servers in data centres, and the forest of racks in a data centre can be a real wild west experience. It’s amazing how easily your paid-by-the-gigabyte personal Ethernet link in the hosting space can be hijacked by someone else’s hardware engineer, for example.

Syslog is quite possibly the latest latecomer to the party of Unix 70’s standards rehabilitated into the PC computing mainstream. The gradual ratification process still under way, and the solid selection of usable tools for smaller businesses outlined here, should help you find a way to live without that wobbly pile of monitors as your first line of defence.
Kiwi Syslog's at-a-glance status indicator.  Looks like a pretty quiet network to me!
Kiwi Syslog's at-a-glance status indicator. Looks like a pretty quiet network to me!
Previous Page
1 2 3 Single page
Copyright © Alphr, Dennis Publishing
Tags:

Most Read Articles

Poll

What would you like to see more of on BiT?
News
Reviews
Features
How To's
Lollies
Photo Galleries
Videos
Opinion
View poll archive

Log In

Email:
Password:
  |  Forgot your password?