From owner-freebsd-security  Wed Jan  6 01:47:07 1999
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id BAA15180
          for freebsd-security-outgoing; Wed, 6 Jan 1999 01:47:07 -0800 (PST)
          (envelope-from owner-freebsd-security@FreeBSD.ORG)
Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.149.24])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA15170
          for <freebsd-security@FreeBSD.ORG>; Wed, 6 Jan 1999 01:47:03 -0800 (PST)
          (envelope-from avalon@cheops.anu.edu.au)
Received: (from avalon@localhost)
	by cheops.anu.edu.au (8.9.1/8.9.1) id UAA24071;
	Wed, 6 Jan 1999 20:35:24 +1100 (EDT)
From: Darren Reed <avalon@coombs.anu.edu.au>
Message-Id: <199901060935.UAA24071@cheops.anu.edu.au>
Subject: Re: kernel/syslogd hack
To: vadim@tversu.ru (Vadim Kolontsov)
Date: Wed, 6 Jan 1999 20:35:23 +1100 (EDT)
Cc: freebsd-security@FreeBSD.ORG
In-Reply-To: <19990106095543.B28727@tversu.ru> from "Vadim Kolontsov" at Jan 6, 99 09:55:43 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

In some mail from Vadim Kolontsov, sie said:
[...]
>   And their solution isn't best for real-time analyzing: it doesn't send
> logs string by string (or at least nK-buffer by buffer). You can, of course,
> configure it to download logs to log server every 2 minutes, and analyze them
> then..

nsyslogd (when it finally gets the hashing/encryption enabled) will provide
a constant flow.  To it, the hashed and encrypted stream of data is just
another source, not a special thing which is handled differently.

The hashing and encryption (for use over TCP) will be enabled "soon".
Currently it just creates a hash log to go with the log file.

To check out current progress, you can download it from

http://coombs.anu.edu.au/~avalon/nsyslog.html

but please don't redistribute it as it's really not yet ready for wide
distribution.

> Regards,
> V.
> 
> P.S. I'm amazed - it seems that nobody (except ssyslogd and nsyslog people)
> is working on more reliable/secure syslog replacement.. may be because
> the whole protocol should be changed..

For now, your immeadiate concern is availability of UDP/514 to spoofed
syslog messages.

In what I think is a "bug" (or missing feature), commenting out syslog/514
in /etc/services causes syslogd not to start rather than to just not open
up the UDP port (2.2.5) but "syslogd -s" shuts down the UDP port for
reception of syslog messages, so that's covered.

As far as /var/run/log goes, chown/chgrp/chmod are your friends or you
can make /var/run/log a symbolic link to a protected directory with which
you use the -p argument to place the log socket.  e.g.:
# mkdir /var/run/log.d
# chmod 700 /var/run/log.d
# ln -s /var/run/log.d/log /var/run/log
# syslogd -p /var/run/log/log

Darren

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message