Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Apr 1998 13:11:57 -0700 (PDT)
From:      "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>
To:        phk@critter.freebsd.dk (Poul-Henning Kamp)
Cc:        peter@netplex.com.au, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-usrsbin@FreeBSD.ORG, soren@dt.dk
Subject:   Re: cvs commit: src/usr.sbin/syslogd syslogd.c
Message-ID:  <199804222011.NAA08010@GndRsh.aac.dev.com>
In-Reply-To: <4371.893270854@critter.freebsd.dk> from Poul-Henning Kamp at "Apr 22, 98 08:47:34 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
> In message <199804221810.LAA07748@GndRsh.aac.dev.com>, "Rodney W. Grimes" writes:
> >> 
> >> Hmmmm,
> >> 
> >> Now, I'm not too sure what people use SecureMode for, but it doesn't
> >> make sense to expect one host to accept remote logging from other
> >> hosts that don't, at least in my book...
> >
> >Your book may not involve a large AS of systems that remotely syslog to
> >a central syslog server.  All ``syslog clients'' run in syslogd -s mode,
> >the ``syslog server'' runs in normal syslogd mode, but has ipfw setup
> >such that it only accepts syslog packets from a trusted list of clients.
> 
> Well, for the ipfw to work, wouldn't the socket need to be bound to 
> a well-known-port then ?  That was the fact that made me conclude that
> you couldn't do the above scenario in the first place.

Your correct, in that you have to wild card the source port, which
would allow someone on one of the syslogd client machines to abuse
the server, but thats better than nothing at all, and the way things
are now you would have to run syslogd in totally unsecure mode, a step
backwards.  A step forward would be to make -s use syslog 514 port
as the source port for syslog messages.  Then you could change the ipfw
rules from

ipfw add pass udp from ${trustedclient} to ${syslogserver} 514
to
ipfw add pass udp from ${trustedclient} 514 to ${syslogserver} 514

> I would think that all securemode should do would be to not include the
> fd in what select is watching, but the code before this change also
> diked out the bind, so you wouldn't know what port you would be sending
> syslog messages from, making ipfw unable to decide if the message came
> from syslogd or some random user...

True, but your changes force us to run wide open, both in and out, if
we want to do remote logging at all :-(.


-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation, Inc.                   Reliable computers for FreeBSD



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804222011.NAA08010>