2

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 ubuntu.com (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.
H2ONaCl
  • 924
  • 3
  • 10
  • 21

1 Answers1

2

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.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 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 06: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 06:49
  • With the benefit of a little experience I now want to comment that VNC is unreliable because of attempted break-ins hitting the maximum and causing the "too many security failures" problem. So while the system is secure, it sometimes fails to allow me to VNC. I am still researching a solution that meets my criteria. – H2ONaCl Mar 10 '17 at 01:32
  • Regarding public key authentication I think any recommendation of this needs to be balanced against the risk of the client machine(s) being stolen and their disks possibly being not encrypted (which might be the norm). IMHO a 10 character alphanumeric upper and lowercase password might be more safe than public key authentication depending upon the physical security of the clients but nobody on stackexchange ever says it so perhaps I'm being controversial. – H2ONaCl Mar 10 '17 at 01:32
  • The solution for robots repeatedly trying to get into VNC is to install gufw and enable only port 22. – H2ONaCl Sep 05 '18 at 01:05