New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Are these IPTables good for hardening a OpenVZ VPS running a web server?
Hi.
I am running Centos 6 32 Bit.
I have disabled password based authentication, set permit root login to no, created a new admin user, and use SSH keys.
I understand that it's best allow SSH access from a specific IP, but I have a dynamic IP so I can't do that.
I am going to install apache, php, mysql.
Also, once I install an SSL certificate, would it be best to remove the port 80 rules, and only allow port 443 (HTTPS)?
Comments
@Stacy ,
Worth noting:
It's entirely possible that you don't, but it's worth looking into.
@Stacy ,
We generally recommend not using
-P OUTPUT DROP, as this requires you to explicitly write rules for every type of traffic you would like to allow to leave the machine, (such as specifically whitelisting yum, I don't see any rules in your configuration that allows yum to download packages from non-standard ports or non-HTTP protocols. (FTP for example, or alternative HTTP ports 81, 8000, 8080, 8443, 8888, or related.However, I note your last OUTPUT rule is to allow all, which conflicts with the chain default action. If you should ever misplace this allow rule from the OUTPUT chain, your server would refuse to make most of its necessary outbound connections such as ntp, dns, FTP, etcetera.
Okay thanks for the feedback. I started learning about iptables today, I'm used to using firewalls with GUI's and just check mark the services I need.
I did iptables -F but then got locked out of my VPS, so I went to serial console and tried to console in but it automatically kicks me out.
I looked up the "unable to open pty" error and it seems like it's a rare glitch with OpenVz.
Opened a ticket with Crissic, awaiting response.
Yup, that one's up to them to fix. It's a simple issue that happens sometimes.
As per the being locked out, I'm not surprised with such a restrictive ruleset
.
Had this as well before.
Keep in mind though that ugly things can happen to disks. And then you're locked out. I'd suggest to keep password auth. enabled but a) have a good, long password and b) not use it but merely have it for backup/emergency.
From what you write, you're not yet very experienced; keep in mind that even experienced guys sometimes lock themselves out, for instance due to a firewall that's too tight. I therefore suggest to generally have a permissive version of your rules available and to auto-install it time-based, say after 10 minutes (to allow yourself back in). Once you're done and everything is nice and perfect you can delete that "fall-back" script.
You can as well limit the IP range. Before doing that, however, keep in mind that one day you might need to urgently log in from who-knows-where.
Another option you might want to consider is port-knocking (which works from everywhere).
Hardening - and then running AMP? Uhum ...
And no, you would almost certainly want to keep port 80 open (and serve it) for visitors who simply can't use https. Unless, of course, you run extremely sensitive services.
One classical case, even for otherwise fully SSLd sites to still keep http open/running is static content like images.
I usually don't save my rules until I disconnect and attempt to log back in. That way, if I'm locked out I can restart the VPS from the provider's control panel (e.g. SolusVM) and iptables reloads more permissive rules.
On a side note: It is my personal opinion that firewalls should not be used to block (D)DOS attacks. Once the attack reaches the machine it's a bit of a moot point as the VPS is already having to handle the load. Attacks should be mitigated upstream before reaching your server. Again, just my thought. But in keeping that, you could just open ports 22, 80, and 443 on INPUT, with the default being DROP. Rate limiting is still fine as it can slow down bots scraping your site for content.
I'm going to respectfully disagree. Disabling passwords and using only keys keeps things substantially more secure. You're just as likely to lose a strong password as your are to lose a key; keep everything safe and backed up and you'll never have to worry about it (as much).
Misunderstanding. I was mainly talking about the server side. The problem with passwords isn't so much that the protection level is weak; that's next to irrelevant with a good password. The problem is eavesdropping it. Keep in mind though that I suggested to keep password auth enabled for emergency cases (aka. very rare exceptional cases. I should have mentioned though that, of course, after such a case the password should be changed.
If you want to really worry about SSH (and get it tight) we're soon in a complex maze. Because, for instance, configuring SSH so as to use/accept only reasonably secure encryption is a) too hard for most users b) accordingly rarely done and c) way more relevant for security than (high quality) emergency password access.
If your router supports dynamic DNS services like no-ip, dyndns, etc. you are good to go.
You can configure your router that it will update the dynamic DNS entry automatically every time you get a new IP adress. Now just use a small script on your VPS that pings your dynamic DNS adress and adds the IP to the IPtables. Put this script on chron and it works.
Doing it this way on one of my VPSs. The VPS runs a DNS-Server, which only my home network should access. The script runs via chron every five minutes and updates my IPtables this way. Works like a charm.
From my end, I'd prefer not to use port 22 for SSH, as bots are configured to scan and bruteforce, it being a common port.
Afraid of being locked out? Just don't add your firewall to 'chkconfig', reboot the server if you are locked out and restart firewall