Server Fault is a question and answer site for system and network administrators. 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

Let me preface this question with some information - I am a developer working for a small startup. The company can not afford to hire a proper *nix sysadmin at this time; Subsequently, I have been tasked to setup a LAMP server running CentOS that will be remotely administered by our lead developer. Said developer is in different timezones every week. Security is very high on my agenda.

The server will be used for beta testing a new version of our flagship product. The server will be accessed by beta-testers (consumers, not QA staff) over both standard port 80 http as well as SSL. It will be accessed by our developer over SSH - as well as ssl access to Subversion for source control and port 21 for FTP.

Here is what I have implemented so far...

Travelling Laptop:

  1. "Keepass" password management app's database file is remotely backed up to mozy. Master password is 198bit key. Database file resides on an "IronKey" hardware encrypted dongle.
  2. Windows login is 132bit key. Workstation locks after 5 min idle.
  3. All code, documents and application settings are stored on a hardware-keyed encrypted drive.

CentOS LAMP Server:

  1. Root access over SSH is disabled. SU - for root.
  2. Followed this tutorial ( in order to lock down OpenSSH.
  3. The following is an nmap scan report for open ports:

Starting Nmap 4.11 ( ) at 2009-08-31 10:56 EDT
Interesting ports on localhost.localdomain (
Not shown: 1668 closed ports
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
80/tcp open http
110/tcp open pop3
143/tcp open imap
225/tcp open unknown
443/tcp open https
631/tcp open ipp
993/tcp open imaps
995/tcp open pop3s
3306/tcp open mysql

So there you have it - I know this is not very secure in it's current state. I have been researching this for days and before I implement or change anything else with this configuration I would like some feedback from professionals. Hopefully our economy will rebound and this stressful security job will be handled by someone more qualified than a lowly c# developer.

Thanks In Advance!

share|improve this question

There are a few things I would suggest:

  • I would start by disabling all the unused services (such as pop3 and imap). This will reduce your attack surface quite dramatically. If you must leave some service on, block it by the firewall for any external sources.
  • Also, pre-populate the SSH server key thumbprint or somehow give it to the lead. Make sure he/she will not connect to the machine unless the thumbprint actually matches, otherwise there is potential man-in-the-middle attack that can be done.
  • Consider using sudo instead of plain old su and restrict what the dev lead can do. Only relax the security policy if there is a legitimate reason for the access.

Under ALL cricumstances avoid FTP. SSH has built in support for file transfer, so do not use FTP at all. It sends both credentials (username/password) and files in cleartext, so anyone on the same network can intercept all the data.

Consider this is as starting point on your fun journey : ).

share|improve this answer
Thank you for the response! Would you suggest SCP or SFTP as a replacement for FTP? – user18939 Aug 31 '09 at 15:30
@Chase, either is good, they are similar in that they run on the same port and kind of act the same as far as transferring files goes. SCP is supposedly faster, but SFTP lets you emulate a filesystem among other things. – prestomation Aug 31 '09 at 15:36
@prestomation - Thanks man! – user18939 Aug 31 '09 at 15:48

Also consider the Guides provided by the National Security Agency, the folks responsible for such things as Security Enhanced Linux. They cover RedHat (and CentOS) 5.3, Mac, Windows, Solaris. Use the guide at: (Be paranoid: type the url into your browser instead of following links.)

Something not covered in the guide is the use of Access Control Lists. Find that at . Google "red hat acl. This radically improves *nix based access control giving you much more flexibility in allowing or disallowing access. This takes some getting used to but is well worth it.

"Unused Ports" Your post did not say if you needed those applications. However, unless absolutely required (as in, there is no other way to do it) I'd disable access to everything. It sounds like you'd need http, and ssh but everything else should have a workaround if you in fact need it. (i.e. mysql can be accessed via command line after sshing into machine. If you need anything more you can use SSH port forwarding. etc.)

Other considerations:

  • I don't know about subversion, but GIT (distributed source control) uses SSH.
  • There are a number of ways of using more secure file transfer as opposed to ftp.
  • Based on studies, it is virtually guaranteed that the Windows machine is compromised so never fully trust either machine or user.
  • If you have the hardware resources (eg enough CPU and RAM, use virtual machines to further partition services (and then run SELinux on those hosts).
  • The NSA guide recommends firewall modifications that lock down ports. Other options are role your own (i.e. based on the masquerading guide at the Linux Documentation Project).

If there is ever any question of physical security of the system or the drives, consider using the easy to use LUKS encryption option during the install. Then there's backup security. Enjoy the journey.

Eric Chowanski

share|improve this answer

Consider using a hardening tool such as Bastille. CentOS is essentially a rebranded RedHat, and as such binary compatible, so for the most part any instructions for the same version number of RHEL should work for CentOS.

Another good CentOS specific resource is the OS Protection wiki page.

The most in depth analysis would be to follow the CIS benchmark.

share|improve this answer
Wow. Excellent resource! I'm downloading the pdf from CIS now. – user18939 Aug 31 '09 at 17:52

Your Answer


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