Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Software Linux

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.
This discussion has been archived. No new comments can be posted.

Secure Syslog Replacement Proposed

Comments Filter:
  • I don't know... (Score:5, Informative)

    by ksd1337 ( 1029386 ) on Wednesday November 23, 2011 @04:50PM (#38152154)
    Text is damn convenient to use. How are you gonna grep a binary file?
  • Re:I don't know... (Score:5, Informative)

    by Anonymous Coward on Wednesday November 23, 2011 @04:53PM (#38152194)

    journalgrep -e "Nov 0[1234]-[0-9][0-9]-2011" | less

  • by whoever57 ( 658626 ) on Wednesday November 23, 2011 @04:55PM (#38152220) Journal
    Set your machine to also log over a secure channel to another machine. Perhaps one that only accepts the syslog entries and no other connections. Problem solved.
  • 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.

  • by jbov ( 2202938 ) on Wednesday November 23, 2011 @06:29PM (#38153320)
    I can mostly agree with you. There is one thing you might be missing.

    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'.
    rm -rf /var/log
    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)

    by ultramkancool ( 827732 ) on Wednesday November 23, 2011 @06:31PM (#38153328) Journal
    Your hashes don't have to match anything. This does not apply. You can just recreate the entire syslog database.
  • by rev0lt ( 1950662 ) on Wednesday November 23, 2011 @07:59PM (#38154094)
    That's why in BSD systems, you can mark a file as append-only, and with securelevel >=1 not even root can remove the flag
  • by alcourt ( 198386 ) on Wednesday November 23, 2011 @10:27PM (#38154938)

    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.

Today is a good day for information-gathering. Read someone else's mail file.