Secure Syslog Replacement Proposed 248
LinuxScribe writes with this bit from IT World: "In an effort to foil crackers' attempts to cover their tracks by altering text-based syslogs, and improve the syslog process as a whole, developers Lennart Poettering and Kay Sievers are proposing a new tool called The Journal. Using key/value pairs in a binary format, The Journal is already stirring up a lot of objections."
Log entries are "cryptographically hashed along with the hash of the previous entry in the file" resulting in a verifiable chain of entries. This is being done as an extension to systemd (git branch). The design doesn't just make logging more secure, but introduces a number of overdue improvements to the logging process. It's even compatible with the standard syslog interface allowing it to either coexist with or replace the usual syslog daemon with minimal disruption.
I don't know... (Score:5, Informative)
Re:I don't know... (Score:5, Informative)
journalgrep -e "Nov 0[1234]-[0-9][0-9]-2011" | less
Pointless -- there is already a secure solution (Score:5, Informative)
Re:Pointless -- there is already a secure solution (Score:5, Informative)
If you have rooted the system you can parse the file remove what ya want and resign/hash everything. If you want a standalone system to have secure logging you use something that's write once, Crypto signing adds nothing unless that signing is coming from a separate system and including an external variable like a use counter so you can detect the jump. This is a solution looking for a problem. When you have a syslog box accepting udp syslog as the only open port, you can find an exploit or flood out the port.
You should be running something like splunk or octopussy to parse your syslog in real time generate alerts etc.
Re:Serious issues with this (Score:4, Informative)
Second, if you log on a machine and that machine gets compromised, I don't see how having checksums and a chained log will keep anyone from just running trashing the whole 'journal'. /var/log
rm -rf
What am i missing here?
Fourth, what happens when our happy cracker destroys those tools?
I think what you are missing is this replacement is intended to prevent "undetected" tampering with the logs. Currently, a cracker can delete the log entries that would identify his or her activities on the machine, thereby going unnoticed. Deleting the log files or destroying the tools, as you suggested, would certainly be a detectable sign that the machine was compromised.
Re:See: Integrity (Score:2, Informative)
Re:Pointless -- there is already a secure solution (Score:5, Informative)
Re:Pointless -- there is already a secure solution (Score:5, Informative)
In a well designed network, a compromise of a target system does not give one increased ability to compromise the log system, because there is no trust relationship, and the central log host does not even have the same user accounts. No user who has an account on the production system is permitted to have an account on the log system.
This topic is basic PCI stuff, and common also for SOX compliance. The problems are far from complex.
The so called solution does not provide sufficient security based on description to eliminate the requirement for central log storage, especially since that is an explicit requirement of PCI. Some may have that as an explicit SOX control as well. The obvious problem with the tool is it is only tamper detection, not tamper protection. Any fool with root can erase the evidence that they were the one logged in. It may be a tad harder to hide the fact that the logs were modified, but even that could be bypassed with the above description by simple virtue of rotating the log post-compromise and "losing" the entries in question.