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>