Re: explanation and code for stream.c issues

[Don.Lewis () TSC TDK COM (Don Lewis)]

On Jan 22,  2:14pm, Vladimir Dubrovin wrote:
} Subject: Re[4]: explanation and code for stream.c issues
} Hello Don Lewis,
}
} 22.01.00 13:58, you wrote: explanation and code for stream.c issues;
}
} D> } Intruder sends SYN packet and then sends, lets say 1000 ACK packets to
} D> } the  same port from same port and source address. SYN packet will open
} D> } ipfilter  to  pass  all  others  packets.  This  attack  doesn't  need
} D> } randomization for each packet.
}
} D> Instead of producing RST responses, this will produce ACKs. Your earlier
} D> comment about this prompted my comment in another thread about the
} D> possible need to rate limit ACK packets.
}
} This  will  not  produce  ACK packets, if ACK send by intruder doesn't
} conform  sequence  number  in the SYN/ACK response of victim. Original
} stream.c used

  [snip]

} But  it's  not  principial  - victim will reply RST for this packet in
} most cases.

Ok, you are correct.  The attacker would have to guess or sniff the
initial sequence number in order to produce a flood of ACK responses,
so the stack is in better shape than I feared.

I'm getting too tired to really analyze this, but I also think that
repeatedly sending the original SYN (sorry for the pun) won't cause
a flood of responses.  I think the victim will periodically resend the
SYN+ACK packet for which it expects an ACK.