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.arpaname = 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@centos.org
http://lists.centos.org/mailman/listinfo/centos
