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
>>>
>>>
>>> I'm assuming I am missing a library/libraries in my chroot jail,
>>> but am not sure which ones. I've got all the libs req'd by ldd,
>>> but I am guessing there is something else that I am missing.
>>
>> ---------- End Original Message ----------
>>
>> 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.
>
> However, when I try to connect to the tftp server, my connection is still
> refused, and I get the following in the log msgs:
>
> Jan 14 12:49:19 apollo atftpd[15302]: Connection refused from
> 192.168.103.103
>
>
> I am obviously doing something still incorrect, but not sure what.
>
> Can you help point me in the right direction please? Is my reverse DNS
> incorrectly set up?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
