Neil Aggarwal wrote: > Maco: > >> i have other mandriva boxes and they all are ok. i m just so >> surprised that a centos box got compromised. > > If you are not doing anything silly in your server > configuration, this is not a CentOS issue. > > Anything *can* be hacked. It just so happens > that it was your CentOS box this time. My two cents here I'm probably stating the obvious here for many users, but ... - For web apps installed from CentOS / EPEL /etc - modify the configuration file to change apache alias directive. Look at your web logs sometime, whether or not you use apps like phpmyadmin or squirrelmail, you will see requests to where CentOS (and other distros) make those apps available by default. These requests are usually either brute force attacks against those apps or trying known (often patched if you keep yum up to date) exploits for them. By changing the alias in the configuration file, when a new exploit is found and the script kiddies launch their scripts against the web, they'll likely miss your box unless they know where to send the request to. Yes, that's security by obscurity, but security by obscurity will protect you from most script kitty attacks, and may prevent you from being owned by a close to zero day exploit. For things like squirrelmail, don't allow it over http, require it be done over https to avoid any sniffing (open networks at coffee shops or student labs or common places for sniffing). I recommend using suhosin for php - and use some of the suhosin directives that lock down the php install, such as not allowing shell execution from within php. That will break some apps (IE squirrelmail requires exec to send a message) but you can specifically enable it for certain web apps and you may be able to patch some apps to no longer need shell execution (IE I believe that squirrelmail could be patched to use php's native mail interface, maybe even easily by using phpMailer, but I've not tried). If you look in pear and pecl, you can sometimes find native ways to do what many apps currently want shell execution for - IE if you use shell execution for ImageMagick, there's a pecl binary extension you can build to do it in pure php w/o calling exec() thus allowing you turn off exec() via suhosin. Many web applications are (historically anyway) vulnerable to sql injection attacks. These attacks can be used to get password hashes that allow the attacker to crack user accounts and elevate their privileges within the web app. Many of web applications out there in common use have not been audited. SQL injection can pretty much be neutered by using prepared statements, so check your web app to see if it uses prepared statements and if it doesn't, port it to use prepared statements. I personally port them to use the pear::mdb2 abstraction layer at the same time, giving me a little more flexibility in case I ever decide I don't want to use MySQL anymore. And for user password hashes, one thing you'll find is that there are some passwords that are very commonly used, so if all you do to make your hash is some variant of md5sum($pass . $salt) and a cracker does get the hash - he just has to look for hashes that occur often and try the passwords used frequently against those accounts. md5sum($pass . strtolower($username) . $salt) or something like that results in unique hashes for two accounts even if the two accounts have identical passwords. Another problem many web applications have is they want the configuration file to be writeable by the web server - and even worse, executed by the web server as a script. I do not believe that is the case for any web apps in rhel/centos or epel, but for something you grab off the web (IE the sphyder search engine) that often is the case. Any web app that has a hole can then be used to trick apache into writing to that configuration file resulting in apache then executing the malicious code. Make damn sure those configuration files are only readable by the web server, hand edit them to make changes. If you MUST use the admin interface of those apps to change configuration, then make a database table to hold the configurations and port the app to get its configuration from the database rather than flat file that apache can write to that the web app then parses as php. Basically, audit every app out there you plan to use - the people who write these web applications often don't take security into consideration before they upload them to their server for your consumption.