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 Zyx Abacab on Saturday June 03 2017, @06:46PM (4 children)
I don't agree: although fail2ban and SSHguard do little to stop a sophisticated attack, both software do help mitigate passive (and automatic) attacks. Specifically, they try to prevent brute-force attacks...which is probably the least sophisticated kind of attack there is!
As such, fail2ban and SSHguard are security software—exactly as far as their intended usage goes.
(Score: 0) by Anonymous Coward on Sunday June 04 2017, @04:56AM (3 children)
I've been running pamshield and have it set up pretty aggressively. As far as I can tell it's working well- it sure blocks a lot of IP addresses.
(Score: 0) by Anonymous Coward on Sunday June 04 2017, @05:03PM (2 children)
The question I always have for these people is "why weren't those IP addresses blocked already?" So much of the security thought for the last forever has been default-allow. That is all wrong; your policy should be default deny. If you never log in to ssh from Australia or wherever, why not drop all packets aimed at ssh from Australia or wherever by default? There is a great article http://www.ranum.com/security/computer_security/editorials/dumb/ [ranum.com] about this basic mistake (among others) that people make with security.
(Score: 0) by Anonymous Coward on Monday June 05 2017, @03:18AM (1 child)
I understand your thinking but you're getting caught up in overly-detailed thinking.
I need to be able to login remotely, and I can't be sure of the IP range I will be at.
I have blocked huge swaths of IPs from many problematic countries. I sure wish IP allocation was not so fragmented. You may not be aware of how fragmented IP allocation is. I'm sure someone has something to do this automatically, and if it ever comes to that, I will find and implement it.
For now, aggressive pamshield has been working very well.
(Score: 1, Interesting) by Anonymous Coward on Monday June 05 2017, @03:43AM
I know it is very fragmented and getting worse every day. Try setting your blocks based on ASN, rather than IP address. There are even tools to do that automatically for you (both white and black). You may not know the exact IP range you will be on, but for most situations, you will know the ASN or ASNs that correspond to the network or its owning company.