Dynamic DNS and firewall access

[Jim Reid]

>>>>> "Sally" == Sally Tomasevic <st1225 at salmar.com> writes:

    Sally> I have an interesting little problem I'm hoping someone can
    Sally> help me out with.  I have a few remote PCs that for which I
    Sally> want to provide remote access into one of our other
    Sally> systems.  I've set up Dynamic DNS so that they can do
    Sally> remote updates, but the local /etc/hosts.allow file still
    Sally> blocks them despite the fact that I allow access to the
    Sally> dymamic domain.

    Sally> For instance.  Say dynamic address 111.222.333.444 get
    Sally> updated via dynamic DNS to be albert.dyn.mydomain.com.  My
    Sally> hosts.allow file has this entry.

    Sally>    in.telnetd: albert.dyn.mydomain.com

    Sally> This, of course, doesn't work and is no big surprise.  The
    Sally> problem, as I see it, seems to be that Linux's
    Sally> anti-spoofing software is rejecting this address, or the
    Sally> gethostbyname() resolution happens first on the number
    Sally> 111.222.333.444 before it has a chance to look up the
    Sally> domain.  This seems to be the likely culprit.

Yeah. Your broad assumption is probably correct, but there are some
minor errors in the details. When an incoming connection is made, the
TCP wrappers code does a reverse lookup by calling gethostbyaddr().
The name that is returned is then passed in a call to gethostbyname()
to find out if someone's trying to spoof the reverse lookups by making
them return names from some other (trusted?)  domain. If all is well,
tcpd then invokes the actual server process, in this case telnetd.

    Sally> Questions.  Is there a way around this? 

Yes, you could put the dynamically assigned IP addresses in the
hosts.allow file, assuming they only get given to these hosts.

    Sally> Can I create dynamic reverse lookup files?

Yes, there's no reason in principle why a reverse zone cannot be
updated dynamically: it's just another zone after all. There might be
problems configuring clients to update both the forward and reverse
zones. There are also security issues: like zapping an important PTR
record. And stuff classless reverse zone delegation can make things
painful too.

    Sally> Any suggestions on providing
    Sally> a better way to allow access to notebook clients who always
    Sally> connect using dymanic IP addresses?

Don't use IP addresses or hostnames to control access. You could use
SSH which uses public-key encryption to authenticate clients and
servers. However managing and distributing the keys is a pain. OTOH,
it eliminates the need for sending passwords in clear text over the
network at the start of a telnet session. This is probably a bigger
security concern than worrying about which IP addresses or hostnames
connect to the telnet port on your computer(s). SSH has some other
good stuff in it too: like optional on-the-fly data compression and
port forwarding.

There are also major security worries about dynamic DNS. At present
anything which is permitted to do dynamic DNS requests can change ANY
resource records in the zone they are allowed update. What if one of
these dynamic update clients decided to replace your zone's MX or NS
records? And if you're allowing this from a pool of addresses, how are
you controlling who or what gets one of those addresses?