From owner-freebsd-questions@freebsd.org Tue Jun 18 20:13:53 2019 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6EAB15C7719 for ; Tue, 18 Jun 2019 20:13:52 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 959DC8C77D for ; Tue, 18 Jun 2019 20:13:50 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id B3CFB4E668; Tue, 18 Jun 2019 13:13:48 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Re: Eliminating IPv6 (?) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23904.1560888828.1@segfault.tristatelogic.com> Date: Tue, 18 Jun 2019 13:13:48 -0700 Message-ID: <23905.1560888828@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 959DC8C77D X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-5.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.75)[ip: (-7.23), ipnet: 69.62.128.0/17(-3.61), asn: 14051(-2.85), country: US(-0.06)]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; NEURAL_HAM_SHORT(-0.95)[-0.945,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 20:13:53 -0000 In message , "Patrick M. Hausen" wrote: >I doubt it would qualify as a bug - possibly a bug in the docs, yes. > >Because the observed behaviour is definitely intentional. The flow of >statements in rc.firewall is: > >0. flush all rules >1. setup_loopback >2. setup_ipv6_mandatory > >and no configuration is going to skip that... This behavior is unambiguously -different- from prior FreeBSD releases. As such it violates the design principal of "least surprise", at least for users such as myself who are "upgrading" from some prior release. Whether that violation of that design principal constitutes a "bug" or not is clearly in the eye of the beholder. >So, yes, there will always be mandatory IPv6 rules in place... I cannot comment on setup_ipv6_mandatory since I am ernestly endevoring entirely avoid even thinking about IPv6. Regarding the setup_loopback() function within /etc/rc.firewall however, I do question the wisdom of the following two lines, in particular: ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any I'm sure that a case could be made for the proposition that pretty much any kind of DENY rule may, in some contexts and circumstances, provide some additional protection against something. I have to say however that my limited networking knowledge is very much "old school" and when I was coming up, it was considered quite routine and normal to check to see if a given daemon (e.g. Sendmail or Apache) was or was not running on the local server by simply telnet'ing to 127.0.0.1 and the relevant port number. The above two lines appear to me to eschew that longstanding and traditional practice, for "security" reasons that are none too obvious, to me at least. My point is that unless and until someone persuades me that the (admittedly small) inconveniences created by the above two rules are actually buying me -anything- in the way of enhanced security, I, for one, do not and will desire to have these rules added to my own own (finely tuned?) IPFW rules, whether I like it or not. I prefer instead to have the traditional complete control over rules which, in prior FreeBSD releases, was afforded by explicit speification of a local IPFW rules list and one which would not be overridden or "enhanced" based on anyone's judgement other than my own. And as long as we are on the subject of the judgements made within the current (12.0-RELEASE) /etc/rc.firewall script, let me say also that, while doing my recent "upgrade" I asked on the freebsd-ipfw mailing list for some clarification as to the exact semantics of, and the differences between, the "client" and "simple" options, as presented in Section 30.4.1 of the Handbook. I was basically blown off and told to go and read the source of /etc/rc.firewall, which I then did. Subsequent to that, I tried using the "simple" option, hoping that this might in some ways be superior (i.e. more secure) than continuing to use the set of ad hoc and personally hand-written IPFW rules that I had been using for years on my old system. I abandoned this attempt very quickly however, as soon as I realized that the pre-canned "simple" option did not allow me to even ping the other devices on my own private RFC 1918 local network, e.g. to see which ones were up and which ones wern't. Here again, somebody somewhere apparently decided that the ability to ping other devices on the local RFC 1918 network represented a security risk. If that's actually true, then all I can say is that I personally didn't get the memo. It all comes back to configurability and personal choice. I elect to use my own set of IPFW rules. And having made that choice, I neither expect nor want that choice fiddled with. (It *wasn't* fiddled with in many prior releases.) If I want someone to hold my little hand, make decisions for me, behind my back and without my consent or knowledge, then I'll use some operating system created in Redmond, Washington. Regards, rfg