It seems unlikely that an automated process was scanning on port 23/tcp for anything that would use the SSL libraries which had these problems. As far as I know, no self-spawning trojan was ever created that would even check port 22 - only port 443 would be affected at least by the slapper worms I know of, since they relied 100% on an SSL-enabled web server. I don't believe they infected via SSH on any port automatically, though it could be theoretically possible (the first advisory bulletins I saw regarding the SSL problem were for SSH actually, the slapper worm was an afterthought that went after web servers, not SSH servers). It seems like you've done a lot right, and very little if anything wrong, but there may be some more checking left to do. A good place to start is a full audit of anything affecting init (ie /etc/rc?.d, /etc/init.d, your init configurations like inittab, etc), a ps listing audit, and running some MD5 checksums against your system binaries against a clean and 100% secure machine if possible. An audit on /tmp sounds like it wouldn't hurt, either. :-) Stephen Smoogen wrote: > > Its a bit late in the game, but you may have a backdoor (or various > backdoors) running on the system. My advice is to do the following (with > the assumption you only have 1 machine available to run the website). > [Sorry if it is a bit general, but its from a list I hand out to > completely new sysadmins working on compromised machines.] > > A) Take the system off the network (letting management know why) > B) Backup the system to completely to tape in case you need to present a > report to law enforcement or management (why I need to be paid > more or sent to that SANS training. :)) > C) Go over what you need on this machine still (IE what code etc is > running on it for webservices that may need to be audited to see if a > back door was planted there.) > D) Reinstall the machine from source cdroms and then put all updates for > that operating system on the machine. > E) If your Linux vendor has an automated system of alerts or updates see > if you can sign up for it or get your employeer to pay > for it. > F) Reinstall the software that you need for the website to be > operational and test it for working. > G) Put the machine back on the network and test functionality again > H) Go over all that was discovered and write up a short report for your > CYA file and to hand over to management over what happened, why, and > what needs to be done in the future. > > If you have multiple hardware and more than 1 staff you can parallelize > portions of C, D, E, and F. H sounds like a nuisance, but it can save > your job or worse. > > On Wed, 2002-10-23 at 13:42, Griff Palmer wrote: > > Hello: > > > > I'm trying to learn more about how the Apache/mod_ssl worm variants operate. > > > > Last month chkrootkit discovered evidence of the Slapper worm on my RedHat > > 7.2 server. I found .bugtraq.c in my /tmp directory and eliminated it. I > > updated my openssl to 0.9.6g-1. I blocked port 443 on my firewall. > > > > I keep my ftp daemon stopped except for occasional short periods when I need > > to use it. I've been leaving port 23 open and making my ssh host listen on > > port 23. (My employer's firewall blocks traffic on port 22, forcing me to go > > to the port 23 setup.) > > > > Regular scans with chkrootkit since then have shown no signs of the slapper > > worm's presence. > > > > This morning I received an e-mail bounce from cinik_wormat_private > > (apparently Yahoo has disabled that address). A search on cinik led me to the > > latest CERT bulletin, which showed information about the slapper B and C > > variants. > > > > After reading the bulletin I discovered the presence of cinik.c and cinik.go > > in my /tmp directory, which I eliminated. > > > > I also discovered an active .bugtraq process on my machine and killed it. > > > > I've blocked UDP packets on ports 1812 and 1813. (Looking at the CERT > > bulletin it looks as if I should also block 1978, 2002 and 4156.) I've > > commented out the listen 443 line in my httpd.conf file. > > > > At this point I'm confused about the mechanics of the infection process and > > about what further steps I may need to take to fully eliminate infection and > > harden my server. > > > > Is Port 23 an avenue of infection? Does upgrading to openssl-0.9.6g-1 not > > eliminate vulnerability to compromise? Is it possible that I missed the > > C-variant code when I discovered the .bugtraq code, and that the C variant > > code has lingered on my machine since then? I'm using chkrootkit-0.37. Is it > > able to detect the B and C variants as well as A variants? > > > > I've run ps on my machine many times since chkrootkit discovered the Slapper > > A variant. Those checks showed no presence of the .bugtraq process. (I even > > downloaded and installed new system binaries in case any of those had been > > subverted.) > > > > The .bugtraq process showed up after I upgraded my kernel this morning. Is it > > possible that my earlier kernel had been compromised and that the .bugtraq > > process was being hidden? > > > > Any advice appreciated. > > > > Griff Palmer > > > > ---------------------------------------------------------------------------- > > This list is provided by the SecurityFocus ARIS analyzer service. > > For more information on this free incident handling, management > > and tracking system please see: http://aris.securityfocus.com > > > -- > Stephen John Smoogen smoogenat_private > Los Alamos National Labrador CCN-2 B-Schedule PH: > Ta-03 SM-261 MailStop P208 DP 17U Los Alamos, NM 87545 > > ---------------------------------------------------------------------------- > This list is provided by the SecurityFocus ARIS analyzer service. > For more information on this free incident handling, management > and tracking system please see: http://aris.securityfocus.com -- /* * * Matt Harris - Senior UNIX Systems Engineer * Smithsonian Institution, OCIO * */ ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Thu Oct 24 2002 - 17:37:03 PDT