Re: avoid DoS
From: Bernd Felsche (bernie@innovative.iinet.net.au)Date: 09/30/02
- Next message: Frode Nygaard: "Re: avoid DoS"
- Previous message: Bit Twister: "Re: Setting/changeing an argument in shell-scripts?"
- In reply to: Nick Maclaren: "Re: avoid DoS"
- Next in thread: Barry Margolin: "Re: avoid DoS"
- Reply: Barry Margolin: "Re: avoid DoS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Bernd Felsche <bernie@innovative.iinet.net.au> Date: Mon, 30 Sep 2002 11:57:46 +0800
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
>In article <ih17na.nqt.ln@innovative.iinet.net.au>,
>Bernd Felsche <bernie@innovative.iinet.net.au> wrote:
>>nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
>>>In article <uui5na.hsq.ln@innovative.iinet.net.au>,
>>>Bernd Felsche <bernie@innovative.iinet.net.au> wrote:
>>>>Damian Menscher <menscher+security@uiuc.edu> writes:
>>>>>Thomas B <bolero92@yahoo.com> wrote:
>>>>>> But I still don't know how to avoid DoS...... (haha...)
>>>>>You can't.
>>>>A tarpit does make DoS more unlikely. DoS is still possible, but
>>>>only by "deliberate" attack.
>>>Eh? What do you mean by a tarpit? Because I can't think of a
>>>meaning that makes sense out of your posting.
http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html
That application is of different primary intent, the side-effects
are however useful.
>>Delay the response to the undesirable incoming connection.
>>Transmit response very, very slowly. Pretend to be a very slow
>>server.
>Think harder. How do you do that unless you can separate the
>undesired connexions from the necessary ones to perfection?
The quest isn't for "perfection". If there's a solution that works
sometimes or a lot of the time, that's a lot better than no solution
at all.
And what's this "connexions" thing? Eh? Some sort of newspeak?
For the semi-literate or to encourage illiteracy?
>It is just as much a denial of service to prevent the administrator
>logging on to investigate the attack as anything else. Yes, that
>happens.
Most packets have knowable origin. If they don't, they should
usually be discarded as no connection is possible.
>>>There is NO technique that can prevent DoS against even accident,
That comment is at the least unhelpful and at worst, misleading.
Tarpits provide a workable solution for a subset of DoS.
e.g.
An ISP's mailserver that has a backlog of spam you're blocking.
The ISP's MTA wakes up after a reboot and attempts to send several
hundred messages "at once", resulting in bandwidth saturation and
your in-house MX potentially becoming overloaded.
Activation of a tarpit based on the source address of the "offender"
will reduce the bandwidth consumption drastically. Even an
artificial throttling of traffic, based on connection source,
relieves bandwidth requirements.
The ISP's MTA will only establish _one_ connection for each email
delivery attempt; and it won't retry until the previous attempt has
terminated. The accidental DoS is therefore prevented within a few
seconds - if the tarpit is activated by detecting an excessive
rate of connection attempts from the same source.
Your assertion that "There is NO technique that can prevent DoS
against even accident," is therefore provably incorrect; even in the
mathematical sense. It only takes one counter-example to disprove a
theory - but no number of examples can prove a theory.
>>_more_unlikely_ is what I said; not impossible. Not prevention in an
>>absolute sense, simply _less_likely_. A DoS will still be possible by
>>deliberate attempts to open further connections before a response is
>>received from the "slow" server.
>Look back at what you said. You said that DoS was possible only by
>a deliberate attack. That is not so.
And I didn't say that DoS was only possible by a deliberate attack.
Is it so hard for you to understand what I wrote?
Maybe English is not your native language any more.
>>>and this is trivially provable by using the Halting Lemma. The
>>>only way that it can be done is to constrain your system so harshly
>>>that the relevant resource usage functions cease to be a Turing
>>>machine and become something mathematically much simpler, with
>>>provable bounds.
>>
>>Why don't you step down from your ivory toil^h^hwer and explain that
>>in English?
>Hmm. Well, in plain English it means that an understanding of
>finite automata theory (which is explained in mathematics, not
>English) is necessary to understand why your remark is necessarily
>wrong.
>>And what have they to do with the practicalities of the Internet
>>where protocols are frequently observed in their being ignored?
>Ah. So computer science has nothing to do with computing? It is
>certainly a viewpoint, and you are welcome to it.
It would help if those practicing computer "science" had an inkling
of the practicalities.
>>Turing machine? pffft. All machines and systems have provable
>>bounds. All resources are finite.
>You are either trolling or would clearly benefit from a bit of
>education into the mathematical background of computing.
A Turing machine is an _abstract_representation_ of a real computer;
a representation that moves from one defined state to another based
on pre-defined criteria. Real machines have more (undefined) states
and are capable of changing between and into those due to undefined
conditions.
Your assumption that all DoS is of a type which cannot be prevented
by tarpits, is provably flawed.
-- /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | I'm a .signature virus! X against HTML mail | Copy me into your ~/.signature / \ and postings | to help me spread!
- Next message: Frode Nygaard: "Re: avoid DoS"
- Previous message: Bit Twister: "Re: Setting/changeing an argument in shell-scripts?"
- In reply to: Nick Maclaren: "Re: avoid DoS"
- Next in thread: Barry Margolin: "Re: avoid DoS"
- Reply: Barry Margolin: "Re: avoid DoS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
