From owner-freebsd-ipfw Sun Jan 12 8: 6: 3 2003 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D25E37B401 for ; Sun, 12 Jan 2003 08:06:01 -0800 (PST) Received: from arthur.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D81543E4A for ; Sun, 12 Jan 2003 08:06:00 -0800 (PST) (envelope-from simon@arthur.nitro.dk) Received: by arthur.nitro.dk (Postfix, from userid 1000) id 54C7E10BF87; Sun, 12 Jan 2003 17:05:59 +0100 (CET) Date: Sun, 12 Jan 2003 17:05:59 +0100 From: "Simon L. Nielsen" To: "Scott M. Nolde" Cc: freebsd-ipfw@freebsd.org Subject: Re: Feature Request Message-ID: <20030112160558.GE348@nitro.dk> References: <20030108145020.GA15778@smnolde.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <20030108145020.GA15778@smnolde.com> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2003.01.08 09:50:20 +0000, Scott M. Nolde wrote: > Has there been consideration to make a "relative skip" function similar to > skipto, where the number of rules are skipped relative to the rule itself? I found this could be useful so I have implemented this in my own firewall script to get the functionality like this : fwcmd_add deny ip from 10.0.0.0/8 to any fwcmd_add skipto ${rule_skip_1} ip from 192.168.1.0/24 to any fwcmd_add deny ip from 192.168.0.0/16 to any fwcmd_add count ip from any to any When run this gives : add 500 deny ip from 10.0.0.0/8 to any add 510 skipto 530 ip from 192.168.1.0/24 to any add 520 deny ip from 192.168.0.0/16 to any add 530 count ip from any to any It is not perfect but it works...=20 The implemetation is not complete yet but you can get the idea : is_num() { expr "$*" + 1 >/dev/null 2>&1 return $? } rule_first=3D500 rule_inc=3D10 # How much to inc pr rule rule_next=3D${rule_first} # The next rule to use # Add a firewall rule fwcmd_add() { # Check if we have a rule number if is_num "$1"; then rule_next=3D$1 shift fi ${fwcmd} add ${rule_next} $@ rule_next=3D$((${rule_next} + ${rule_inc})) =20 # Note the are a bit odd since they are used by the next rule # Warning: These will FAIL if an absoule rule nr is used in one of # the rules before the one being skipped to rule_skip_1=3D$((${rule_next} + ${rule_inc} * 2)) rule_skip_2=3D$((${rule_next} + ${rule_inc} * 3)) rule_skip_3=3D$((${rule_next} + ${rule_inc} * 4)) } --=20 Simon L. Nielsen --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+IZJm8kocFXgPTRwRAiqnAKDV4dS+3x+4vXAFLktin3deB99UywCg1C8E k472IQc1ZiT75XuhRLzAHBA= =pz7b -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jan 15 22: 8:29 2003 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50AE037B401; Wed, 15 Jan 2003 22:08:28 -0800 (PST) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.5.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAF8743F5F; Wed, 15 Jan 2003 22:08:27 -0800 (PST) (envelope-from agapon@excite.com) Received: from asv3.srv.hcvlny.cv.net (asv3.srv.hcvlny.cv.net [167.206.5.52]) by mta1.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0H8S00HBBMEUNK@mta1.srv.hcvlny.cv.net>; Thu, 16 Jan 2003 01:08:54 -0500 (EST) Received: from edge.foundation.invalid (ool-4355489e.dyn.optonline.net [67.85.72.158]) by asv3.srv.hcvlny.cv.net (8.12.6/8.12.6) with ESMTP id h0G68Ln9014894; Thu, 16 Jan 2003 01:08:22 -0500 (EST) Received: from localhost (localhost.foundation.invalid [127.0.0.1]) by edge.foundation.invalid (8.12.6/8.12.3) with ESMTP id h0G68MZY007554; Thu, 16 Jan 2003 01:08:23 -0500 (EST envelope-from agapon@excite.com) Date: Thu, 16 Jan 2003 01:08:19 -0500 (EST) From: Andriy Gapon Subject: Re: Requireing IPsec on wi interface? X-X-Sender: avg@edge.foundation.invalid To: freebsd-mobile@FreeBSD.ORG Cc: freebsd-ipfw@FreeBSD.ORG Message-id: <20030116010203.G7550@edge.foundation.invalid> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'd rather see this behavior be configured via sysctl than introducing an overhead for all interfaces and messing with ipfw layer2 rules. Sort of surpising that such a big difference in ipsec-ipfw interaction between 4.7-release and stable was made without a wide discussion or at least an announcement. In reply to: Date: Wed, 15 Jan 2003 23:24:52 -0500 From: "Ben Pfountz" To: Subject: Re: Requireing IPsec on wi interface? Message-ID: <002501c2bd17$36ebdd80$6511a8c0@benspiece> Hey list, Just to close out my thread, here is what I found dealing with forcing IPsec on a network interface with FreeBSD 4.7-STABLE or later... IPsec packets can be seperated from clear packets at the layer2 level in the firewall. Once they get up to the higher levels, the esp flag cannot be used to seperate clear from encrypted packets. This is an example of how to block all non-ipsec packets coming in on an interface: allow all esp from any to any in via wi0 layer2 deny all not esp from any to any in via wi0 layer2 allow all from any to any in via wi0 not layer2 You will need IPFW2, so read the IPFW man page on how to build it into your system. Ben -- Andriy Gapon * Broadcast Message from wnpdev21 (pts/tg) Wed Jan 8 09:12:47... replacing the jar - krishna 3931 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Jan 17 14:11:56 2003 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98BA737B401 for ; Fri, 17 Jan 2003 14:11:55 -0800 (PST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CA9443E4A for ; Fri, 17 Jan 2003 14:11:55 -0800 (PST) (envelope-from Jian.Song@nominum.com) Received: from nominum.com (yomiko.engr.nominum.com [128.177.194.45]) by shell.nominum.com (Postfix) with ESMTP id 17CDA137F02 for ; Fri, 17 Jan 2003 14:11:55 -0800 (PST) Message-ID: <3E280462.9000104@nominum.com> Date: Fri, 17 Jan 2003 13:25:54 +0000 From: Jian Song User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.0.1) Gecko/20030107 X-Accept-Language: en-us, en, zh, zh-cn, zh-tw MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: (no subject) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG auth 9e62facd subscribe freebsd-ipfw Jsong@nominum.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Jan 17 14:25:29 2003 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52E3137B401 for ; Fri, 17 Jan 2003 14:25:28 -0800 (PST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00DFC43F13 for ; Fri, 17 Jan 2003 14:25:28 -0800 (PST) (envelope-from Jian.Song@nominum.com) Received: from nominum.com (yomiko.engr.nominum.com [128.177.194.45]) by shell.nominum.com (Postfix) with ESMTP id B7F0C137F06 for ; Fri, 17 Jan 2003 14:25:27 -0800 (PST) Message-ID: <3E280776.3060502@nominum.com> Date: Fri, 17 Jan 2003 13:39:02 +0000 From: Jian Song User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.0.1) Gecko/20030107 X-Accept-Language: en-us, en, zh, zh-cn, zh-tw MIME-Version: 1.0 To: freebsd-ipfw@FreeBSD.ORG Subject: How to do tcp payload validation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi: I need to do tcp payload validation. Specifically, the tcp stream I am looking at contains multiple messages. Each message has a two byte length header and immediately follow by the body. I would like to monitor the tcp traffic and intercept each message. If there is an error, I will send RSTs to both ends of the connection. While I can do a BPF tap and do ip reassembly and tcp processing myself, I was wondering whether this can be achieved through ipfw or ipfilter. I would like a TCP tap which pass tcp payload data to a user process for further validation. This way, I don't have to worry about matching ACKs and do TCP stream reassembly. Thanks, Jian Song To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Jan 18 7:57:49 2003 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA19637B401 for ; Sat, 18 Jan 2003 07:57:46 -0800 (PST) Received: from mail.queens.unimelb.edu.au (greed.queens.unimelb.edu.au [203.28.244.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 6CAE743EB2 for ; Sat, 18 Jan 2003 07:57:45 -0800 (PST) (envelope-from tim@queens.unimelb.edu.au) Received: (qmail 58832 invoked from network); 18 Jan 2003 15:57:38 -0000 Received: from unknown (HELO queens.unimelb.edu.au) (10.0.1.254) by greed.queens.unimelb.edu.au with SMTP; 18 Jan 2003 15:57:38 -0000 Date: Sun, 19 Jan 2003 02:57:38 +1100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: keep-state checking of interface? From: Tim Burgess To: freebsd-ipfw@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <911DF304-2AFD-11D7-B465-000393BE2C60@queens.unimelb.edu.au> X-Mailer: Apple Mail (2.551) Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi All, I would like to suggest (what I consider to be) a potential improvement to the usefulness of the stateful inspection features in ipfw (and ipfw2). We have a fairly typical setup, where we are firewalling between three 'sections' - a group of private hosts who need internet access, a group of servers (web, mail, etc - with some services running on the firewall machine itself) and the internet. (In reality there are several groups of private hosts but that complexity detracts from the problem at hand). Now, imagine that we would like the private hosts to be able to access the internet, which just 'happens' to include our webserver. What I would consider then the 'typical' firewall scenario here (pretend for now there are no services on the firewall itself) would be to firewall packets separately in both directions on the 'private hosts' interface abc0, and a separate set of rules on the 'servers' interface abc1. In less words, the firewall should look something like: Private Hosts: 1.2.3.0/24 Servers: 4.5.6.0/24 Interfaces on firewall: abc0: 1.2.3.1 abc1: 4.5.6.1 ext0: 20.21.22.23 (uplink to internet) Firewall rules (incomplete, obviously, for example purposes) 100 skipto 1000 ip from any to any via abc0 101 skipto 2000 ip from any to any via abc1 102 allow ip from any to any via abc2 1000 allow tcp from 1.2.3.0/24 to any 80,443,110 1001 allow tcp from any 80,443,110 to 1.2.3.0/24 established 1002 deny ip from any to any # incoming access for webserver 2000 allow tcp from any to 4.5.6.10 80 2001 allow tcp from 4.5.6.10 80 to any established # outgoing access from outgoing mail server 2002 allow tcp from 4.5.6.11 to any 25 2003 allow tcp from any 25 to 4.5.6.11 established # deny other stuff 2004 deny ip from any to any In this way, our webserver appears to our private hosts just like any other host on the internet, and we can firewall them independently because each packet is considered twice (once for each interface). Now, imagine that we would like to use stateful inspection on 'both' of these firewalls. Consider the following rules: (100-102 same as above) 1000 check-state 1001 allow tcp from 1.2.3.0/24 to any 80,443,110,22 keep-state 1002 deny ip from any to any 2000 check-state # We don't use keep-state on incoming connections to help avoid DoS 2001 allow tcp from any to 4.5.6.10 80 2002 allow tcp from 4.5.6.10 80 to any established # We can keep state on the outgoing mail connections though 2003 allow tcp from 4.5.6.11 to any 25 keep-state Now here is the problem: Imagine one of our private hosts tries to ssh to our webserver. Under the original (and correct) configuration they would be blocked, not so under the stateful configuration. The SYN packet will pass inward through the abc0 interface and establish a stateful rule. Then the packet is passed outward through the abc1 interface and the (rule 2000) check-state rule matches the stateful rule from the other interface! (being a 'real' environment, I haven't been able to verify this behaviour but have examined the source code to ipfw2 and am pretty sure this is what would happen). So, it would be nice if the stateful rules could be tied to a particular interface using some kind of syntax. I realise that a lot of simple firewalls don't really take into account that the packets pass through (possibly) twice, so the original syntax would be relied upon by many users, however for situations like ours (which I don't imagine are rare) it would be very nice to have. Sorry for the long-winded post!!! Cheers, Tim --- Tim Burgess Queens' College University of Melbourne To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Jan 18 9:39:28 2003 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4285337B401 for ; Sat, 18 Jan 2003 09:39:27 -0800 (PST) Received: from yellow.csi.cam.ac.uk (yellow.csi.cam.ac.uk [131.111.8.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 750D343F13 for ; Sat, 18 Jan 2003 09:39:26 -0800 (PST) (envelope-from sa264@cam.ac.uk) Received: from localhost ([127.0.0.1]) by yellow.csi.cam.ac.uk with esmtp (Exim 4.10) id 18ZwwB-0003wM-00; Sat, 18 Jan 2003 17:39:19 +0000 Date: Sat, 18 Jan 2003 17:39:10 +0000 From: AMAKAWA Shuhei To: Tim Burgess Cc: freebsd-ipfw@freebsd.org Subject: Re: keep-state checking of interface? In-Reply-To: <911DF304-2AFD-11D7-B465-000393BE2C60@queens.unimelb.edu.au> References: <911DF304-2AFD-11D7-B465-000393BE2C60@queens.unimelb.edu.au> MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At Sun, 19 Jan 2003 02:57:38 +1100, Tim Burgess wrote: > > So, it would be nice if the stateful rules could be tied to a > particular interface using some kind of syntax. I realise that a lot > of simple firewalls don't really take into account that the packets > pass through (possibly) twice, so the original syntax would be relied > upon by many users, however for situations like ours (which I don't > imagine are rare) it would be very nice to have. Something like this, perhaps? 10 check-state 100 skipto 1000 ip from any to any via abc0 101 skipto 2000 ip from any to any via abc1 102 allow ip from any to any via abc2 1001 skipto 1500 tcp from 1.2.3.0/24 to any 80,443,110,22 in recv abc0 keep-state 1002 deny ip from any to any 1500 allow ip from any to any via abc0 1999 deny ip from any to any 2001 allow tcp from any to 4.5.6.10 80 2002 allow tcp from 4.5.6.10 80 to any established 2003 skipto 2500 tcp from 4.5.6.11 to any 25 in recv abc1 keep-state 2004 deny ip from any to any 2500 allow ip from any to any via abc1 2999 deny ip from any to any When a match is found by check-state, the associated "skipto" is executed rather than allow. Then you can perform some extra checking. I don't know if my example above is correct, but you get the idea? -- Shuhei To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message