From owner-freebsd-security Fri Jan 21 11:16:11 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.servercom.com (mail.servercom.com [198.76.116.6]) by hub.freebsd.org (Postfix) with ESMTP id 1A2BE15728 for ; Fri, 21 Jan 2000 11:15:31 -0800 (PST) (envelope-from yardley@uiuc.edu) Received: from liquid (wake-gw.wakeland.servercom.com [198.88.186.1]) by mail.servercom.com (Post.Office MTA v3.5.3 release 223 ID# 0-57662U1200L100S0V35) with ESMTP id com; Fri, 21 Jan 2000 13:13:16 -0600 Message-Id: <4.2.0.58.20000121131202.0135ef10@students.uiuc.edu> X-Sender: yardley@students.uiuc.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 21 Jan 2000 13:15:27 -0600 To: Vladimir Dubrovin From: Tim Yardley Subject: Re: explanation and code for stream.c issues Cc: news@technotronic.com, bugtraq@securityfocus.com, freebsd-security@FreeBSD.ORG In-Reply-To: <8920.000121@sandy.ru> References: <4.2.0.58.20000121112253.012a8f10@students.uiuc.edu> <4.2.0.58.20000121112253.012a8f10@students.uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 01:04 PM 1/21/2000, Vladimir Dubrovin wrote: >Hello Tim Yardley, > >21.01.00 20:25, you wrote: explanation and code for stream.c issues; > >T> -- start rule set -- >T> block in quick proto tcp from any to any head 100 >T> pass in quick proto tcp from any to any flags S keep state group 100 >T> pass in all >T> -- end rule set -- > >Attack can be easily changed to send pair SYN and invalid SYN/ACK >packets before spoofing some port. I guess in this case your ruleset >will be useless. But i belive it's possible to limit the number of TCP >packets send to some host with ipfw: > >ipfw pipe 10 config delay 50 queue 5 packets >ipfw add pipe 10 tcp from any to $MYHOST in via $EXTERNAL > >I have not tested this rule but i guess with appropriate delay and >queue it will stop any TCP spoofing. As was mentioned in the "advisory/explanation" on the issue, ipfw cannot deal with the problem due to the fact that it is stateless. The attack comes from random ip addresses, therefore throttling like that only hurts your connection or solves nothing at all. In other words, the random sourcing and method of the attack, makes a non-stateless firewall useless. /tmy -- Diving into infinity my consciousness expands in inverse proportion to my distance from singularity +-------- ------- ------ ----- ---- --- -- ------ --------+ | Tim Yardley (yardley@uiuc.edu) | http://www.students.uiuc.edu/~yardley/ +-------- ------- ------ ----- ---- --- -- ------ --------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message