Description of problem: TCP wrappers seems to have problems matching by hostname if a remote host has both IPv6 and IPv4 addresses but connects using IPv4, even if the local tcp-wrapped service is currently IPv4-only. When using tcp_wrappers to control access to vsftpd, setting the rule ALL: localhost in /etc/hosts.allow does not match connections from 127.0.0.1 if DNS contains the resource records localhost. IN A 127.0.0.1 localhost. IN AAAA ::1 I tested this by additionally setting ALL:ALL in /etc/hosts.deny. However, connections from ::1 work if listen_v6=YES has been set and listen=YES has been unset in /etc/vsftpd/vsftpd.conf. The connections from 127.0.0.1 are still blocked. It appears that when tcp_wrappers matches the hostname to an IP address, if it gets an IPv6 address, it only uses that, and doesn't match against the IPv4 address. This can be tested by using the command "telnet ::1 21" as a IPv6-aware FTP client. When matching by hostname, tcp_wrappers should be matching connections from *either* IPv4 or IPv6 adddresses belonging to the host. Version-Release number of selected component (if applicable): tcp_wrappers-7.6-37.2 vsftpd-2.0.1-5.EL4.3 caching-nameserver-7.3-3
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Created attachment 157994 [details] a little test tcp_wrappers did not resolve the hostnames given in the hosts.{allow,deny} files. It resolved the address of the connection to a hostname. As a solution to another bug I modified it to resolve the hostnames but it seems I'll have to remove that, so I came back to this one. It might be caused by the contents of your /etc/hosts. If you have something like "127.0.0.1 localhost.localdomain localhost", then the only address it sees is localhost.localdomain. I'm attaching a little test program that shows whether this is the case. I may modify the code to treat localhost and localhost.localdomain as they're the same, or we can agree that this is a misconfiguration on your side and close it.
I decided to modify it to treat localhost and localhost.localdomain as equivalent.
Regarding comment #6, the line in /etc/hosts 127.0.0.1 localhost.localdomain localhost shouldn't be considered a misconfiguration on my side, since that is what is set by default by our installer. Also, all aliases on the line in /etc/hosts should resolve; that's the point of having aliases on the line, after all. If it doesn't, that should be a new bug.
By misconfiguration I meant the use of "localhost" instead of "localhost.localdomain" in the hosts.allow file, not in the hosts file. Basically, the problem is that the hostnames in hosts.allow/deny are not resolved at all. The address of the client is resolved to the corresponding hostname and that hostname is then used. And as far as I know, the glibc functions to resolve an address to a hostname return only one hostname and I'm not sure whether it is correct for an address to have more than one reverse record at all. Then the question is whether we should add the support for resolving the hostnames in hosts.allow/deny files. It may open some possibilities for DNS-based attacks. (on the other hand, though, the issue with localhost vs. localhost.localdomain is quite common and is therefore fine to work around)
Ah. Interesting, that's not clearly documented, but that makes perfect sense. The RFCs are contradictory, but in practice the implementations I've seen allow the address of the client to resolve to a single host name (each address in DNS must have no more than one PTR record). The silly localhost.localdomain entry in /etc/hosts makes the name localhost in hosts.allow not a FQDN, and we never check DNS since we have a match in /etc/hosts. Names that aren't FQDNs probably are not allowed to work in TCP wrappers because to be "safe" we'd have to do something that would be the moral equivalent of matching with PARANOID, which is more work. For RHEL5, the localhost6 entry probably complicates things further, but I have not tested that scenario, and this was on RHEL4. Using hostnames for access control in TCP wrappers already opens some DNS-based attacks, but this is one more nail in the coffin. That argues that if this security mechanism is used, you should really be filtering on IPs for better control (even though that is subject to various attacks as well). I'm going to bounce comment #11 off of the GLS instructional team for their edification and further feedback.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0566.html