> I recently set up a central logging machine that receives all the log
> information generated by tcp wrappers and ssh. This gets the access logs
> off any machine that may be hacked and also allows us to recognise and
> report scans of our services and machines (which are, unfortunately, public
> I've also started to gather all auth.* syslog records. What other useful
> syslog records should I be gathering?
Sorry about the long delay, we had a "major incident" in our machine room
that knocked out a significant amount of our services and have been spending
the past couple of weeks recovering.
Everyone is now _terribly_ interested in disaster recovery plans and physical
There were only a couple of replies; one suggested I send all log records to
the logging machine and the other warned of possible security problems.
So, instead of a summary I'm providing some notes on what we are attempting
to do and the possible solutions we are concidering.
We've installed a Linux PC to act as a central logging service that will
received selected syslog entries from a number of services (currently 20 but
potentially two or three hundred systems so just copying everything to the
logging service is not possible.) The intentions are two fold
* to have an off system copy of all access logs so a successful
hacker cannot destroy the evidence of a successful hack, and
* to allow site wide service and protocol scanning to be detected
(already the prototype setup reports regular site-wide slow scans of
network services that we would not normally detect without a central
The logging machine is set up as a blackhole with no network services apart
from syslogd and a SSH service that is restricted to the machines used by
the Unix support team.
Using standard syslogd record forwarding the communications with the logging
PC are in the clear. This shouldn't matter much as unencrypted passwords
should not leak into the syslog records. A 3rd party with a promiscuous
network card attached to our internal (firewalled) network may gain some
limited information using basic traffic analysis but there's nothing much
there that cannot be found via other techniques.
However, as we all know, some users attempt to login using their password
rather than their username at the login: prompt so passwords can leak into
system logs (it's even worse with the web logs but we're not attempting to
collect them; and I won't even mention the widespread use of world readable
system log files...) Because of this we would like to encrypt the syslog
records before deploying the scheme beyond machines under our direct
control (and on our internal network.)
syslogd-ng does allow encrypted communication but there are support and
political reason why we can't use it (one of the reasons we want to provide
this logging service is to cover on-site Unix systems that are not under our
direct control -- we can just about persuade people to edit a syslog.conf
file but replacing a binary is beyond them and we just don't have the staff
available to do it for them, nor support the altered operating system.) In
the future we may be able to use IPSec, but it's adoption is going to be
slow; for now we may have to make use of SSH, stunnel or a number of other
methods to hide the message contents. Fortunately, most current versions of
syslogd allow writing to named pipes so interfacing the syslog systems is
easy. But installing and correctly configuring SSH is going to baffle the
same people who would be unable to install syslogd-ng :-(
It may turnout to be both simpler and safer to create a parallel, well
secured, logging service making use of local named pipes to connect to a
local syslogd and avoid the builtin record forwarding service provided by
current Sun/SGI/AIX versions of syslogd. We could then include other logs
not managed via syslog, such as loginlog and sulog. We could then
distribute pre-configured packages for installation by all but the most
incapable of administrators.
So, in the end there appear to be no simple answers. However, the support
advantages of centrallised logging are so great that we shall continue to
look for a safe and reliable scheme. If any useful software comes out of
this, I should be able to make it public.
-- /\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\
File not found. Should I fake it? (Y/N)
S U BEFORE POSTING please READ the FAQ located at N ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/faq . and the list POLICY statement located at M ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/policy A To submit questions/summaries to this list send your email message to: N firstname.lastname@example.org A To unsubscribe from this list please send an email message to: G email@example.com E and in the BODY type: R unsubscribe sun-managers S Or . unsubscribe sun-managers firstname.lastname@example.org L To view an archive of this list please visit: I http://www.latech.edu/sunman.html S T
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:16 CDT