From owner-freebsd-security Thu Nov 20 17:50:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA00475 for security-outgoing; Thu, 20 Nov 1997 17:50:05 -0800 (PST) (envelope-from owner-freebsd-security) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA00442 for ; Thu, 20 Nov 1997 17:49:58 -0800 (PST) (envelope-from danny@panda.hilink.com.au) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id MAA18200; Fri, 21 Nov 1997 12:49:07 +1100 (EST) Date: Fri, 21 Nov 1997 12:49:05 +1100 (EST) From: "Daniel O'Callaghan" To: Robert Watson cc: freebsd-security@FreeBSD.ORG, bugtraq@netspace.org Subject: Re: ipfw workaround for syn-loop attack, FreeBSD 2.2.5-STABLE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 20 Nov 1997, Robert Watson wrote: > Adding a rule for the interface denying packets from oneself appears to > defend against the new attack. > > This rule worked: > 03001 deny ip from 128.2.91.57 to 128.2.91.57 via ed0 > Where 128.2.91.57 is the host's IP address on device ed0. > > Adding this to rc.firewall on FreeBSD is also a good idea. Multi-homed > hosts require one entry per device, needless to say. With terminal servers which have IP addresses which move from interface to interface, the following rules are more generic: ---------------------------------------------- #!/bin/sh /sbin/ipfw add 1 allow ip from any to any via lo0 for ip in 127.0.0.1 192.2.3.4 192.2.3.6 192.7.8.9 do /sbin/ipfw add 2 deny log ip from $ip to any in done ----------------------------------------------- The above will prevent all self-spoofing attacks. The posted (and merged) fix in tcp_input.c will not prevent attacks where packets are formed to go from one interface to another on a multi-homed machine. I have not verified that the multi-homed attack works, but my guess is that it would. Sigh. I had made a start on reducing vulnerability to this sort of thing in rc.firewall, but I had only got as far as 127.0.0.0/8 and had to get back to money-earning work. Looks like I should finish the job. Danny