NFS tcp wrapper situation

[Ric Wheeler]

Warren Togami wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=480420#c17
>
> Here is some background information of how this happened.  A long
> standing bug in NFS since August 2000 is that it did not support tcp
> wrappers /etc/hosts.deny and /etc/hosts.allow.  This was fixed upstream,
> but then they discovered an issue.
>
> /etc/hosts.deny:
> mountd: badhost.example.com
>
> If DNS is down or the source IP address lacks a reverse lookup, then it
> has no way of knowing that it is meant to be denied.  It allows the
> connection.  This was considered to a be an unacceptable bug.  If
> someone specifies a hostname, from a security perspective they expect
> the failure case to err to the side of caution and deny by default if
> cannot affirm that the incoming client is not a listed denied hostname.
>  Thus "deny upon reverse DNS failure" became the default behavior in
> nfs-utils.
>
> This manifested in F-9 and F-10 with a many people suddenly unable
> to NFS mount after nfs-utils update hit mirrors ~January 14th.  This is
> especially problematic in cases where people use caching DNS
> nameservers, as it is non-trivial to explain to everyone how to setup a
> proper DNS for arbitrary addresses.  These individuals might also have
> no control over DNS on their network.
>
> I believe that "hostname in /etc/hosts.deny fails to deny" should be
> NOTABUG for several reasons:
>
> * BAD POLICY and MISCONFIGURATION.
> TCP wrappers is behaving exactly how it is defined in policy.  Hostname
> in hosts.deny (itself always a bad idea) is dependent on the DNS server
> to be properly configured and operating.  Failure due to hostnames in
> /etc/hosts.deny is MISCONFIGURATION.  If they are really concerned about
> unknown clients connecting to that service, then they should use a
> wildcard like "mountd: ALL" and allow specific hosts or IP ranges in
> /etc/hosts.allow.

I disagree - you can easily get into a situation here where a user has 
put "badhost.example.com" into hosts.deny and by your argument, if DNS 
lookup fails, you will always allow them in.

Clearly, not the correct response for a security policy.

As we discussed with Steve D this afternoon, I think that the correct 
behaviour would be to:

    (1) Fix tcp wrappers to parse the /etc/hosts.* files and disable 
this denial if no rules for your service are defined.
    (2) If you don't believe in this policy, either uninstall TCP 
wrappers OR use only IP addresses in the /etc/hosts.* files.

What you are proposing would flip the security policy on its head - if 
you cannot resolve the hostname, always allow access.

To recap, to trigger this concern you have, you have to take the 
following steps:

    (1) Edit either file and install an allow or deny rule with 
hostnames (we currently ship without any rules defined, the files are 
effectively empty)
    (2) Have a DNS failure
    (3) Have configured NFS service

The fix for a user is easy - change the hostnames to IP addresses or 
uninstall TCP wrappers, right?

I really, really don't see this as anything other than correcting a long 
standing bug.

A different (and very valid) argument can be made that tcp wrappers are 
garbage and that we should not ship them. Until then, I would argue that 
we should fix them to work as expected.

What would be nice is if tcp wrappers itself had an easy to use API that 
allowed us to query for a specific service - if no rules (default or 
specific to your service) have been specified, you can disable the DNS 
reverse lookup path.

Regards,

Ric

> * Host names in iptables or tcp wrappers rules are ALWAYS a bad idea
> because you are relying upon an unreliable and insecure external data
> source that is DNS.  DNS can be too easily spoofed, hijacked, denial of
> service attacked, and it lacks any semblance of authentication or
> encryption.
> * It is wrong for a service wrapped by tcp wrappers to over-engineer
> itself to workaround misconfiguration on the part of the sysadmin.
> * It is inconsistent with the behavior of any other service wrapped by
> tcp wrappers.  "sshd: badhost.example.com" allows incoming connections
> if reverse DNS lookup fails.  Does this mean sshd and every other
> service wrapped by tcp wrappers should also be modified?
> * This is inconsistent with iptables.  "iptables -A INPUT -p tcp --dport
> 22 -s badhost.example.com -j REJECT" might also fail to reject an
> incoming connection under similar DNS-related conditions.  It would be
> clearly wrong for sshd to second-guess and parse iptables rules, and
> make its own decision based its own reverse DNS query matching hostnames
> found in those iptables rules.  Why is it OK to second guess tcp
> wrappers but not iptables?
> * Even if we agree that this is a bug that should be fixed and not
> simply sysadmin misconfiguration, the correct layer to fix it is in tcp
> wrappers itself, not the individual wrapped services.
>
> We had a lengthy discussion and have come to reluctant agreement on how
> to proceed from here.  It was decided by the filesystem people that even
> if it is only the result of misconfiguration, nfs-utils should protect
> and deny by default.
>
> Steve is working on the next build of nfs-utils with slightly different
> logic.  It will behave exactly as it did before this change (no tcp
> wrappers or deny on reverse DNS lookup failure).  It will only enable
> tcp wrapper and the new denial behavior if any mountd, statd or wildcard
> lines appear in /etc/hosts.deny or /etc/hosts.allow.
>
> We will hopefully have a new build tomorrow.
>
> Workarounds until this is fixed...
> ==================================
> 1) Remove tcpwrappers (if you don't need quotas this might be OK)
> 2) Downgrade nfs-utils to these versions:
> http://kojipkgs.fedoraproject.org/packages/nfs-utils/1.1.2/7.fc9/
> http://kojipkgs.fedoraproject.org/packages/nfs-utils/1.1.4/4.fc10/
> 3) For LTSP users, you can opt to stop using NFS entirely.  LTSP users
> can switch to NBD instead, which is a little more work, but clients boot
> a little faster.
> https://fedorahosted.org/k12linux/NBDRootConfiguration
>
> Warren Togami
> wtogami at redhat.com
>
>