From owner-freebsd-questions Thu Jun 7 16: 2:53 2001 Delivered-To: freebsd-questions@freebsd.org Received: from phoenix.volant.org (dickson.phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id 5876537B403 for ; Thu, 7 Jun 2001 16:02:50 -0700 (PDT) (envelope-from patl@Phoenix.Volant.ORG) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with esmtp (Exim 1.92 #8) id 1588nh-0002IB-00; Thu, 7 Jun 2001 16:02:49 -0700 Received: from localhost (localhost [127.0.0.1]) by asimov.phoenix.volant.org (8.9.3+Sun/8.9.3) with SMTP id QAA10060; Thu, 7 Jun 2001 16:02:46 -0700 (PDT) From: patl@Phoenix.Volant.ORG Date: Thu, 7 Jun 2001 16:02:46 -0700 (PDT) Reply-To: patl@Phoenix.Volant.ORG Subject: Re: IPFW rules and outward connections To: Bill Moran Cc: Josh Thomas , freebsd-questions@freebsd.org In-Reply-To: <3B1FE973.AE494B0D@iowna.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 7-Jun-01 at 13:54, Bill Moran (wmoran@iowna.com) wrote: > ... Basically, if some other > rule in your ruleset allows an internal machine to establish a > connection, this rule will allow the machines that are part of the > connection to continue to communicate. More accurately, it will allow any incoming packet with the header flags set in such a manner that it -claims- to be part of an established connection. Even if the connection is now closed, or never existed at all. This is used for some types of Denial Of Service attacks and stealth port scans. > The opposite of established is setup, for example: > > allow tcp from 192.168.5.73 to any 22 setup > allow tcp from any to 192.168.5.73 22 setup > allow tcp from any to any established > deny tcp from any to any > > Will allow the IP listed to initiate a ssh connection to anyone or > receive a ssh connection from anyone, while the second rule ensures that > the connection can continue to communicate and the final rule blocks > anything that doesn't fit into the first category. > tcp communications must establish themselves, therefore anything that is > not specifically allowed to "setup" will never get to the "established" > state. (it's probably best, for speed, to always put the "established" > rule near the beginning of your ruleset) But some l33t h4x0r can craft bogus packets which -claim- to be part of a non-existant established connection. -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message