--On Monday, January 28, 2008 11:59:01 -0500 Jeff Plewes <plewes (at) gmail (dot) com [email concealed]>
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 (at) utdallas (dot) edu [email concealed])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
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 (at) utdallas (dot) edu [email concealed])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
[ reply ]