Hot answers tagged security
at a fundamental level, your issue is partly exacerbated by pushing your backups from the host, rather than pulling them off of it. You can fix that issue, and in addition physically (or logically if needs be) unplug the backup volumes on the central backup host. I do have machines which push backups to S3, but those S3 buckets use versioning so an ...
Normally, a compromised server is backed up as an image for further investigation in a closed down lab reimaged or reinstalled/restored, to keep production going Leaving a compromised machine, even if you seemingly clean it out, in production, isn't a safe practice
You have a bunch of different things all going on in your question. I'll address them separately. My Windows Server 2008 R2 server gets hammered tons of login attempts. I guess somebody is running a Brute Force attack. As a general bit of advice: Don't guess. Know. Computer systems are exceedingly complex. A good system administrator should start by ...
I go the opposite way and use passwordless sudo. %sudo ALL=(ALL:ALL) NOPASSWD:ALL As you point out, make sure your user ssh keys have a passphrase. Also, make sure you disable password authentication to SSH. If you've done the above, I find this configuration is very functional.
There are various ways of setting this up, including using a different authentication method than passwords to start with. One method might be using TLS/SSL certificates for connection. But normally, keeping the password in a read-only file would suffice - as Kondybas says, if the root account is compromised, then everything is compromised.... You might ...
What you want to do is modify your Firewall policy so that on an Untrusted (Public) network, the only allowed ports that come in are the ones that you've specified. Disable all other inbound rules. Presumably your public interface is marked as such, yes? If, on the other hand, it's sitting on a trusted internal network, you want to do the filtering at the ...
Having a password on sudo isn't just about authentication, it provides an interrupt to authorize requests too. If you copy and paste in a script that contains sudo rm -rf / passwordless sudo wont help you. There is also the possibility that a potential user becomes a target for privilege escalation by another user, if the a malicious user can somehow ...
Seems the reason for the disclaimer is that there are ways to break out of the open_basedir rule, [like this trick here]. I would still use it on a shared host but don't count on it as your only security. Also have each virtual host owned by a different user and run the apache process under that user account for the scripts on that host. To your more ...
No, you don't need to share the root. Your visitors that have it trusted already (likely from the company who provided their OS) will already have it. Yes, using your command should be correct, assuming they're all PEM encoded. Per the University of Wisconsin here, order does matter, but only if you provide the root.
Only top voted, non community-wiki answers of a minimum length are eligible