Subj : Apache 1.3.22 up but?
To   : Mike Luther
From : mark lewis
Date : Fri Nov 02 2001 10:08 am

ml>> welcome to the world of the NIMDA worm attempting
ml>> to infect your server <<GG>>  there are a few
ml>> tricks to handle this... however, the standard 404
ml>> page is ok, too... unless you can block on ip
ml>> packet contents, this'll be with us for a while...

ML> I have a worse introduction than this, though.  Port 137/138
ML> to Port 139 versions of this Nimda.# worm *CAN* get to an OS/2
ML> TCPBUIE box.

those ports are normal netbeui/netbios over tcp/ip stuff, AFAIK... i don't know
what is used in a non-tcp/ip configuration for netbeui/netbios...

ML> That's another on-going research project I've
ML> not had time to finish yet as to whether or not there really
ML> is a hole on OS/2 NETBIOS.  Too much to do yet to set up the
ML> test pair of computers across my IP to do the work, groan. But
ML> I've already had two infestations of all the files on one box
ML> until I too out Port 80 with IJFIRE until I could do something
ML> more specific.

uuuggghhh... and here i sit behind injoy v2.0b with nothing else between that
box and the net... have that apache/2 1.3.22 server running and a couple of
aliasmatch statements in httpd.conf to at least send something i want to send
back... in fact, my stuff has a bit more output than many because i fully
expect that some stuff may be being sent manually by a person attempting to
hack in themselves...

here's those aliasmatch statements...

# these are to "stop" stupid attempts to use windows expolits on us
AliasMatch (.*)\cmd.exe "z:/apache/htdocs/idiots/index.html"
AliasMatch (.*)\root.exe "z:/apache/htdocs/idiots/index.html"
AliasMatch (.*)\admin.dll "z:/apache/htdocs/idiots/index.html"
AliasMatch (.*)\default.ida "z:/apache/htdocs/idiots/index.html"

i have these within the <IfModule mod_alias.c> container so that they are only
loaded if the mod_alias module is loaded...

you might also find this one useful...

# Those of you who have seen the "file not found" /favicon.ico
# (for example) in your Apache error logs should listen here.
# All you have to do is add this line to your httpd.conf.
# I hate Microsoft IE 5. The supplied regular expression is
# matched against the URL, and if it matches, the server will
# substitute any parenthesized matches into the given string
# and use it as a filename. That will teach them.

RedirectMatch (.*).ico$ http://www.microsoft.com$1.ico

# That one liner above will redirect all ".ico" request from
# your server to the Microsoft server. Now you'll be letting
# their damm server deal with the errors and bandwidth. It
# will NOT interupt your traffic at all! If MS is going to
# request files from your server, it's only appropriate that
# they deal with the problems they cause...

ML> Well, I think IJFIRE's ruleset can be used to block on packet
ML> contents. Thus I supposed, but haven't been down this pig
ML> trail, that one has to write the rulebase for each such
ML> thingy, down to the point where there is a common string
ML> content for that.  In this case, what I think you are saying
ML> is that I have to think out writing the 'rule' for it.  I have
ML> to either ue the .CFG rulebase or filter based on the packet
ML> content for what would be an INSTR or similar sort of mid
ML> character array.  That could be on the:

ML>   208.180.221.87 - - [26/Oct/2001:20:15:43 +0000] "GET
ML>    /scripts/root.exe?/c+dir HTTP/1.0" 404 280
ML>   208.180.221.87 - - [26/Oct/2001:20:15:44 +0000] "GET
ML>    /MSADC/root.exe?/c+dir
ML>    HTTP/1.0" 404 278

ML>          ----->  GET/MSADC/root.exe?/

ML> right?

yes, pretty much... i think i'd trap on "/path/root.exe" and each of the
others... in otherwords, just shorten it enough to get just that stuff without
having to parse too much... it really should be enough to let apache handle it
but it is possible that one may see 1000+ hits per second from NIMDAs all over
the first two ip octets you're in...

ML> Since I don't have such, it's common to those two
ML> hits, IJFIRE is told to simply drop them, right?

yes, that should work... hopefully ijfire won't get bogged down trying to
handle the possible high numbers of hits or even get taken out, itself...

ML> I at first thought that it would be a simple matter to block
ML> it on the basis of packet type.  But now that I look at how
ML> it is done, I think I've learned that won't work.  Hold this
ML> thought for a moment for log comments below.

'k...

ml>> i'd be firing off reports to cos letting them know
ml>> the address and what its doing... it should be up
ml>> to them to determine who has that connection and
ml>> notify them (as well as knocking them off the net
ml>> until they get their stuff cleaned up and patched
ml>> properly)...

ML> You can do that by filing the logs with [email protected]
ML> as I actually did for the two sites that did get in using a
ML> twisted Port 137/138 morphed ot Port 139 game somehow.

ok... i'll add that address to my abuse addresses list... don't know that i'll
need it unless i get hit from there during one/some of the random ip number
generation attacks that nimda uses... in many cases, i've been able to hop over
to one of the windows boxes, here, and smack that attacking machine right off
the entire network... it's quite easy when you can use the windows sdk (i
think) shutdown.exe program(s) and tell it to shutdown \\ipnumber\ipc$ (or
whatever its called)... i've even had some luck in placing patches and such on
those machines along with a text file in the startup folder that tells them
when they turn the machine back on why it went down, where to locate the placed
patches and how to do it... even going so far as to specifically tell them they
HAVE to unplug the network wire during the process so that they're not
attacking or being attacked during the patching process... in a few cases, i've
even called them on the phone and talked to them directly telling them who i
was, what i was doing, and why... you should hear some of their comments when i
tell them certain steps (like placing a file in a certain place and they see it
pop into existance via drag and drop from my desktop! or when i send the
shutdown command) that i'm doing... there are times that i really wish that i
could see and capture their facial expressions...

ml>> i let injoy start and stop my apache server when it
ml>> connects and when i specifically click on the hangup
ml>> button... other than that, if i have to get off the
ml>> net, i simply unplug the phone line and stop injoy
ml>> from dialing out... i use a script to determine if my
ml>> apache is already up and if it is not, i start it...
ml>> i also do this with my "DDNS" updater program...

ML> Well, from the SYS3175's that Apache 1.3.22 throws, apparently
ML> when the Desktop trys to rebuild itself on a botched shutdown,
ML> I think what you really need to do might be to force a
ML> graceful shutdown before the thing is loaded each time!

that may very well be... i dunno... my system has gone down the hard way when
the UPS batteries have run out of power but i've never had this problem because
injoy hasn't dialed out and connected until after the stuff has been rebuilt or
whatever... i guess it may also help that that box runs quite a few tasks all
the time... from a clean boot, CTRL-ESC shows twenty-three (23) tasks running
and those are running all the time as that machine's server ops that i employ
here...

[trim]

ML> I'm cable hosted.  I can't just yank the phone line if
ML> I'M not here and something goes bad wrong that someone
ML> else can only fix by pushing the reset box on a locked
ML> box!

uuugh... that does toss in a bit of a sticky wicket, eh? hummm... maybe you can
run some sort of monitor that checks that tcp/ip is up and operational before
apache is launched... you don't think it could be an EMX thing failing, do you?
what level are you at with EMX and are you using the runtime only or the
development??

)\/(ark


* Origin: (1:3634/12)