Eric B. wrote:
I've been working at getting a tftp server up an running in a chroot jail, and I have finally succeed getting almost everything working. The server itself works fine, however, it is implemented as a tcpwrapper application (ie: in.tftpd) and I am having trouble getting it to resolve DNS names. I copied my /etc/hosts.allow and /etc/hosts.deny in my chroot/etc folder, however, they only work properly if I provide IP addresses. If I use FQDN, they fail.
For instance, in hosts.allow: in.tfptd: 192.168.1.101 allow
works fine
But the following fails in.tftptd: eric.test.com allow
from a security standpoint i don't think you want to control access by fqdn. the name being given access is based on the inverse-map lookup (in-addr.arpa) on the inbound ipnumber - not the forward lookup. so, this isn't controlled by the keepers of the "test.com" zone, rather, anyone can set up "eric.test.com" as an inverse entry for an ipnumber for which they control the in-addr.arpa records.
If hosts.allow and friends use the fqdn without reverse validation, then I consider this a huge bug. The original tcp wrappers will set the hostname to "unknown" if the reverse and rdns do not match (ip -> rdns -> ip must return the original IP). I am certain this is still the case in the current implementations.
i.e., putting an fqdn in the hosts.allow file only gives security by obscurity. if someone figures out the fqdns that you're giving access to, and has control of the in-addr.arpa for an ipnumber range they can connect from, they can gain access to your system.
- Rick
Thanks for the feedback Rick. I didn't realize that security implication. However I'm already running this on a machine that is heavily firewalled on a VPN so I am fairly sure that no one will be accessing this externally, but I still would like to restrict access to particular machines. Ideally, would rather use FQDN to make life easier for me to administer. I have created my additional reverse-dns pointer but I am still having problems with it.
nslookup from the server gives me: # nslookup 192.168.3.103 Server: 192.168.1.67 Address: 192.168.1.67#53
103.3.168.192.in-addr.arpa name = eric.test.com.3.168.192.in-addr.arpa.
It looks like there is a missing trailing dot in your DNS zone configuration. I doubt you are authoritative for the in-addr.arpa zone.
in your zone file, you should have something like 103 IN PTR eric.test.example. (notice the last dot). Otherwise, the zone name (@ORIGIN) will be added.
make sure you have a matching reverse _and_ forward resolution. you should get something like:
192.168.3.103 => eric.test.example _and_ eric.test.example => 192.168.3.103
If you only have the reverse lookup, the result is untrusted and sane applications should ignore it.
Thanks for the pointer. Indeed, I was missing the trailing . after my FQDN in my revers file. I have updated my reverse files, and nslookup is resolving better, but still not further ahead.
My reverse file: 3.168.192.in-addr.arpa now contains the following line: 103 IN PTR eric.test.com.
If I try nslookups now, my results are as follows:
# nslookup 192.168.3.103 Server: 192.168.1.67 Address: 192.168.1.67#53
103.103.168.192.in-addr.arpa name = eric.test.com.
# nslookup eric.test.com Server: 192.168.1.67 Address: 192.168.1.67#53
Name: eric.test.com Address: 192.168.3.103
So from that, it seems as though the DNS / rDNS are properly configured, does it not? Similarly, I have both the forward and reverse domain name on the DNS server as the nslookups show. However, I still get the same error msg: Jan 14 17:46:50 apollo atftpd[15905]: Connection refused from 192.168.103.103
I have even tried putting a trailing dot in the hosts.allow files, but that too (as expected) made no difference.
I have concluded that it isn't a firewall issue, as it works fine if I give it the full address instead of the FQDN in the hosts.allow file. So I figure I still have something wrong with either my DNS setup and/or missing some critical lib in my chroot jail that I don't know about (although the app doesn't complain that I am missing any libs, and works fine given an ip address).
Any ideas what else I might be doing incorrectly?
Thanks,
Eric