SFTP is an option but would require some customer communication.. will
keep in mind for the future..
No customers have ssh access. ftpusers are driven by database.. (proftpd)
cisco pix firewall limits the ports available.. other ports (xinetd
etc) are open but not permitted from public internet. (as you
mentioned another box on the segment could "leap-frog" the exploit..
so this could be it.)
Our next step is to snort box the traffic on that segment.
-Jeff
On Jan 28, 2008 2:24 PM, Paul Schmehl <pauls@utdallas.edu> wrote:
--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/
