Hi,
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.
Any suggestions?
Thanks!
Eric
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.
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.
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?
Thanks,
Eric
On Mon, 2008-01-14 at 12:54 -0500, 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.<snip>
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.
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?
Have you checked the firewall settings on the target machine? IIRC, long ago when I was doing some sharing, I tested if it was firewall by disabling firewall on the target (inside a private net, no/low risk) temporarily and it worked. That clued me to get my iptables adjusted to allow my local net denizens have access to a small set of services.
Thanks,
Eric
<snip sig stuff>
HTH
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?
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
On Mon, 2008-01-14 at 17:53 -0500, Eric B. wrote:
Eric B. wrote:
<snip>
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
AAA Correct? -----|||
I haven't seen that in your previous posts. Type in posting or some configuration problem?
<snip>
Thanks,
Eric
<snip sig stuff>
HTH
"William L. Maltby" CentOS4Bill@triad.rr.com wrote in message news:1200354890.5507.35.camel@centos01.homegroannetworking...
On Mon, 2008-01-14 at 17:53 -0500, Eric B. wrote:
Eric B. wrote:
<snip>
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
AAACorrect? -----|||
Whoops - cut & paste typo. That line is supposed to read: Jan 14 17:46:50 apollo atftpd[15905]: Connection refused from 192.168.3.103
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Eric B. Sent: Monday, January 14, 2008 5:59 PM To: centos@centos.org Subject: [CentOS] Re: Re: Re: What libs req'd to resolve DNS within achrootjail?
"William L. Maltby" CentOS4Bill@triad.rr.com wrote in message news:1200354890.5507.35.camel@centos01.homegroannetworking...
On Mon, 2008-01-14 at 17:53 -0500, Eric B. wrote:
Eric B. wrote:
><snip>
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
AAACorrect? -----|||
Whoops - cut & paste typo. That line is supposed to read: Jan 14 17:46:50 apollo atftpd[15905]: Connection refused from 192.168.3.103
Can you post your complete hosts.allow and hosts.deny files?
"Mike Kercher" mike@vesol.com wrote in message news:6115482898C59848B35DB9D491C9A28E08BFA3@srv1.home.middlefinger.net...
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
AAACorrect? -----|||
Whoops - cut & paste typo. That line is supposed to read: Jan 14 17:46:50 apollo atftpd[15905]: Connection refused from 192.168.3.103
Can you post your complete hosts.allow and hosts.deny files?
Not much to them actually: /chroot/tftpd/etc/hosts.allow: # # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # in.tftpd : eric.test.com : allow
/chroot/tftpd/etc/hosts.deny: # # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # in.tftpd : ALL : deny
Again, I have concerns that I might be missing something in my chroot jail, but when I change my hosts.allow file to read the following, it works fine. in.tftpd: 192.168.3.103 : allow
So I am utterly and totally confused. I keep thinking that there must be something DNS related that I need in the chroot jail that I am missing. I do have a /chroot/tftpd/etc/resolv.conf with the nameserver entry that points to the DNS server, and all files in my /chroot/tftpd/etc dir are world readable. I also have a /chroot/tftpd/etc/hosts file (that is pretty much empty - just a line for 127.0.0.1).
# ls -l /chroot/tftpd/etc -rw-r--r-- 1 root root 148 Jan 14 17:53 hosts -rw-r--r-- 1 root root 417 Jan 14 17:37 hosts.allow -rw-r--r-- 1 root root 370 Jan 13 12:13 hosts.deny -rw-r--r-- 1 root root 1267 Jan 12 21:43 localtime -rw-r--r-- 1 root root 1686 Jan 12 15:50 nsswitch.conf -rw-r--r-- 1 root root 86 Jan 14 17:52 resolv.conf -rw-r--r-- 1 root root 20373 Jan 12 15:47 services
Is there anything else I need that I am missing? Either config file or lib?
Any suggestions of things I can try?
Thanks,
Eric
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Eric B. Sent: Monday, January 14, 2008 8:45 PM To: centos@centos.org Subject: [CentOS] Re: Re: Re: Re: What libs req'd to resolve DNSwithinachrootjail?
"Mike Kercher" mike@vesol.com wrote in message news:6115482898C59848B35DB9D491C9A28E08BFA3@srv1.home.middlefi
nger.net...
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
AAACorrect? -----|||
Whoops - cut & paste typo. That line is supposed to read: Jan 14 17:46:50 apollo atftpd[15905]: Connection refused from 192.168.3.103
Can you post your complete hosts.allow and hosts.deny files?
Not much to them actually: /chroot/tftpd/etc/hosts.allow: # # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # in.tftpd : eric.test.com : allow
/chroot/tftpd/etc/hosts.deny: # # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # in.tftpd : ALL : deny
Again, I have concerns that I might be missing something in my chroot jail, but when I change my hosts.allow file to read the following, it works fine. in.tftpd: 192.168.3.103 : allow
So I am utterly and totally confused. I keep thinking that there must be something DNS related that I need in the chroot jail that I am missing. I do have a /chroot/tftpd/etc/resolv.conf with the nameserver entry that points to the DNS server, and all files in my /chroot/tftpd/etc dir are world readable. I also have a /chroot/tftpd/etc/hosts file (that is pretty much empty - just a line for 127.0.0.1).
# ls -l /chroot/tftpd/etc -rw-r--r-- 1 root root 148 Jan 14 17:53 hosts -rw-r--r-- 1 root root 417 Jan 14 17:37 hosts.allow -rw-r--r-- 1 root root 370 Jan 13 12:13 hosts.deny -rw-r--r-- 1 root root 1267 Jan 12 21:43 localtime -rw-r--r-- 1 root root 1686 Jan 12 15:50 nsswitch.conf -rw-r--r-- 1 root root 86 Jan 14 17:52 resolv.conf -rw-r--r-- 1 root root 20373 Jan 12 15:47 services
Is there anything else I need that I am missing? Either config file or lib?
Any suggestions of things I can try?
Thanks,
Eric
Something I found:
15.2.3.2. Access Control
Option fields also allow administrators to explicitly allow or deny hosts in a single rule by adding the allow or deny directive as the final option.
For instance, the following two rules allow SSH connections from client-1.example.com, but deny connections from client-2.example.com:
sshd : client-1.example.com : allow sshd : client-2.example.com : deny
By allowing access control on a per-rule basis, the option field allows administrators to consolidate all access rules into a single file: either hosts.allow or hosts.deny. Some consider this an easier way of organizing access rules.
Conceivably, you could put all rules into one file (hosts.allow maybe). See if that helps..
Mike
Can you post your complete hosts.allow and hosts.deny files?
Not much to them actually: /chroot/tftpd/etc/hosts.allow: # # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # in.tftpd : eric.test.com : allow
/chroot/tftpd/etc/hosts.deny: # # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # in.tftpd : ALL : deny
Again, I have concerns that I might be missing something in my chroot jail, but when I change my hosts.allow file to read the following, it works fine. in.tftpd: 192.168.3.103 : allow
So I am utterly and totally confused. I keep thinking that there must be something DNS related that I need in the chroot jail that I am missing. I do have a /chroot/tftpd/etc/resolv.conf with the nameserver entry that points to the DNS server, and all files in my /chroot/tftpd/etc dir are world readable. I also have a /chroot/tftpd/etc/hosts file (that is pretty much empty - just a line for 127.0.0.1).
# ls -l /chroot/tftpd/etc -rw-r--r-- 1 root root 148 Jan 14 17:53 hosts -rw-r--r-- 1 root root 417 Jan 14 17:37 hosts.allow -rw-r--r-- 1 root root 370 Jan 13 12:13 hosts.deny -rw-r--r-- 1 root root 1267 Jan 12 21:43 localtime -rw-r--r-- 1 root root 1686 Jan 12 15:50 nsswitch.conf -rw-r--r-- 1 root root 86 Jan 14 17:52 resolv.conf -rw-r--r-- 1 root root 20373 Jan 12 15:47 services
Is there anything else I need that I am missing? Either config file or lib?
Any suggestions of things I can try?
Thanks,
Eric
Something I found:
15.2.3.2. Access Control
Option fields also allow administrators to explicitly allow or deny hosts in a single rule by adding the allow or deny directive as the final option.
For instance, the following two rules allow SSH connections from client-1.example.com, but deny connections from client-2.example.com:
sshd : client-1.example.com : allow sshd : client-2.example.com : deny
By allowing access control on a per-rule basis, the option field allows administrators to consolidate all access rules into a single file: either hosts.allow or hosts.deny. Some consider this an easier way of organizing access rules.
Conceivably, you could put all rules into one file (hosts.allow maybe). See if that helps..
Just tried putting everything in the hosts.allow but didn't make any difference. Tried also in the hosts.deny bu no success either.
Where did you find that reference? What does 15.2.3.2 point to?
Any other ideas / theories?
Thanks!
Eric
Eric B. wrote:
Can you post your complete hosts.allow and hosts.deny files?
Not much to them actually: /chroot/tftpd/etc/hosts.allow: # # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # in.tftpd : eric.test.com : allow
/chroot/tftpd/etc/hosts.deny: # # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # in.tftpd : ALL : deny
Again, I have concerns that I might be missing something in my chroot jail, but when I change my hosts.allow file to read the following, it works fine. in.tftpd: 192.168.3.103 : allow
So I am utterly and totally confused. I keep thinking that there must be something DNS related that I need in the chroot jail that I am missing. I do have a /chroot/tftpd/etc/resolv.conf with the nameserver entry that points to the DNS server, and all files in my /chroot/tftpd/etc dir are world readable. I also have a /chroot/tftpd/etc/hosts file (that is pretty much empty - just a line for 127.0.0.1).
# ls -l /chroot/tftpd/etc -rw-r--r-- 1 root root 148 Jan 14 17:53 hosts -rw-r--r-- 1 root root 417 Jan 14 17:37 hosts.allow -rw-r--r-- 1 root root 370 Jan 13 12:13 hosts.deny -rw-r--r-- 1 root root 1267 Jan 12 21:43 localtime -rw-r--r-- 1 root root 1686 Jan 12 15:50 nsswitch.conf -rw-r--r-- 1 root root 86 Jan 14 17:52 resolv.conf -rw-r--r-- 1 root root 20373 Jan 12 15:47 services
Is there anything else I need that I am missing? Either config file or lib?
Any suggestions of things I can try?
Thanks,
Eric
Something I found:
15.2.3.2. Access Control
Option fields also allow administrators to explicitly allow or deny hosts in a single rule by adding the allow or deny directive as the final option.
For instance, the following two rules allow SSH connections from client-1.example.com, but deny connections from client-2.example.com:
sshd : client-1.example.com : allow sshd : client-2.example.com : deny
By allowing access control on a per-rule basis, the option field allows administrators to consolidate all access rules into a single file: either hosts.allow or hosts.deny. Some consider this an easier way of organizing access rules.
Conceivably, you could put all rules into one file (hosts.allow maybe). See if that helps..
Just tried putting everything in the hosts.allow but didn't make any difference. Tried also in the hosts.deny bu no success either.
Where did you find that reference? What does 15.2.3.2 point to?
Any other ideas / theories?
- make sure tftpd is really using the in.tftpd name (you said it works with IPs?) - make sure it does resolve the IP correctly. I have no idea how you could test this.
but what is the benefit in managing the zone file instead of hosts.*? I mean, since you put the IP in the DNS zone file, why not put it in hosts.*?
Again, I have concerns that I might be missing something in my chroot jail, but when I change my hosts.allow file to read the following, it works fine. in.tftpd: 192.168.3.103 : allow
So I am utterly and totally confused. I keep thinking that there must be something DNS related that I need in the chroot jail that I am missing. I do have a /chroot/tftpd/etc/resolv.conf with the nameserver entry that points to the DNS server, and all files in my /chroot/tftpd/etc dir are world readable. I also have a /chroot/tftpd/etc/hosts file (that is pretty much empty - just a line for 127.0.0.1).
# ls -l /chroot/tftpd/etc -rw-r--r-- 1 root root 148 Jan 14 17:53 hosts -rw-r--r-- 1 root root 417 Jan 14 17:37 hosts.allow -rw-r--r-- 1 root root 370 Jan 13 12:13 hosts.deny -rw-r--r-- 1 root root 1267 Jan 12 21:43 localtime -rw-r--r-- 1 root root 1686 Jan 12 15:50 nsswitch.conf -rw-r--r-- 1 root root 86 Jan 14 17:52 resolv.conf -rw-r--r-- 1 root root 20373 Jan 12 15:47 services
Is there anything else I need that I am missing? Either config file or lib?
Any suggestions of things I can try?
Thanks,
Eric
Something I found:
15.2.3.2. Access Control
Option fields also allow administrators to explicitly allow or deny hosts in a single rule by adding the allow or deny directive as the final option.
For instance, the following two rules allow SSH connections from client-1.example.com, but deny connections from client-2.example.com:
sshd : client-1.example.com : allow sshd : client-2.example.com : deny
By allowing access control on a per-rule basis, the option field allows administrators to consolidate all access rules into a single file: either hosts.allow or hosts.deny. Some consider this an easier way of organizing access rules.
Conceivably, you could put all rules into one file (hosts.allow maybe). See if that helps..
Just tried putting everything in the hosts.allow but didn't make any difference. Tried also in the hosts.deny bu no success either.
Where did you find that reference? What does 15.2.3.2 point to?
Any other ideas / theories?
- make sure tftpd is really using the in.tftpd name (you said it works
with IPs?)
Yes. It works with the IPs, so I am somewhat sure that the daemon name in hosts.allow/deny is right and that I am editing the correct hosts.allow/deny files. When I change the IP in those files, I get the responses that I expect (either access allowed or denied).
- make sure it does resolve the IP correctly. I have no idea how you could
test this.
Me neither. That's the problem. I have no idea how I can test that the daemon is resolving it properly.
but what is the benefit in managing the zone file instead of hosts.*? I mean, since you put the IP in the DNS zone file, why not put it in hosts.*?
Looks like I prob. won't have a choice afterall. But was originally thinking that it would neater and easier to read by have FQDN in teh hosts.* file. Plus, it also means I only need to update things in one place (DNS) if/when my server changes IPs.... Like this I would need to update DNS and remember to update my hosts.* files....
Tx,
Eric
Eric B. wrote:
but what is the benefit in managing the zone file instead of hosts.*? I mean, since you put the IP in the DNS zone file, why not put it in hosts.*?
Looks like I prob. won't have a choice afterall. But was originally thinking that it would neater and easier to read by have FQDN in teh hosts.* file. Plus, it also means I only need to update things in one place (DNS) if/when my server changes IPs.... Like this I would need to update DNS and remember to update my hosts.* files....
if you can't find the solution, then use a single file to update both dns and hosts.* files.
the benefit is that in case of a dns misconfiguration or vulnerability, you don't run the risk of opening access to your tftpd.
________________________________
From: centos-bounces@centos.org on behalf of Eric B. Sent: Tue 1/15/2008 11:39 AM To: centos@centos.org Subject: [CentOS] Re: Re: Re: Re: Re: What libs req'd toresolveDNSwithinachrootjail?
Can you post your complete hosts.allow and hosts.deny files?
Not much to them actually: /chroot/tftpd/etc/hosts.allow: # # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # in.tftpd : eric.test.com : allow
/chroot/tftpd/etc/hosts.deny: # # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # in.tftpd : ALL : deny
Again, I have concerns that I might be missing something in my chroot jail, but when I change my hosts.allow file to read the following, it works fine. in.tftpd: 192.168.3.103 : allow
So I am utterly and totally confused. I keep thinking that there must be something DNS related that I need in the chroot jail that I am missing. I do have a /chroot/tftpd/etc/resolv.conf with the nameserver entry that points to the DNS server, and all files in my /chroot/tftpd/etc dir are world readable. I also have a /chroot/tftpd/etc/hosts file (that is pretty much empty - just a line for 127.0.0.1).
# ls -l /chroot/tftpd/etc -rw-r--r-- 1 root root 148 Jan 14 17:53 hosts -rw-r--r-- 1 root root 417 Jan 14 17:37 hosts.allow -rw-r--r-- 1 root root 370 Jan 13 12:13 hosts.deny -rw-r--r-- 1 root root 1267 Jan 12 21:43 localtime -rw-r--r-- 1 root root 1686 Jan 12 15:50 nsswitch.conf -rw-r--r-- 1 root root 86 Jan 14 17:52 resolv.conf -rw-r--r-- 1 root root 20373 Jan 12 15:47 services
Is there anything else I need that I am missing? Either config file or lib?
Any suggestions of things I can try?
Thanks,
Eric
Something I found:
15.2.3.2. Access Control
Option fields also allow administrators to explicitly allow or deny hosts in a single rule by adding the allow or deny directive as the final option.
For instance, the following two rules allow SSH connections from client-1.example.com, but deny connections from client-2.example.com:
sshd : client-1.example.com : allow sshd : client-2.example.com : deny
By allowing access control on a per-rule basis, the option field
allows
administrators to consolidate all access rules into a single file: either hosts.allow or hosts.deny. Some consider this an easier way of organizing access rules.
Conceivably, you could put all rules into one file (hosts.allow
maybe).
See if that helps..
Just tried putting everything in the hosts.allow but didn't make any difference. Tried also in the hosts.deny bu no success either.
Where did you find that reference? What does 15.2.3.2 point to?
Any other ideas / theories?
_______________________________
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-tcpwr appers-access.html
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of William L. Maltby Sent: Monday, January 14, 2008 5:55 PM To: CentOS General List Subject: Re: [CentOS] Re: Re: What libs req'd to resolve DNS within achroot jail?
On Mon, 2008-01-14 at 17:53 -0500, Eric B. wrote:
Eric B. wrote:
<snip>
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
AAACorrect? -----|||
I haven't seen that in your previous posts. Type in posting or some configuration problem?
<snip>
Thanks,
Eric
<snip sig stuff>
HTH
Bill
Additionally, the connection was refused from 192.168.103.103 (NOT 192.168.3.103)
Mike
"Mike Kercher" mike@vesol.com wrote in message news:6115482898C59848B35DB9D491C9A28E08BFA1@srv1.home.middlefinger.net...
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
AAACorrect? -----|||
Additionally, the connection was refused from 192.168.103.103 (NOT 192.168.3.103)
Sorry - in my haste (and frustration), I copied the wrong line from my log file. It actually reads: Jan 14 17:49:50 apollo atftpd[15905]: Connection refused from 192.168.3.103
-
Eric B. -
Mike Kercher -
mouss -
William L. Maltby