Date: Sat, 22 Jan 2000 14:14:29 +0300 From: Vladimir Dubrovin <vlad@sandy.ru> To: Don Lewis <Don.Lewis@tsc.tdk.com> Cc: Tim Yardley <yardley@uiuc.edu>, news@technotronic.com, bugtraq@securityfocus.com, freebsd-security@FreeBSD.ORG Subject: Re[4]: explanation and code for stream.c issues Message-ID: <1593.000122@sandy.ru> In-Reply-To: <200001221058.CAA16745@salsa.gv.tsc.tdk.com> References: <200001221058.CAA16745@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
packet.tcp.th_ack = 0;
i changed to
packet.tcp.th_ack = random();
for ACK packets.
But it's not principial - victim will reply RST for this packet in
most cases.
+=-=-=-=-=-=-=-=-=+
|Vladimir Dubrovin|
| Sandy Info, ISP |
+=-=-=-=-=-=-=-=-=+
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1593.000122>