Subj : Apache 1.3.22 up but?
To   : Mark Lewis
From : Mike Luther
Date : Fri Nov 02 2001 01:25 pm

More learning from Mark!  Thank you so much for sharing...

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.

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

Nor I.

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

Interesting.

ml> here's those aliasmatch statements...

Snipped for bandwidth but put into the keep and learn how to do this!

ml> you might also find this one useful...

Ditto.

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

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

Mmm . Mint Cookies, saved in notebook!  Gee how little I know,  And I never
really wanted to .. oh well.  Such is life! ;)

ML> right?

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

I think I know enough to begin writing here...  Trying to triage all this into
what is most proactical (I'll leave you to figure out about four terrible pun
relationships in that coineed word!) at this point!

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

I've read into that this can happen but hav no information on what the chances
are based on this level of attack rates.

ml> ok... i'll add that address to my abuse addresses list... don't know
ml> that i'll need it unless i get hit from there during
ml> one/some of the random ip number generation attacks
ml> that nimda uses... in many cases, i've been able to
ml> hop over to one of the windows boxes, here, and smack
ml> that attacking machine right off the entire network...

How delicate!

ml> it's quite easy when you can use the windows sdk (i
ml> think) shutdown.exe program(s) and tell it to shutdown
ml> \\ipnumber\ipc$ (or whatever its called)... i've even
ml> had some luck in placing patches and such on those
ml> machines along with a text file in the startup folder
ml> that tells them when they turn the machine back on why
ml> it went down, where to locate the placed patches and
ml> how to do it... even going so far as to specifically
ml> tell them they HAVE to unplug the network wire during
ml> the process so that they're not attacking or being attacked during the
ml> patching process... in a few cases, i've even called
ml> them on the phone and talked to them directly telling
ml> them who i was, what i was doing, and why... you
ml> should hear some of their comments when i tell them
ml> certain steps (like placing a file in a certain place
ml> and they see it pop into existance via drag and drop
ml> from my desktop! or when i send the shutdown command)
ml> that i'm doing... there are times that i really wish
ml> that i could see and capture their facial
ml> expressions...

Sorry for my twisted humor personality, but you remember back when I think it
was Jack Lemmon played the Devil, had turned this poor soul into a parrot?  He
didn't like it's looks, so he wrenched the beak around qrotesquely, looked at
it with a tilted head like a parrot does, and then commented out of the side of
his mouth, "Definitely Piccasso!"  ;)


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> that may very well be... i dunno... my system has gone down the hard way
ml> when the UPS batteries have run out of power but i've
ml> never had this problem because injoy hasn't dialed out
ml> and connected until after the stuff has been rebuilt

I can reason this load-linee out mentally..

ml> or whatever... i guess it may also help that that box
ml> runs quite a few tasks all the time... from a clean
ml> boot, CTRL-ESC shows twenty-three (23) tasks running
ml> and those are running all the time as that machine's
ml> server ops that i employ here...

But in this case, we're dealing with a problem, I think, at core level in the
Kernel that sneaked in here at W40508 level.  It wasn't there for the original
level of FP 15.  Showed up when I upgraded the Kernel only.  I didn't get it
caught in time and figured out to report it in Testcase officially.  In the
couple of months it took me isolate a trap like this that doesn't even trap the
box and leaves no way to trace it, things went far forward from W40508.  Plus,
who in heck wants to work with the Adaptec 1542C level cards which is the only
place I see it?   As well, I'm not at all sure the Kernel is really even the
cause, as I've sorta now pinned it on the SYSTEM checking CANARY deal from
Norman in conjunction with this.

To date Norman hasn't even answered the support help request... ;(

But with the /bs- option in the command line loads I use, and full semaphore
and hand flag files created for SCANBLDP to keep more than one task at a time
from hitting the same messaage area, the lock seems gone.

ML> I'm cable hosted.   ....

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

I'm at current level 4.09 as I recall.  It reports, I think, 61 in the version
dump screen.  I'm also using the full development game, but really don't need
that for this box.  It's just easier to set up and dump in a common format for
stuff like this everywhere than do this on one box and that on another.

Thanks,

This one showed up directly here on OS2INET by the way.

--> Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)