Seven Critical Things To Protect Your Infrastructure and Data
https://infosec.engineering/seven-critical-things-to-protect-your-infrastructure-and-data/
@pypper @jerry strong (public key SFTP, for example) authentication, plus limiting access to very specific IPs or subnets should take care of that.
And, if the bad guys are already on your server, they will find a way to exfiltrate, your push backups are not going to make that considerably easier.
But they *will* make it easier to actually *have backups*. The alternative means that anyone who gets access to the server can delete backups also...
@rysiek
I strongly disagree. Pull backup means you have a server that has access to all your servers. If that server is compromised, you are in a world of pain.
A push backup means you can setup a sanctuary (for instance with network diodes). If you fear about loosing your backup in case of a server compromise, rotate the dest dir, or set history to read-only with a cron or a post-push script.
@pypper @jerry
@rysiek you’re right. I wrote that list based on a currently frustrating situation I may or may not be dealing with.
@jerry ah. In case you are, in fact, dealing with a situation that may or may not be frustrating, good luck!
@jerry one thing I am missing from this list is compartmentalization.
Put stuff in VMs, put stuff in containers, put stuff on different servers that do not talk to each other, if at all possible. Make pull, not push, backups. Same for logs.
Your public SFTP (you are using SFTP, not FTP, right?) server really does not need to have write access to your LDAP machine.
Basically do everything you can to limit any potential infection as much as possible by the design of your infrastructure itself.