Re: Re: What libs req'd to resolve DNS within a chroot jail?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



> 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

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux