[CentOS] Centos 5.3 -> Apache - Under Attack ? Oh hell....
Michael A. Peters
mpeters at mac.com
Wed Jun 3 15:21:56 UTC 2009
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.
More information about the CentOS
mailing list