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

I have been tightening up my web server security and wanted to know what else I can do.

I am running CentOS 5 with these measures: - All passwords to FTP, MySQL etc are generated from and (for the ones which cannot be too long). - Running iptables with all ports shut off except for http mail and smtp, the important ports like FTP SSH are blocked to all except my static office IP. There is also no response to pings. - Rootkit Hunter running daily - The server is PCI compliant according to Comodo - Not running any crappy made php apps, we use Zend Framework for our stuff and do have kayako installed and keep them up to date.

Can't really think of anything else I can do... I could implement a brute force measure, but I think I already have by simply changing my SSH port to a number above 10000 and blocking it off with iptables.

share|improve this question

You could turn on SELinux and make sure that everything still works. Note that SELinux doesn't like ssh anywhere other than 22 by default though.

share|improve this answer
While the packaged configs would likely get cranky over moving ssh, SELinux can be configured to know what your actual working environment is. – Scott Pack May 30 '10 at 2:52
I'm running ssh on not-22 and SELinux(in enforcing mode) doesn't mind. – Kevin M May 30 '10 at 11:57

Just because comodo says you are PCI compliant it does not mean you are really compliant. All they do is scan your ports and look for common web exploits. To be truely compliant is a much longer list of things.. Like your whole data center must be compliant and how you store credit card info.. Comodo cannot check that

share|improve this answer

It's for Debian, but should be customizable for CentOS.

Additional things you may want to do:

  1. have you secured mysql? No anonymous users, non-localhost users, or testing databases?
  2. have you secured apache?
    • with a minimal set of loaded modules?
    • locked down "/"?
    • locked down virtual hosts?
    • locked down Location?
    • minimal set of apache options/directives for each location?
    • any ssl configuration?
  3. FTP passwords are sent in clear text mode. May be better to use ftps or sftp (they are different)
  4. Is sshd_config locked down?
    • is access by ssh keys with passkey authentication?
    • is root allowed to lock in?
    • are only selected users/groups allowed to login using ssh?
    • you may want to look at single packet authentication
  5. You may want to use firehol or a good firewall generating script, rather than just iptables.
  6. Have you secured your email server?
    • only authenticated ssl/tls or startls connections
    • smtp must be authenticated with ssl/tls or startls unless sent from trusted hosts
    • have you checked if you are running an open relay mail server?
share|improve this answer

So you have an ssh server that you have running on port 10000 that you have blocked by iptables? I'm assuming you have an ssh server installed so you can enable it once in a while in order to have remote access once in a while.

You can install sshguard or denyhosts in order to secure your ssh a bit more. These tools block IP addresses if they have a certain number of failed connection attempts.

share|improve this answer

One of my favorite tools which helps provide heightened security is portsentry (with tcpwrappers). Anybody who touches a non-active port will be locked out. Portsentry is available as an RPM from official sources.

Another possibility is to use the System Event Correlator (SEC). This gives you advanced log monitoring capabilities.

If you are using PHP, I'd consider switching to Suhosin, the hardened PHP.

All in all, these are just tips: the best thing to do is go through a security checklist (or two) to make sure you didn't miss anything.

Oh, and one more thing: if you have the authority and desire to do so, you could switch to one-time passwords. CentOS provides this capability via opie.

share|improve this answer

just 2 little additions.

  1. bad php codes is a real pain. suhosin can not protect php for everthing. use phpsecurity to see what sort of wholes in your php installation. here it will give you detailed explanation for each prevention config.

  2. is fail2ban for automated blocks for abusers & forcers. it will protect many services on your server ssh, ftp, http, smtp etc. better than denyhosts and with less source usage than portsentry & much more effective.

another option is removing execute permission of anything in /tmp. in fact creating a new partition for /tmp & mounting it without execute permission is a perfect idea. if you can handle that already working a production server.

and a few reminders. it's so easy to understand which port is sshd running on, because of it's banner (contains SSH word). you can test it via "nmap". at this point it's meanless to change ssh port. & remove all sort of version information on banners, welcome messages, server signatures anywhere else just remove. because exploiters are also checks for software versions.

share|improve this answer

Your Answer


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