[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: NFS tcp wrapper situation

Steve Grubb wrote:
On Tuesday 20 January 2009 08:19:25 pm Ric Wheeler wrote:
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
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.

Generally, you should put allow rules and not the reverse. If you want a bulletproof security policy, you have to have ALL: ALL in hosts.deny so that any failure results in denial. What the deny file can safely be used for is excluding a network you control from a larger selection. IOW, you allow all of the 192.168. network except for the 192.168.1. subnet. But even then you can use the EXCEPT operator in the allow file for this condition. So, you likely do not need to ever put something in the deny file other than ALL: ALL.

I don't disagree with the best way to use it as you suggest, but the specific issue is for those who (naively?) put a hostname into the deny file. I don't think that we can assume that users will always do the optimal thing :-)

The way the code works today, you will get the expected behavior (mounts from that client are denied) only as long as DNS is working properly. When the DNS lookup fails, it will be allowed.


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.

Look at hosts_access(5) for the rules governing tcp_wrappers. They haven't changed in a long long time.

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?

Or rewrite the rules from the mostly closed perspective which means you deny everyone and allow some connections.

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.

They are working just 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.

What some services do is have a configuration flag that tells the daemon whether or not to use tcp_wrappers. This way you have an escape hatch if you'd rather write iptables rules.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]