Date: Sun, 18 Feb 2001 17:07:53 -0500 From: Brian Reichert <reichert@numachi.com> To: freebsd-security@FreeBSD.ORG Subject: Re: Remote logging Message-ID: <20010218170753.A85795@numachi.com>
next in thread | raw e-mail | index | archive | help
Date: Sun, 18 Feb 2001 17:05:07 -0500 From: Brian Reichert <reichert@numachi.com> To: Carroll Kong <damascus@home.com> Subject: Re: Remote logging On Sun, Feb 18, 2001 at 01:40:21PM -0500, Carroll Kong wrote: > At 01:22 PM 2/18/01 -0500, you wrote: > >What? Syslog? > > > >Set up a secured box, with syslogd: > > > > loghost# syslogd -a 192.186/16 > > > >Have this machine configured to write many machines' logs into > >whatever scheme you find useful for analysis. > > > >Have your other boxes have syslogd configured with something as > >simple as: > > > > *.* @loghost > > > >There are additional steps you can take to keep syslogd immune from > >DNS outages; read the manpages. > > > >Make sure all fo your boxes are syncroninzed via NTP. > > > > > > > > Ragnar > > > >-- > >Brian 'you Bastard' Reichert <reichert@numachi.com> > > That is a good idea, however, what is to stop the enemy from killing > syslogd as his first option? To develop this further: people trying to handle these issues have _multiple_ networks. Each important (public) host has two NICs and is on both. The loghost is on that private 'administrative' network, and is locked down to death. Along with any terminal servers, backup servers, etc. These are machines that are the support structure of your LAN. If you allow logins at all, you would have in place strict access controls. Mind you, if one of the dual-homed hosts gets compromised, then the attacker could take steps to congest that administrative network, or congest the loghost. That's where an adaptive switch comes in, however you implement that. > I do not think syslogd logs when it gets > killed? Correct. > So, despite the secure log host, he might not get the valuable > info he needs. I suppose you could then start speculating a break in if > there are no more MARKs since syslogd is dead. I'm not certain which syslogd you're referring to, here. - The loghost could have the syslogd process watchdogged in any number of ways. Presumably, you also have log rotation and auditing going on. - The host(s) generating syslog packets: your log auditing would involve looking for traffic anomalies. Absence of syslog packets from any one host is an anomaly. :) > Even that could be > fabricated I suppose. Checking for falsified syslog records is a different issue. :/ Relying _exclusively_ on syslog records to notice a compromise is a loss. > Ugh. Security sure is tough to implement > fully. 'Fully'? What problems are you trying to solve? Security is, at best, an exercise in risk analysis. Any security you impose introduces inconveniences for your legitimate users. When those impositions outweigh the risks/costs of a compromise, you've misunderstood your needs. >Not trying to say you are wrong, just that I am curious how does > one stop this possible problem? Have you found a way to avoid it? Which particular problem? (I'm not being snide; you introduced several issues above...) > > -Carroll Kong > -- Brian 'you Bastard' Reichert <reichert@numachi.com> 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010218170753.A85795>