Eliminating IPv6 (?)

[Ronald F. Guilmette]

In message <BAC48B99-6ABA-4C05-A1C5-1112076A9290 at punkt.de>, 
"Patrick M. Hausen" <hausen at punkt.de> 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