SoylentNews is people
SoylentNews
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?
(Score: 2) by bzipitidoo on Saturday June 03 2017, @04:03PM (6 children)
Yes, the KISS principle.
That's how I run my web site. Not even a full LAMP stack, just the L and A parts. No CMS either, wrote all the HTML myself, in a text editor. I put a little JavaScript in one of the pages, but the site is quite viewable without it, just won't see the pretty chess boards I made. Have never had a problem with my website being defaced or compromised, and I've had it up for 13 years now.
I can get by without the M and P parts because I am not running a forum or taking payments or donations, or anything that needs a registration process for users. There just isn't much surface for the black hats to work with.
(Score: 3, Interesting) by N3Roaster on Saturday June 03 2017, @04:46PM (1 child)
Also worth noting is that a lot of what simple sites use the P for are things that static site generators (jekyll, nanoc) do well now. Using any of those you can keep the nice template features, feed generation, &c. Let the generator update the site from a git hook. All of that is still locked up behind port 22 (hopefully no root login allowed, key based) so you're not increasing the attack surface. That's pretty easy to set up on Linode.
Typica - Free software for coffee roasting professionals. [typica.us]
(Score: 2) by TheRaven on Sunday June 04 2017, @12:52PM
sudo mod me up
(Score: 2) by Phoenix666 on Saturday June 03 2017, @10:47PM (3 children)
That's exactly what I did, for the same reasons. Other than that, I did set up a mail server using the Perfect Server for Debian guide on HowtoForge. That's the only other service and set of ports left open in the firewall. The SSH I set up to bounce everything coming from China, because fail2ban's logs were showing IP addresses in that range trying to brute force it; in fact I can still see the fail2ban logs bouncing attempts from those IP's the way it's supposed to. And yet, somewhere in the system there's a process that keeps recreating reverse SSH connections to that range of IP addresses. Looked in all the usual places for said process, ran lsof on the open connections, and still haven't found it yet.
It's really a bare-bones implementation that I kept current with package updates on a fairly regular basis, so that's why I'm mystified. I've always trusted the KISS principle and the strength of FLOSS and guides on best practices to do the heavy lifting on security, but this episode has me re-examining that.
Washington DC delenda est.
(Score: 0) by Anonymous Coward on Sunday June 04 2017, @01:02AM
SystemD.
(Score: 0) by Anonymous Coward on Sunday June 04 2017, @01:18AM
i don't know which perfect server guide on howtoforge you're talking about but the ones i'm seeing are taking about bind and apache? that's not how to set up any "perfect" mail server. bind shouldn't be used on any server if possible. sounds like you're not doing enough research nor being paranoid enough.
(Score: 0) by Anonymous Coward on Sunday June 04 2017, @06:15AM
a. Your hosting provider may have been compromised. Your site was attacked via a hole in Xen, VMWare, or Linux containers.
b. Your client, used for ssh, was compromised.
c. Intel's management firmware bug got you. That chip on the motherboard either attacked your kernel or it is itself doing the outbound ssh.
d. The outbound ssh is running in SMM (system management mode) and was possibly installed by the PC vendor. It could be even, or just crummy anti-theft stuff calling home.
e. Debian is compromised. They may have a bad developer or ftp maintainer.
f. Maybe you got a bad install disk, and thus you aren't actually using Debian. It looks like Debian, being based off of Debian, but it has different package sources.