Date: Sun, 7 Apr 2002 21:24:20 -0400 From: "Joe & Fhe Barbish" <barbish@a1poweruser.com> To: <cjclark@alum.mit.edu> Cc: <freebsd-bugs@FreeBSD.ORG> Subject: RE: kern/36683: Stop dynamic rules from displaying using ipfw list command Message-ID: <LPBBIGIAAKKEOEJOLEGOCEGGCNAA.barbish@a1poweruser.com> In-Reply-To: <20020407125833.P70207@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ******************************************************************** On the subject of ipfw forwarding and ipfw divert, let me summarize. The ipfw divert command and ipdivert are two separate things and unrelated? 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. 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? ******************************************************************** 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. >> 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? ----Original Message----- From: Crist J. Clark [mailto:crist.clark@attbi.com] Sent: Sunday, April 07, 2002 3:59 PM To: Joe & Fhe Barbish Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/36683: Stop dynamic rules from displaying using ipfw list command On Sun, Apr 07, 2002 at 01:55:42PM -0400, Joe & Fhe Barbish wrote: > Thank You Crist for your reply, I am still confused on some of the > questions and would like to discuss them in more detail. > > >> When do these sysctl mibs get control, before the packet gets to > >> ipfw or after the packets have passed through the ipfw firewall? > >> > >> net.inet.icmp.drop_redirect=1 > >> net.inet.icmp.log_redirect=0 > >> net.inet.ip.redirect=0 > >> net.inet.icmp.bmcastecho=0 > >> net.inet.tcp.blackhole=2 > >> net.inet.udp.blackhole=1 > >> net.inet.tcp.log_in_vain=1 > >> net.inet.udp.log_in_vain=1 > > > >After. > > The ipfw firewall is built on the foundation principle that every packet > passes through the firewall rules and if the packet does not match any of > the rules it gets rejected by default. Yes. (Generally, you can change the final default rule to accept with the appropriate kernel configuration option of course.) > Now your answer "after" is saying > that packets which get caught by the above Mibs have passed through the > ipfw firewall and do not get caught by the default rule that is suppose > to deny everything. What you are saying is in direct conflict of how > ipfw works. Please explain what is really happening with these packets > that they are not being caught by the ipfw default reject rule. 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). > Crist, don't take this the wrong way, But your answers to my questions about > how the new limit option works did not answer my questions. > 'I believe' translated into, I do not know for sure, and have not looked > into it to find out, here is my best educated guess. My educated guess is > the author of the new limit function either dove-tailed the limit logic into > the existing dynamic rules table or pirated some of that code and built his > own > limit dynamic table or a variation there of. No, it's simpler than that, 'limit' rules just use the same code, not a copy of, the same code path, as all other dynamic rules. A 'limit' rule behaves just like any other 'keep-state' rule except when one goes to add a new dynamic rule, you check how many dynamic rules have already been created. If you are at the limit, you don't allow the creation of a new dynamic rule. This effectively blocks any more connections. That said, some code had to be added to the path to handle some of the issues dynamic rules create (you store information in the parent rule, whereas other keep-state rules do not modify the parent rule), but these don't (shouldn't) have any impact on how the user sees things work. So the moral of the story is, 'limit' rules are just like any other 'keep-state' rule except for the advertised additional functionality. [snip] > I interpret this sentence from the man page example 'The former (assuming it > runs on a gateway) will allow each host on a /24 network to open at most 10 > TCP connections.' to mean that using my original question below the first > group is what is really happening and not the second group as you said. > Crist, you are in the inner circle and have access to the author of the > limit option. Please contact the author to get the details or put me in > contact with the author so we can work out the answers, one on one. > > > ipfw add allow tcp from any to me setup limit src-addr 4 I was thinking backwards when I read that the first time. > > Is it saying that for each unique ip address in the src ip > > address field it will allow up to 4 simultaneous connections? > > So I would see > > > > src_ip_addr 122.33.45.11 accept > > src_ip_addr 122.33.45.12 accept > > src_ip_addr 122.33.45.12 accept > > src_ip_addr 122.33.45.11 accept > > src_ip_addr 122.33.45.11 accept > > src_ip_addr 122.33.45.12 accept > > src_ip_addr 122.33.45.12 accept > > src_ip_addr 122.33.45.11 accept > > src_ip_addr 122.33.45.11 rejected This _is_ how it would work. > ****************************************** > > >> kern.ipc.somaxconn=1024 > > >Hmmm... Not sure if this is a good idea in the first place or if it is > >even relevant now with the SYN-cookie implementation. > > I have no frame of reference to even begin to understand what you are > saying here. Please explain what the 'SYN-cookie implementation' is, > and what release it is in? What I was talking about was this: It's been in -STABLE since mid-December, revision 1.107.2.20 date: 2001/12/14 20:21:12; author: jlemon; state: Exp; lines: +264 -462 MFC: syncache support. And the original log for -CURRENT, revision 1.143 date: 2001/11/22 04:50:43; author: jlemon; state: Exp; lines: +261 -470 Introduce a syncache, which enables FreeBSD to withstand a SYN flood DoS in an improved fashion over the existing code. Reviewed by: silby (in a previous iteration) Sponsored by: DARPA, NAI Labs Explaining how it works is... complicated. See section 2.1.4 of the 4.5-RELEASE release notes for a high-level description, http://www.freebsd.org/releases/4.5R/relnotes-i386.html#AEN21 > >> net.link.ether.inet.max_age=600 > > >Cutting the age in half will have little impact on that type of > >attack. > > What do you mean by your statement? Are you saying the age limit needs to > be even shorter, say 100 or 200 or what? This attack type is targeted at > creating an Denial of Service when the ARP table fills up. When this type > of thing happens to the dynamic rules table the solution is to shorten the > life time limit to release table resources faster, so it's only normal that > this same solution will work here also. Please clarify what you mean. If someone can spit hundreds of ARP packets per second to you, you would have to set this to a rediculusly low level to try to prevent a DoS attack. When you set it so low, you start killing yourself since you need to send out ARPs so often to update your cache. Playing with that sysctl(8) setting is not relevent to any DoS attack I can think of. > >> These are /etc/rc.conf options. The first 2 have sysctl mibs, what > >> is the relationship between the mibs and these rc.conf options. > >> Does the exclusive use of keep-state rules address what the > >> tcp_drop_synfin option is doing? > > > >Look at the code in the rc-files for each one. > > You really lost me with this statement. What rc.files are you talking about? > Where are they located. There is no /etc/rc.tcp_drop_synfin file. $ grep 'tcp_drop_synfin' /etc/rc* /etc/rc.network: case ${tcp_drop_synfin} in $ more /etc/rc.network . . . case ${tcp_drop_synfin} in [Yy][Ee][Ss]) echo -n ' drop SYN+FIN packets=YES' sysctl net.inet.tcp.drop_synfin=1 >/dev/null ;; esac As for the specific question about 'keep-state' and 'tcp_drop_synfin,' they have nothing to do with one another. > >> Does the blackhole mib do the same thing as the tcp_restrict_rst option? > > >There is no such option anymore. > > Again what are you talking about? Which MIB are you referring to and in > what version of FBSD are you referring to? There is no tcp_restrict_rst anymore, date: 2001/06/09 16:18:11; author: des; state: Exp; lines: +1 -8 MFC: Nuke the TCP_RESTRICT_RST option. Since 'blackhole' did the same thing. That was merged into 4.3-STABLE very shortly after 4.3-RELEASE. > >> What is the exact difference between ipfw forwarding and ipfw divert? > >> From what I read in the man page it's just a play on words and they both > >> do the same thing. > >> Is forward the ipfw version of the external divert program? > > >Very, very, different. 'divert' sends a packet to a divert(4) > >socket. 'fwd' actually sends a packet to a new network > >destination. 'fwd' involves no userland programs. > > Yes this is very obvious from the ipfw man page info that divert is an > external program and forward is built into ipfw. But my question still > is unanswered. 'Is forward the ipfw version of the external divert program?' > Maybe I need to clarify my question. As user ppp has a built in Nat > function and there is a natd external program which does the same thing. Here is what happens in these two cases. For natd(8), packets enter the machine through a NIC or some network interface. They get passed through the firewall rules. The packet matches a divert(4) rule and gets passed out to a userland program, in this case natd(8). natd(8) uses the libalias(3) code to work its magic on the packet and passes it back in via the same divert(4) socket. The packet continues through the firewall. For ppp(8), a packet comes in over the serial line from the modem device. ppp(8), a userland program, is IP aware and uses the libalias(3) code again to do NAT magic on the packets. When ppp(8) is all done, it passes the packet to the tun(4) device (a network interface) and the packet starts its way through the firewall. In a diagramatic sense we have, natd(8) (NAT) ^ | | v network ---> interface ---> ipfw(8) ---> IP stack PPP link ---> ppp(8) ---> interface ---> ipfw(8) ---> IP stack (NAT) (tun(4)) The 'fwd' for ipfw(8) never enters into any of this. > So is ipfw forward the ipfw version of the external divert program and > ipfw goes one step further by enabling ipfw to issue rules which will pass > packets direct to the external divert program. Now the common functionally > in both cases is a another box on the lan behind the firewall can be pointed > to by a port number which is different that what was contained in the > original packet. The documentation on forward is very sparse and not very > enlighten. Please describe what exactly forward is intended to do in the > light of what divert does. I think people believe the documentation on 'fwd' is sparse because they do not realize how simple it is. All 'fwd' does is send a packet to a specific destination regardless of the address on the packet. If you gateway has, fwd 192.0.2.1 tcp from any to 192.0.2.100 10000 When it processes a packet like so, tcp 10.10.10.100:32198 -> 192.0.2.100:10000 It sends it to 192.0.2.1 instead of 192.0.2.100. That's all 'fwd' does, nothing more, nothing less. So 192.0.2.1 will receive a packet with headers saying, tcp 10.10.10.100:32198 -> 192.0.2.100:10000 > Finally we come to the FTP question. I get the idea from your response that > a request from behind the firewall to start an FTP session with a FTP server > on the public internet can be coded with one keep-state ipfw rule that will > allow the complete session conversation to happen (including the FTP server > opening data port 20 and the sending of data over the high port range) if > the original request uses passive 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 Allows passive FTP to work (you can make that rule much more restrictive with respect to the source and destination addresses of course). That may or may not jibe well with your site 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. > Why does the first rule not handle the complete session conversation? Because FTP uses separate control and data connections. The first rule only passes the control connection. -- 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?LPBBIGIAAKKEOEJOLEGOCEGGCNAA.barbish>