Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 3 Aug 2002 14:28:54 -0700
From:      "Crist J. Clark" <crist.clark@attbi.com>
To:        Joe & Fhe Barbish <barbish@a1poweruser.com>
Cc:        FBIPFW <freebsd-ipfw@FreeBSD.ORG>, 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>
In-Reply-To: <MIEPLLIBMLEEABPDBIEGIEFKCHAA.barbish@a1poweruser.com>
References:  <20020803070339.GC47529@blossom.cjclark.org> <MIEPLLIBMLEEABPDBIEGIEFKCHAA.barbish@a1poweruser.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20020803212854.GA55652>