Date: Tue, 19 Oct 1999 01:22:05 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Jerry Bell <jerry@bellnetworks.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: IPFW Improvements. (comments?) Message-ID: <Pine.BSF.4.10.9910190114150.25065-100000@current1.whistle.com> In-Reply-To: <380BECA0.620E5226@bellnetworks.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Oct 1999, Jerry Bell wrote: > I have a few proposed additions to IPFW that I'd like to get feedback > on. The changes are mostly from my experience with other (commercial) > firewalls. > > Change source and destination identifier in the rule processing from one > IP address (or range of addresses) to an array of IP addresses (or range > of IP addresses). This allows for a more manageable rulebase. > ex. ipfw add pass all from 10.0.0.1/24,10.0.1.0/24 to > 10.0.0.1/24,10.0.1.0/24 > The real advantage is being able to do somethine like this: > > #!/bin/sh > dnservers=10.0.0.1,10.0.0.2,10.0.0.3 > smtpservers=10.0.0.4,10.0.0.5,10.0.0.6 > ipfw add pass udp from any to $dnservers 53 > ipfw add pass tcp from any to $smtpservers 25 > > ... and so on. but you need to store this somewhere.. the present system of fixed structures doesn't support this without an enormous waste of space...I'm not sure how useful it would be in practice.. It would require rewriting of large parts of the code, not to mention a complete rewrite of the interface and user program. This is the kind of thing that is easy to say to a human and a bitch to implement. > > > A really nice feature would be remote authentication to open certain > firewall rules to the source IP address. The way most other > implementations work is the firewall listens on a certain port for > authentication. The user telnets to that port enters a > username/password and gets authenticated. This allows traffic from that > users IP address to pass through certain firewall rules. IPFW already > supports uid/gid checks in the rule processing. (kerberos, or some > other authentication scheme may work better, since it is encrypted) A > 'listener' for authentication and a way to bind the uid/gid to an IP > address would be needed. Also, a ttl probably should be specified on a > rule by rule basis. This can already be done with a daemon without any ipfw changes.. The daemon adds a rule to allow itself to be connected to. When it get's a successful authentication, it adds more rules to allow the successful user in. > > Finally, a tcp connection state table. Presently, the common method of > designing IPFW rulebases is to restrict which source ip addresses and/or > destination port numbers are allow to make a connection using the > 'setup' flag, then allowing all tcp packets which are 'established' to > pass through. In an ideal world, this works pretty well, but in reality > you can't make any assumptions about the equipment you are protecting > behind the firewall. The ability to squelch ALL tcp traffic which has > not gone through the proper setup routine (and thus firewall > examination) would be very useful. This is what NATD does to some extent.. it would be possibel to have a kernel natd in conjunction with ipfw.. patches accepted. > > The big problems with the state table is that it takes up a lot of cpu > time and memory, especially on busy connections. This would probably > best be left as a kernel mod or an additional ipfw parameter, and not > the default behavoir, since it is so resource intensive. Or a daemon.. NATD anyone? > > I'm interested in hearing your feedback as to the viability of these > changes and any comments. I am not sure who is maintaining IPFW, so I > do not know if these issues have already come up. I could probably > stumble through the first change (source/destination arrays), but the > other two are probably beyond my abilities right now. The first is the hardest.. unless you implement it as a group of rules. > > I appreciate your time. > > Jerry > jerry@bellnetworks.net > http://www.bellnetworks.net/cs > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" 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.10.9910190114150.25065-100000>