[OT] Nimda etc (was Re: New mod_perl hacker wannabe . . .)
Er, you might look at http://www.tonkinresolutions.com/MSIISProbes.pm.html ... Always a good idea to search the mod_perl list archives, as well as put out ideas in the present tense :) Nick ~~~ Nick Tonkin On Mon, 29 Oct 2001, Louis LeBlanc wrote: On 10/28/01 08:29 PM, Jeremy Rusnak sat at the `puter and typed: Just today, I finished a new module - my first from scratch - for handling 404 errors. I know Apache::404 isn't a real imaginative name, but it works. I took a look at this, it's a good idea for smaller sites. I would suggest that you figure out a way to put a rate limit on the number of E-mails that are sent warning the admin, though. On my site we receive over a million page views a day...When something gets broken I don't want to have 10,000 E-mails in my inbox. In addition, there are many black hats out there who might be tempted to use this an exploit. I once had a script that told the user Error blah blah...An E-mail has been sent to our support staff to notify them of the problem. Of course some people decided to call the script thousands of times and fill up the hard drive on our mail server. Of course, not all sites are going to have issues like this...But I think if you're going to be releasing modules it might be a good idea to include some notes for sites that MIGHT. Very good point. The CodeRed and Nimda modules have a cache mechanism (File::Cache, IIRC) that prevents repeat reports within a 24 hour period. Definitely a good idea. This would also help with the likes of the Nimda and CodeRed hits, so you would only get one per day of any of the unique URIs generating reports. Now I DO see the value of opening discussion *prior* to just throwing a module out! :) Look for V1.01 in the next week :) Thanks! Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ Second Law of Final Exams: In your toughest final -- for the first time all year -- the most distractingly attractive student in the class will sit next to you.
[OT] Nimda, etc (was: New mod_perl hacker wannabe . . .)
FWIW, Apache::CodeRed seemed like a good idea for a while, and then Nimbda
showed up, and it was apparent no one was actually doing anything about the
infected machines. I got sick of the notifications and the junk in my error
log, so I resorted to this handler:
LocationMatch \.(ida|exe)$
SetHandler perl-script
PerlHandler sub { return OK; }
/LocationMatch
From: John Michael [EMAIL PROTECTED]
Date: Sun, 28 Oct 2001 20:27:03 -0600
To: [EMAIL PROTECTED]
Subject: Re: New mod_perl hacker wannabe . . .
My server is constantly getting scanned by various hacking robots. I will
get hundreds of these a day or more sometimes.
[Sun Oct 28 18:51:00 2001] [error] [client 64.81.175.236] File does not
exist: /home/usr1/digital/html/scripts/root.exe
[Sun Oct 28 18:51:01 2001] [error] [client 64.81.175.236] File does not
exist: /home/usr1/digital/html/MSADC/root.exe
[Sun Oct 28 19:28:29 2001] [error] [client 64.81.41.2] File does not exist:
/home/usr1/digital/html/scripts/root.exe
Re: [OT] Nimda, etc (was: New mod_perl hacker wannabe . . .)
David Young wrote:
FWIW, Apache::CodeRed seemed like a good idea for a while, and then Nimbda
showed up, and it was apparent no one was actually doing anything about the
infected machines. I got sick of the notifications and the junk in my error
log, so I resorted to this handler:
LocationMatch \.(ida|exe)$
SetHandler perl-script
PerlHandler sub { return OK; }
/LocationMatch
And the most effective would be to use PerlPostReadRequestHandler
(or PerlInitHandler, which is an alias to PerlPostReadRequestHandler)
LocationMatch \.(ida|exe)$
SetHandler perl-script
PerlPostReadRequestHandler Apache::DONE
/LocationMatch
since it returns at the earliest possible request phase. And you don't
need the sub {}, just Apache::* will do.
Apache::DONE tells Apache to immediately jumps out of the request
loop, log the transaction and close the client connection. This is
one way to halt the transaction without generating an error status.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [OT] Nimda, etc (was: New mod_perl hacker wannabe . . .)
LocationMatch \.(ida|exe)$
SetHandler perl-script
PerlPostReadRequestHandler Apache::DONE
/LocationMatch
I tried adding the above code to my perl.conf file. and got this error on
restart.
Syntax error on line 31 of /etc/httpd/conf/conf/perl.conf:
PerlPostReadRequestHandler not allowed here
JM
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: David Young [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, October 28, 2001 11:45 PM
Subject: Re: [OT] Nimda, etc (was: New mod_perl hacker wannabe . . .)
David Young wrote:
FWIW, Apache::CodeRed seemed like a good idea for a while, and then
Nimbda
showed up, and it was apparent no one was actually doing anything about
the
infected machines. I got sick of the notifications and the junk in my
error
log, so I resorted to this handler:
LocationMatch \.(ida|exe)$
SetHandler perl-script
PerlHandler sub { return OK; }
/LocationMatch
And the most effective would be to use PerlPostReadRequestHandler
(or PerlInitHandler, which is an alias to PerlPostReadRequestHandler)
LocationMatch \.(ida|exe)$
SetHandler perl-script
PerlPostReadRequestHandler Apache::DONE
/LocationMatch
since it returns at the earliest possible request phase. And you don't
need the sub {}, just Apache::* will do.
Apache::DONE tells Apache to immediately jumps out of the request
loop, log the transaction and close the client connection. This is
one way to halt the transaction without generating an error status.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [OT] Nimda, etc (was: New mod_perl hacker wannabe . . .)
I tried
PerlPostReadRequestHandler Apache::DONE
and apache would not start
I changed it to:
LocationMatch \.(ida|exe)$
SetHandler perl-script
PerlInitHandler Apache::DONE
/LocationMatch
Apache then started
And it looks for the module DONE.pm
So I guess you have to write the module for it to work.
I then changed it to:
LocationMatch \.(ida|exe)$
SetHandler perl-script
PerlInitHandler sub { return OK; }
/LocationMatch
and got this in the error log.
Argument OK isn't numeric.= tried changeing it from OK to 200 and
still did not work.
It did get rid of the file not found error.
So I changed the OK to 200 in this version and it does work.
LocationMatch \.(ida|exe)$
SetHandler perl-script
PerlHandler sub { return 200; }
/LocationMatch
I'm guessing this is because apache::constants have not been loaded at this
point.
Thanks
JM
David Young wrote:
FWIW, Apache::CodeRed seemed like a good idea for a while, and then
Nimbda
showed up, and it was apparent no one was actually doing anything about
the
infected machines. I got sick of the notifications and the junk in my
error
log, so I resorted to this handler:
LocationMatch \.(ida|exe)$
SetHandler perl-script
PerlHandler sub { return OK; }
/LocationMatch
And the most effective would be to use PerlPostReadRequestHandler
(or PerlInitHandler, which is an alias to PerlPostReadRequestHandler)
LocationMatch \.(ida|exe)$
SetHandler perl-script
PerlPostReadRequestHandler Apache::DONE
/LocationMatch
since it returns at the earliest possible request phase. And you don't
need the sub {}, just Apache::* will do.
Apache::DONE tells Apache to immediately jumps out of the request
loop, log the transaction and close the client connection. This is
one way to halt the transaction without generating an error status.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [OT] Nimda, etc (was: New mod_perl hacker wannabe . . .)
John Michael wrote: I tried PerlPostReadRequestHandler Apache::DONE and apache would not start I changed it to: LocationMatch \.(ida|exe)$ SetHandler perl-script PerlInitHandler Apache::DONE /LocationMatch Apache then started And it looks for the module DONE.pm My bad, should have tested and not send things off my head :( Try this: PerlModule Apache::Constants LocationMatch \.(ida|exe)$ SetHandler perl-script PerlInitHandler Apache::Constants::DONE /LocationMatch % HEAD http://127.0.0.1:8000/foo.exe 500 unexpected EOF before status line seen Client-Date: Mon, 29 Oct 2001 06:48:10 GMT _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
NIMDA worm; MSIISProbes.pm
Hello, Now that Micro$oft has finally put out some information about their latest trick I have posted a new version of MSIISProbes.pm. Version 1.02 changes include putting the URL to a page containing info about each worm into a PerlSetVar ... this means that once you have configured MSIISProbes.pm with your e-mail and cacheing preferences, you can add traps for new worms as Micro$oft releases them, er, discovers them. Available at http://www.tonkinresolutions.com/MSIISProbes.pm.tar.gz More info at http://www.tonkinresolutions.com/MSIISProbes.pm.html Comments/flames welcome. - nick ~~~ Nick Tonkin
[OT] Re: Nimda worm
On Tue, Sep 18, 2001 at 04:07:59PM -0700, Nick Tonkin wrote: Heh, as Nat maybe saw the worm doesn't always request ?/c+dir, so until I can figure out a better way to identify it we'll have to go with cmd.exe|root.exe Here's a sample Nimda hit (courtesy of 'nc -l -p 80' -- try it yourself on a net-connected machine not already running a web server and just wait a few seconds): GET /scripts/root.exe?/c+dir HTTP/1.0 Host: www Connnection: close Note the Host: www header. You can trap this one by setting up a virtualhost called 'www'.
Re: NIMDA worm; MSIISProbes.pm
Nick Tonkin writes:
Now that Micro$oft has finally put out some information about their
latest trick I have posted a new version of MSIISProbes.pm.
Version 1.02 changes include putting the URL to a page containing info
about each worm into a PerlSetVar ... this means that once you have
configured MSIISProbes.pm with your e-mail and cacheing preferences, you
can add traps for new worms as Micro$oft releases them, er, discovers
them.
Available at http://www.tonkinresolutions.com/MSIISProbes.pm.tar.gz
More info at http://www.tonkinresolutions.com/MSIISProbes.pm.html
I was looking at your Apache::MSIISProbes module, and I didn't
understand the part about the nimda rewrite rules, mostly because I
haven't used the rewrite rules. Do the following rules
RewriteCond %{REQUEST_URI} !nimda
RewriteCond %{QUERY_STRING} /c.dir
RewriteRule .* /nimda? [R,L]
mean unless I've already rewritten the rule, if the query string matches
c.dir (i.e., will match c+dir found in most of the requests), rewrite
the request as /nimda? From my observation, nimbda also tries c+tftp
and tries to get /scripts/Admin.dll, /c/Admin.dll, /d/Admin.dll and
/MSADC/Admin.dll. Could I change the rewrite rules to
RewriteCond %{REQUEST_URI} !nimda
RewriteCond %{QUERY_STRING} /c.(tftp|dir)
RewriteRule .* /nimda? [R,L]
to catch either request, and then do
RewriteCond %{REQUEST_URI} /(scripts|MSADC|c|d)/Admin.dll
RewriteRule .* /nimda? [R,L]
to catch the others?
Thanks.
Re: NIMDA worm; MSIISProbes.pm
On Wed, 19 Sep 2001, Bruce Albrecht wrote:
I was looking at your Apache::MSIISProbes module, and I didn't
understand the part about the nimda rewrite rules, mostly because I
haven't used the rewrite rules. Do the following rules
RewriteCond %{REQUEST_URI} !nimda
RewriteCond %{QUERY_STRING} /c.dir
RewriteRule .* /nimda? [R,L]
mean unless I've already rewritten the rule, if the query string matches
c.dir (i.e., will match c+dir found in most of the requests), rewrite
the request as /nimda?
right.
From my observation, nimbda also tries c+tftp
and tries to get /scripts/Admin.dll, /c/Admin.dll, /d/Admin.dll and
/MSADC/Admin.dll. Could I change the rewrite rules to
RewriteCond %{REQUEST_URI} !nimda
RewriteCond %{QUERY_STRING} /c.(tftp|dir)
RewriteRule .* /nimda? [R,L]
to catch either request, and then do
RewriteCond %{REQUEST_URI} /(scripts|MSADC|c|d)/Admin.dll
RewriteRule .* /nimda? [R,L]
to catch the others?
Well, the rules you put forward seem fine, but I'm not sure you'll catch
everything ...
BTW the '?' on the end is to remove the query string ... if you leave it
off mod_rewrite puts the original one back.
- nick
Nimda
If no one did the calculation before it amounts to a data transfer of approximately 250 MB a month considering the continuous 100Kbps of probe I am getting since yesterday evening. Doesn't matter to people with T1 links I guess but people hosted on shared servers and anyone else with dedicated IP might not like that :(. Mithun
Nimda worm
Heh, as Nat maybe saw the worm doesn't always request ?/c+dir, so until I can figure out a better way to identify it we'll have to go with cmd.exe|root.exe so my httpd.conf is now: Location /default.ida SetHandler perl-script PerlHandler Apache::MSIISProbes PerlSetVar worm_name CodeRed /Location LocationMatch (cmd.exe|root.exe) SetHandler perl-script PerlHandler Apache::MSIISProbes PerlSetVar worm_name Nimda /LocationMatch ~~~ Nick Tonkin
