Dear Salasi,
Bastile looks a good tool but is not being supported for centos. I also do run mysql server so what is your hardening tips for it.

A couple of things for mysql:

1) Never, ever, ever expose it directly to the internet.
2) All the users that the web programs like phpMyAdmin have should have VERY limited permissions. Basically they should only be able to read and write to the individual database they need. Do not EVER give GRANT privileges to these users.
3) Lock down user access. If the mysql is running on the same machine as Apache, all the mysql users should only have localhost access. If they are on different machines, the allowed IP addresses should be limited to the Apache machine.
4) If possible, run mysql connections over unix sockets, not TCP/IP
5) Make sure MySQL itself is dropping down to an unprivileged user after starting and that user doesn't really have access to anything.

And lastly, the hardest part is trying to make sure that any web programs sanitize their user input before sending it to MySQL. Most reputable programs will do this, but if you have people writing their own, they may not be.

Dear Hangdong,

1)How to not expose it to the internet if I am using phpMyAdmin with .htaccess is that safe?
2)I sometimes need to log in as root for adding table and other management task is phpMyAdmin with .htaccess safe enough?
3)Yes I have limited the users based on their local ips.
4)How to set unix sockets?
5)How ensure this unprivileged any settings?

How to sanatize? Any tips on it ? Normally I take the post value and start working on it? How normally can they hack via the sql injection?

r

Please understand I'm not trying to be offensive here, but this question is actually kind of disturbing. Lets start with that the .htaccess file is absolutely NOT the way to secure MySQL. Beyond that you need to do some serious homework on how applications like phpMyAdmin work with a database.

As long as it is you and nobody else has the MySQL root password, you're probably safe. Unless phpMyAdmin has been compromised. If your users need to add tables, you can usually configure their non-privileged users to be able to do that within their own database, and nowhere else. And again, .htaccess is the wrong way to secure MySQL.
Based on the previous questions, I have the strong suspicion we're not talking about the same thing here. I'm talking about the MySQL users, and those are going to be residing on the same machine as the Apache. So if Apache is running on a different machine, THAT is the IP address that MySQL users should be restricted to.

Neither of these is hard, but it indicates you need to spend some time reading MySQL documentation. I'll give you some places to get started, but most of this is just a google away:

http://dev.mysql.com/doc/refman/5.0/en/security.html
https://dev.mysql.com/doc/refman/5.0...st-attack.html
http://dev.mysql.com/doc/refman/5.0/...rivileges.html

I'll give you a link to get started (http://stackoverflow.com/questions/1...input-with-php) but do realize this is a VERY large topic.

Dear Hangdong,
Sorry for the disturbing question. Thank you for all your links. Looks this is a process and not able to be done over a nite. I will take some time to read those link and slowly apply it. I have created limited users with limited access that is already in place now.

Technically, that is correct, but it does claim to be compatible with Red Hat, and, plus or minus some trademarks (and, maybe, more relevantly, how the OS identifies itself). So it is probable that the version for the appropriate RH version on which your version of Centos is based will run, you just might have to apply some intelligence if it starts spitting out error messages about wrong kernel idents, or something, because that would probably just be an artefact of the Centos vs RH branding and kernel version identifying.

There was a message about Bastille starting up again - after a previous last message in their news log about a Sept 2007 (!) most recent change, there is another about a new beginning in Jan 2012, so perhaps the 'no current development' bit will turn out false, I don't know. So, I'd guess that 'something else' (GNU Tiger?) is probably still the better answer, that might change if there is a new Bastille release.

And, a more general warning about hardening scripts - while it sounds counter-intuitive, hardening scripts can be a bad thing, if you just use them in order not to think about security.

Yeah, they get you to do some stuff that you ought to do, they act as an instant prompt and a guide to get things done, all of which are positive, but that can become less positive if it means that you think that all of security can be covered by some canned script. You have to know what your script does, and, more particularly, what it doesn't do, because what it doesn't do you still have to take care of fully manually. If you think of a script as a quick way to get 80% of the stuff done, or a check whether you have remembered the basics, they are good, but if you think that they are everything, then you'll get caught eventually.

Dear Salasi,
It will be gui based right? I think that will be a problem on my side as my server is sitting remotely. Besides that whatever links given by handong I will take time to digest and working on them. As you said security is a process so I could not do it over one nite it will take time.

You are asking about Bastille, rather than GNU Tiger, right? As far as I remember, Bastille is just a collection of scripts and has nothing graphical about it, so that shouldn't be a problem.

I'm now going to indulge in a bit of further thread drift, if I may. We haven't mentioned securing ssh yet, have we? You shouldn't assume that ssh is necessarily secure until you have done a bit of work on it. (fail2ban does actually help, here!) Samhain has a good page on the options, and there plenty of ways of skinning this particular cat, but I did want to mention that the default isn't safe, which seems to come as a surprise to some people.

Dear Salasi,
Yes the first level of defence I have done is implementing the key based method for login rather then the normal one. So what extra should I be done next and in your last link it talks about sshd with fail2ban too? Should I impelement that too?

If you've moved to key-based logins, then ssh is reasonably secure (as long as the keys are under control). You could implement fail2ban, but that would mostly serve to keep a lot of junk out of your log files, it isn't going to provide any security over what the keys already do.

Dear Handog,
In addition to ssh keys what else do you suggest to harden up the server off course I am still digesting things on the php and apache. Anything of your mind any tools which will be helpful such AIDE etc. Thank you.

Well, I'd suggest you look into using SELinux, which should be part of CentOS. It is a fairly big topic, but it is there for a reason. The CentOS howto might be a good starting point.

You also might want to read some of Unspawn's advice in this thread. It is about Ubuntu, but much of the advice is distro agnostic.