With a DOS attack, you are sending requests to the server in order to
tie up resources. The reason for the sequence numbers in TCP is order
to make sure that data can flow to and from client and service. With
HTTP, a TCP packet is sent, and a response is sent. However for a DOS
you don't need the return packets. The request is made, the server
processes the request, and the response is generated.

It's the server processing you want done, and even waiting for a
response is time wasted for an attack. The DOS attack will send
request, drop connection, send request, drop connection... Generally
you target something that you know will eat up at least some resources
on the server.

By moving those requests to send a 302, you cut down the amount of
processing for false requests using a spoof IP. The service only
expends enough resources to generate the 302, and because the IP is
either spoofed, or not checking the response, the request to the
resource which generates more load never happens.

Hope that makes sense.

On Aug 9, 8:30 pm, Kyle Mulka <repalvigla...@yahoo.com> wrote:
> From Wikipedia:
> "Some upper layer protocols provide their own defense against IP
> spoofing. For example, Transmission Control Protocol (TCP) uses
> sequence numbers negotiated with the remote machine to ensure that
> arriving packets are part of an established connection. Since the
> attacker normally can't see any reply packets, he has to guess the
> sequence number in order to hijack the connection. The poor
> implementation in many older operating systems and network devices,
> however, means that TCP sequence numbers can be predicted."
>
> This seems to say that TCP could be used instead of HTTP 302s. Is
> there something I'm missing for why 302s are necessary here?
>
> --
> Kyle Mulkahttp://twilk.com
>
> On Aug 8, 10:45 pm, John Kalucki <jkalu...@gmail.com> wrote:
>
> > In a simplified sense, the redirect nullifies a pernicious class of
> > attack where the source IP address is forged. A redirect cannot be
> > followed with a false source address. The attacks that remain are
> > those where the source IP address is valid. You can then imagine other
> > techniques that than can be applied against valid IP addresses. And so
> > the problem is divided and ameliorated, but never fully solved.
>
> > I'm going to push back for a second with some food for thought for
> > developers: The API is via HTTP. HTTP is a well defined protocol. 302
> > redirects are a valid and well worn part of the HTTP protocol.
> > Consider why applications are not built using fully HTTP compliant
> > libraries. This doesn't address all the problems that we're all
> > having, but it does address some.
>
> > -John Kaluckihttp://twitter.com/jkalucki
> > Services, Twitter Inc.
>
> > On Aug 8, 8:53 am, Kyle Mulka <repalvigla...@yahoo.com> wrote:
>
> > > An attacker can just as easily follow a 302 as can a legitimate API
> > > developer or user of Twitter. I don't understand why Twitter thinks
> > > this is a solution to the problem. Please stop 302ing.
>
> > > Thanks,
>
> > > --
> > > Kyle Mulkahttp://twilk.com

Reply via email to