Earlier quoted context omitted.
If a server can push backups, it must necessarily have credentials for and write access to that backup repository. If the server is compromised, that write access could be used to attack the backup repository as well. Pulling backups from a server removes the need for credentials or access to the backup repository.
Plus, if you're super paranoid, pulling doesn't require leaving any ports open and software listening on the repository.
My First 10 Minutes on a Server
281–290 of 298 posts
Re: My First 10 Minutes on a Server
#282Re: My First 10 Minutes on a Server
#283Earlier quoted context omitted.
Plus, if you're super paranoid, pulling doesn't require leaving any ports open and software listening on the repository.
But it requires leaving a port open on the DB server where an attacker can get a whole copy of your database, or destroy it.
Re: My First 10 Minutes on a Server
#284Earlier quoted context omitted.
>This is a really bad idea and a good way to get owned. Database backups must be PULLED Just make sure your database server doesn't have permission to delete backups (e.g. Have it POST a backup via HTTPS). There is nothing wrong with db server initiated backups.
This is still open to abuse in the form of your legitimate backup script being disabled and replaced by one uploading false backups. You wouldn't know anything has happened until you go to restore from one. Of course, this is an edge case, but I believe setting up a pull-based backup system is still going to be less work than a write-only push system.
Re: My First 10 Minutes on a Server
#285Earlier quoted context omitted.
They could be, or you could take the route you won't regret later and use a configuration management system. Deutsche Telekom has open-sourced system-hardening cookbooks for Chef, Puppet, and Ansible.
Good to know. I did some searching and found them here: http://dev-sec.io/
Re: My First 10 Minutes on a Server
#286Earlier quoted context omitted.
I used to use this, but I found that it's significantly less useful than a git repo with my server-specific Chef cookbook in it. Manually modifying servers was never a good idea; it's worse now, even with tools like this.
I suppose that's true, but in the field where I work (social science), servers are mostly spun up to scratch an immediate and idiosyncratic itch, so configuration tends to happen organically. I agree that's probably not a good idea, and learning Pupchefsible is well worth the effort. In the meantime, though, there's at least some degree of reproducibility with etckeeper.
If you need reproducibility without a CM framework, keep backups of your machines.
Re: My First 10 Minutes on a Server
#287Earlier quoted context omitted.
I feel like arch wiki is that thing today. It's a bit disorganised and things get outdated while nobody's looking, but there's almost anything you'd every want in there.
It seems like there a bunch of articles there but they're more like notes on how to use a tool specifically with Arch, rather than a guide for everyone. Compare this page http://www.tldp.org/HOWTO/Quota.html to this page https://wiki.archlinux.org/index.php/Disk_quota . TLDP organized HOWTOs like mini-books; tables of content, multiple authors, versioned releases, and of course, you could download them all and search…
I appreciate TLDP for what it is and the details they go to. But Arch wiki can easily be read as a FAQ for all modern systems. And it will usually send you to other places for details (sometimes TLDP as well)
Re: My First 10 Minutes on a Server
#288Here's an Ansible role (I made it) that automates the steps described in the article: https://github.com/LucianU/ansible-secure .
Re: My First 10 Minutes on a Server
#289I don't mean to sound flippant but why can't these "lock down your new box" tutorials just be a bash script? Shouldn't they be?
Hardening (along with any other server setup/configuration) should be implemented using some idempotent configuration management software (Chef, Puppet, Ansible, etc). It's 2016, there's no need to configure servers manually.
Here is Ansible playbook I recently created https://github.com/chhantyal/5minutes
Re: My First 10 Minutes on a Server
#290Fail2ban? sshguard? unnecessary. Just disable ssh passwd auth (which generally is a good idea) -> done/done If you don't like lognoise from ssh scanners (even if you disable passwd auth), move your sshd port to some random high port and make note of it in your ~/.ssh/config Generally: if in doubt, take the more simple and elegant solution to a problem.
Sick of seeing this idiotic advice. Standard ports are standard for a reason. Perhaps one should also change their web and mail ports for "security".