How can I check my server's security ?
 

Hi,

I have just installed CentOS 5.4 and has the following details:

running Apache 2 as web server
named is running
ftp service is disabled
iptables has been configured and turned on
ping is allowed
SSH port has been changed
mysql is running

How can I test is my server safe or not ?
Any tools should be good to use for testing purpose ?
How can I test is my Apache setting safe or not ?
How can I really test how difficult to attack my server ?

Any advice ? :hattip:

you might check into nessus. read up on it here.

i do believe that nmap is in the cent repo

http://nmap.org/
http://www.insecure.org/

I can't really think of a 'just add water and get security' solution; maybe someone else can come up with one.

The rest of us can currently do nothing to tell how well you have done this; firewalls are good, but a badly configured one probably makes things worse by giving you an excessive feeling of being protected.

If that is all you have done for ssh, it has probably given you an extra 30 seconds or a minute of time delay in a crack attack. I suppose it might clean up your log files a little, but that's not security.

If someone can fingerprint your server and detect the new ssh port, it doesn't help much. If it is combined with fingerprint suppression and/or passwordless ssh or whitelisting ssh sources, or port knocking it could easily be every bit as good as you need (until the bad guys get more sophisticated).

You need strong passwords. One way that you can test them is something like John the Ripper (and if you do choose to use something like a password checking solution, don't install it and leave it or any output that it gives; it could prove a useful weapon for a bad guy). If you are the only one who has administrative access, you only have to ensure that you only ever set good passwords and testing is unnecessary. Although, I do have to comment that some people's idea of what constitutes a strong password is inadequate.

Someone needs to check log files; everyone knows it is a good idea, but not everyone does it. You don't want to find out that someone has spent the last six months, on and off, trying to break in. That's probably long enough for them to succeed.

You should double check that nothing is listening on ports that you didn't know about when you came up with your iptables ruleset.

Check all that your software is up-to-date and keep it that way.

I think I've probably sailed closer to the wind than is desirable to help, but there are some things that you ought to search on.

First of all, and in addition to advice offered already, you should install the latest release of the distribution which in your case is Centos 5.5 and keep that installation up to date. Secondly you should understand that securing your server and auditing security is a continuous process. So running tools just once, expecting tools to do all the work for you and relying on any single particular tool simply is the wrong approach. What's more important is that you should understand that running tools is not a substitute for conceptual and practical knowledge. Furthermore the security posture of your machine, setting attributes and auditing events all are in essence binary: on or off, yes or no. There is no "if", "maybe" or "thinking": something is secure or not, something is vulnerable or not, integrity is maintained or not. So replies in response to a security-related question from people who just tell you "not to worry" (without them having been shown evidence or having given you things to check) you may dismiss without giving it any further thought. Finally, and related to the previous point, you should understand that what you don't know about you can't respond to. Most attacks are preceded by reconnaissance and, when configured properly, access details and errors will show up in logs. People often forget that checking logs regularly may help you adjust access controls (automagically) or avoid or contain a breach of security.


So. With the listing of software installed at hand your first port of call should be reading your distributions documentation with respect to distribution, kernel, subsystems, services and other software settings related to user management, component configuration and access controls. To see what I mean ask yourself for instance:
- if the MAC-layer RHEL / Centos provide (SE Linux) needs to be disabled?
- which software is not required for (headless?) server operation?
- if you really require this application instead of a more secure, better performing or less features having alternative?
- if you really require all these applications to run on one machine instead of spreading them out over machines for security and performance reasons?
- which system accounts need to be enabled and do they require a shell?
- which human users need accounts on the system (as opposed to virtual user accounts)?
- who has access to services and how would you check that?
- if you should bring a developed product from the development area to the production machine without sanity checks, performance tests and guarantees?
- how you would be informed of changes in the systems state, service and performance behaviour, unauthorized traffic and access?
- what you need to do to verify integrity of the file system and trust results to be unambiguous?
- what you would do if you suspect a (D)DoS?
- what you would do if you suspect a breach of security?
- how you ensure that what you backup is what you need to restore state?


Practically speaking the initial security posture of your machine starts before installing the O.S. by determining what the purpose of the machine will be (what services it should support), where in the network it will reside (behind a router or not, in a DMZ or not) and who may access services (say access restrictions on /admin paths) and in what way (behind an IDS, behind an application firewall, behind a reverse proxy, et cetera). (And if you are or will be providing services in a professional way then you should give thought to procedures like using staging machines and do contingency planning as well.) Security is about you being in and retaining control throughout the service life of the machine: from the base installation phase on access to the machine should be restricted, no services should be exposed until secured and logging should be enabled to ensure access controls function properly. When the initial installation is finished create a baseline file system backup, create a file system integrity checker baseline database, store backups off site, choose a configuration method (anything that lets you track system changes and restore versions of configuration files) and then harden the initial setup. One tool to use locally during installation phase checking is GNU/Tiger. Even with the bare minimum of configuration it can provide you with quick wins in terms of things to check. Another indispensable tool is Logwatch which summarizes system and service logs so you can investigate issues and adjust controls. (Check out the LQ FAQ: Security references post #1?) With the base installation now configured properly and hardened, your backup, update and auditing processes in place, services can be added in a way you can control and audit and providing them in a reliable and more secure way only makes sense now.


Without being able to vouch for the integrity of the system all of the time checking the web stack makes no sense. And similar to the base installation web stack components come with extensive documentation. Plus there's tons and tons of docs and checklists (CERT, SANS, CIS, PCI-DSS) out there to check your components well before running any tools. Please see the (partial) overview at LQ FAQ: Security references post #6: "Securing networked services" which covers web server, database, PHP and tools. Note tools may have different scopes and purposes ranging from single purpose network port scanners like nmap or hping2 to locally run vulnerability checkers like GNU/Tiger or LSAT to web application vulnerability scanners like w3af, webscarab, wapiti or websecurify to remotely run vulnerability checkers like Nessus or OpenVAS, Sara, Saint, to complete auditing and penetration frameworks like the Metasploit Project. But like I said before you should know what you need to test for: running tools is not a substitute for conceptual and practical knowledge.


HTH

Unspawn, The link in your post (to the Sourceforge page) looks like it has a lot of really valuable information. I had been looking for information that goes "beyond the basics". Thank You for posting that.

As the 'Apache, PHP, MySQL' link mentioned indirectly in unSpawn's post seems to have gone missing, Can I suggest this (the 'security tips' page in particular) on Apache's own site?

One word of warning about Apache security documents: many of them are a bit dated, so ensure that anything that you look at for real detail is at least solidly into this century (and mentions of Apache 1.x are a bit of a give-away, too), as some of the early stuff either won't be applicable to recent releases or won't cover more recently discovered threats.

You don't say exactly how you are using Apache, but you should also ensure that you are familiar with cross site scripting attacks.

Thanks a lot !
very useful advise ^ ^