Re: URL Scan and Unknown Sessions - Repost

From: Karl Levinson [x y], mvp (levinson_k_at_despammed.com)
Date: 09/01/03 

Date: Mon, 1 Sep 2003 09:12:09 -0400

I agree with the previous response that there's not much you can do or need
to do on the server level that you aren't already doing. I think everything
is working as it should be. URLScan is blocking this and will continue to
block this, so URLScan is probably preventing some of the impact that might
otherwise be occurring. I could be wrong, but I don't think 1,000 of these
a day should cause a noticable impact on your server performance. Our
modest server used to get way more than 1,000 Code Red and/or Nimda requests
a day, and there are probably many sites that still get that many hits from
various causes today. Running Performance Monitor to quantitatively measure
and monitor server performance is not such a bad idea.

Any additional blocking would probably need to be done on a device upstream,
such as a firewall or perhaps an old spare computer running Snort inline,
assuming your firewall can handle recognizing such traffic... but even then,
you run the risk of affecting the performance of your firewall, possibly
even more so than if you just let the traffic flow through as it is flowing
today.

I will admit I also don't know what exactly is going on here, but doing a
Google search seems to imply that other people are not noticing this kind of
activity, so it's either a new attack [which I doubt] or just an unexplained
phenomenon or a misconfiguration. Repetetive unsuccessful requests like the
ones below usually turn out to not be malicious, because resending the same
attack over and over isn't the way attackers tend to work. Running Snort or
a sniffer might help you gather some additional information on whether these
are crafted packets or not:

http://securityadmin.info/faq.htm#sniffer
http://www.snort.org

"Anthony Bouch" <tony@nospamforever.com> wrote in message
news:elMx7GHcDHA.2432@TK2MSFTNGP10.phx.gbl...
> Hi - below is the original post. I've just seen a huge jump in activity
for
> this problem. Date and times aren't included but they're coming every
minute
> at fairly regular intervals - well over a thousand a day now - this will
> eventually bring our system down if we can't solve this one.
>
> Can anyone offer any advice or suggestions?
>
> ---
>
> About a week ago I started to see a sudden jump in the URLScan logs
> containing the following entries - coming from a fairly wide range of IP
> address.
>
> 220.1.32.141: Sent verb 'SEARCH', which is not specifically allowed.
Request
> will be rejected.
> 63.93.158.6: Sent verb 'SEARCH', which is not specifically allowed.
Request
> will be rejected.
> 209.243.42.231: Sent verb 'SEARCH', which is not specifically allowed.
> Request will be rejected.
> 67.41.6.124: Sent verb 'SEARCH', which is not specifically allowed.
Request
> will be rejected.
> 216.145.56.173: Sent verb 'SEARCH', which is not specifically allowed.
> Request will be rejected.
> 4.24.236.118: Sent verb 'SEARCH', which is not specifically allowed.
Request
> will be rejected.
>
> I'm getting about 1000 of these a day.
>
> The real problem is that the IIS Logs shows the following:
>
> 220.1.32.141 - 192.168.50.100 80 GET /<Rejected-By-UrlScan> ~/ 404 -
> 220.1.32.141 - 192.168.50.100 80 GET /Default.aspx - 200
> Mozilla/4.0+(compatible;+MSIE+5.5;+Windows+98)
> 63.93.158.6 - 192.168.50.100 80 GET /<Rejected-By-UrlScan> ~/ 404 -
> 63.93.158.6 - 192.168.50.100 80 GET /Default.aspx - 200
> Mozilla/4.0+(compatible;+MSIE+5.5;+Windows+98)
> 209.243.42.231 - 192.168.50.100 80 GET /<Rejected-By-UrlScan> ~/ 404 -
> 209.243.42.231 - 192.168.50.100 80 GET /Default.aspx - 200
> Mozilla/4.0+(compatible;+MSIE+5.5;+Windows+98)
> 67.41.6.124 - 192.168.50.100 80 GET /<Rejected-By-UrlScan> ~/ 404 -
> 67.41.6.124 - 192.168.50.100 80 GET /Default.aspx - 200
> Mozilla/4.0+(compatible;+MSIE+5.5;+Windows+98)
> 216.145.56.173 - 192.168.50.100 80 GET /<Rejected-By-UrlScan> ~/ 404 -
> 216.145.56.173 - 192.168.50.100 80 GET /Default.aspx - 200
> Mozilla/4.0+(compatible;+MSIE+5.5;+Windows+98)
> 4.24.236.118 - 192.168.50.100 80 GET /Default.aspx - 200
> Mozilla/4.0+(compatible;+MSIE+5.5;+Windows+98)
> 4.24.236.118 - 192.168.50.100 80 GET /<Rejected-By-UrlScan> ~/ 404 -
>
> I pretty new to this and am really not sure what's going on here - except
> that they're coming in pairs - and that each one is creating a session on
> the server when it is given Default.aspx - which is a waste of resource
(our
> site allows sessions - 20 minute expiry).
>
> Any ideas or suggestions about what might be going on here would be
greatly
> appreciated.
>
> Best regards,
>
> Tony
>
>
>
>
>
>

Relevant Pages

  • Re: [Full-disclosure] how to detect DDoS attack through HTTP response analysis(throuput)
    ... The modsecurity have a better result than mod_qos to slowloris attack, ... if server says error 408, it could be just a script which takes long to ... amount of simultaneous requests; similar requests by IP; ...
    (Full-Disclosure)
  • Re: What doesnt lend itself to OO?
    ... > system design within that context seriously). ... >>The first line exists in the server. ... > objects between client and server i.e. as far as the client code is ... the message data packet data in the server between requests, ...
    (comp.object)
  • Re: Client Server and Throttling
    ... Kernel paged pool is limited by the reserved area of address space, ... resources are allocated for the requests. ... When outlook PST files are located on a ... the server may run out of paged pool, ...
    (microsoft.public.vc.mfc)
  • Re: [Full-disclosure] Arbitrary DDoS PoC
    ... make multiple requests for just one of your requests, ... its resources to flood the targets resources. ... Not trying to really argue your examples, I'm just saying his script and ... intensive script/page on that server. ...
    (Full-Disclosure)
  • Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
    ... I have an embedded server I ... I/O, audio, and child processes that handle VoIP signaling protocols ... want to throttle the concurrency of requests at the kernel level *for ...
    (Linux-Kernel)