Re: Followup: Syslog
Quoting Micah Anderson [EMAIL PROTECTED]: One additional tweak which falls into line with the security setups, that I think is a good idea is to made the log files in /var/log to be chattr +a (append only) so logfiles cannot be modified or removed altogether to cover up tracks. This isn't the the biggest security trick because all it does is make it if you don't know about chattr then you can't install a trojan. If you've got root then removing the immutability flags is trivial, but only if you know how to, or even know they exist. But it has kept the lower-level admins at a site I work at from modifying the logfiles, which is against policy. Not every filesystem that Linux works with supports the append-only flag. If append-only is attempted, it must be able to cope with this absence. (I'm sure I'm not the only one that has /var/log symlinked to /mnt/floppy ;) -- Andrew Stribblehill [EMAIL PROTECTED] Systems programmer, IT Service, University of Durham, England -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Followup: Syslog
from the secret journal of Micah Anderson ([EMAIL PROTECTED]): One additional tweak which falls into line with the security setups, that I think is a good idea is to made the log files in /var/log to be chattr +a (append only) so logfiles cannot be modified or removed altogether to cover up tracks. This isn't the the biggest security trick because all it does is make it if you don't know about chattr then you can't install a trojan. If you've got root then removing the immutability flags is trivial, but only if you know how to, or even know they exist. But it has kept the lower-level admins at a site I work at from modifying the logfiles, which is against policy. That's exactly right, append-only mode is useless. This is only mean for situations where non-root users must be able to write to a file, but not modify it. If syslog is running as root, there is zero point to this excersize. And as someone else pointed out, not every linux filesystem (or possibly even the hurd's implimentation of ext2) supports this. Just because a feature exists, doesn't mean that it should be used. -- Jacob Kuntz [EMAIL PROTECTED] http://underworld.net/~jake -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Followup: Syslog
On Wed, Apr 18, 2001 at 01:57:33PM +0100, Andrew Stribblehill wrote: Not every filesystem that Linux works with supports the append-only flag. If append-only is attempted, it must be able to cope with this absence. (I'm sure I'm not the only one that has /var/log symlinked to /mnt/floppy ;) Other arguments about the utility of append-only aside, why not use ext2 floppies? There's not too much space overhead. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Followup: Syslog
Peter Cordes writes: On Wed, Apr 18, 2001 at 01:57:33PM +0100, Andrew Stribblehill wrote: Not every filesystem that Linux works with supports the append-only flag. If append-only is attempted, it must be able to cope with this absence. (I'm sure I'm not the only one that has /var/log symlinked to /mnt/floppy ;) Other arguments about the utility of append-only aside, why not use ext2 floppies? There's not too much space overhead. If you are going to go to that much trouble, use a CD writer for logging. Ken Seefried, CISSP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Followup: Syslog
Quoting Micah Anderson [EMAIL PROTECTED]: One additional tweak which falls into line with the security setups, that I think is a good idea is to made the log files in /var/log to be chattr +a (append only) so logfiles cannot be modified or removed altogether to cover up tracks. This isn't the the biggest security trick because all it does is make it if you don't know about chattr then you can't install a trojan. If you've got root then removing the immutability flags is trivial, but only if you know how to, or even know they exist. But it has kept the lower-level admins at a site I work at from modifying the logfiles, which is against policy. Not every filesystem that Linux works with supports the append-only flag. If append-only is attempted, it must be able to cope with this absence. (I'm sure I'm not the only one that has /var/log symlinked to /mnt/floppy ;) -- Andrew Stribblehill [EMAIL PROTECTED] Systems programmer, IT Service, University of Durham, England
Re: Followup: Syslog
from the secret journal of Micah Anderson ([EMAIL PROTECTED]): One additional tweak which falls into line with the security setups, that I think is a good idea is to made the log files in /var/log to be chattr +a (append only) so logfiles cannot be modified or removed altogether to cover up tracks. This isn't the the biggest security trick because all it does is make it if you don't know about chattr then you can't install a trojan. If you've got root then removing the immutability flags is trivial, but only if you know how to, or even know they exist. But it has kept the lower-level admins at a site I work at from modifying the logfiles, which is against policy. That's exactly right, append-only mode is useless. This is only mean for situations where non-root users must be able to write to a file, but not modify it. If syslog is running as root, there is zero point to this excersize. And as someone else pointed out, not every linux filesystem (or possibly even the hurd's implimentation of ext2) supports this. Just because a feature exists, doesn't mean that it should be used. -- Jacob Kuntz [EMAIL PROTECTED] http://underworld.net/~jake
Re: Followup: Syslog
On Wed, Apr 18, 2001 at 01:57:33PM +0100, Andrew Stribblehill wrote: Not every filesystem that Linux works with supports the append-only flag. If append-only is attempted, it must be able to cope with this absence. (I'm sure I'm not the only one that has /var/log symlinked to /mnt/floppy ;) Other arguments about the utility of append-only aside, why not use ext2 floppies? There's not too much space overhead. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE
Re: Followup: Syslog
Peter Cordes writes: On Wed, Apr 18, 2001 at 01:57:33PM +0100, Andrew Stribblehill wrote: Not every filesystem that Linux works with supports the append-only flag. If append-only is attempted, it must be able to cope with this absence. (I'm sure I'm not the only one that has /var/log symlinked to /mnt/floppy ;) Other arguments about the utility of append-only aside, why not use ext2 floppies? There's not too much space overhead. If you are going to go to that much trouble, use a CD writer for logging. Ken Seefried, CISSP
Re: Followup: Syslog
Of all the days, it was on Sat, Apr 14, 2001 at 02:32:20PM -0400 that Jacob Kuntz quoth: from the secret journal of Andy Bastien ([EMAIL PROTECTED]): Another technique is to use a separate logging server which has the transmit leads on it's ethernet connection snipped. It's capable of receiving (via UDP only, since it can't ACK!) log entries, but it's virtually impossible to start an interactive session remotely to shut it down or otherwise interfere with it. It's possible to attack the It also can't arp. You'll need to prime the arp cache from a file for every host that needs immutable logs. Have you tried this? I wonder if you'll even get a link light. A syslog that strips formfeeds and line feeds attached to a printer is a little better, but I haven't found an efficient way to egrep with my eyes. I have to admit I've never done this myself, but I know people who do. If you have a hub that won't sent packets to the link because the transmit leads don't make a circuit, the leads can be looped back or some hubs will let you disable link detection. Here's a page that discusses how to make a receive-only cable (scroll down to 3.6): http://www.robertgraham.com/pubs/sniffing-faq.html This from a mailing list discussion about some problems that people have had with cutting the transmit wires. Be aware that the guy who starts the thread clipped the wrong wires: http://www.securityportal.com/list-archive/firewall-wizards/1998/Aug/0167.html Of course, you can use a standard cable with a dedicated logging network segment and disable all network services on the logging server except for syslog. Different networks are find that different solutions work the best for them. I also don't want to claim that there is anything wrong with logging to a printer, and some people might want to log to a printer and a remote server. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Followup: Syslog
I've decided to try an either make my own syslogger, or contribute/modify one of the existing. The current sysklogd simply doesn't meet my needs or demands. Until I complete my "quest", here's my current syslog.conf, which I personally believe to be better. Some people really like one big log - just add a line saying something like "*.* -/var/log/syslog". Please bear over with any errors, and the bad layout :) P.S.: I hope it's not a cardinal sin to attach it, but it's only 1985 bytes. Regards Kenneth # /etc/syslog.conf Configuration file for syslogd. # # For more information see syslog.conf(5) # manpage. # # First some standard logfiles. Log by facility. # # Authentication? auth,authpriv.* /var/log/auth.log # This is evil :) Logs everything except auth/authpriv to syslog (I hate it.) #*.*; auth,authpriv.none; -/var/log/syslog #*.*/var/log/syslog #cron.* /var/log/cron.log daemon.*-/var/log/daemon.log kern.*;kern.!=info;\ kern.!=debug-/var/log/kern.log kern.info /var/log/kern.info lpr.* -/var/log/lpr.log #mail.* /var/log/mail.log user.* -/var/log/user.log uucp.* -/var/log/uucp.log # # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. # # Modified, so there's no duplicate info! mail.debug;mail.!warning-/var/log/mail.info mail.=warning -/var/log/mail.warning mail.err/var/log/mail.err # Logging for INN news system # news.crit /var/log/news/news.crit news.=err /var/log/news/news.err news.notice;news.!err -/var/log/news/news.notice news.debug;news.!notice -/var/log/news/new.info # # Some `catch-all' logfiles. # *.=debug;\ auth,authpriv.none;\ news.none;mail.none;-/var/log/debug *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ kern.!=info;\ mail,news.none -/var/log/messages # # Emergencies are sent to everybody logged in. # *.emerg * # # I like to have messages displayed on the console, but only on a virtual # console I usually leave idle. # #daemon,mail.*;\ # news.=crit;news.=err;news.=notice;\ # *.=debug;*.=info;\ # *.=notice;*.=warn /dev/tty8 # The named pipe /dev/xconsole is for the `xconsole' utility. To use it, # you must invoke `xconsole' with the `-file' option: # #$ xconsole -file /dev/xconsole [...] # # NOTE: adjust the list below, or you'll go crazy if you have a reasonably # busy site.. # daemon.*;mail.*;\ news.crit;news.err;news.notice;\ *.=debug;*.=info;\ *.=notice;*.=warn |/dev/xconsole
Re: Followup: Syslog
Of all the days, it was on Sat, Apr 14, 2001 at 02:32:20PM -0400 that Jacob Kuntz quoth: from the secret journal of Andy Bastien ([EMAIL PROTECTED]): Another technique is to use a separate logging server which has the transmit leads on it's ethernet connection snipped. It's capable of receiving (via UDP only, since it can't ACK!) log entries, but it's virtually impossible to start an interactive session remotely to shut it down or otherwise interfere with it. It's possible to attack the It also can't arp. You'll need to prime the arp cache from a file for every host that needs immutable logs. Have you tried this? I wonder if you'll even get a link light. A syslog that strips formfeeds and line feeds attached to a printer is a little better, but I haven't found an efficient way to egrep with my eyes. I have to admit I've never done this myself, but I know people who do. If you have a hub that won't sent packets to the link because the transmit leads don't make a circuit, the leads can be looped back or some hubs will let you disable link detection. Here's a page that discusses how to make a receive-only cable (scroll down to 3.6): http://www.robertgraham.com/pubs/sniffing-faq.html This from a mailing list discussion about some problems that people have had with cutting the transmit wires. Be aware that the guy who starts the thread clipped the wrong wires: http://www.securityportal.com/list-archive/firewall-wizards/1998/Aug/0167.html Of course, you can use a standard cable with a dedicated logging network segment and disable all network services on the logging server except for syslog. Different networks are find that different solutions work the best for them. I also don't want to claim that there is anything wrong with logging to a printer, and some people might want to log to a printer and a remote server.
Re: Followup: Syslog
On Sun, 15 Apr 2001 14:45:04 EDT, Andy Bastien writes: A syslog that strips formfeeds and line feeds attached to a printer is a little better, but I haven't found an efficient way to egrep with my eyes. [...] Here's a page that discusses how to make a receive-only cable (scroll down to 3.6): http://www.robertgraham.com/pubs/sniffing-faq.html You can connect the dedicated logger machine to your live machine with a null-modem cable, and run a simple program on the dumb logger that dumps everything that appears on /dev/ttyS0 to a file, and get the syslogd on the live machine to send everything to /dev/ttyS0. Since the only connection between the dedicated logger and the rest of your network is a serial cable, and since you aren't running a getty on those serial lines, you can be fairly sure that nobody is going to hack into the machines to modify the logs. And you can log onto the console of the logger machine to grep the log files whenever you want. --- Wade -- /\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign| Wade Richards --- [EMAIL PROTECTED] X - NO HTML/RTF in e-mail | Fight SPAM! Join CAUCE. / \ - NO Word docs in e-mail | See http://www.cauce.org/ for details.
Re: Followup: Syslog
I've decided to try an either make my own syslogger, or contribute/modify one of the existing. The current sysklogd simply doesn't meet my needs or demands. Until I complete my quest, here's my current syslog.conf, which I personally believe to be better. Some people really like one big log - just add a line saying something like *.* -/var/log/syslog. Please bear over with any errors, and the bad layout :) P.S.: I hope it's not a cardinal sin to attach it, but it's only 1985 bytes. Regards Kenneth # /etc/syslog.conf Configuration file for syslogd. # # For more information see syslog.conf(5) # manpage. # # First some standard logfiles. Log by facility. # # Authentication? auth,authpriv.* /var/log/auth.log # This is evil :) Logs everything except auth/authpriv to syslog (I hate it.) #*.*; auth,authpriv.none; -/var/log/syslog #*.*/var/log/syslog #cron.* /var/log/cron.log daemon.*-/var/log/daemon.log kern.*;kern.!=info;\ kern.!=debug-/var/log/kern.log kern.info /var/log/kern.info lpr.* -/var/log/lpr.log #mail.* /var/log/mail.log user.* -/var/log/user.log uucp.* -/var/log/uucp.log # # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. # # Modified, so there's no duplicate info! mail.debug;mail.!warning-/var/log/mail.info mail.=warning -/var/log/mail.warning mail.err/var/log/mail.err # Logging for INN news system # news.crit /var/log/news/news.crit news.=err /var/log/news/news.err news.notice;news.!err -/var/log/news/news.notice news.debug;news.!notice -/var/log/news/new.info # # Some `catch-all' logfiles. # *.=debug;\ auth,authpriv.none;\ news.none;mail.none;-/var/log/debug *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ kern.!=info;\ mail,news.none -/var/log/messages # # Emergencies are sent to everybody logged in. # *.emerg * # # I like to have messages displayed on the console, but only on a virtual # console I usually leave idle. # #daemon,mail.*;\ # news.=crit;news.=err;news.=notice;\ # *.=debug;*.=info;\ # *.=notice;*.=warn /dev/tty8 # The named pipe /dev/xconsole is for the `xconsole' utility. To use it, # you must invoke `xconsole' with the `-file' option: # #$ xconsole -file /dev/xconsole [...] # # NOTE: adjust the list below, or you'll go crazy if you have a reasonably # busy site.. # daemon.*;mail.*;\ news.crit;news.err;news.notice;\ *.=debug;*.=info;\ *.=notice;*.=warn |/dev/xconsole
Re: Followup: Syslog
Of all the days, it was on Fri, Apr 13, 2001 at 05:54:07PM -0500 that Kevin van Haaren quoth: --On Friday, April 13, 2001 3:40 PM -0700 Micah Anderson [EMAIL PROTECTED] hath wrote: | One additional tweak which falls into line with the security setups, that | I think is a good idea is to made the log files in /var/log to be chattr | +a (append only) so logfiles cannot be modified or removed altogether to | cover up tracks. This isn't the the biggest security trick because all it | does is make it if you don't know about chattr then you can't install a | trojan. If you've got root then removing the immutability flags is | trivial, but only if you know how to, or even know they exist. But it has | kept the lower-level admins at a site I work at from modifying the | logfiles, which is against policy. | if you want a real way to do this (more than just obscuring what you've done) go get one of those old dot-matrix printers with fanfold paperfeed and dump your logs to it in addition to the one on drive. Keep it in a secured room. Another technique is to use a separate logging server which has the transmit leads on it's ethernet connection snipped. It's capable of receiving (via UDP only, since it can't ACK!) log entries, but it's virtually impossible to start an interactive session remotely to shut it down or otherwise interfere with it. It's possible to attack the server that is sending the log entries to shut down its connection to the logging server, but this is probably no easier that disabling a printer on a parallel port (a simple way is to send 1 formfeeds), and by the time this can be accomplished, there should already be a trail of log entries. Old log entries can be written to multiple CDRs for archival purposes, with a copy stored in a secure off-site location. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Followup: Syslog
On Sat, Apr 14, 2001 at 02:58:02PM +0200, Luca Gibelli wrote: One additional tweak which falls into line with the security setups, that I think is a good idea is to made the log files in /var/log to be chattr +a (append only) so logfiles cannot be modified or removed altogether to cover up tracks. This isn't the the biggest security trick because all it does is make it if you don't know about chattr then you can't install a trojan. If It's indeed *too* trivial. though a large number of script kiddies are really really dumb. I'd suggest using LIDS for such things. For those who don't know it, it's a kernel patch which adds capabilities support. It makes impossible to delete logs 'cause in order to disable "append only" you should reboot with a kernel without lids, but lids forbids rebooting unless the admin is logged from a local console. or just use lcap lcap CAP_SYS_MODULE CAP_SYS_RAWIO CAP_SYS_BOOT CAP_LINUX_IMMUTABLE that revokes the ability to load modules, denies access to /dev/mem, /dev/kmem and /proc/kcore. revokes the ability to reboot(), and revokes the ability to set or remove immutable/append only bits. there are a few problems with this: throw away your logrotation scripts, they will now fail and your logs will permanently bloat until you reboot the system into single user mode and rotate them on the console manually. you can't reboot remotely anymore, a shutdown -r now will bring the system all the way down to where it runs the actual reboot command which will fail and init will spawn sulogin. there is no way to seal the raw disk devices using linux capabilities, so the immutability bits can be trivially removed by directly modifying the filesystem through /dev/hda* or /dev/sda*. this is a pretty lame oversight IMO given the BSD securelevel at level 1 revokes the ability to access raw devices for mounted filesystems, and at level 2 revokes the ability to access any raw disk device. you need to protect the script running lcap at boot, this means you have to make / or /etc immutable which will severely break your system (i have read an immutable / makes the system unusable) otherwise all the cracker needs to do is: cp -a /etc /etc.foo mv /etc /etc.crap mv /etc.foo /etc remove annoying lcap script reboot of course that last step is liable to make someone notice, and if you revoked CAP_SYS_BOOT your machine will just go down and stay down until you take care of it and hopefully notice the bogus /etc.crap. (which can't be rm -rfed until after the reboot chattr -R -ia /etc.crap) lids might be able to solve some of these problems, but remains a royally obnoxious thing to administer, you end up having to do pretty much everything from the console (depending on the config i suppose), and well if i wanted that i would use NT ;-) and it sounds like lids may not be portable to arch != i386. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Followup: Syslog
Il giorno Fri, Apr 13 in un momento di profonda ispirazione Micah Anderson scrisse riguardo a Re: Followup: Syslog : One additional tweak which falls into line with the security setups, that I think is a good idea is to made the log files in /var/log to be chattr +a (append only) so logfiles cannot be modified or removed altogether to cover up tracks. This isn't the the biggest security trick because all it does is make it if you don't know about chattr then you can't install a trojan. If It's indeed *too* trivial. I'd suggest using LIDS for such things. For those who don't know it, it's a kernel patch which adds capabilities support. It makes impossible to delete logs 'cause in order to disable append only you should reboot with a kernel without lids, but lids forbids rebooting unless the admin is logged from a local console. -- Luca Gibelli ([EMAIL PROTECTED] || [EMAIL PROTECTED]) PGP Fingerprint: EC7C D6D2 D754 89F8 BDE8 8924 6341 3B07 C2F3 9102 PGP Key Available on: Key Servers || http://gibelli.oltrelinux.com/gibelli.asc BOFH excuse 208: Traffic jam on the Information Superhighway. pgpZH7bITyDy1.pgp Description: PGP signature
Re: Followup: Syslog
Of all the days, it was on Fri, Apr 13, 2001 at 05:54:07PM -0500 that Kevin van Haaren quoth: --On Friday, April 13, 2001 3:40 PM -0700 Micah Anderson [EMAIL PROTECTED] hath wrote: | One additional tweak which falls into line with the security setups, that | I think is a good idea is to made the log files in /var/log to be chattr | +a (append only) so logfiles cannot be modified or removed altogether to | cover up tracks. This isn't the the biggest security trick because all it | does is make it if you don't know about chattr then you can't install a | trojan. If you've got root then removing the immutability flags is | trivial, but only if you know how to, or even know they exist. But it has | kept the lower-level admins at a site I work at from modifying the | logfiles, which is against policy. | if you want a real way to do this (more than just obscuring what you've done) go get one of those old dot-matrix printers with fanfold paperfeed and dump your logs to it in addition to the one on drive. Keep it in a secured room. Another technique is to use a separate logging server which has the transmit leads on it's ethernet connection snipped. It's capable of receiving (via UDP only, since it can't ACK!) log entries, but it's virtually impossible to start an interactive session remotely to shut it down or otherwise interfere with it. It's possible to attack the server that is sending the log entries to shut down its connection to the logging server, but this is probably no easier that disabling a printer on a parallel port (a simple way is to send 1 formfeeds), and by the time this can be accomplished, there should already be a trail of log entries. Old log entries can be written to multiple CDRs for archival purposes, with a copy stored in a secure off-site location.
Re: Followup: Syslog
from the secret journal of Andy Bastien ([EMAIL PROTECTED]): Another technique is to use a separate logging server which has the transmit leads on it's ethernet connection snipped. It's capable of receiving (via UDP only, since it can't ACK!) log entries, but it's virtually impossible to start an interactive session remotely to shut it down or otherwise interfere with it. It's possible to attack the It also can't arp. You'll need to prime the arp cache from a file for every host that needs immutable logs. Have you tried this? I wonder if you'll even get a link light. A syslog that strips formfeeds and line feeds attached to a printer is a little better, but I haven't found an efficient way to egrep with my eyes. -- Jacob Kuntz [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://underworld.net/~jake
Followup: Syslog
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Sorry for the crosspost, but I want to get as much coverage as possible)
First of, thank you everyone for responding! It's given me some food for
thought, and I also found a lot of errors in what I thought would be best.
Anyway, I've compiled a rough "wishlist" here, listing what people (including
me) generally request. The reason for this is to get a discussion started, so
we can all have the most efficient (and secure) logging possible. Please
comment (if you wish) on the points noted here, but don't feel restricted to
only those - I'm more than willing to consider other features...
Here it goes:
o One log with everything (like /var/log/syslog)
o Authentication log (/var/log/auth.log)
o Non-important stuff in separate logs (/var/log/service.{info,warn,err}
o Human-readable datetime
o Machine-processible (ie, fixed field widths, like now)
o High-precision date/time (TAI64?)
o Docs + inclusion in the "Securing Debian Manual"
o /secure/ remote-logging (ie, crypto)
o Fallback log (ie, if something gets missed, it is logged to fx.
/var/log/missed)
o Permission checking (?)
o Running as non-root
o Encrypted logs (Compressed?)
o User-defined facilities (ie, firewall.info, xfree.err)
After reading through the features which people would like to see, it seems
to me that there is really need for something else besides sysklogd. What I
really want to know is, why is syslog-ng and/or msyslog not more widely used?
What do they lack? Compatibility and security are the only points I can see
where they might not qualify as a total replacement.
With that in mind, I've been considering making my own logger. Is this a good
idea? I've considered it a bit, and thought it would be best to start with
the current sysklogd source, and make small, tested changes to be sure that
it's still safe working. What do people think of this?
So, anybody want to jump in and make some comments? Even if you think it's
trivial what you have to say, please do so anyway. If you feel it's not worth
everybody's mailbox, just mail me personally. Think of it as a poll :)
And also, if "the people" think it's a good idea with a new syslogger, then
there's the all-important question of the project name. Ideas are welcome :)
Yours truly
Kenneth Vestergaard Schmidt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjrXePQACgkQDoYBnf2u3ClpEgCdE0yIaKciVvRrXO0NPpdznFYh
uygAni+LWrS3QP7mBAFmV1bv7C0ezqSw
=PbVU
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Followup: Syslog
One additional tweak which falls into line with the security setups, that I
think is a good idea is to made the log files in /var/log to be chattr +a
(append only) so logfiles cannot be modified or removed altogether to cover
up tracks. This isn't the the biggest security trick because all it does is
make it if you don't know about chattr then you can't install a trojan. If
you've got root then removing the immutability flags is trivial, but only if
you know how to, or even know they exist. But it has kept the lower-level
admins at a site I work at from modifying the logfiles, which is against
policy.
In order to do this properly you need to modify the sysklogd scripts to set
and unset them during rotation (/etc/cron.daily/sysklogd and
/etc/cron.weekly/sysklogd) - on a side note, why are system logs rotated
through sysklogd and other logs like btmp are rotated with logrotate? Why
aren't these all done via logrotate? - the way I modified these files was as
follows:
(this is the snippit from /etc/cron.weekly/sysklogd that is different)
cd /var/log
for LOG in syslogd-listfiles --weekly
do
if [ -f $LOG ]; then
chattr -ia $LOG
chattr -i $LOG.[0-4]
chattr -i $LOG.[0-4].gz
savelog -g adm -m 640 -u root -c 4 $LOG /dev/null
chattr +a $LOG
chattr +i $LOG.[0-4]
chattr +i $LOG.[0-4].gz
fi
done
for LOG in syslogd-listfiles --auth
do
if [ -f $LOG ]; then
chown root.adm $LOG
chmod o-rwx $LOG
chattr +a $LOG
fi
done
(Here is the snippit from /etc/cron.daily/sysklogd that is different):
cd /var/log
for LOG in syslogd-listfiles
do
if [ -f $LOG ]; then
chattr -ia $LOG
chattr -i $LOG.[0-7]
chattr -i $LOG.[0-7].gz
savelog -g adm -m 640 -u root -c 7 $LOG /dev/null
chattr +a $LOG
chattr +i $LOG.[0-7]
chattr +i $LOG.[0-7].gz
fi
done
for LOG in syslogd-listfiles --auth
do
if [ -f $LOG ]; then
chown root.adm $LOG
chmod o-rwx $LOG
chattr +a $LOG
fi
Kenneth Vestergaard Schmidt schrieb am Samstag, den 14. April 2001:
(Sorry for the crosspost, but I want to get as much coverage as possible)
First of, thank you everyone for responding! It's given me some food for
thought, and I also found a lot of errors in what I thought would be best.
Anyway, I've compiled a rough "wishlist" here, listing what people (including
me) generally request. The reason for this is to get a discussion started, so
we can all have the most efficient (and secure) logging possible. Please
comment (if you wish) on the points noted here, but don't feel restricted to
only those - I'm more than willing to consider other features...
Here it goes:
o One log with everything (like /var/log/syslog)
o Authentication log (/var/log/auth.log)
o Non-important stuff in separate logs (/var/log/service.{info,warn,err}
o Human-readable datetime
o Machine-processible (ie, fixed field widths, like now)
o High-precision date/time (TAI64?)
o Docs + inclusion in the "Securing Debian Manual"
o /secure/ remote-logging (ie, crypto)
o Fallback log (ie, if something gets missed, it is logged to fx.
/var/log/missed)
o Permission checking (?)
o Running as non-root
o Encrypted logs (Compressed?)
o User-defined facilities (ie, firewall.info, xfree.err)
After reading through the features which people would like to see, it seems
to me that there is really need for something else besides sysklogd. What I
really want to know is, why is syslog-ng and/or msyslog not more widely used?
What do they lack? Compatibility and security are the only points I can see
where they might not qualify as a total replacement.
With that in mind, I've been considering making my own logger. Is this a good
idea? I've considered it a bit, and thought it would be best to start with
the current sysklogd source, and make small, tested changes to be sure that
it's still safe working. What do people think of this?
So, anybody want to jump in and make some comments? Even if you think it's
trivial what you have to say, please do so anyway. If you feel it's not worth
everybody's mailbox, just mail me personally. Think of it as a poll :)
And also, if "the people" think it's a good idea with a new syslogger, then
there's the all-important question of the project name. Ideas are welcome :)
Yours truly
Kenneth Vestergaard Schmidt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
PGP signature
Re: Followup: Syslog
--On Friday, April 13, 2001 3:40 PM -0700 Micah Anderson [EMAIL PROTECTED] hath wrote: | One additional tweak which falls into line with the security setups, that | I think is a good idea is to made the log files in /var/log to be chattr | +a (append only) so logfiles cannot be modified or removed altogether to | cover up tracks. This isn't the the biggest security trick because all it | does is make it if you don't know about chattr then you can't install a | trojan. If you've got root then removing the immutability flags is | trivial, but only if you know how to, or even know they exist. But it has | kept the lower-level admins at a site I work at from modifying the | logfiles, which is against policy. | if you want a real way to do this (more than just obscuring what you've done) go get one of those old dot-matrix printers with fanfold paperfeed and dump your logs to it in addition to the one on drive. Keep it in a secured room. kevin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Followup: Syslog
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Sorry for the crosspost, but I want to get as much coverage as possible)
First of, thank you everyone for responding! It's given me some food for
thought, and I also found a lot of errors in what I thought would be best.
Anyway, I've compiled a rough wishlist here, listing what people (including
me) generally request. The reason for this is to get a discussion started, so
we can all have the most efficient (and secure) logging possible. Please
comment (if you wish) on the points noted here, but don't feel restricted to
only those - I'm more than willing to consider other features...
Here it goes:
o One log with everything (like /var/log/syslog)
o Authentication log (/var/log/auth.log)
o Non-important stuff in separate logs (/var/log/service.{info,warn,err}
o Human-readable datetime
o Machine-processible (ie, fixed field widths, like now)
o High-precision date/time (TAI64?)
o Docs + inclusion in the Securing Debian Manual
o /secure/ remote-logging (ie, crypto)
o Fallback log (ie, if something gets missed, it is logged to fx.
/var/log/missed)
o Permission checking (?)
o Running as non-root
o Encrypted logs (Compressed?)
o User-defined facilities (ie, firewall.info, xfree.err)
After reading through the features which people would like to see, it seems
to me that there is really need for something else besides sysklogd. What I
really want to know is, why is syslog-ng and/or msyslog not more widely used?
What do they lack? Compatibility and security are the only points I can see
where they might not qualify as a total replacement.
With that in mind, I've been considering making my own logger. Is this a good
idea? I've considered it a bit, and thought it would be best to start with
the current sysklogd source, and make small, tested changes to be sure that
it's still safe working. What do people think of this?
So, anybody want to jump in and make some comments? Even if you think it's
trivial what you have to say, please do so anyway. If you feel it's not worth
everybody's mailbox, just mail me personally. Think of it as a poll :)
And also, if the people think it's a good idea with a new syslogger, then
there's the all-important question of the project name. Ideas are welcome :)
Yours truly
Kenneth Vestergaard Schmidt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjrXePQACgkQDoYBnf2u3ClpEgCdE0yIaKciVvRrXO0NPpdznFYh
uygAni+LWrS3QP7mBAFmV1bv7C0ezqSw
=PbVU
-END PGP SIGNATURE-
Re: Followup: Syslog
One additional tweak which falls into line with the security setups, that I
think is a good idea is to made the log files in /var/log to be chattr +a
(append only) so logfiles cannot be modified or removed altogether to cover
up tracks. This isn't the the biggest security trick because all it does is
make it if you don't know about chattr then you can't install a trojan. If
you've got root then removing the immutability flags is trivial, but only if
you know how to, or even know they exist. But it has kept the lower-level
admins at a site I work at from modifying the logfiles, which is against
policy.
In order to do this properly you need to modify the sysklogd scripts to set
and unset them during rotation (/etc/cron.daily/sysklogd and
/etc/cron.weekly/sysklogd) - on a side note, why are system logs rotated
through sysklogd and other logs like btmp are rotated with logrotate? Why
aren't these all done via logrotate? - the way I modified these files was as
follows:
(this is the snippit from /etc/cron.weekly/sysklogd that is different)
cd /var/log
for LOG in syslogd-listfiles --weekly
do
if [ -f $LOG ]; then
chattr -ia $LOG
chattr -i $LOG.[0-4]
chattr -i $LOG.[0-4].gz
savelog -g adm -m 640 -u root -c 4 $LOG /dev/null
chattr +a $LOG
chattr +i $LOG.[0-4]
chattr +i $LOG.[0-4].gz
fi
done
for LOG in syslogd-listfiles --auth
do
if [ -f $LOG ]; then
chown root.adm $LOG
chmod o-rwx $LOG
chattr +a $LOG
fi
done
(Here is the snippit from /etc/cron.daily/sysklogd that is different):
cd /var/log
for LOG in syslogd-listfiles
do
if [ -f $LOG ]; then
chattr -ia $LOG
chattr -i $LOG.[0-7]
chattr -i $LOG.[0-7].gz
savelog -g adm -m 640 -u root -c 7 $LOG /dev/null
chattr +a $LOG
chattr +i $LOG.[0-7]
chattr +i $LOG.[0-7].gz
fi
done
for LOG in syslogd-listfiles --auth
do
if [ -f $LOG ]; then
chown root.adm $LOG
chmod o-rwx $LOG
chattr +a $LOG
fi
Kenneth Vestergaard Schmidt schrieb am Samstag, den 14. April 2001:
(Sorry for the crosspost, but I want to get as much coverage as possible)
First of, thank you everyone for responding! It's given me some food for
thought, and I also found a lot of errors in what I thought would be best.
Anyway, I've compiled a rough wishlist here, listing what people (including
me) generally request. The reason for this is to get a discussion started, so
we can all have the most efficient (and secure) logging possible. Please
comment (if you wish) on the points noted here, but don't feel restricted to
only those - I'm more than willing to consider other features...
Here it goes:
o One log with everything (like /var/log/syslog)
o Authentication log (/var/log/auth.log)
o Non-important stuff in separate logs (/var/log/service.{info,warn,err}
o Human-readable datetime
o Machine-processible (ie, fixed field widths, like now)
o High-precision date/time (TAI64?)
o Docs + inclusion in the Securing Debian Manual
o /secure/ remote-logging (ie, crypto)
o Fallback log (ie, if something gets missed, it is logged to fx.
/var/log/missed)
o Permission checking (?)
o Running as non-root
o Encrypted logs (Compressed?)
o User-defined facilities (ie, firewall.info, xfree.err)
After reading through the features which people would like to see, it seems
to me that there is really need for something else besides sysklogd. What I
really want to know is, why is syslog-ng and/or msyslog not more widely used?
What do they lack? Compatibility and security are the only points I can see
where they might not qualify as a total replacement.
With that in mind, I've been considering making my own logger. Is this a good
idea? I've considered it a bit, and thought it would be best to start with
the current sysklogd source, and make small, tested changes to be sure that
it's still safe working. What do people think of this?
So, anybody want to jump in and make some comments? Even if you think it's
trivial what you have to say, please do so anyway. If you feel it's not worth
everybody's mailbox, just mail me personally. Think of it as a poll :)
And also, if the people think it's a good idea with a new syslogger, then
there's the all-important question of the project name. Ideas are welcome :)
Yours truly
Kenneth Vestergaard Schmidt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
pgp3xZVnBNjkd.pgp
Description: PGP signature
Re: Followup: Syslog
--On Friday, April 13, 2001 3:40 PM -0700 Micah Anderson [EMAIL PROTECTED] hath wrote: | One additional tweak which falls into line with the security setups, that | I think is a good idea is to made the log files in /var/log to be chattr | +a (append only) so logfiles cannot be modified or removed altogether to | cover up tracks. This isn't the the biggest security trick because all it | does is make it if you don't know about chattr then you can't install a | trojan. If you've got root then removing the immutability flags is | trivial, but only if you know how to, or even know they exist. But it has | kept the lower-level admins at a site I work at from modifying the | logfiles, which is against policy. | if you want a real way to do this (more than just obscuring what you've done) go get one of those old dot-matrix printers with fanfold paperfeed and dump your logs to it in addition to the one on drive. Keep it in a secured room. kevin
