246 lines
9.1 KiB
HTML
246 lines
9.1 KiB
HTML
<!--startcut ======================================================= -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<html>
|
|
<head>
|
|
<META NAME="generator" CONTENT="lgazmail v1.1I.e">
|
|
<TITLE>The Answer Guy 38: Telnetd and pausing</TITLE>
|
|
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000"
|
|
LINK="#3366FF" VLINK="#A000A0">
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<H4>"The Linux Gazette...<I>making Linux just a little more fun!</I>"</H4>
|
|
<P> <hr> <P>
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<center>
|
|
<H1><A NAME="answer">
|
|
<img src="../../gx/dennis/qbubble.gif" alt="(?)"
|
|
border="0" align="middle">
|
|
<font color="#B03060">The Answer Guy</font>
|
|
<img src="../../gx/dennis/bbubble.gif" alt="(!)"
|
|
border="0" align="middle">
|
|
</A></H1>
|
|
<BR>
|
|
<H4>By James T. Dennis,
|
|
<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a><BR>
|
|
Starshine Technical Services,
|
|
<A HREF="http://www.starshine.org/">http://www.starshine.org/</A>
|
|
</H4>
|
|
</center>
|
|
|
|
<p><hr><p>
|
|
<!-- endcut ======================================================= -->
|
|
<!-- begin 32 -->
|
|
<H3 align="left"><img src="../../gx/dennis/qbubble.gif"
|
|
height="50" width="60" alt="(?) " border="0"
|
|
>Telnetd and pausing</H3>
|
|
|
|
|
|
<p><strong>From Clive Flint on Thu, 25 Feb 1999
|
|
</strong></p>
|
|
<P><STRONG>
|
|
Hi,
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
I have made a Linux server using a Tulip dt5/100 machine with 40Mb
|
|
Memory, a 16Mb swap file and a 1Gb hard disk.
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
I have a problem that when I try to telnet into the machine it
|
|
doesn't respond for about 30-40 seconds. Once it has responded
|
|
then it will talk quite normally.
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
If I then start another telnet session on my pc it again pauses
|
|
for the 30-40 seconds. Is there any reason and is there anything
|
|
that can be done.
|
|
</STRONG></P>
|
|
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
This is a classic problem. TCP Wrappers (<TT>/sbin/tcpd</TT>)
|
|
is attempting to check the consistency of your name
|
|
and IP address using its "double reverse DNS lookup."
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
I've described this before but the short form is:
|
|
tcpd does a reverse lookup to associate a name with
|
|
your IP address. It then does a forward lookup on
|
|
that purported name and scans the responses for your
|
|
IP address. A properly maintained domain will have
|
|
consistent forward and reverse mappings.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
The reason Wietse Venema (author of TCP Wrappers) does
|
|
this is to allow you to use host and domain names in
|
|
your <TT>/etc/hosts.allow</TT> and <TT>/etc/hosts.deny</TT> files while
|
|
reducing the risks inherent in that.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
Consider the case of someone who controls any reverse DNS
|
|
domain (that is anyone who "owns" or has subverted any
|
|
nameserver to which a range of IP address <TT>PTR</TT> records as
|
|
been delegated). It is trivial for them to return <EM>any</EM>
|
|
name they like in response to reverse DNS requests.
|
|
However, it would be non-trivial for an outsider to
|
|
modify your forward DNS zones (and, if they could they could
|
|
use "man-in-the-middle" attacks against most common
|
|
prototols to disrupt your system in many creative ways).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
So, tcpd uses a "double reverse" method.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
The easy solution for real IP addresses which have been
|
|
properly delegated to you by your ISP or through the IANA
|
|
(or your national address registry) is to simply update
|
|
your reverse zone maps to match the forward ones.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
The reason this only affect the initial connections,
|
|
and that it only affects a limited set of services is
|
|
because tcpd is only active for those services which are
|
|
listed in the <TT>/etc/inetd.conf</TT> as being launched by <tt>tcpd</tt>
|
|
with lines like:
|
|
</BLOCKQUOTE>
|
|
|
|
<blockquote><pre>ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd
|
|
</pre></blockquote>
|
|
<BLOCKQUOTE>
|
|
(You'd see similar affects from programs that are
|
|
linked with "<tt>libwrap</tt>" --- a compiler library which
|
|
implements the same set of host access checks as
|
|
TCP Wrappers).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
The reason your web services aren't affected is because
|
|
they aren't launched through <tt>inetd</tt> and they aren't
|
|
compiled with <tt>libwrap</tt>. (And they don't do these
|
|
double reverse lookups).
|
|
</BLOCKQUOTE>
|
|
<Pre><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>ip numbers
|
|
192.9.200.1 clive.clara.net (linux server)
|
|
192.9.200.100 cef1 (winnt machine)
|
|
192.9.200.101 clivemob (win98 machine)
|
|
</STRONG></Pre>
|
|
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
I believe you should be using RFC1918 addresses
|
|
for these systems since the real address for
|
|
<tt>clive.net</tt> seem to cluster in the <tt>195.8.69.*</tt> range
|
|
and a reverse lookup of <tt>192.9.200.0</tt> suggests that
|
|
those are not assigned at this time.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
I'm assuming that you've just "picked these out of a
|
|
hat" --- that they haven't been delegated to you. This
|
|
also suggests that you're using masquerading or a
|
|
set of applications proxies (such as SOCKS, DeleGate,
|
|
Danta, etc) to access the 'net.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
You could configure your nameserver for "split" DNS
|
|
or you could configure an internal nameserver (used
|
|
by all your internal systems). Another technique is
|
|
to simply put the appropriate entries in your <TT>/etc/hosts</TT>
|
|
file. This will bypass DNS (and reverse DNS) queries
|
|
for most services. The '<TT>gethostbyaddr()</TT>' library
|
|
function will find the IP address and name in the
|
|
<TT>/etc/hosts</TT> file first (under most common configurations).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
(That might fail if you've changed your <TT>/etc/hosts.conf</TT>
|
|
(libc5) or <TT>/etc/nsswitch.conf</TT> (glibc). However, it's
|
|
incredibly unlikely that you've touched either of
|
|
those files).
|
|
</BLOCKQUOTE>
|
|
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
The server is running dhcp service and that works fine. If I web
|
|
to it it responds immediately with no delay.
|
|
</STRONG></P>
|
|
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
Like I said --- this only affects TCP wrapped services
|
|
(and others that would do similar consistency checks.
|
|
</BLOCKQUOTE>
|
|
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
Any help would be gratefully received.
|
|
</STRONG></P>
|
|
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
Try adding the appropriate IP addresses to the <TT>/etc/hosts</TT>
|
|
files on the involved servers.
|
|
</BLOCKQUOTE>
|
|
<!-- sig -->
|
|
|
|
<!-- end 32 -->
|
|
<!--startcut ======================================================= -->
|
|
<P> <hr> <P>
|
|
<H5 align="center"><a href="http://www.linuxgazette.com/copying.html"
|
|
>Copyright ©</a> 1999, James T. Dennis
|
|
<BR>Published in <I>The Linux Gazette</I> Issue 38 March 1999</H5>
|
|
<P> <hr> <P>
|
|
<!-- begin tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<TABLE WIDTH="96%"><TR VALIGN="center" ALIGN="center">
|
|
<TD ROWSPAN="3" COLSPAN="4" WIDTH="24%"><A HREF="../lg_answer38.html"
|
|
><IMG SRC="../../gx/dennis/answernew.gif"
|
|
ALT="[ Answer Guy Index ]"></A></td>
|
|
<TD WIDTH="6%"><A HREF="1.html">1</A></TD>
|
|
<TD WIDTH="6%"><A HREF="2.html">2</A></TD>
|
|
<TD WIDTH="6%"><A HREF="3.html">3</A></TD>
|
|
<TD WIDTH="6%"><A HREF="4.html">4</A></TD>
|
|
<TD WIDTH="6%"><A HREF="5.html">5</A></TD>
|
|
<TD WIDTH="6%"><A HREF="6.html">6</A></TD>
|
|
<TD WIDTH="6%"><A HREF="7.html">7</A></TD>
|
|
<TD WIDTH="6%"><A HREF="8.html">8</A></TD>
|
|
<TD WIDTH="6%"><A HREF="9.html">9</A></TD>
|
|
<TD WIDTH="6%"><A HREF="10.html">10</A></TD>
|
|
<TD WIDTH="6%"><A HREF="11.html">11</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD><A HREF="12.html">12</A></TD>
|
|
<TD> </TD>
|
|
<TD><A HREF="14.html">14</A></TD>
|
|
<TD> </TD>
|
|
<TD><A HREF="16.html">16</A></TD>
|
|
<TD><A HREF="17.html">17</A></TD>
|
|
<TD><A HREF="18.html">18</A></TD>
|
|
<TD><A HREF="19.html">19</A></TD>
|
|
<TD> </TD>
|
|
<TD><A HREF="21.html">21</A></TD>
|
|
<TD><A HREF="22.html">22</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD><A HREF="23.html">23</A></TD>
|
|
<TD><A HREF="24.html">24</A></TD>
|
|
<TD> </TD>
|
|
<TD><A HREF="26.html">26</A></TD>
|
|
<TD> </TD>
|
|
<TD><A HREF="28.html">28</A></TD>
|
|
<TD><A HREF="29.html">29</A></TD>
|
|
<TD><A HREF="30.html">30</A></TD>
|
|
<TD><A HREF="31.html">31</A></TD>
|
|
<TD><A HREF="32.html">32</A></TD>
|
|
<TD> </TD>
|
|
</TR></TABLE>
|
|
<!-- end tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<P> <hr> <P>
|
|
<!-- begin lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<A HREF="../index.html"
|
|
><IMG SRC="../../gx/indexnew.gif" ALT="[ Table Of Contents ]"></A>
|
|
<A HREF="../../index.html"
|
|
><IMG SRC="../../gx/homenew.gif" ALT="[ Front Page ]"></A>
|
|
<A HREF="../lg_bytes38.html"
|
|
><IMG SRC="../../gx/back2.gif" ALT="[ Previous Section ]"></A>
|
|
<A HREF="../lg_tips38.html"
|
|
><IMG SRC="../../gx/fwd.gif" ALT="[ Next Section ]"></A>
|
|
<!-- end lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
</BODY></HTML>
|
|
<!--endcut ========================================================= -->
|