Slashdot Mirror

← Back to Stories (view on slashdot.org)

Secure Syslog Replacement Proposed

Posted by Unknown on from the why-all-the-hate dept.

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.

8 of 248 comments (clear)

  1. I don't know... by ksd1337 · · Score: 4, Informative

    Text is damn convenient to use. How are you gonna grep a binary file?

    1. Re:I don't know... by Anonymous Coward · · Score: 5, Informative

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

  2. Pointless -- there is already a secure solution by whoever57 · · Score: 5, Informative

    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.

    --
    The real "Libtards" are the Libertarians!
    1. Re:Pointless -- there is already a secure solution by silas_moeckel · · Score: 4, 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.

      --
      No sir I dont like it.
    2. Re:Pointless -- there is already a secure solution by rev0lt · · Score: 5, Informative

      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

    3. Re:Pointless -- there is already a secure solution by alcourt · · 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.

      --
      "I may disagree with what you say, but I will defend unto the death your right to say it." -- Voltaire
  3. Re:Serious issues with this by jbov · · Score: 4, Informative
    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.

  4. Re:See: Integrity by ultramkancool · · Score: 2, Informative

    Your hashes don't have to match anything. This does not apply. You can just recreate the entire syslog database.