David
Mon Jun 16 11:59:37 CDT 2008
On Jun 16, 4:17=A0am, A J Hawke <a...@lawlessland.co.uk> wrote:
> On Mon, 16 Jun 2008 03:29:08 -0700, David Wang wrote:
> > On Jun 15, 11:26=A0pm, A J Hawke <a...@lawlessland.co.uk> wrote:
> >> On Sun, 15 Jun 2008 19:17:36 -0700, David Wang wrote:
> >> > On Jun 15, 11:53=A0am, A J Hawke <a...@lawlessland.co.uk> wrote:
> >> >> On Sun, 15 Jun 2008 18:45:44 +0000, Dave wrote:
> >> >> > "A J Hawke" <a...@lawlessland.co.uk> wrote in message
> >> >> >news:4854c6b6$0$10630$fa0fcedb@news.zen.co.uk...
> >> >> >> On Sat, 14 Jun 2008 20:26:24 -0700, David Wang wrote:
>
> >> >> >>> On Jun 14, 2:24 am, A J Hawke <a...@lawlessland.co.uk> wrote:
> >> >> >>>> Here is a question for the experts;
>
> >> >> >>>> Suppose IIS is being scanned by a web vulnerability scanner.
> >> >> >>>> This could be from a static IP or a proxy chain of IPs. What is=
> >> >> >>>> the best defence? I know that many of them make a great deal of=
> >> >> >>>> 'noise' after the event, but what can you do at the time of it?=
>
> >> >> >>>> Many of them produce alot of 404 errors, is that they key?
>
> >> >> >>> The best defense is to stay up to date with security. For the
> >> >> >>> most part, you won't be able to figure out whether you are being=
> >> >> >>> cased by someone, and if you just jump at any random status
> >> >> >>> code, you will drive yourself crazy.
>
> >> >> >>> In other words, if you stay up to date like Fort Knox, you don't=
> >> >> >>> really care if anyone is scanning you.
>
> >> >> >>> //David
> >> >> >>>
http://w3-4u.blogspot.com
> >> >> >>>
http://blogs.msdn.com/David.Wang
> >> >> >>> //
>
> >> >> >> How very Microsoft 'Install our patches and ignore the problem'
> >> >> >> Ummm.
>
> >> >> > what would you like to do?
>
> >> >> How about spot the attack coming in and stop it? Or am I asking to
> >> >> much of IIS?- Hide quoted text -
>
> >> >> - Show quoted text -
>
> >> > The Internet, with its current set of protocols, is fundamentally
> >> > trusting and thus open to attacks. Trying to "spot the attack" is an
> >> > useless exercise when the protocols allow anonymous (cowardly) access=
> >> > and spoofing.
>
> >> > The server has to spend all the time/resources to identify the
> >> > attacker, while the attacker remains anonymous and always present.
>
> >> > Furthermore, the attack can be intensive as there are always more
> >> > clients than servers.
>
> >> > Thus, if the server wastes time to spot the attack, that sheer act
> >> > can become a Denial-of-Service vulnerability itself.
>
> >> > //David
> >> >
http://w3-4u.blogspot.com
> >> >
http://blogs.msdn.com/David.Wang
> >> > //
>
> >> Put it another way then, is there a reliable IDS application for server=
> >> 2003, or is it necessary to sandwich an IIS server between a Linux box
> >> running as an IDS to protect it from basic attacks?- Hide quoted text -=
>
> >> - Show quoted text -
>
> > Are you trying to secure IIS itself, the application running on IIS, or
> > the server running IIS?
>
> > I personally do not consider it necessary to run IDS or any Linux box to=
> > sandwich/watch an IIS6 server. IIS6 is provably secure by default to the=
> > point that you mostly worry about the security of the application
> > running on IIS6, and no IDS system is going to secure that for you.
>
> > IIS6 itself is secure against basic attacks, but that says nothing about=
> > the applications running on top of it, whether they are secure against
> > basic attacks like canonicalization or SQL injection. However, that
> > security is clearly with the application itself and not IIS.
>
> > Thus, I do not believe in IDS as a primary defense against basic
> > attacks. I find IDS useful only as a secondary line of defense, as an
> > internal alarm system, and only if it is smart enough to minimize false
> > positives while never having false negatives.
>
> > //David
> >
http://w3-4u.blogspot.com
> >
http://blogs.msdn.com/David.Wang
> > //
>
> I don't agree; an analogy:
> If a small child keeps hammering a parent with the same request "I want a
> golden goose, I want a golden goose, I want a golden goose' at some point
> it is reasonable to expect the parent to change their response from 'I
> will think about it' to 'You are not having a golden goose now shut up'.
>
> In this case the parent is IIS, the child is the client.
>
> If you can enhance the servers capability with ISAPI or other
> technologies, you should also be able to expect to secure it against
> basic DoS, scanning and hammering attempts. I know I can get a $25 FTP
> server app to do it without arguing.- Hide quoted text -
>
> - Show quoted text -
I disagree with the analogy. The child happens to be the attacker, and
you are saying that IIS can tell the attacker to quit and go
elsewhere? I highly doubt that would happen.
Please define what you mean by "basic DoS" and "Scanning". Especially
how to detect false-positives. So that we can ignore the trivial
defense like turning off the server power or pulling the network plug.
Hammering attempts are fundamentally unstoppable given the current
Internet infrastructure. It is common acceptance that anyone with
enough clients can hammer and take any service off the Internet
indefinitely.
I think you are asking for solutions but implemented at the wrong
level. Yes, web servers support extensibility and yes you can take
advantage of it for DoS issues like this, but I hardly believe it to
be the correct approach and certainly beyond what Web Servers are
reasonably expected to do.
For example, I think the right way to address a DoS, which is an
attack against service resources, is to stop it as close to the
outside as possible. By the time a request reaches your web server, it
has already consumed much of your bandwidth resources from the
outside, through your network infrastructure (consuming bandwidth),
regardless of what the web server does. The only thing a Web Server
can do is run custom code to reject such requests, but why do you run
that on the Web Server when you should run that on the Router sitting
at the border between your network and the Internet -- that way, when
it filters out such traffic, it *never* consumes network/bandwidth/CPU
resources inside your hosted web services. Similar arguments can be
made for DoS, hammering, and scanning.
In fact, even if you stop it as close to the outside as possible, the
attack consumes network resources to reach your site -- so even if
your site rejects the DoS attack, your host provider may become the
bottleneck, and so-on up the chain. There is only so much one can do
given the current structure of the Internet.
Thus, for IIS to come out with basic DoS, scanning, and hammering
attempts makes no sense on the technical and financial basis. It is
technically better to do this at the Router, and that is why the
market is out there and not on IIS.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//