> 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