Date: Wed, 6 Sep 2000 16:34:24 -0500 (CDT) From: missnglnk <missnglnk@sneakerz.org> To: Luigi Rizzo <luigi@info.iet.unipi.it> Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: Issues with ipfw(8)'s dynamic rules Message-ID: <Pine.BSF.4.21.0009061513420.44236-100000@sneakerz.org> In-Reply-To: <Pine.BSF.4.21.0009050845390.39513-100000@sneakerz.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 Sep 2000, missnglnk wrote:
> Date: Tue, 5 Sep 2000 08:46:11 -0500 (CDT)
> From: missnglnk <missnglnk@sneakerz.org>
> To: Luigi Rizzo <luigi@info.iet.unipi.it>
> 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 <missnglnk@sneakerz.org>
> > To: Luigi Rizzo <luigi@info.iet.unipi.it>
> > 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 <luigi@info.iet.unipi.it>
> > > To: missnglnk <missnglnk@sneakerz.org>
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009061513420.44236-100000>