The SANs Diary for Wednesday has a good article on log aggregators.
While I have included the original content below, the article is at http://isc.sans.org/diary.html?storyid=7351 (incase something is added later)
Often times, if hackers or worms break into your computer, they will try to delete the logs on the local computer to help hide their tracks. Having all your computers submit their local logs to a central log server will help you maintain copies of those logs. Even if a bad guy isn’t trying to delete your logs, its also a good way to aggregate log data and to review it centrally using tools such as Swatch – http://freshmeat.net/projects/swatch/, Logsurfer – http://www.crypt.gen.nz/logsurfer/ or SEC – http://kodu.neti.ee/~risto/sec/ to see if there are unusual events occurring on your systems. These three tools all allow you to build a set of rules to help filter the log traffic. Messages that are ‘normal’ noise can be ignored and messages that are indicative of unusual activity can generate an alert to notify your admins to review the activities.
There are 3 main syslog packages at this time:
1) syslog – the original syslog program. This only supports sending
messages to the central log server over UDP. As such, you have no
guarantees that the messages will get to the central server. Because
it is UDP based, it is important that you use a firewall to block
inbound UDP syslog traffic from the Internet. This is so malicious
users can not send in a flood of syslog entries that result in filling
up the filesystem on your central syslog server.
– in the spirit of Star Trek, this is ‘syslog – the next generation’.
syslog-ng includes support to submit logs to a central server using
TCP, so it can compensate for packets that got lost due to network
issues or slow down sending if there is network congestion. syslog-ng
also can use supplemental tools, such as stunnel to encrypt the log traffic between the source and the central log server using SSL.
3) rsyslog – this is the
latest syslog replacement. It can use TCP as well for more reliable
communication. It now has native encryption support built-in,
eliminating the need to use a second tool like stunnel to secure the
network communication. It can also use MySQL as a storage backend
rather than flat text files. This is useful for tools such as phplogcon which can be used to visualize the log data.
For environments with Windows systems, there are add-ons you can
install to allow you to submit your various Windows event logs to a
syslog server as well. Some examples of these products are winlogd – http://edoceo.com/creo/winlogd, SNARE – http://www.intersectalliance.com/projects/SnareWindows/index.html, and a Perl module Win32::Syslog.
Here’s another suggestion for getting Windows event logs to a central log server via UDP: