1. 19
  1.  

  2. 13

    This is a pretty weak guide, and I’d suggest (with no malice intended) that the author isn’t qualified to write this.

    Just as one example for starters, it’s possible to hide processes:

    https://sysdig.com/blog/hiding-linux-processes-for-fun-and-profit/

    1. 6

      The author admits that the guide is pretty weak at the start.

      This seems to be targeted at less experienced users and offers some basic advice. To someone who just has a WordPress site on a VPS this kind of guide is incredible useful.

      If you are dealing with a talented adversary who is hiding their processes this won’t help. But a pretty big portions of compromises are people who left their password as “root123” and got owned by a bot.

      1. 2

        The other also conflates ~/.bash_history with /var/log/wtmp in the section about last(1).

        1. 1

          I’d like to see a good guide to monitoring UDP traffic.

      2. 5

        I was surprised they didn’t cover some kind of intrusion detection tool like Tripwire or whatever its modern equivalent is.

        1. 4

          Boom! Exactly my thoughts. I was thinking strong sandboxing, picking apps by people who can code securely (esp minimalist apps), monitoring, logs on write-once storage (or append-only), and good backups with restore tests. People shouldn’t waste time with this article. A more thorough resource or consultation with an INFOSEC expert will cover more ground.

        2. 4

          I disagree that you should only shut down the server if you’re not very technical. At the moment you learn of a breach, you have no idea what back doors the intruder has installed in your system, or your network as a whole. If you want to mitigate the intrusion, you should shut the system down until you can examine it in an environment where you’re certain it will no longer be accessible to the intruder.

          What about shutting off the server’s network access? That may not be sufficient. What if the intruder has installed a daemon that switches it back on? How about shutting down the switch port the server is connected to? What if the intruder has access to your switch and can turn that port back on?