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 <> 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 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 abuse@cox-internet.com 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) .