121–130 of 143 posts
If securing a server were as straightforward as changing ssh settings and firewall rules, distro providers would do this sort of thing out-of-the-box, or at the least there would be a script circulating on github for doing this specific setup.
Earlier quoted context omitted.
Your concerns are not an issue with a distro like Debian where the only upgrades are for backported security fixes (or, when an announced point release comes around, critical bug fixes). I worked for several years at a shop with dozens of Debian servers, and nightly unattended upgrades very rarely caused issues, and never caused anything truly serious.
Debian is very stable. I recommend running "safe-upgrade" nightly -- and keeping an eye out for when you need a "dist-upgrade" (typically new kernel images -- and other stuff that should be tested (eg: test that the server actually boots -- not to mention do a reboot to use the new kernel). I'm not sure how good the Ubuntu LTS relases are, but Debian has always been great at both keeping a stable system up, and keepi…
[1] "upgrade" if using apt-get, "safe-upgrade" if using aptitude
Earlier quoted context omitted.
As a seasoned system administrator, I strongly advise you against unattended or automatic upgrades. In a Linux or FLOSS eco system components are very strongly coupled but loosely developed. Say glibc is base of nearly every server application but it is and server apps are not regres tested for each other. Which will or may lead to incompatibilities, down times or performance issues even on edge cases data loss. So p…
Your concerns are not an issue with a distro like Debian where the only upgrades are for backported security fixes (or, when an announced point release comes around, critical bug fixes). I worked for several years at a shop with dozens of Debian servers, and nightly unattended upgrades very rarely caused issues, and never caused anything truly serious.
Ten years ago, I had a Debian server completely wedge itself on an update. glibc was hosed, practically nothing would run, and I couldn't untangle the mess. Had it been unattended, downtime would have been even longer than the hours it took to rebuild the box from scratch.
This was not the first or last time such an event would occur, merely the most severe.
Updates break things. Anyone who claims otherwise is either incredibly lucky, or incredibly inexperienced.
Earlier quoted context omitted.
Can you explain how this would work? How do I use a private CA to generate(?) keys for ssh authentication?
https://blog.habets.se/2011/07/OpenSSH-certificates hopefully explains how to set up CA for SSH
Where can I buy this as a service?
You could use Heroku, Amazon Elastic Beanstalk, or a myriad of similar services. You could also hire a consultant to secure the system for you.
Most truly competent sysadmins already have full-time employment by a product company or hosting provider. Most so-called sysadmin consultants are former web developers who taught themselves Linux and security, and don't know what they don't know.
I've never understood the compulsion to restrict outbound traffic on an internet facing server that you do not intend to be used by other (untrusted) people. If someone is good enough to own you with everything else locked down, they can change any firewall rules completely if they need to, or just tunnel out over an allowed port. Creating a non-root user then giving them carte blanche sudo rights is similarly odd to…
The option to block traffic per-application in Linux is no longer included in iptables (I think it was the switch --cmd-owner )
Earlier quoted context omitted.
Your concerns are not an issue with a distro like Debian where the only upgrades are for backported security fixes (or, when an announced point release comes around, critical bug fixes). I worked for several years at a shop with dozens of Debian servers, and nightly unattended upgrades very rarely caused issues, and never caused anything truly serious.
> Your concerns are not an issue with a distro like Debian Ten years ago, I had a Debian server completely wedge itself on an update. glibc was hosed, practically nothing would run, and I couldn't untangle the mess. Had it been unattended, downtime would have been even longer than the hours it took to rebuild the box from scratch. This was not the first or last time such an event would occur, merely the most severe.…
Earlier quoted context omitted.
> Your concerns are not an issue with a distro like Debian Ten years ago, I had a Debian server completely wedge itself on an update. glibc was hosed, practically nothing would run, and I couldn't untangle the mess. Had it been unattended, downtime would have been even longer than the hours it took to rebuild the box from scratch. This was not the first or last time such an event would occur, merely the most severe.…
But if you can't flip a switch to deploy an identical server and/or restore from a backup image, aren't you in deep shit anyway? Your failure plan is to rebuild the box from scratch?
For a highly-available mission-critical infrastructure in 2013, the failure plan is also to rebuild from scratch, because "failure" means redundant and backup systems have exploded. This is most likely to occur when you automatically roll out untested changes to your infrastructure.
In either case, you won't be sleeping tonight. Or possibly tomorrow night.
Can I haz an Ansible playbook with good things?
If you allow some self-promotion: you can take a look at the ansible playbook repo I've been putting up (including some documentation and background in the doc directory): https://github.com/pjan/the-ansibles In all honesty; the steps in the TO's article are only providing basic security. Pointing the ansible playbooks to your server will further enhance it. You should also consider changing the SSH port, but that's…