Re: DNS CACHE POISONING? - Our Portal is redirecting to our first competition

[Paul Schmehl <pauls () utdallas edu>]

--On Monday, January 28, 2008 11:59:01 -0500 Jeff Plewes <plewes () gmail com> 
wrote:

> Update,
>
> The problem box:
> - centos 5 base, updated via yum from default repository.
> - httpd 2.2.3-11.el5_1.centos.3 (2.2.8 backport?)
> - php 5.2.5 compiled from source
> - courier-authlib 0.60.2 compiled from source
> - courier-imap-4.3.0 compiled from source
> - exim 4.69 compiled from source
> - proftpd 1.3.1 compiled from source
>
> I have no control panel of any sort installed.
>
> The box was running RH9.. had the issue.. formatted and replaced with
> fresh install of centos 5... copied over customer vhosts..
>
> Gets hit again within days.
>
> ports open = 20,21,22,25,80,110,143,443 + pasv port range for ftp

This is probably unrelated to your problem, but is there some reason you can't 
run sftp instead of ftp?  You'd eliminate one daemon and make all file 
transfers secure.  Customers using Windows can download WinSCP for free and use 
it just like an unsecure ftp client.  If they're using CMS programs to manage 
their websites, *most* (if not all) of those should allow the use of sftp.

> I have many other hosts in the datacenter with various configurations
> but all would have had the same apache, php, ssh, ssl versions as this
> box before at RH9. None of them have been hit.. none of them however,
> contain exim, courier, or proftpd
>
> Im starting to lean towards these packages as a possible entry-point
> for the trojan?

Possibly, but do you allow root logins through ssh?  Are any of your customers 
using easily guessed passwords that would allow entry followed by a local 
privilege escalation?  (That opens a whole other can of worms.)  Are you sure 
you don't have initd (or xinitd) listening?  What about syslogd?  Are you sure 
you don't have some other box that's compromised and being used to hack 
internally?

There's a lot of variables to consider.  Perhaps bring up a snort box and watch 
for that one server's traffic?  Do you have any idea of the timeframe of this 
most recent breakin?  Anything in the logs around that time that looks at all 
suspicious?

--
Paul Schmehl (pauls () utdallas edu)
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/