From owner-freebsd-security Sun Feb 18 14: 8: 1 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.numachi.com (numachi.numachi.com [198.175.254.2]) by hub.freebsd.org (Postfix) with SMTP id 7BDB837B401 for ; Sun, 18 Feb 2001 14:07:55 -0800 (PST) Received: (qmail 23830 invoked by uid 3001); 18 Feb 2001 22:07:53 -0000 Received: from natto.numachi.com (198.175.254.216) by numachi.numachi.com with SMTP; 18 Feb 2001 22:07:53 -0000 Received: (qmail 85813 invoked by uid 1001); 18 Feb 2001 22:07:53 -0000 Date: Sun, 18 Feb 2001 17:07:53 -0500 From: Brian Reichert To: freebsd-security@FreeBSD.ORG Subject: Re: Remote logging Message-ID: <20010218170753.A85795@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Date: Sun, 18 Feb 2001 17:05:07 -0500 From: Brian Reichert To: Carroll Kong 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 > > 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 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