Subj : Apache 1.3.22 up but?
To : Mark Lewis
From : Mike Luther
Date : Thu Nov 01 2001 02:00 am
Thanks, Mark ...
ml> welcome to the world of the NIMDA worm attempting to infect your server
<<GG>> 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
[email protected] 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)
