From owner-freebsd-ipfw Sat Aug 3 11:18:30 2002 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 7CDCA37B400; Sat, 3 Aug 2002 11:18:19 -0700 (PDT) Received: from smtp.a1poweruser.com (oh-chardon6a-62.clvhoh.adelphia.net [68.65.175.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB4DB43E4A; Sat, 3 Aug 2002 11:18:17 -0700 (PDT) (envelope-from barbish@a1poweruser.com) Received: from barbish (lanwin1 [10.0.10.6]) by smtp.a1poweruser.com (Postfix) with SMTP id BF8B12E; Sat, 3 Aug 2002 14:22:10 -0400 (EDT) Reply-To: From: "Joe & Fhe Barbish" To: "Crist J. Clark" Cc: "FBIPFW" , , , , , , , , Subject: RE: natd & keep-state Date: Sat, 3 Aug 2002 14:18:14 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020803070339.GC47529@blossom.cjclark.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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 So Crist we meet again. And yes you and I have been over this subject before in the FBSD-questions list. All you do is state your personal opinion that natd and keep-state works and not accept the possibility that you may be wrong. I have proven it does not by examples I have sent you in the past. You explained very nicely in http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2858187+0+archive/2002/freebsd- questions/20020217.freebsd-questions exactly what natd's problem is. I have gotten the ipfw rule set posted in the original post which started this thread to work with user ppp -nat ,ipnat and on a FBSD firewall box with no lan behind it. But it will not work with NATD. One does not have to be a genus to see that this proves there is something wrong with NATD. Crist I quote you "There is not a bug. ipfw(8) and natd(8) both work as intended. It happens that 'keep-state' and natd(8) tend not to work very well together without some serious rule gymnastics. But as I think I have mentioned to you before, when you use stateless ipfw(8) rules in combination with natd(8), you can end up with a stateful firewall. It may be easier to do that than try to pound 'keep-state' and natd(8) into submission." End quote. Let me point out to you Crist. My rule set does not use any stateless Rules or any kind of rule gymnastics to work as documented by the man pages when user ppp -nat or ipnat is used, or when there is no lan behind the IPFW firewall needing NAT services. It just does not make logical sense that natd should not function in the same manner. In my opinion, what you have stated above proves NATD does indeed contain bugs when it encounters keep-state rules and further supports my cause. The author of the keep-state option saw the need in ipfw to provide a more complete security protection of the bi-directional exchange of packets during the session conversation so fraudulent packets could not be inserted into the session conversation undetected. There was never any intent to accomplish this function with the assistance of stateless rules or rule gymnastics. That fact is proven by my keep-state rules only based rules file working when natd is not used. The evidence and even your own words conflicts with your personal opinion. On this subject your opinion has no creditable in my eyes. I have posted to this list group seeking help from a wider audience of people who are suppose to have expertise in the internals of ipfw/natd. I am of the opinion ipfw keep-state rules on individual selection rules do not function when used with the IPFW's built in natd function. Ipfw is continuously being released to the general public with out adequately being tested or this would have been found and fixed all ready. You write a lot of words, which is suppose to back up your position, but all they do is clarify my position. You have never made the effort to test my rules file for your self and provide me with a working rule set without stateless rules or coding gymnastics to prove your point that natd & keep-state rules work and I am wrong. That's what's it's going to take to get me to drop this subject. I stand on this point, prove me wrong in the form of an working rule set or admit natd is not functioning correctly and create a bug report to get it fixed. I have previous posted a bug report on this problem and you were the one who serviced that bug report and decided that this is not a problem. I think your lack of comprehending the impact this problem has on the effort to move keep-state only firewalls into the mainline of the user community to provide them with the maximum level of protection is a dis-service to the FBSD community. As I told you before, I believe cutting the natd code out of the parent ipfw program and making it an stand-a-lone function so it gets control at the same time user ppp -nat and ipnat does is the solution to this problem. It will also remove all the confusion surrounding the divert natd rule and felicitate the standardization on keep-state ipfw firewall rule sets. There is far to much emphasizes put on stateless rules and rules files coding logic based on the setup/established flags as simple stateful rules. Would like to see these two rule concepts documented as deprecated and the Advanced Stateful extensions check-state / keep-state rule concept being emphasized as the preferred ipfw rule method. IPFILTER/IPNAT all ready provides the users this level of protection. Can YOU rise to the challenge? Now don't go off the deep end, this is not a flame. I am just stating my own observations and opinions. Opinions are like assholes, everybody has one. The freedom to voice our opinions and to disagree with other peoples opinions is what this list group is all about. This is where we the FBSD user community are chartered to discuss this type of subject. More heads besides just mine and yours Crist have to address this problem. Help me get the people you know who maintain natd & ipfw to participate. They have to look into the ipfw/natd source code to design a solution. Maybe this change can be combined/included with the ipfw2 effort. I want to provoke participation by the authors of natd. Get agreement natd has a bug. Get it fixed for version 5.0. What harm is there in those goals? Joe Below is my original post for those who are just now join this thread. IPFW list members Advanced Stateful extensions were introduced in FBSD 4.0. When they first can out I changed my ipfw rules from stateless and simple stateful to using only Advanced Stateful rules for my user ppp -nat ISP connection. The ipfw rule set that works with user ppp -nat is posted below. I have tried to get this same rules file to function exchanging user ppp -nat for ipfw natd. There was always problems with natd ip address and the dynamic rules table getting mismatches so I went back to user ppp -nat. Every new version of FBSD I would try again to use natd hopping there may have been some fixes to natd, but no such luck. Each new version still failed. Each time I would post questions to the FBSD questions list, but most of the replies were from people who were having the same problems with natd and keep-state rules that I was. Well now I am forced to address the problem again because I now have cable access to the internet and I can no longer use the -nat function of user ppp. So this time I joined this ipfw list hoping my post will be read by a larger group of people who have an very technical understanding of IPFW/NATD and the Advanced Stateful extensions check-state / keep-state who will be able to Provide a solution or come to the realization that there is a bug that needs fixing. The following posted rules are the rules file that works just fine using user ppp -nat. As you can see it is very basic but demonstrates the logic flow of only allowing selected functions to be started for access to the public internet and selected functions originating from the public internet to be started for access to the local network. To use these rules for NATD I change xif="tun0" to xif="rl0" which is the Nic card cabled to the cable modem. odns1 & odns2 to the ip address of the cable providers dns servers. And add the $cmd 200 divert natd all from any to any via $xif as rule number 200 so it gets positioned before the check-state statement. The positioning of the divert statement is patterned after the /etc/rc.firewall sample. Be assured that the rc.conf and kernel options are in place to activate NATD. I an now using FBSD version 4.6. I have read and reread the ipfw man pages until I an blue in the face. I am not a newbe to FBSD or IPFW and post this in hopes of achieving a real solution in the way of a working ipfw/natd rules file based on my rules file below. I have chosen functions which should be easy for you to test on your own systems. Thanks for your help in this matter Joe # Flush out the list before we begin. /sbin/ipfw -q -f flush # Set rules command prefix # The -q option on the command is for quite mode. # Do not display rules as they load. Remove during development to see. #cmd="/sbin/ipfw -q add" cmd="/sbin/ipfw add" # Set defaults # set these to your external interface network xif="tun0" odns1="218.216.115.111" # ISP's dns server 1 IP address odns2="218.216.115.112" # ISP's dns server 2 IP address # Set these to your inside interface network iif="xl0" # Nic card # Internal gateway housekeeping $cmd 100 allow all from any to any via lo0 # allow all localhost $cmd 150 deny all from any to 127.0.0.0/8 # deny use of localhost IP $cmd 160 deny all from 127.0.0.0/8 to any # deny use of localhost IP $cmd 180 allow all from any to any via $iif # allow all local LAN ######## control section ############################################ $cmd 500 check-state # Deny & log all fragments as bogus packets $cmd 502 deny log all from any to any frag via $xif # Deny & log ACK packets that did not match the dynamic rule table $cmd 501 deny log tcp from any to any established via $xif ######## outbound section ########################################### # Interrogate packets originating from behind the firewall, private net. # Upon a rule match, it's keep-state option will create a dynamic rule. # Allow out www function $cmd 600 allow tcp from any to any 80 out via $xif setup keep-state # Allow out access to my ISP's Domain name server. $cmd 610 allow tcp from any to $odns1 53 out via $xif setup keep-state $cmd 611 allow udp from any to $odns1 53 out via $xif keep-state $cmd 615 allow tcp from any to $odns2 53 out via $xif setup keep-state $cmd 616 allow udp from any to $odns2 53 out via $xif keep-state # Allow out send & get email function $cmd 630 allow tcp from any to any 25,110 out via $xif setup keep-state # Allow out & in FBSD (make install & CVSUP) functions # Basically give user id root "GOD" privileges. $cmd 640 allow tcp from me to any out via $xif setup keep-state uid root # Allow out ping $cmd 650 allow icmp from any to any out via $xif keep-state # Allow out TELNET $cmd 660 allow tcp from any to any 23 out via $xif setup keep-state ############ passive FTP rules for LAN PC FTP to public Internet ###### # Allow passive FTP control channel 21 & data high ports $cmd 700 allow tcp from any to any 21 out via $xif setup keep-state $cmd 710 allow tcp from any to any 10000-65000 out via $xif setup keep-state ##### End of passive FTP rules for LAN PC FTP to public Internet ###### ######## inbound section ############################################ # Allow in www $cmd 800 allow tcp from any to any 80 in via $xif setup limit src-addr 4 # Allow in ssh function $cmd 820 allow log tcp from any to me 22 in via $xif setup limit src-addr 4 # Allow in Telnet $cmd 830 allow tcp from any to any 23 in via $xif setup limit src-addr 4 #$cmd 830 allow tcp from any to any 23 in via $xif setup keep-state ######## catch all section ############################################ # Stop & log external redirect requests. $cmd 845 deny log icmp from any to any icmptype 5 in via $xif # Stop & log spoofing Attack attempts. $cmd 850 deny log ip from me to me in via $xif # Stop & log ping echo attacks # stop echo reply (ICMP type 0), and echo request (type 8). $cmd 860 deny log icmp from any to me icmptype 0,8 in via $xif # Reject & Log all setup of incoming connections from the outside $cmd 900 deny log tcp from any to any setup in via $xif # Everything else is denied by default # deny and log all packets that fall through to see what they are $cmd 910 deny log logamount 500 all from any to any ####################################################################### -----Original Message----- From: owner-freebsd-ipfw@FreeBSD.ORG [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Crist J. Clark Sent: Saturday, August 03, 2002 3:04 AM To: Joe & Fhe Barbish Cc: FBIPFW Subject: Re: natd & keep-state On Wed, Jul 31, 2002 at 10:07:59PM -0400, Joe & Fhe Barbish wrote: > IPFW list members > > Advanced Stateful extensions were introduced in FBSD 4.0. When they > first can out I changed my ipfw rules from stateless and simple > stateful to using only Advanced Stateful rules for my user > ppp -nat ISP connection. The ipfw rule set that works with user > ppp -nat is posted below. I have tried to get this same rules file to > function exchanging user ppp -nat for ipfw natd. There was always > problems with natd ip address and the dynamic rules table getting > mismatches so I went back to user ppp -nat. Every new version of FBSD > I would try again to use natd hopping there may have been some fixes > to natd, but no such luck. Each new version still failed. Each time I > would post questions to the FBSD questions list, but most of the > replies were from people who were having the same problems with natd > and keep-state rules that I was. Well now I am forced to address the > problem again because I now have cable access to the internet and I > can no longer use the -nat function of user ppp. So this time I joined > this ipfw list hoping my post will be read by a larger group of people > who have an very technical understanding of IPFW/NATD and the Advanced > Stateful extensions check-state / keep-state who will be able to > Provide a solution or come to the realization that there is a bug > that needs fixing. Deja vu. I think we've been through this before, http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2858187+0+archive/2002/freebsd- questions/20020217.freebsd-questions There is not a bug. ipfw(8) and natd(8) both work as intended. It happens that 'keep-state' and natd(8) tend not to work very well together without some serious rule gymnastics. But as I think I have mentioned to you before, when you use stateless ipfw(8) rules in combination with natd(8), you can end up with a stateful firewall. It may be easier to do that than try to pound 'keep-state' and natd(8) into submission. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org 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