Announcement

Collapse
No announcement yet.

Systemd To Secure Logs With "Forward Secure Sealing"

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by LightBit View Post
    The worst thing attacker can do, is modify your logs?

    A lot of complexity for tiny (or no) security improvement.
    It doesn't improve security as such but it helps a lot in detecting a security breach.

    If the worst possible thing happens and an attacker gains full system access, you will want to find out ASAP and take the system down.

    Comment


    • #12
      Originally posted by LightBit View Post
      The worst thing attacker can do, is modify your logs?

      A lot of complexity for tiny (or no) security improvement.
      If the attacker has *already* gained root access, he/she will most certainly delete the log(s) on the local machine to cover up the intrusion. However if the logs are stored on a remote logging server there is a copy of the logs there as well, and will be useful in reconstructing the intrusion as long as THAT machine isn't also compromised.

      If the log is opened append only, the file cannot be altered except truncated or deleted

      This key signing thing isn't really worth it IMO, if attacker already has root powers

      Comment


      • #13
        Originally posted by DeepDayze View Post
        If the attacker has *already* gained root access, he/she will most certainly delete the log(s) on the local machine to cover up the intrusion. However if the logs are stored on a remote logging server there is a copy of the logs there as well, and will be useful in reconstructing the intrusion as long as THAT machine isn't also compromised.

        If the log is opened append only, the file cannot be altered except truncated or deleted

        This key signing thing isn't really worth it IMO, if attacker already has root powers
        A hacker who wants to keep access to the machine will modify but not delete the logs. Missing logs raise red flags, logs withinformation that isn't 100% accurate is much harder to notice.

        Comment


        • #14
          Yo dawg, we heard you like crypto, so...

          Comment


          • #15
            Originally posted by LightBit View Post
            The worst thing attacker can do, is modify your logs?

            A lot of complexity for tiny (or no) security improvement.
            As others have pointed out, modifying the logs can ensure that an intruder goes undetected even if you have a good review policy. Deleting them, or not changing them, gives the intruder away. If you assume the worst, every system is insecure and will be breached at some point in its life. Once that happens, the next thing you want to figure out is how they got in, and what they did with their access. If you cannot do this, your entire security process beyond this point is built upon faith, something that you shouldn't be entirely happy with. Not even knowning in the first place is a completely catastrophe though, something that could see you fired when you have a sony level breach.

            I haven't went through it all, but it sounds like a good thing for stand alone dedicated servers, and a step up if it makes itself easy to combine with a logging server. Its not something you inheritly need to be running on your desktop though, especially not if you don't pay attention to the logs in the first place.

            Comment


            • #16
              Originally posted by wpoely86 View Post
              It doesn't improve security as such but it helps a lot in detecting a security breach.

              If the worst possible thing happens and an attacker gains full system access, you will want to find out ASAP and take the system down.
              If attacker gains full system access, he can also replace systemd FSS with infected systemd ...

              Comment


              • #17
                Originally posted by LightBit View Post
                If attacker gains full system access, he can also replace systemd FSS with infected systemd ...
                ... because random reboots aren't suspicious at all.

                Comment


                • #18
                  Originally posted by ShadowBane View Post
                  ... because random reboots aren't suspicious at all.
                  If you don't know it happend.

                  Maybe attacker could write kernel module which would "break" systemd FSS.

                  Comment


                  • #19
                    Originally posted by DeepDayze View Post
                    If the attacker has *already* gained root access, he/she will most certainly delete the log(s) on the local machine to cover up the intrusion.

                    NO.

                    This is wrong thinking and shows a lack of understanding about computer security.

                    A attacker that takes over a machine will often have a goal of concealing his/her activity for the purposes of retaining control over the server and using it as a platform to penetrate deeper into your organization. A example of what a attacker will want happen is that a careless admin will try to log in to the system with their admin username and account.. then the attacker can use that username and account to then access a large numbers of servers in your organization. It is to the attacker's advantage to remain undetected for as long as possible. The more time they have undetected the more time they have to take consolidate their control and gather more information about your org.

                    I am sure all of that makes perfect sense to you. However were you are wrong is this:

                    IF they delete the logs they may cover up how they penetrated your system, but it throws a HUGE red flag. Deleting the logs is EXACTLY what you don't want to happen if your attacker and is EXACTLY the sort of thing a IDS will look for in order to detect if a system has been compromised.

                    And YES having a network logger is often advantageous and will perform a important function, but it is not always practical to implement. Quite often you do not have that option for a variety of reasons.

                    With this feature SystemD can guarantee that PRIOR to the attacker gaining root access that the logs will be unmolested. Once the attacker has access to root all bets are off. The attacker can modify kernel structures in memory, replace systemd itself, or do all sorts of other crazy stuff that will have the ability to manipulate logging on the machine to hide his tracks.

                    It doesn't improve security as such but it helps a lot in detecting a security breach.
                    It helps with investigating a security breach, which helps with security and is a valuable thing.


                    what is stopping him from writing to the block device directly?
                    Absolutely nothing is stopping him except the attacker's level of sophistication.

                    But the ability to edit a block device isn't going help even the most experienced hacker from breaking the cryptographic hash on the log files.

                    Comment


                    • #20
                      Originally posted by drag View Post
                      NO.

                      This is wrong thinking and shows a lack of understanding about computer security.

                      A attacker that takes over a machine will often have a goal of concealing his/her activity for the purposes of retaining control over the server and using it as a platform to penetrate deeper into your organization. A example of what a attacker will want happen is that a careless admin will try to log in to the system with their admin username and account.. then the attacker can use that username and account to then access a large numbers of servers in your organization. It is to the attacker's advantage to remain undetected for as long as possible. The more time they have undetected the more time they have to take consolidate their control and gather more information about your org.
                      Lookup Uplink (game) log deleter levels
                      Deleting or overwriting is something that will be noticed much easier, true, but it will still prevent or slowdown a backtrace.

                      Comment

                      Working...
                      X