Subj : Apache 1.3.22 up but? To : Mark Lewis From : Mike Luther Date : Thu Nov 01 2001 03:00 am Thanks, Mark ... ml> welcome to the world of the NIMDA worm attempting to infect your server <> there are a few tricks to handle this... ml> however, the standard 404 page is ok, too... unless ml> you can block on ip packet contents, this'll be with ml> us for a while... I have a worse introduction than this, though. Port 137/138 to Port 139 versions of this Nimda.# worm *CAN* get to an OS/2 TCPBUIE box. That's another on-going research project I've not had time to finish yet as to whether or not there really is a hole on OS/2 NETBIOS. Too much to do yet to set up the test pair of computers across my IP to do the work, groan. But I've already had two infestations of all the files on one box until I too out Port 80 with IJFIRE until I could do something more specific. Well, I think IJFIRE's ruleset can be used to block on packet contents. Thus I supposed, but haven't been down this pig trail, that one has to write the rulebase for each such thingy, down to the point where there is a common string content for that. In this case, what I think you are saying is that I have to think out writing the 'rule' for it. I have to either ue the .CFG rulebase or filter based on the packet content for what would be an INSTR or similar sort of mid character array. That could be on the: 208.180.221.87 - - [26/Oct/2001:20:15:43 +0000] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 280 208.180.221.87 - - [26/Oct/2001:20:15:44 +0000] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 278 -----> GET/MSADC/root.exe?/ right? Since I don't have such, it's common to those two hits, IJFIRE is told to simply drop them, right? I at first thought that it would be a simple matter to block it on the basis of packet type. But now that I look at how it is done, I think I've learned that won't work. Hold this thought for a moment for log comments below. ml> i'd be firing off reports to cos letting them know the address and what ml> its doing... it should be up to them to determine who ml> has that connection and notify them (as well as ml> knocking them off the net until they get their stuff ml> cleaned up and patched properly)... You can do that by filing the logs with abuse@cox-internet.com as I actually did for the two sites that did get in using a twisted Port 137/138 morphed ot Port 139 game somehow. ml> i let injoy start and stop my apache server when it connects and when i ml> specifically click on the hangup button... other than ml> that, if i have to get off the net, i simply unplug ml> the phone line and stop injoy from dialing out... i ml> use a script to determine if my apache is already up ml> and if it is not, i start it... i also do this with my ml> "DDNS" updater program... Well, from the SYS3175's that Apache 1.3.22 throws, apparently when the Desktop trys to rebuild itself on a botched shutdown, I think what you really need to do might be to force a graceful shutdown before the thing is loaded each time! You would modify the normal startup to do that. The SHUTDOWN.CMD which is really a REXX script is: /* Rexx script to shut down Apache */ pid = linein("logs\httpd.pid") 'kill.exe -TERM 'pid It can be run over and over again if it isn't running with no abend. Thus whay can't you just use that prior to each load and when the desktop goes to autorebuild, it gets properly terminated? If you use an error trap routine in REXX unless you get a null return for the loader line it just rolls aroun to the script start until the IP comes back clean? I'm cable hosted. I can't just yank the phone line if I'M not here and something goes bad wrong that someone else can only fix by pushing the reset box on a locked box! --> Sleep well; OS/2's still awake! ;) Mike @ 1:117/3001 --- Maximus/2 3.01 * Origin: Ziplog Public Port (1:117/3001) .