Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Apr 2002 20:24:39 -0700
From:      "Crist J. Clark" <crist.clark@attbi.com>
To:        Joe & Fhe Barbish <barbish@a1poweruser.com>
Cc:        freebsd-bugs@FreeBSD.ORG
Subject:   Re: kern/36683: Stop dynamic rules from displaying using ipfw list command
Message-ID:  <20020407202439.T70207@blossom.cjclark.org>
In-Reply-To: <LPBBIGIAAKKEOEJOLEGOCEGGCNAA.barbish@a1poweruser.com>; from barbish@a1poweruser.com on Sun, Apr 07, 2002 at 09:24:20PM -0400
References:  <20020407125833.P70207@blossom.cjclark.org> <LPBBIGIAAKKEOEJOLEGOCEGGCNAA.barbish@a1poweruser.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 07, 2002 at 09:24:20PM -0400, Joe & Fhe Barbish wrote:
> Crist Thanks you have cleared up some of the items, but I still have
> questions.
> 
> >That is not at all what I am saying. The functionalities of those
> >sysctl(8) knobs only take effect after a packet has gone through the
> >firewall rules. If the packet is dropped in the firewall, the packet
> >is dropped. End of story for that packet. The function of these never
> >comes into play. These only affect packets after ipfw(8). For packets
> >that get dropped, there is no "after" ipfw(8).
> 
> This is your prvious reply about that group of sysctl knobs. I have test
> results that do not agree with what you are saying. My test example is as
> follows
> 
>  00610 allow tcp  from any to 63.110.55.10 53 out via tun0 setup keep-state
>  00611 allow udp  from any to 63.110.55.10 53 out via tun0 keep-state
>  00910 deny log all from any to any
> 
> Here rule 610 & 611 only let out DNS requests to my ISP dsn server and
> accepts the replys back in. There are no other rules, so rule 910 denys
> and logs every thing else in or out.
> I receive this log message from log_in_vain 'connection attempt to udp
> 206.13.75.122:1042 from 63.110.55.10:53.'
> 
> In my log I do not have an entry for this packet rejected by rule 910.
> The test results indicate the log_in_vain knob got control before the ipfw
> rules.
> If log_in_vain got control after the ipfw rules then rule 910 would have
> rejected
> and logged it and log_in_vain would have never seen it.
> 
> Now please explain how you think rule 910 got bypassed and the log-in-vain
> function executed after ipfw was done with the packet.

Rule 910 did not get bypassed. That packet was passed by a dynamic
rule associated with 611. You sent out a DNS query to 63.110.55.10:53
from 206.13.75.122:1042 (I assume that is your IP address). This
passed 611 and created a dynamic rule. The response came back passed
the dynamic rule. When the packet came out of the firewall after being
accepted, it got logged in vain.

> On the subject of ipfw forwarding and ipfw divert, let me summarize.
> 
> The ipfw divert command and ipdivert are two separate things and unrelated?

Huh? What is "ipdivert?"

> The ipfw divert commands sole purpose is to branch to the natd external
> kernel program from within the ipfw rule set to perform network address
> translation between private and public address.

No, look at the manpage again. divert(4) is a much more general
tool. It is a way to send packets that match firewall rules out to
and back from userland by using socket(2)s. divert(4) is most
frequently used with natd(8), but it is not limited to natd(8).

> If natd is enabled in rc.conf but never called from ipfw using the divert
> command, will natd do the NAT function on the packet before it enters ipfw?

No. natd(8) will sit there listening on the divert(4) socket, but with
no 'divert' rule in the firewall, nothing will ever be sent to it.

> FTP
> 
> >No, when using passive FTP, the client initiates all of the
> >connections.
> >
> >  allow tcp from any to any out via tun0 setup keep-state
> 
> The rule you show above to allow passive ftp to function is way too open,
> it allows any tcp functions to be started not just ftp. Nobody is going to
> open the doors like that.

It allows any TCP connection originating on the internal, "trusted"
network out. That is a _very_ common security policy.

> >> In 4.4 I have to use these 2 rules to do that for passive FTP.
> >>
> >>     allow tcp from any    to any 21        out via tun0 setup keep-state
> >>     allow tcp from any 20 to any 1024-49151 in via tun0 setup keep-state
> >
> >Ack! A very insecure rule.
> 
> Yes I said that myself. So since your wide open any to any rule is ridicules
> and my rule above is a insecure rule. What rule syntax do I use for a secure
> ftp out bound request that handles the complete session conversation?

No, this is much less secure than the rule I gave. In the one I gave,
anything on your trusted network can initiate TCP connections to the
outside world. No one can initiate an incoming connection. However,
with your rule, anyone from the outside can initiate a TCP connection
to any machine on your internal network in the 1024-49151 port range
(which includes things like NFS, most any other RPC service, X
servers, etc.).
-- 
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-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020407202439.T70207>