Date: Wed, 21 Oct 1998 07:10:13 -0700 From: Cy Schubert <cschuber@passer.osg.gov.bc.ca> To: "Jeffrey J. Mountin" <jeff-ml@mountin.net> Cc: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca>, freebsd-security@FreeBSD.ORG Subject: Re: Again logging! Message-ID: <199810211411.HAA14866@passer.osg.gov.bc.ca> In-Reply-To: Your message of "Wed, 21 Oct 1998 07:49:31 CDT." <3.0.3.32.19981021074931.010c36dc@207.227.119.2>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3.0.3.32.19981021074931.010c36dc@207.227.119.2>, "Jeffrey J. Mounti n" writes: > At 06:57 AM 10/15/98 -0700, Cy Schubert - ITSD Open Systems Group wrote: > >Or you could configure tcpd to log to a file instead of syslog, though > >I wouldn't recommend it. (I know many sysadmins who do). > > If the tought here was to "hide" the log, they would do better to hide tcpd > from ps et all. Obscurity method? Some people like to have independent logs. If so, why hack syslogd? Why use the scarce LOCAL syslogd resource if there are other ways? Have the daemon write to its own log or better yet Mike Jenken's comment about !daemon_name in syslog.conf would be a better suggestion. > > Better to have a highly secured system taking in the logs and work from > there. It should alarm if they stop coming too. > > >I especially like Mike Jenkins' comment. An excellent suggestion. > > Agreed. Only used that method on a few server with just too many daemons > and not enough LOCAL's. > > >I've noticed that the ports, some in particular, have become quite > >configurable. Yet another opportunity... > > How so? > > Usually I either mod the patch or 'make patch' and tweak the source. Both > are just a slight hassle, but it seems more correct to change the Makefile > or make.conf, which I just happened to do for Apache, since the default > structure to me is unwanted. For tcpd it's only one in patch-aa. Sshd > needs a quick change in the config file, and my first use of the popper > port had me recompiling 2 custom daemons, so as to avoid changes. Been there, done that. My suggestion was that since the ports are becoming more configurable, e.g. $KRB5_HOME, why not use the same concept and set up an environment variable that defines where the logs go and what syslog facility a particular port is to use? For example if someone likes to use local1.info for tcpd logs, then define that in make.conf or make.conf.local? At the site that I work at syslog locals are a scarce resource. A number of vendor products use local; and we have a locally written application & a Remedy front end on each machine that use two of the local facilities. Software that arbitrarily uses a local syslog facility is a pain. ** ... And no, I am not suggesting that FreeBSD's syslogd support more local facilities. In a heterogeneous environment like ours (FreeBSD, Linux, Solaris 1 & 2, DEC UNIX, AIX, NCR SYSVR4, DG/UX, and HP-UX) local0-7 is all we can use, and beating up on the vendors to add a feature or enhance a product is a futile exercise. > > Overall once you get used to the assumptions the ports are good, but one > really should follow the changes and make sure that they meet your needs. > Turning on every single bell and whistle in Apache didn't seem sensible, > but then knowing what is needed and the fact it doesn't clobber existing > files. 8-) > > Still it can be an opportunity to shoot yourself, especially when you've > developed certain habits over the years of rolling your own. > > > Jeff Mountin - Unix Systems TCP/IP networking > jeff@mountin.net Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: cschuber@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Government of BC 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?199810211411.HAA14866>