From owner-freebsd-ipfw Sun Sep 3 21:42:34 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id 7EE8837B422 for ; Sun, 3 Sep 2000 21:42:32 -0700 (PDT) Received: from locust.wam.umd.edu (adsl-138-88-45-28.bellatlantic.net [138.88.45.28]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id AAA08257 for ; Mon, 4 Sep 2000 00:42:31 -0400 (EDT) Message-Id: <4.3.2.7.0.20000904003907.00b12450@pop.wam.umd.edu> X-Sender: bmbintz@pop.wam.umd.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Sep 2000 00:39:34 -0400 To: freebsd-ipfw@freebsd.org From: Brian Bintz Subject: subscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Sep 4 12:27:53 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from sneakerz.org (sneakerz.org [207.154.226.254]) by hub.freebsd.org (Postfix) with ESMTP id 8D9C837B422 for ; Mon, 4 Sep 2000 12:27:51 -0700 (PDT) Received: by sneakerz.org (Postfix, from userid 1023) id 395CF5D006; Mon, 4 Sep 2000 14:27:46 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by sneakerz.org (Postfix) with ESMTP id 37EB959206 for ; Mon, 4 Sep 2000 14:27:46 -0500 (CDT) Date: Mon, 4 Sep 2000 14:27:46 -0500 (CDT) From: missnglnk To: freebsd-ipfw@freebsd.org Subject: Issues with ipfw(8)'s dynamic rules Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I found some undesirable side effects with ipfw's dynamic rules as I was toying with it today. a) Expired Dynamic Rules Aren't Really Expired I noticed that once a dynamic rule expires (hitting its respective timeout value), it's not removed from the dynamic table (unless the dynamic table is full), so the connection is still allowed to continue instead of being dropped, the only indications that an expired connection is still in use is the "invalid state" messages that are sent to the console, and the combined analyzation of ipfw(8) and netstat(1) output. My Solution: Remove expired UDP and ICMP dynamic rules from the table, and for expired TCP connections send an RST to both sides of the connection, and then remove expired TCP dynamic rules from the table. b) Premature Rule Expiration TCP connections will expire prematurely if the connection has been idle longer than the dynamic state ACK lifetime, but shorter than the TCP keepalive interval. This would result in "Connection reset by peer" messages, but since the first issue is still present, it only results in "invalid state" messages being sent to the console My Solution: By default, set the dynamic state ACK lifetime to the TCP keepalive interval, warn user if he/she sets the dynamic state ACK lifetime to a value less than the TCP keepalive interval. P.S. My solutions are only suggested solutions. -- missnglnk@sneakerz.org http://www.sneakerz.org/~missnglnk/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Sep 4 12:40:19 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 8D30037B424 for ; Mon, 4 Sep 2000 12:40:16 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id VAA16957; Mon, 4 Sep 2000 21:42:06 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200009041942.VAA16957@info.iet.unipi.it> Subject: Re: Issues with ipfw(8)'s dynamic rules In-Reply-To: from missnglnk at "Sep 4, 2000 02:27:46 pm" To: missnglnk Date: Mon, 4 Sep 2000 21:42:06 +0200 (CEST) Cc: freebsd-ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I found some undesirable side effects with ipfw's dynamic > rules as I was toying with it today. > > a) Expired Dynamic Rules Aren't Really Expired > I noticed that once a dynamic rule expires (hitting its respective > timeout value), it's not removed from the dynamic table (unless > the dynamic table is full), so the connection is still allowed to > continue instead of being dropped, the only indications that an In my code at least (and i think in the CVS tree as well) rules which hit their deadline are listed but the first time a lookup crosses through them they are really removed, so the connection is not allowed (otherwise how could you see the premature expire below!) > that are sent to the console, and the combined analyzation of > ipfw(8) and netstat(1) output. > > My Solution: Remove expired UDP and ICMP dynamic rules from the > table, and for expired TCP connections send an RST > to both sides of the connection, and then remove > expired TCP dynamic rules from the table. You really don't want to send RST's around from your firewall! > b) Premature Rule Expiration > TCP connections will expire prematurely if the connection has been > idle longer than the dynamic state ACK lifetime, but shorter than ... there is no easy solution to this, as you have no idea on what the keepalive interval is, nor if it is used at all. As someone suggested to me, the only real solution is have the firewall implement keepalives by itself, but this requires keeping track of sequence numbers (not that expensive) and sending pkts out from the firewall triggered by timeouts. Thanks for the suggestions, but i think problem a) does not really exists (or if it does, please tell me on which version of the system you see it) and problem b) cannot be solved the way you suggest. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Sep 5 6:15:29 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from sneakerz.org (sneakerz.org [207.154.226.254]) by hub.freebsd.org (Postfix) with ESMTP id 8CF8937B42C for ; Tue, 5 Sep 2000 06:15:26 -0700 (PDT) Received: by sneakerz.org (Postfix, from userid 1023) id 011295D008; Tue, 5 Sep 2000 08:15:20 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by sneakerz.org (Postfix) with ESMTP id F132E59206; Tue, 5 Sep 2000 08:15:20 -0500 (CDT) Date: Tue, 5 Sep 2000 08:15:20 -0500 (CDT) From: missnglnk To: Luigi Rizzo Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: Issues with ipfw(8)'s dynamic rules In-Reply-To: <200009041942.VAA16957@info.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 4 Sep 2000, Luigi Rizzo wrote: > Date: Mon, 4 Sep 2000 21:42:06 +0200 (CEST) > From: Luigi Rizzo > To: missnglnk > Cc: freebsd-ipfw@FreeBSD.ORG > Subject: Re: Issues with ipfw(8)'s dynamic rules > > > I found some undesirable side effects with ipfw's dynamic > > rules as I was toying with it today. > > > > a) Expired Dynamic Rules Aren't Really Expired > > I noticed that once a dynamic rule expires (hitting its respective > > timeout value), it's not removed from the dynamic table (unless > > the dynamic table is full), so the connection is still allowed to > > continue instead of being dropped, the only indications that an > > In my code at least (and i think in the CVS tree as well) rules > which hit their deadline are listed but the first time a lookup > crosses through them they are really removed, so the connection is > not allowed (otherwise how could you see the premature expire > below!) Do "ipfw show" and look at the dynamic rule output, the timeout is listed there, I've had several SSH connections expired but I'm still able to do things, i.e. send this message via pine. > > that are sent to the console, and the combined analyzation of > > ipfw(8) and netstat(1) output. > > > > My Solution: Remove expired UDP and ICMP dynamic rules from the > > table, and for expired TCP connections send an RST > > to both sides of the connection, and then remove > > expired TCP dynamic rules from the table. > > You really don't want to send RST's around from your firewall! Agreed. > > b) Premature Rule Expiration > > TCP connections will expire prematurely if the connection has been > > idle longer than the dynamic state ACK lifetime, but shorter than > ... > there is no easy solution to this, as you have no idea on what the > keepalive interval is, nor if it is used at all. As someone suggested to > me, the only real solution is have the firewall implement keepalives > by itself, but this requires keeping track of sequence numbers > (not that expensive) and sending pkts out from the firewall triggered > by timeouts. > > Thanks for the suggestions, but i think problem a) does not really > exists (or if it does, please tell me on which version of the system > you see it) and problem b) cannot be solved the way you suggest. 4.0-RELEASE gives you the "invalid state" messages scrolling down the screen after the connections expires, and 5.0-CURRENT increments the expiration time by the value of the dynamic RST lifetime even though the connection has expired, also not once have I had an expired connection drop. Can't problem B be solved by silently dropping the connection? > cheers > luigi > -----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > Mobile +39-347-0373137 > -----------------------------------+------------------------------------- > -- missnglnk@sneakerz.org http://www.sneakerz.org/~missnglnk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Sep 5 6:46:14 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from sneakerz.org (sneakerz.org [207.154.226.254]) by hub.freebsd.org (Postfix) with ESMTP id C512037B423 for ; Tue, 5 Sep 2000 06:46:11 -0700 (PDT) Received: by sneakerz.org (Postfix, from userid 1023) id 5446C5D007; Tue, 5 Sep 2000 08:46:11 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by sneakerz.org (Postfix) with ESMTP id 52B1459206; Tue, 5 Sep 2000 08:46:11 -0500 (CDT) Date: Tue, 5 Sep 2000 08:46:11 -0500 (CDT) From: missnglnk To: Luigi Rizzo Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: Issues with ipfw(8)'s dynamic rules In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 5 Sep 2000, missnglnk wrote: > Date: Tue, 5 Sep 2000 08:15:20 -0500 (CDT) > From: missnglnk > To: Luigi Rizzo > Cc: freebsd-ipfw@FreeBSD.ORG > Subject: Re: Issues with ipfw(8)'s dynamic rules > > On Mon, 4 Sep 2000, Luigi Rizzo wrote: > > > Date: Mon, 4 Sep 2000 21:42:06 +0200 (CEST) > > From: Luigi Rizzo > > To: missnglnk > > Cc: freebsd-ipfw@FreeBSD.ORG > > Subject: Re: Issues with ipfw(8)'s dynamic rules > > > > > I found some undesirable side effects with ipfw's dynamic > > > rules as I was toying with it today. > > > > > > a) Expired Dynamic Rules Aren't Really Expired > > > I noticed that once a dynamic rule expires (hitting its respective > > > timeout value), it's not removed from the dynamic table (unless > > > the dynamic table is full), so the connection is still allowed to > > > continue instead of being dropped, the only indications that an > > > > In my code at least (and i think in the CVS tree as well) rules > > which hit their deadline are listed but the first time a lookup > > crosses through them they are really removed, so the connection is > > not allowed (otherwise how could you see the premature expire > > below!) > > Do "ipfw show" and look at the dynamic rule output, the timeout is > listed there, I've had several SSH connections expired but I'm still > able to do things, i.e. send this message via pine. > > > > that are sent to the console, and the combined analyzation of > > > ipfw(8) and netstat(1) output. > > > > > > My Solution: Remove expired UDP and ICMP dynamic rules from the > > > table, and for expired TCP connections send an RST > > > to both sides of the connection, and then remove > > > expired TCP dynamic rules from the table. > > > > You really don't want to send RST's around from your firewall! > > Agreed. > > > > b) Premature Rule Expiration > > > TCP connections will expire prematurely if the connection has been > > > idle longer than the dynamic state ACK lifetime, but shorter than > > ... > > there is no easy solution to this, as you have no idea on what the > > keepalive interval is, nor if it is used at all. As someone suggested to > > me, the only real solution is have the firewall implement keepalives > > by itself, but this requires keeping track of sequence numbers > > (not that expensive) and sending pkts out from the firewall triggered > > by timeouts. > > > > Thanks for the suggestions, but i think problem a) does not really > > exists (or if it does, please tell me on which version of the system > > you see it) and problem b) cannot be solved the way you suggest. > > 4.0-RELEASE gives you the "invalid state" messages scrolling down the > screen after the connections expires, and 5.0-CURRENT increments the > expiration time by the value of the dynamic RST lifetime even though the > connection has expired, also not once have I had an expired connection > drop. > > Can't problem B be solved by silently dropping the connection? I meant problem A, not B. > > cheers > > luigi > > -----------------------------------+------------------------------------- > > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > > Mobile +39-347-0373137 > > -----------------------------------+------------------------------------- > > > -- > missnglnk@sneakerz.org > http://www.sneakerz.org/~missnglnk > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Sep 6 14:34:30 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from sneakerz.org (sneakerz.org [207.154.226.254]) by hub.freebsd.org (Postfix) with ESMTP id B998C37B423 for ; Wed, 6 Sep 2000 14:34:24 -0700 (PDT) Received: by sneakerz.org (Postfix, from userid 1023) id 156405D008; Wed, 6 Sep 2000 16:34:24 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by sneakerz.org (Postfix) with ESMTP id 114E559206; Wed, 6 Sep 2000 16:34:24 -0500 (CDT) Date: Wed, 6 Sep 2000 16:34:24 -0500 (CDT) From: missnglnk To: Luigi Rizzo Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: Issues with ipfw(8)'s dynamic rules In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 5 Sep 2000, missnglnk wrote: > Date: Tue, 5 Sep 2000 08:46:11 -0500 (CDT) > From: missnglnk > To: Luigi Rizzo > Cc: freebsd-ipfw@FreeBSD.ORG > Subject: Re: Issues with ipfw(8)'s dynamic rules > > On Tue, 5 Sep 2000, missnglnk wrote: > > > Date: Tue, 5 Sep 2000 08:15:20 -0500 (CDT) > > From: missnglnk > > To: Luigi Rizzo > > Cc: freebsd-ipfw@FreeBSD.ORG > > Subject: Re: Issues with ipfw(8)'s dynamic rules > > > > On Mon, 4 Sep 2000, Luigi Rizzo wrote: > > > > > Date: Mon, 4 Sep 2000 21:42:06 +0200 (CEST) > > > From: Luigi Rizzo > > > To: missnglnk > > > Cc: freebsd-ipfw@FreeBSD.ORG > > > Subject: Re: Issues with ipfw(8)'s dynamic rules > > > > > > > I found some undesirable side effects with ipfw's dynamic > > > > rules as I was toying with it today. > > > > > > > > a) Expired Dynamic Rules Aren't Really Expired > > > > I noticed that once a dynamic rule expires (hitting its respective > > > > timeout value), it's not removed from the dynamic table (unless > > > > the dynamic table is full), so the connection is still allowed to > > > > continue instead of being dropped, the only indications that an > > > > > > In my code at least (and i think in the CVS tree as well) rules > > > which hit their deadline are listed but the first time a lookup > > > crosses through them they are really removed, so the connection is > > > not allowed (otherwise how could you see the premature expire > > > below!) > > > > Do "ipfw show" and look at the dynamic rule output, the timeout is > > listed there, I've had several SSH connections expired but I'm still > > able to do things, i.e. send this message via pine. > > > > > > that are sent to the console, and the combined analyzation of > > > > ipfw(8) and netstat(1) output. > > > > > > > > My Solution: Remove expired UDP and ICMP dynamic rules from the > > > > table, and for expired TCP connections send an RST > > > > to both sides of the connection, and then remove > > > > expired TCP dynamic rules from the table. > > > > > > You really don't want to send RST's around from your firewall! > > > > Agreed. > > > > > > b) Premature Rule Expiration > > > > TCP connections will expire prematurely if the connection has been > > > > idle longer than the dynamic state ACK lifetime, but shorter than > > > ... > > > there is no easy solution to this, as you have no idea on what the > > > keepalive interval is, nor if it is used at all. As someone suggested to > > > me, the only real solution is have the firewall implement keepalives > > > by itself, but this requires keeping track of sequence numbers > > > (not that expensive) and sending pkts out from the firewall triggered > > > by timeouts. > > > > > > Thanks for the suggestions, but i think problem a) does not really > > > exists (or if it does, please tell me on which version of the system > > > you see it) and problem b) cannot be solved the way you suggest. > > > > 4.0-RELEASE gives you the "invalid state" messages scrolling down the > > screen after the connections expires, and 5.0-CURRENT increments the > > expiration time by the value of the dynamic RST lifetime even though the > > connection has expired, also not once have I had an expired connection > > drop. > > > > Can't problem B be solved by silently dropping the connection? > > I meant problem A, not B. Try this (sloppy, but I think you can see the point): --- sys/netinet/ip_fw.c.orig Wed Sep 6 00:41:12 2000 +++ sys/netinet/ip_fw.c Wed Sep 6 12:29:12 2000 @@ -735,4 +735,3 @@ break ; - default: -#if 0 + case TH_RST | (TH_RST << 8) : /* @@ -741,7 +740,15 @@ */ - if ( (q->state & ((TH_RST << 8)|TH_RST)) == 0) - printf("invalid state: 0x%x\n", q->state); -#endif + printf("invalid state: 0x%x\n", q->state); q->expire = time_second + dyn_rst_lifetime ; break ; + default: + printf("packet should be dropped (state: 0x%x)\n", q->state); + old_q = q ; + if (prev != NULL) + prev->next = q = q->next ; + else + ipfw_dyn_v[i] = q = q->next ; + dyn_count-- ; + free(old_q, M_IPFW); + break ; } @@ -1277,4 +1284,34 @@ */ - if (q == NULL && f->fw_flg & IP_FW_F_KEEP_S) - install_state(chain); + if (q == NULL && f->fw_flg & IP_FW_F_KEEP_S) { + switch(proto) { + case IPPROTO_TCP: + if (flags & TH_SYN) { + DEB(printf("-- installing state for TCP packet\n")); + install_state(chain); + } else { + DEB(printf("-- invalid TCP connection state\n")); + } + break; + case IPPROTO_UDP: + DEB(printf("-- installing state for UDP packet\n")); + install_state(chain); + break; + case IPPROTO_ICMP: + if (is_icmp_query(ip)) { + DEB(printf("-- installing state for ICMP packet\n")); + install_state(chain); + } else { + DEB(printf("-- invalid ICMP connection state\n")); + } + break; + default: +#ifdef IPFIREWALL_DEFAULT_TO_ACCEPT + DEB(printf("-- installing state for unknown packet\n")); + install_state(chain); +#else + DEB(printf("invalid unknown protocol connection state\n")); +#endif + break; + } + } #endif a) Fuzz #1 + #2" The default action before was to simply increment the state's expiration time by the dynamic RST lifetime amount, I changed it to remove the state instead. b) Fuzz #3: After adding the code in fuzzes #1 and #2, I saw that a new state would be installed if the matching rule wasn't protocol-specific (i.e. allow ip from any to any keep-state), so I added some protocol matching code before calling install_state(). WARNING: I consider my code very messy as only as a cheap bandaid for now, in other words, this should not be used on production machines until cleaned up. -- missnglnk@sneakerz.org http://www.sneakerz.org/~missnglnk/ > > > cheers > > > luigi > > > -----------------------------------+------------------------------------- > > > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > > > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > > > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > > > Mobile +39-347-0373137 > > > -----------------------------------+------------------------------------- > > > > > -- > > missnglnk@sneakerz.org > > http://www.sneakerz.org/~missnglnk > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-ipfw" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Sep 6 22:38:41 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from sneakerz.org (sneakerz.org [207.154.226.254]) by hub.freebsd.org (Postfix) with ESMTP id 909D637B423 for ; Wed, 6 Sep 2000 22:38:38 -0700 (PDT) Received: by sneakerz.org (Postfix, from userid 1023) id 3F5505D006; Thu, 7 Sep 2000 00:38:33 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by sneakerz.org (Postfix) with ESMTP id 3DAE059206; Thu, 7 Sep 2000 00:38:33 -0500 (CDT) Date: Thu, 7 Sep 2000 00:38:33 -0500 (CDT) From: missnglnk To: Luigi Rizzo Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: Issues with ipfw(8)'s dynamic rules In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --- sys/netinet/ip_fw.c.orig Wed Sep 6 21:01:07 2000 +++ sys/netinet/ip_fw.c Wed Sep 6 21:40:55 2000 @@ -735,4 +735,3 @@ break ; - default: -#if 0 + case TH_RST | (TH_RST << 8) : /* @@ -741,7 +740,18 @@ */ - if ( (q->state & ((TH_RST << 8)|TH_RST)) == 0) - printf("invalid state: 0x%x\n", q->state); -#endif + printf("invalid state: 0x%x\n", q->state); q->expire = time_second + dyn_rst_lifetime ; break ; + default: + /* + * A TCP packet found in unknown state, drop it. + */ + DEB(printf("packet should be dropped (state: 0x%x)\n", q->state)); + old_q = q ; + if (prev != NULL) + prev->next = q = q->next ; + else + ipfw_dyn_v[i] = q = q->next ; + dyn_count-- ; + free(old_q, M_IPFW); + break ; } @@ -838,4 +848,7 @@ } - if (dyn_count >= dyn_max) /* try remove old ones... */ - remove_dyn_rule(NULL, 0 /* expire */); + /* + * Unconditionally remove expired states. + */ + remove_dyn_rule(NULL, 0 /* expire */); + if (dyn_count >= dyn_max) { @@ -1277,4 +1290,43 @@ */ - if (q == NULL && f->fw_flg & IP_FW_F_KEEP_S) - install_state(chain); + if (q == NULL && f->fw_flg & IP_FW_F_KEEP_S) { + /* + * Instead of unconditionally adding a new state, + * check the protocol and flags, and add a new state + * or ignore packet. + */ + switch(proto) { + case IPPROTO_TCP: + if (flags & TH_SYN) { + DEB(printf("-- installing state for TCP packet\n")); + install_state(chain); + } else { + DEB(printf("-- invalid TCP connection state\n")); + } + break; + case IPPROTO_UDP: + DEB(printf("-- installing state for UDP packet\n")); + install_state(chain); + break; + case IPPROTO_ICMP: + if (is_icmp_query(ip)) { + DEB(printf("-- installing state for ICMP packet\n")); + install_state(chain); + } else { + DEB(printf("-- invalid ICMP connection state\n")); + } + break; + default: + /* + * Unknown packet, if default is to accept all + * packets, add a new state, otherwise ignore. + */ +#ifdef IPFIREWALL_DEFAULT_TO_ACCEPT + DEB(printf("-- installing state for unknown packet\n")); + install_state(chain); +#else + DEB(printf("invalid unknown protocol connection state\n")); +#endif + break; + } + } #endif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message