Date: Mon, 18 Oct 1999 23:59:28 -0400 From: Jerry Bell <jerry@bellnetworks.net> To: freebsd-hackers@freebsd.org Subject: IPFW Improvements. (comments?) Message-ID: <380BECA0.620E5226@bellnetworks.net>
next in thread | raw e-mail | index | archive | help
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. 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. 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. 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. 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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?380BECA0.620E5226>