Re: security advice

[debiantech <debiantech () gmail com>]

 Hi,

Although not the only way this can happen, I am willing to bet this 
machine is not only an email server but a public web server. Not only 
this but a guess is you are running some sort of CMS/CRM on that 
webserver that uses PHP, possibly a web based email interface. If I have 
been right so far, my first suggestion is to go to the home page for the 
software and compare the version you have to the current stable version 
and read the changelog which might help you understand your 
vulnerability. Check the security lists for known vulnerabilities as 
well. From experience this type of job is usually done using a remote 
file include (RFI) somewhere meaning they fooled something in your PHP 
scripts into including a remote file from one of their web servers which 
then gave them an interface to upload the junk to a world writable 
directory and fire it up. There are typically only three common world 
writable directories these types of attacks use. /tmp, /var/tmp, and 
/dev/shm. Look in these directories because more often than not you will 
find remnants of other attempts successful and not. Usually these little 
toys also delete logs their actions may land in but to be safe you may 
want to check your logs. A good one for the apache logs is to search for 
.txt . Usually the file they include is a .txt file. This would not be 
in an apache error log as the page loaded successfully for them and 
returned 200. For good measure I check all logs.

If things are ringing a bell here for you then my first suggestion is to 
adjust the php.ini configuration to NOT allow remote includes of any 
kind. After that update all of your pre-built web based systems. It's 
advisable to reinstall and start fresh as well since you are unsure 
exactly what was done on your machine, personally I would get a new hard 
drive and keep the old for my own analysis at the very least. Depending 
on the password policy for users you may want them to change especially 
if folks use dictionary words for the password. You may also want to 
look into implementing AIDE or something similar for file monitoring as 
well as ensuring you do at least daily checks with things such as 
rkhunter, logwatch, logcheck, and any other setups of this type. 
Remember a happy server is one being watched as closely as possible.

If I hit the nail on the head then I have a simple shell script (I call 
it Bookem) I use to detect just this sort of hack job. It checks for 
files in world writable directories, tests apache processes (before you 
shut the stuff down :{) and other tell tale signs and drops the results 
to a text file. This way I can run a fast initial analysis and then shut 
them down quickly if it comes back positive. My guess is if you would 
have left the stuff running, Bookem would have found an Apache process 
with an open connection to some remote IRC server (recently they have 
usually been in Brazil) running on a non-irc port.

If all of this comes true then you can celebrate with your server on 
it's first trip on a botnet.

I hope this helps

On 8/24/2010 3:17 AM, Edmund wrote:
> Hi,
>
> Just yesterday, I found out that my company's e-mail server had been
> compromised.  This fact, for some reasons, didn't seem to be a 'big
> deal' to others.  I'm still stunned; but, considering how lax I had
> become, it shouldn't be surprising.  *sigh*
>
> [story mode]
> Basically, the incident started out with an innocuous "there is
> something wrong with sending e-mail" from a co-worker.  I looked
> at the e-mail server and everything seemed to be ok, so I decided
> to check the firewall.  That's when I noticed it was running
> very sluggish.  "Uh oh."
>
> I couldn't figure out which program was making it go slow.  I
> thought it was the proxy, but it wasn't.  I rebooted the
> firewall.  It was ok, up until a certain point and that's
> when it slowed down.  I tcpdump'd one ethernet nic, and
> noticed a huge amount of packets being sent to a remote
> site from my e-mail server.  (Capital UH OH)
>
> Checking out the |ps ax| I noticed a very suspicious
> file "./s<ip#>".  Immediately I knew someone had
> accessed the system.  I started to become a little
> panicky.  I searched for the './s' file.  Then looking
> up online, I found that I could go into the /proc
> filesystem and find the pid and then the exe will
> be shown.  Found the full path.  Looking at the
> files within the folder "/var/tmp/.b", it was
> confirmed.
>
> I shouldn't have done what I did next.  I killed
> the running program and deleted the folder.  :(
> In hindsight, I should have killed the program
> and zipped up the darn folder for analysis.
> I'm still regretting that move.  *banging head
> on table*
>
> Cleaned up a few extra items and it seems normal.
> I ran 'rkhunter' and filled out the necessary
> warnings it found.
>
> [story mode off]
>
> I'm still very reprimanding myself for being
> so careless. This is one lesson that I gotta
> have imprinted in my thick skull.
>
> Anyway, given this lesson,  can someone offer
> any methodologies/programs that I can use to
> protect the company system?   I'm now going
> through the firewall rules to find out what
> holes the intruder might have entered through.
>
> Thanks.
>
> Ed
>
> ------------------------------------------------------------------------
> Securing Apache Web Server with thawte Digital Certificate
> In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
> it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
> install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
> highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.
>
> http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
> ------------------------------------------------------------------------


------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------