From owner-freebsd-ipfw Sat Aug 3 14:29:15 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 A478237B400; Sat, 3 Aug 2002 14:29:05 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id E96F543E65; Sat, 3 Aug 2002 14:29:04 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020803212904.TTDL22139.rwcrmhc52.attbi.com@blossom.cjclark.org>; Sat, 3 Aug 2002 21:29:04 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g73LT2JK056103; Sat, 3 Aug 2002 14:29:03 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g73LSt0U056102; Sat, 3 Aug 2002 14:28:55 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Sat, 3 Aug 2002 14:28:54 -0700 From: "Crist J. Clark" To: Joe & Fhe Barbish Cc: FBIPFW , archie@whistle.com, cmott@scientech.com, perhaps@yes.no, suutari@iki.fi, dnelson@redwoodsoft.com, brian@awfulhak.org, ru@FreeBSD.ORG, rizzo@icir.org Subject: Re: natd & keep-state Message-ID: <20020803212854.GA55652@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20020803070339.GC47529@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ 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 On Sat, Aug 03, 2002 at 02:18:14PM -0400, Joe & Fhe Barbish wrote: > 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. Right, I told you to use 'ppp -nat' since it you don't run into this problem. The problem is, as I have shown over and over, that when you use natd(8), the source or destination of a NATed packet change mid-way through a set of firewall rules. This is how natd(8) works. This is how natd(8), using divert(4) is _supposed_ to work. However, the fact that addresses change and how they change depends on the direction (in or out of the firewall) makes this _feature_ (not bug) of natd(8)-divert(4)-ipfw(8) interaction not play well with 'keep-state' rules. But when you use 'ppp -nat' the NAT step no longer takes place in the firewall rules at all. The rules, the 'keep-state' rules in particular, always see the packets with internal addresses still on them. Thus, 'keep-state' rules work with no problems. (Note that this is also how IPFilter works. All of the NAT takes place before or after the packets go through the filter rules.) > 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. Right, for the reasons I have explained several times. > 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. Again, everything is working how is was designed to. The _designs_ of doing NAT with natd(8)-divert(4)-ipfw(8) and using 'keep-state' rules do not work well. It's not a bug in the program. The systems were never designed with compatibility in mind. > 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. Sure you can. Anyone who can sniff a connection can insert stuff into a vanilla TCP session. There is no way to stop that with firewall rules. 'keep-state' rules prevent packets not associated with a particular TCP session from passing the firewall. That is, I cannot pass a random ACK packet through a firewall using 'keep-state' rules. > There was never > any intent to accomplish this function with the assistance of stateless > rules or rule gymnastics. And there was no intent to make any special features to get it to work with natd(8). > That fact is proven by my keep-state rules > only based rules file working when natd is not used. Yep, they work as intended. > The evidence and even your own words conflicts with your personal opinion. I don't see how. > On this subject your opinion has no creditable in my eyes. Fine, whatever. But the ipfw(8) and natd(8) developers seem to hold the same opinion. Maybe if you proposed some possible way for natd(8) and 'keep-state' rules to work well together someone could do it. > 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. See the archive. People post with this problem/question several times per month. And they get the same answer you do. > 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 I don't have to. I can read them and see that, like you say, they wouldn't work. > 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. The following partial ruleset shows what worked fine for me for years, add divert natd ip from any to any add tcp from any to any 80 keep-state out via $xif add tcp from any to any 80 keep-state in via $iif But this won't work right for everyone or for every service. It does pretty well for something like HTTP. > That's what's it's going to take to get me to drop this subject. For someone else to write your ruleset for you? And for them to not write a ruleset that merely applies your security policy properly, but applies your policy _and_ tries to use certain features purely for the sake of using them? > 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. *sigh* ONE MORE TIME. natd(8)-diver(4)-ipfw(8) works as designed, so there is no bug. ipfw(8) 'keep-state' works as designed, so there is no bug. The two WERE NEVER DESIGNED TO BE USED TOGETHER, so there is no bug. No one ever told you that they would work well together. My PC's CDROM doesn't play DVDs. I would like it to, but it is not a bug because of that. It was not designed to play DVDs, and no one ever told me that it would. > 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. Talk to luigi, the ipfw(8) maintainer, or ru, the natd(8) maintainer, and see what they say then. As I said before, if you or someone else has thought of a good way to get 'keep-state' and natd(8) to work well together, send in the patches or the plan. > As I told you before, I believe cutting the natd code out of the > parent ipfw program This is just it, natd(8) really has no direct ties to ipfw(8) at all. natd(8) is a daemon that runs out in userland. ipfw(8) is a command that tinkers with the firewall ruleset in the kernel. The firewall ruleset and natd(8) really don't have any interaction except for passing data (the raw packets) back and forth over a divert(4) socket. This fundamental lack of understanding makes it clear why you don't understand how I can say that everything works as designed. > 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. But it would not be natd(8) anymore. It would have to be some completely new mechanism that does NAT in the kernel. Either that or you would need hooks out to userland somewhere else (like ppp(8) has). Yeah, it'd be cool to have that. You can (a) write the code up to do this yourself, (b) pay someone else to write the code up, or (c) find someone to volunteer to do (a) or (b). Just wishing for it will not make it happen. Sending long winded messages to mail lists trying to label your desired new features as an existing bug will not necessarily do it either. > 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? I could, but I don't need to. I don't need to write new code to do what I want with firewalls. Everything I need is there. Maybe if hadn't gotten back to fulltime work, I could do it for kicks, but not when I sit at a computer dealing with networking and firewalls all day at work. > 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. *wave* Hi, ru. Hi, luigi. > They have to look into the ipfw/natd source code to design a solution. They _have to?_ > Maybe this change can be combined/included with the ipfw2 effort. If you put NAT in ipfw(8), you wouldn't need natd(8) at all. There are some new rule types and features you could add to ipfw(8) to make rule gymnastics easier, but you would still need gymnastics (e.g. a rule action that establishes a dynamic rule, but does not accept the packet and lets it continue through the ruleset might help). > I want to provoke participation by the authors of natd. > Get agreement natd has a bug. You want to depricate natd(8). > Get it fixed for version 5.0. > What harm is there in those goals? Harm? Introducing new code is usually somewhat of a security hazard. The question is actually, "What is the benefit versus the cost? And who is willing to pay the cost?" -- 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