15

I've just signed up for a linux VPS to host a website I've been creating and I need some advice on the best approach to secure it.

I've previously been hosting it off a VM in the house, but I want to get rid of that. So security has been handled by the fact that I'm NAT'd and only certain ports opened/forwarded to the machine.

Now I find myself in a situation where the machine is essentially completely open to the internet, so I'm thinking that I need to start doing something with IP tables? This is something completely new to me.

I was thinking that there might be a more elegant solution, involving connecting it to my vpn on a separate interface to connect through that, but not sure where to get started with that.

I need:

  1. SSH access from anywhere (using a non-standard port that is already configured)
  2. Postgres Access from a single location
  3. Web (http/https) access from anywhere
  4. FTP access from a single location

Questions:

  1. What is the best practice for securing a linux machine like this? is it iptables?
  2. Can you point me in the direction of resources (decent ones) to learn how do this.

My linux level is fairly high, I can write/debug bash scripts, edit configs from scratch, etc, and I understand a fair bit about the architecture, but I'm no guru.

AviD
  • 72,138
  • 22
  • 136
  • 218
Martin
  • 303
  • 3
  • 8
  • I'm liking the responses, but I'm leaving open as I'm still waiting on whether there are specific difference between a remote VPS and a local machine (physical or VPS). – Martin Jan 20 '12 at 16:17

3 Answers3

9
  • Limit access to services. IPtables is a good way to handle that. Setup connect rules that enforce what you described for each service and drop everything else.
  • Limit your daemons through proper configuration. If you only authenticate with a public key over ssh (and you're confident enough that you won't lose it and deny yourself access), turn off password and keyboard auth. Fail2Ban is handy for brute force attempts, but instant rejection is rather satisfying too. Configure your FTP server to only export the related directory tree.
  • Assume that each of your daemons is compromised now... except maybe SSH because that's just one of those things. Use external facilities to limit what the daemon can do on your host.

I'm a huge fan of AppArmor on Linux because the configuration is something that can be reasonably understood and it's very powerful for sand-boxing applications. For example, you can limit Postgres and anything ever executed by it to only affect the database storage field. The same applies for web and FTP servers -- they never need to read anything any data that's outside of their operating directories and never need to open another network port. Get an email alert to any violations of those rule sets.

Isolating your services like that will give you confidence in the integrity of the machine as a whole even if an individual service is compromised.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • I like the AppArmor idea, do you know of any online resources that will help me learn how to do it? And IPTables... – Martin Jan 20 '12 at 16:13
  • @Martin http://www.novell.com/documentation/apparmor/pdfdoc/book_opensuse_aaquick21_start/book_opensuse_aaquick21_start.pdf ; The Internet is littered with IPTables docs. – Jeff Ferland Jan 20 '12 at 19:24
  • Are there any pre-configured VPS services available? Any on windows server? – Paul Podlipensky Mar 10 '12 at 03:52
6

depending on the VPS host provider they may offer a firewall solution that will allow you to setup what can and cannot be accessed from the outside world.

to give you an example i recently worked on a VPS host for a client that had nothing but HTTP / HTTPS access to the internet, but the control panel for the VPS (part of the hosts package) provided a system to configure the firewall that was infront of the VPS, this allowed me to open up SSH, MYSQL & FTP access to only a single static IP address that is part of my own home broadband package.

IP Tables will allow you to-do a lot of work to ensure the box is secure from the outside world and you can even provide rulesets to help reduce attacks where people try to bruteforce SSH passwords (basically you could say in the rule, if this ip address gets an ssh login wrong 5 times in a timeframe, blacklist the IP for a set period of time or perminantly).

Something i would suggest you looking into is configuring SSH so that it does not allow ROOT login (this can be done in the SSH config file, off the top of my head i cannot rememeber where this file is stored)

Another thing that should be configured for SSH access is to setup Key Based authentication, this means that ONLY the PC that the Linux server has the public key for will be allowed to connect to the system, at that point you can turn off password authentication so as to help mitigate Bruteforce attacks on the server.

If in your case the host does not provide any firewall options and the box is completely open to the internet then your best looking at configuring IPTables

here is a link to some IPTables related information, sadly i have not had much input with IPTables so cannot guarantee its worth.

http://www.pettingers.org/code/firewall.html

hope this helps.

Kristiaan
  • 161
  • 2
  • They don't offer a firewall unfortunately, it's a very cheap host. It will be something I look for in a future host though. – Martin Jan 20 '12 at 16:11
3

You will treat this box just like any physical box that has a public IP. You need to follow the basic Linux hardening guidelines such as:

  1. Keep the box update.
  2. Remove unnecessary programs.
  3. Have iptables running and locked down as tight as possible.
    • You can do any specific source based rules you want with these such such as your FTP and Postgres requirement.
  4. Run SSH on a non standard port and don't allow root logins.
    • You can also do key based authentication to make it securer.
    • I would also recommend running denyhosts and/or fail2ban so you can them monitor your logs for failed login attempts and then instantly block IPs through /etc/hosts.deny. It's just another layer that will make you feel a lot better about SSH being open.
  5. Run a HIDS on the box. I would recommend OSSEC for both some alerting of malfunctions on your box, potential attacks, and also as a file integrity and root kit detection.
  6. Monitor your services to ensure they are all up and running correctly. Using a program such as Nagios.
  7. Etc.

You could also set up a VPN, such as using OpenVPN to get into the box. That way you can run OpenVPN on a nonstandard port and then you can configure it for both key based and password based authentication before it allows you in.

Below are 2 sites that I would highly recommend looking at.

http://www.sans.org/score/checklists/linuxchecklist.pdf

http://www.cyberciti.biz/tips/linux-security.html

Eric
  • 416
  • 2
  • 9
  • I was thinking of joining the box to my home network (which is sufficiently secured) via a constant VPN connection, not the way you are suggesting. Is this possible? – Martin Jan 20 '12 at 16:15
  • 1
    So you are going to have a VPS with a public IP, and then have a VPN connection to it 24/7 so it's on your home network and can access anything within that network? I guess I don't quite understand the setup. Since this server is going to be a website, and could potentially have people trying to attack it, I wouldn't want it in my home network if you are already moving it to a VPS. If you want to use the VPN route, I would use the VPS as a server and then use your home network as a client and just connect into whenever you need to. – Eric Jan 20 '12 at 18:08