All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Is your VPS really safe?
I'm very concerned about security. My boxes don't allow password logins, the only services allowed by the firewall are HTTP and SSH (running on a non-standard port), Wordpress is always the last version, etc. phpMyAdmin runs on a password-protected directory (and I'm considering using a big random string for directory name) and the length of my passwords are at least 16 to 20 chars. But how can I tell that my VPS is REALLY safe? Could you tell that your server is?
I know that is no such thing as a "perfect solution", but how could I improve that? All the updates that the Debian Security Team brings to us are enough? All these things that I've did don't matter if someone could somehow crack the OpenSSH server and login on the system.
Comments
Sounds like you're doing most of what I recommend. I'd add fail2ban to block anyone trying to brute force SSH (though moving it to a non-standard port and disabling password-based access certainly cuts down on the skiddie attacks). The most important thing is to keep everything backed up and have a good intrusion detection system (even if that just means having an email sent out whenever someone logs in) so that you can find out when someone does get in.
@NickM I've used fail2ban for a few years, but with the huge drop on login attempts when SSH is not running on port 22 I just feel that it is not necessary anymore (and it uses too much memory for a LEB). I do have rsnapshot backing up everything every 4 hours and the daily backups that goes to Dropbox are AES-encrypted, but I've never used an intrusion detection system. What solution do you use? A personal-written script that sends a email to you whenever someone get in?
Just a simple
mail -s “Login on [Server Name]” [email protected]
in /etc/profile works well enough for my needs.I guess it is enough for me too. Thank you, @NickM.:)
Doesn't matter. Still a red bullseye. And when was the last time you checked your plugins and themes?
@drmike At least once every two days.
How specifically are you checking them?
At the Dashboard -> Updates. You mean that the Wordpress plugin folder is writable for the www-data user, and that is a serious security risk? It's the only PHP application that I let write permission to some folders.
And have to go home so I'm going to assume that you;re going to say the autoupgrader. For that, i say bullseye as there's no security check and point you to point 1 here as proof:
http://wpmu.org/wordpress-security-101-8-tips-tricks-and-tweaks-to-secure-your-wordpress-website/
along with whatever version back in the 2 branch where their downloader for the zip package got hacked and everyone who downloaded the core software got their sites hacked.
good night.
edit: yup, bullseye
Yes, fail2ban is not very useful for SSH if you disable password login and change the port. The pattern it searches is for password fail. For publickey login the attacker even doesn't have a chance to get that far. You can add new pattern to catch any disconnection due to non-publickey.
But fails2ban would still be good for other services.
BTW, if you are talking about your web server, why not add a reverse proxy? That way you only have a simple yet secure system w/ a reverse proxy open to public, and your important stuff is on another server behind it. If the reverse proxy is hacked, it would take more time for the hacker to get into your real server, and usually you have enough time to take care of that.
I would also suggest ht password protecting your wp-admin directory as well. Alot of Brute Force attempts target wp-admin. A further step would be to change your admin name (if you are using the default "admin" login).
I always:
SSH on another port without passwd auth
only run needed services
keep stuff up to date
backup really often to multiple locations
The admin interface should be protected by SSL + client certificate. Password protecting is also not safe.
No vps is safe as long as it connects to the internet. You can only take precautions and go from there.
@NickM I've tested the simple intrusion detection method that you suggested, but it works only for shell access. I've tried to send emails warning about SFTP logins, but I can't got it done (using ~/.ssh/rc for example). Anyway, it is still useful.
@drmike I know that Wordpress has it weak points, but I could not stop using it cause it's too awesome and it just suit my needs. I've ever tried to use the minimum number of plugins that is possible (4, including Askimet), but that are times like when someone injected malicious code on popular plugins (like WPTouch, which I have installed).
@danielfeng In the past few days I've been reading about Varnish, but the websites that I run aren't really well-visited (less than a hundred visits every day) so a reverse proxy could be a rocket launcher to kill an ant. Disconnections due to non-publickey are truly dangerous? Or just some useless hits? I tend to use SSH Tunneling to login on the admin area (although not always), maybe I'll restricted its access to allow only the VPS IP address itself.
@kiloserve I change the default administrator username whenever I'm installing Wordpress. It's one of those simple things that could bring huge benefits.
@dmmcintyre3 I've been doing all that.
Hi All,
Is it usefull to rename wp-admin folder to something else?
@pepaya yes everything you do is a plus for the security.
Also you can move your configuration file out of your public_html
Restricting ssh login attempts is not necessary if your password 8+ random chars long or you are using key auth. Failed login attempts in logs do not indicate hacking attempts, it's normal internet background noise - some scripts or worms check broad IP ranges for weak passwords - it's harmless if you have unique 8+ random chars password.
You should use debian stable (not testing) for timely security updates.
Really wordpress is the weak point, you may want to separate frontend and backend using reverse proxy - nginx is light and easy to install, not sure how much it will help. Also if it is for OpenVZ vps box - host server can be seen in traceroute, so attacker may try to hack host server, or find your vps provider by IP whois and try to get access to your vps control panel account by social engineering.
Also you may check sources of your scripts to see how they parse user input, and check that register_globals is off in php.
In short you have nothing to worry about if you host just a wordpress blog, but if you are running something money related (like onlie e-currency exchange) or something else that may be specially targeted - you may want to move to dedicated server as it is more secure than vps, separate frontend and backend, check how your scripts parse user input.
You cannot - even if you do everything perfect on your side.. it's still just virtual private server and I am pretty sure that among your vps providers all of them aren't that commited as you are regarding security. Just imagine.. all those relatively unknown cheap vps amateur hosts and their nodes... some admins here are great, skilled, know what they are doing.. but all of them? No way...
And as long something drasticly don't go wrong there's no way to know that. Scary, a?
In your case I'd worry more about your VPS provider's security. You seem rock solid.
I've been quite interested in VPS-specific security - ie beyond application level or server-specific level, which are all the case regardless of whether the server is a 'real metal' server, a VPS or your own computer --- stuff that is specific to the nature of VPS's.
First risk is if the VPS provider's root password to the hypervisor is something guessable - you have no way of knowing of course. But any attacker is probably going to concentrate on that - as then they'll be pwning many boxes in one go.
Secondly, if the provider is using a management tool like SolusVM, the root password it asks for when you buy/setup the VPS is stored in plaintext so that if you ever reload an OS, it can set that as the default root. Therefore you should make sure you don't use one of your regular passwords at the point of purchase/setup as that is sitting on the VPS provider's server somewhere in plaintext And of course, change it when you first log in - change via SSH, not the management control panel.
Another concern is if the VPS provider wants to take a sneaky snoop through your VPS filesystem. Large corporate providers won't have the time or interest and will (hopefully) have accountability measures in place (audits, logs, people reviewing them). I'm always concerned about the individual teenage VPS provider who is bored and wants to look through his 50 or so customers' instances. No one is going to know.
Thanks! Can you explain me where in the file? at the beggining is OK ?
Yeah, it should work just fine at the beginning of the file.
If you don't trust a provider, go elsewhere. If you can't find a provider you trust, give up. Keep your data on your own computer, locked in a room and disconnected from the Internet.
Regardless of the security measures you take, there is a significant level of trust involved.
Thank you! Very useful!
Another thing that seems to help is .htaccess url rewrites, or rewrites in nginx. This keeps those that go snooping with a lot less snooping lol.
If you really want to now everything that gets changed, then you can use VaultPress, but it is a premium service, so you have to pay.
However, I think it should be simple to replicate the same checking effect. You can store two copies of your blog or site's files and then compare both every few hours. So when you make a change, you just apply it to both.
Or you can use the open source version of tripwire, or systraq, or bsign, etc
i don't get the "use ssh on another port" can't you just nmap, and find out in 1 second?
In my experience over 90% of all SSH attacks are bots attacking port 22. If you're not on port 22 then the only attacks you'll receive are attacks specifically targeting you, in which case, DenyHosts will fix that quickly.
99% of the attacks on ssh running on port 22 are script kiddies. Moving your ssh port is really intended to stop only them. They look for easy to exploit servers, and for them, it doesn't make sense to do a full port scan on every server - in the time that it would take them to do so, they can check another thousand IPs for SSH running on port 22.