1

I have a site running on a VPS. I set up the LAMP stack and a few other programs personally. This is only the second time I have set up a VPS and I am a bit worried about security. Are there things that I should be aware of (regarding my Linux install and LAMP stack) which people could use to gain access to my VPS and steal/alter my site or shut it down?

closed as too broad by Adi, AJ Henderson, Xander, TildalWave, Eric G Mar 20 '14 at 17:05

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

1

Any external service is a security risk. You indicated you're running a LAMP stack, so I'm assuming you have at least the following services running:

 1. SSHd
 2. Apache/Nginx
 3. PHP
 4. MySQL

MySQL by default is not externally facing, and you should not make it so unless you're involved in a clustering or replication environment (in which case there are alternatives to putting it on the wide web, like a VPN.)

Apache/Nginx + PHP cannot be made internally facing if you intend on providing content to people on the web, so these are going to be your main points of ingress.

SSHd itself has to be public facing (not always, but for the sake of simplicity in this case). Use of a Key pair for authentication and completely disabling password authentication is your best best for preventing people from obtaining access via this service.

Let's talk about webservices. Apache, Nginx, and PHP. These are the services that people will attempt to exploit in order to obtain access to your machine, so let's talk about securing them.

Firstly, you're going to want to isolate the services. If you've installed them yourself that means that ensuring that Apache and Nginx are running as non-root users.

Secondly, you're going to want to take a look at php-fpm or suphp, which allow PHP to operate as a user that is separate from your webserver even at a virtualhost or directory level.

This accomplishes two things, by taking root permissions away from Apache/Nginx, if someone gains control of that service they cannot impact anything but the operation of that specific service.

Changing the user of php (especially on a per-site basis) isolates the PHP module from interacting with other sites on the machine, and with the webserver itself, so if you have a client or website with exploitable code on it, your entire service, other sites, and your machine is not at risk.

  • 1
    I want to add. Make sure your stack is only a LAMP stack. If you install a bundle of software that is LAMP, it could have things you might not want in it. PHPMYADMIN, FTP, WEBDAV. XAMPP has these (even though XAMPP is supposed to be used as a development platform). – user11869 Mar 20 '14 at 14:30
  • @Rell3oT trust no stock images! question everything! :) – Ahrotahntee Mar 20 '14 at 17:16
1

Your application code.

Any server-side application code - be it PHP/Perl/Python (whatever the P in LAMP means to you) is your greatest risk. Whether you have written it yourself, or it's an open-source (or commercial) package, any coding flaws could lead to security vulnerabilities like SQL injection.

If you have written code yourself, you should follow the OWASP Top 10 at a minimum. You should also check your code, perhaps by scanning with Zap or Rips (which are free), or other tools, or hiring a pen testing company.

If you're using open-source or commercial software, you should check their history of vulnerabilities. If there are none at all that is a worry, it probably means the code has never been audited. If there is a small number, that's a good sign. If there are many you may want to avoid the project. Plugins can cause risks as well as core applications (a big problem with CMSs like Drupal).

Other people have mentioned infrastructure tweaks, but in general the defaults are pretty good these days. I would restrict SSH to key based login (instead of passwords) and ensure the application connects to the database using a low-privileged user.

0

What you are trying to achieve is known as hardening, i.e. making systems and services more secure. Obviously there is a lot to talk and think about. You probably want also to take a much broader perspective, because you probably want to harden your complete server, not only the few services you mentioned above.

Personally I think the NSA did a great job here. Take a look at their recommendations for various operating systems. Although they specifically speak about RHEL5 in case of Linux, most of the tips can be applied to any Linux distribtuion.

  • Both the links here point to wikipedia - did you mean to include a link to the NSA stuff? – symcbean Mar 20 '14 at 15:42
0

Although it's a bit dated, the SANS check list is a good starting point (I'm about to go and look for the NSA list Karol mentioned).

But the big wins come from the simple things:

  • pick good passwords,
  • don't run stuff you don't need,
  • make sure you can identify when patches are available for the software you are using and install them promptly.

Not the answer you're looking for? Browse other questions tagged or ask your own question.