Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Saturday June 03 2017, @02:32PM   Printer-friendly
from the cat-and-mouse-and-dogged-determination dept.

A couple years ago I set up a simple brochure-ware site for the School Board in the district here in Brooklyn, hosted on a VPS instance on Linode, to publicize the dates of public meetings, meeting minutes, etc. The VPS doesn't contain any sensitive information so I locked down the ports to 80, 443, and 22, hardened the SSH with measures like fail2ban, kept the system updated every week or so, and called it a day.

Last week, though, the site was compromised. Blowing the instance away and re-creating it from physical backups is not a problem, but in poring through the system to figure out how it was breached I realized both that my own security chops aren't deep enough and that standard best security practices might not be good enough anymore, anyway, given the many vulnerabilities exposed in the last year and realities like the NSA trove that Shadow Brokers leaked.

So the question for the more experienced security professionals in the Soylent community is, can they recommend a good guide and/or site to hone linux security chops and forensic skills that's current?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by Phoenix666 on Saturday June 03 2017, @11:15PM (3 children)

    by Phoenix666 (552) on Saturday June 03 2017, @11:15PM (#520013) Journal

    Thanks for that. Do you have any go-to sites or guides you refer to?

    I did not use key-based SSH, just a strong password, banned IP ranges from China and Russia, and put fail2ban in to prevent brute-forcing. Didn't think I'd need it...

    Funny thing is, Fail2ban is still there bouncing brute-force attacks from the banned IP ranges, but reverse SSH connections to those ranges keep spawning from some process in the system I haven't found yet.

    --
    Washington DC delenda est.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2, Insightful) by Anonymous Coward on Sunday June 04 2017, @12:49AM

    by Anonymous Coward on Sunday June 04 2017, @12:49AM (#520032)

    You are probably making the most basic mistake when doing the triage. You are still trusting the machine. Do not trust any of the tools on the machine to give you an honest answer. A few tools that may give you anywhere close to a reliable answer is to compare the contents of /proc to what the tools report (missing PIDs, cmdline files, etc), rkhunter and chkrootkit on both the machine and a live cd, comparing hashes using a tool like rpm -V, hashing all files on the computer and comparing them to the hashes made by the tools on a live cd. Basically, once your computer is compromised, verify the trust you give it as anything can be changed by an adversary with enough privileges.

  • (Score: 1, Insightful) by Anonymous Coward on Sunday June 04 2017, @06:14AM

    by Anonymous Coward on Sunday June 04 2017, @06:14AM (#520120)

    The first thing you should do is make a backup of the compromised image, shut down the server, and use a local throwaway box with a VM not connected to the network to run hashes of every file on the box, match them to the official hashes provided by debian's packaging system. This will show you what is backdoored.. if nothing matches someone infected a process only.

    If you ran Samba lately, that had a zero day and it could have been exploited.

  • (Score: 0) by Anonymous Coward on Monday June 05 2017, @03:37AM

    by Anonymous Coward on Monday June 05 2017, @03:37AM (#520562)

    Funny thing is, Fail2ban is still there bouncing brute-force attacks from the banned IP ranges, but reverse SSH connections to those ranges keep spawning from some process in the system I haven't found yet.

    You keep using that word. I do not think it means what you think it means. Silliness aside, I don't think people are really reading your problem. If I understand you correctly, you have some unknowable process trying to open an outgoing ssh?

    Forgive me if you've already written it somewhere; what distro is it?

    It sounds like you have a virus (malware) in the distro- maybe kernel, driver, libs...

    Have you run tcpdump?