Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

No doubt there is much good information at this link on hardening a linux server and at the child links off of that. And at this link to relevant tools it seems there has not yet been a popular security tool that the wiki writers are not enthusiastic about. Reading and understanding it all would take a considerable amount of time depending on the level of knowledge you are starting with and then more time on top to install and evaluate and learn to use a subset of the 15 or so tools and implement enhanced security. However, the volume and nature of the advice makes it seem to me that the advisers may have in mind the security of well-known sites with multiple logins (and users), dedicated IT security personnel, and a web-presence reputation and corporate reputation to protect.

What high priority steps should I take in much less time than it would take to research security on stackexchange and (say, 30 minutes or less) to enhance the security of my certainly-not-well-known server? Details about my deployment and needs:

  • one instance (on the linode cloud) running the desktop version of ubuntu 10.10 (Maverick) and no intention nor need to have more than one instance
  • availability needs: one multi-hour outage per month is acceptable. If and when there is a DOS attack, it will be inconvenient to figure out how to avoid it happening again but probably no more than an inconvenience
  • privacy need: yes, please
  • one administrator, presently logging in as root with SSH
  • zero users, in the traditional sense. The administrator would be the only 'user' logging in to evolve the system and when it goes live, the administrator will be VNCing to look at results once or twice per day
  • SSH, although I did nothing at the server to force the client to do this
  • VNC. At the client I always use SSH for VNC, although I did nothing at the server to force the client to do this
  • The system is mostly up and running but I will occassionally need to apt-get install, remove, or purge as I evolve the system I am developing
  • Filezilla to evolve the system (example: send it a new version of the application). I always specify port 22 but I did nothing at the server to require this
  • the server runs exactly one application in Java (and a little bash scripting) developed by a trusted person, although that application will link popular libraries (example: Java's Joda) or invoke popular utilities (example: gnome-terminal, linux beep utility 1). The application uses a trusted library to talk to the internet and the port number is known to me.
  • the administrator is using a strong password
[1] I know there is no need to install the linux beep utility on a cloud server but I sometimes run this application on my desktop computer where it is nice to have sounds. It is simpler for me to have only one version of the application rather than a sounded version and a silent version.

share|improve this question
up vote 2 down vote accepted

I think your implied criticism of the resources there is a little bit unfair.

But ok, so the premise is I get 30 minutes to secure the Linux server as well as possible? Fair enough. Here's a proposed checklist:

  • Turn on automatic updates for all software. Choose a distribution that provides security updates for an essentially unlimited time. (For instance, I wouldn't use Fedora for this purposes, because after 2 releases -- a year or so -- Fedora will no longer provide automatic security updates, which might render my server silently insecure after a certain amount of time.) Update all software packages.

  • Enable a software firewall (iptables) and configure it to block inbound access to everything but SSH, VNC, and the port for that one server you are running.

  • Turn on automatic periodic backups.

  • Confirm that if the server gets hacked, it's not a big deal, either for my employer or for my professional reputation.

  • Configure SSH to allow only public key authentication (disable password authentication).

  • Reboot the Linux server.

  • Check that you got the firewall configuration right by scanning all open ports on the server using nmap, and making sure that nothing shows up other than the 3 you intended to allow.

  • Check that you can access your service (i.e., that none of your security lockdowns broke the server application you are running).

P.S. I'll point out that my answer on those threads already comes pretty close to your criteria; and please see my answer in any case for more elaboration on several the suggestions above.

The SANS checklist mentioned there already comes pretty close to your criteria, too, as it seems to be ordered by priority.

share|improve this answer
At the link you wrote that auto-updates is worth the risk of broken applications. That by itself is not a trivial issue. By focusing on a high priority list, at least you are helping in this part of the problem, thanks. – H2ONaCl Apr 23 '12 at 6:13
@broiyan, thanks. I think one way to deal with the risk of broken applications is by choosing a Linux distribution that best fits your risk tolerance regarding the risk of broken applications, vs getting the latest version of everything. For instance, my impression is that RHEL tries to avoid updates that might break your system (while still promptly providing updates that fix security problems), while, e.g., Fedora focuses on getting you the latest version of the code and assumes you'll deal with any breakage. – D.W. Apr 23 '12 at 6:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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