> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
