Sleep well; OS/2's still awake! ;)
Instantly .. about a quarter of a meg a day even on this DHCP
address of logs similar to:
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
Of course all the 208.180.###.### are coming from my COX IP's
dominion! But gee, maybe I ought to let them suffer instead
of asking IJFIRE to dump dis and dat and having to constantly
re-write the dump matrix stuff?
Equally important from an OS2INET standpoint, just what
methodology does one use with our available OS/2 tools for net connectivity to keep a joint BBS and INET server presence up
mission critical style?
welcome to the world of the NIMDA worm attempting to infect your server<<GG>> there are a few tricks to handle this...
however, the standard 404 page is ok, too... unless
you can block on ip packet contents, this'll be with
us for a while...
i'd be firing off reports to cos letting them know the address and what its doing... it should be up to them to determine who
has that connection and notify them (as well as
knocking them off the net until they get their stuff
cleaned up and patched properly)...
i let injoy start and stop my apache server when it connects and when i specifically click on the hangup button... other than
that, if i have to get off the net, i simply unplug
the phone line and stop injoy from dialing out... i
use a script to determine if my apache is already up
and if it is not, i start it... i also do this with my
"DDNS" updater program...
Sleep well; OS/2's still awake! ;)
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.
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...
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...
you might also find this one useful...
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...
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...
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...
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...
i let injoy start and stop my apache server when it
connects and when i specifically click on the hangup
button... other than that, if i have to get off the
net, i simply unplug the phone line and stop injoy
from dialing out... i use a script to determine if my
apache is already up and if it is not, i start it...
i also do this with my "DDNS" updater program...
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...
I'm cable hosted. ....
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??
Sleep well; OS/2's still awake! ;)
welcome to the world of the NIMDA worm attempting
to infect your server <<GG>> there are a few
tricks to handle this... however, the standard 404
page is ok, too... unless you can block on ip
packet contents, this'll be with 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.
i'd be firing off reports to cos letting them know
the address and what its doing... it should be up
to them to determine who has that connection and
notify them (as well as knocking them off the net
until they get their stuff 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.
i let injoy start and stop my apache server when it
connects and when i specifically click on the hangup
button... other than that, if i have to get off the
net, i simply unplug the phone line and stop injoy
from dialing out... i use a script to determine if my
apache is already up and if it is not, i start it...
i also do this with my "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!
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!
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...
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!" ;)
I can reason this load-linee out mentally..
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...
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... ;(
I'm cable hosted. ....
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??
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.
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...
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!
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...
I've read into that this can happen but hav no information on
what the chances are based on this level of attack rates.
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...
How delicate!
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...
Interesting.
here's those aliasmatch statements...
Snipped for bandwidth but put into the keep and learn how to
do this!
you might also find this one useful...
Ditto.
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...
Mmm . Mint Cookies, saved in notebook! Gee how little I know,
And I never really wanted to .. oh well. Such is life! ;)
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,050 |
| Nodes: | 15 (0 / 15) |
| Uptime: | 63:08:46 |
| Calls: | 236,058 |
| Calls today: | 6 |
| Files: | 60,364 |
| D/L today: |
78 files (86,255K bytes) |
| Messages: | 289,808 |