----
When someone connects to your system, all tcpwrappers have to look at
is the numeric IP address, in this case 194.226.190.211. Tcpwrappers
do a reverse lookup on the IP address to find out the host name. In
this case host211.pl16.nsc.ru was found. Then the PARANOID check is
done by doing a lookup on the name (host211.pl16.nsc.ru) to make sure
that it is REALLY that IP address. In this case the lookup of
host211.pl16.nsc.ru failed, so the connection was refused because
tcpwrappers thinks someone might be faking the IP address.
----
Thus, since a reverse lookup for the first client gives the result while for
the second client fails, for the first one the PARANOID check (a direct
lookup) is done (and results in refuse) while the second is considered as
not mapped in DNS, and it's not a reason for the refuse.
[I thought that direct lookup has to be done first, and for the second
client it would be impossible since it had no name. Actually this
circumstance misled me before. Else the explanation of Arrigo Triulzi
would be sufficient for me. Arrigo, I'm sorry! :-) ]
I also consider as very useful information from Tom, here it is:
----
The use of the paranoid directive is to provide a layer of safety when
accepting connections from DNS domains.
/etc/hosts.allow:
ALL: LOCAL .foobar.com
In this case, all connections from any system who's hostname ends with
".foobar.com" will be allowed access to all services wrapped by tcpd
and other services using libwrap.a (see note below). The problem is
that if you rely on DNS to limit access, you need to trust the DNS
server. The paranoid directive is supposed to help you trust the answers
that you are getting from DNS.
If the address can't be resolved at all, then it won't match any of the
DNS domain based access rules, ergo no DNS trust issues.
That isn't to say that I wouldn't like to see a rule like wu-ftp's
!nameserved directive, which allows you to deny access to anyone
who's hostname can't be resolved.
NOTE: Some programs that use libwrap.a, like Wietse's portmapper,
will not do hostname lookups (they take too long for these services)
and must have numeric IP addresses.
Tom
-----
Following are my previous summary and original post.
Much thanks again to all of you,
Irene
*************************************************************************
* *
* Irene A. Shilikhina e-mail: irene_at_alpha.iae.nsk.su *
* System administrator, *
* Institute of Automation & Electrometry, *
* Siberian Branch of Russian Academy of Sciences, *
* Novosibirsk, Russia *
* http://www.iae.nsk.su/~irene *
*************************************************************************
* * *
* Good intentions pave a path to * Every cloud has a silver lining. *
* the hell. * *
* * *
*************************************************************************
On Wed, 23 Sep 1998, Irene A. Shilikhina wrote:
>
> Hello managers,
>
> much thanks to those who responded to my mail (and some of you did it more
> than once, so I thank you also for your patience and time!):
>
> Kalle Flodkvist,
> Arrigo Triulzi,
> Martin Mokrejs,
> Sean O'Connell,
> Tim Winders,
> Phil Farrell.
>
> The essence of my mail was that I could not understand why in one case tcp
> wrapper refused telnet connection from the host which had no address
> resolution while in another case connection was executed though in the log
> file only IP address was pointed, and running nslookup by hand showed that
> this host had no DNS resolution either. The second point was that when this
> second host connected, in the sialog, entries appeared informing about
> failure during login procedure, and these entries had no user name in
> them.
>
> Arrigo and Phil explained that impossibility to resolve the host name or
> IP address was not yet a motivation for connection to be refused (I was
> wrong in my expectation that with -DPARANOID option, for the hosts with
> unresolvable name or address, connection would be refused), and only
> the contradiction in these resolutions results in refuse.
> [Then why the request from the first host is accompanied with the messages
> >Sep 21 16:42:56 alpha telnetd[14228]: warning: can't verify hostname:
> > ^^^^^^^^^^^^^^^^^^^^^
> >gethostbyname(host211.pl16.nsc.ru) failed
> >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >Sep 21 16:42:56 alpha telnetd[14228]: refused connect from 194.226.190.211
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> when this host name is indeed unresolvable? This question remains.]
>
> On the other hand, Sean quietened me that the messages in sialog about
> failure in login without a user name is produced when typing ^] to break
> the session and the quiting at the telnet> prompt (it is a good news for me
> :-) since helps me to get rid of unnecessary suspicions).
>
> Phil says:
> >I would actually like to have an option that says "refuse connections
> >from hosts that are not in the name servers", that is, when the
> >connection from 192.0.0.8 came in, if a reverse lookup failed and
> >could not get a system name, then refuse to allow it. I don't know
> >how to do that either with TCP wrappers.
> [And I would like to provide the same behaviour of TCP WRAPPER. If anyone
> knows how to get it, I would be happy to hear about it.]
>
> Tim supposes that a strange accomplishment of traceroute to the second host
> (when the IP address in the last string in the output is different from
> what I pointed) results from that the last router in the output is either
> a filtering router or a firewall. (It is also a useful information for me!)
>
> Kalle and Martin gave advice to use additional measures to defend our system.
>
> Following are several quotes from the answers and my original posting.
> If anyone have additional consideration in the question, please let me know.
>
> Thanks again,
> Irene
> *************************************************************************
> * *
> * Irene A. Shilikhina e-mail: irene_at_alpha.iae.nsk.su *
> * System administrator, *
> * Institute of Automation & Electrometry, *
> * Siberian Branch of Russian Academy of Sciences, *
> * Novosibirsk, Russia *
> * http://www.iae.nsk.su/~irene *
> *************************************************************************
> * * *
> * Good intentions pave a path to * Every cloud has a silver lining. *
> * the hell. * *
> * * *
> *************************************************************************
> >From Arrigo:
>
> >What I was trying to explain is that the logic is:
> >
> >o machine with DNS name and IP address which do not correspond
> > (i.e. spoofed) => PARANOID will deny access
> >o machine with *no* DNS entry will be allowed because there are
> > (were?) lots of machines on the Internet without DNS
> > entries. PARANOID cannot decide whether it is only a DNS
> > timeout problem (TCP/Wrappers have timeouts which you can
> > change).
> >Arrigo
> >
> >--
> >Arrigo Triulzi <arrigo_at_albourne.com> - Systems Director
> >Albourne Partners Ltd. - London, UK
>
> *************************************************************************
> >From Fill:
>
> >I have seen this same behavior in TCP wrappers. Here is my understanding.
> >The -DPARANOID option refuses connections from hosts that claim to be
> >a name that does not resolve to their real IP address. For example,
> >if an incoming telnet request packet claims to be from host
> > foo.bar.com
> >with IP address
> > 192.0.0.8
> >and a name lookup of foo.bar.com gives a different IP address, or a
> >reverse lookup of 192.0.0.8 gives a different name, then the connection
> >will be refused. This site is claiming to be someone else.
> >
> >On the other hand, if the incoming connection from 192.0.0.8 does
> >not have ANY host name in the packet, it is not claiming to be anyone.
> >It is just 192.0.0.8. In this case, TCP wrappers allows it. There
> >is no fraud here.
> >
> >I would actually like to have an option that says "refuse connections
> >from hosts that are not in the name servers", that is, when the
> >connection from 192.0.0.8 came in, if a reverse lookup failed and
> >could not get a system name, then refuse to allow it. I don't know
> >how to do that either with TCP wrappers.
> >
> >-Phil Farrell, Computer Systems Manager
> >Stanford University School of Earth Sciences
> >farrell_at_pangea.stanford.edu
>
> ************************************************************************
> >From Tim:
>
> >On Tue, 22 Sep 1998, Irene A. Shilikhina wrote:
> >
> >> The IP address 195.46.96.17 is not resolvable either.
> >> I have neither /etc/hosts.deny nor /etc/hosts.allow.
> >> I call "traceroute 195.46.96.17", and it is accomplished with such
> >> strings:
> >> 11 Irkutsk1-S7.RoSprint.net (193.232.91.189) 507 ms * *
> >> 12 Irnet-One-gw.RoSprint.net (193.232.91.73) 1000 ms * 1596 ms
> >> 13 195.46.96.49 (195.46.96.49) 1183 ms !H 1525 ms !H 1718 ms !H
> >>
> >The !H from traceroute means the host is not available. I get the same
> >thing from my site. I suspect the 195.46.96.49 router is either a
> >filtering router or a firewall. Either they have ping and traceroute
> >blocked from entering their site (many netowrks do this) or they don't
> >allow any traffic back in to their site.
> >
> >As for the telnet problem into your site, I suspect one of several things
> >could be happening. Their firewall is allowing telnet out but is blocking
> >packets coming back in. The remote host trys to get to you, but the
> >session can never be established because your hosts packets are blocked by
> >the firewall. This would be a misconfiguration on their site and is the
> >most likely case. Other scenarios are more "evil" and are not very
> >likely.
> >
> >I hope this helps!
> >
> >=== Tim
> >
> >---------------------------------------------------------------------
> >| Tim Winders, CNE, MCSE | Email: TWinders_at_SPC.cc.tx.us |
> >| Network Administrator | Phone: 806-894-9611 x 2369 |
> >| South Plains College | Fax: 806-897-4711 |
> >---------------------------------------------------------------------
> ****************************************************************************
> >From Sean:
>
> >On 22 September 1998, Irene A. Shilikhina wrote:
> >> without the refuse message. The same time, in sialog there are such
> >>entries:
> >>
> >> SIA:ERROR Tue Sep 22 13:00:33 1998
> >> Failure to authenticate session for on /dev/ttyp4
> >> SIA:ERROR Tue Sep 22 13:01:21 1998
> >> Failure to authenticate session for (null) on /dev/ttyp4
> >
> >You can reproduce this by telneting to your box and typing
> >^] to break the session and then quit at the telnet> prompt.
> >I have seen this with someone running mscan before. Basically,
> >they were looking for the info provided by:
> >
> >Digital UNIX (myalpha.isds.duke.edu) (ttypa)
> >
> >login:
> >telnet> quit
> >Connection closed.
> >
> >excerpt from my sialog:
> >SIA:ERROR Tue Sep 22 08:49:44 1998
> >Failure to authenticate session for on /dev/ttypa
> >
> >Hope this helps,
> >S
> >--
> >-------------------------------------------------------------------------
> >Sean O'Connell Email: sean_at_stat.Duke.EDU
> >Institute of Statistics and Decision Sciences Phone: (919) 684-5419
> >Duke University Fax: (919) 684-8594
> **************************************************************************
> My original posting:
>
> I have been using tcp wrapper rather long. But before it was built according
> to defaults. Yesterday I installed it with some options and among them with
> KILL_OPT = -DKILL_IP_OPTIONS
> to protect against hosts that pretend to have someone elses host address.
> Besides, (from README):
> When compiled with -DPARANOID, the wrappers will always attempt to look
> up and double check the client host name, and will always refuse
> service in case of a host name/address discrepancy. This is a
> reasonable policy for most systems.
>
> Therefore, I consider as normal such strings in the log file:
>
> Sep 21 16:42:56 alpha telnetd[14228]: warning: can't verify hostname:
> gethostbyname(host211.pl16.nsc.ru) failed
> Sep 21 16:42:56 alpha telnetd[14228]: refused connect from 194.226.190.211
>
> since host211.pl16.nsc.ru is not resolvable with the name server.
> So, in this case the user has no access to required service.
>
> Nevertheless, today I received such an entry in my log file:
>
> Sep 22 12:59:20 alpha telnetd[6735]: connect from 195.46.96.17
>
> without the refuse message. The same time, in sialog there are such entries:
>
> SIA:ERROR Tue Sep 22 13:00:33 1998
> Failure to authenticate session for on /dev/ttyp4
> SIA:ERROR Tue Sep 22 13:01:21 1998
> Failure to authenticate session for (null) on /dev/ttyp4
>
> (without user name (!) though it's rather telnet than ftp). So, I can judge
> that this time the service *WAS ACCESSIBLE*, and only login procedure was
> the last defence against violation.
>
> The IP address 195.46.96.17 is not resolvable either.
> I have neither /etc/hosts.deny nor /etc/hosts.allow.
> I call "traceroute 195.46.96.17", and it is accomplished with such strings:
>
> 11 Irkutsk1-S7.RoSprint.net (193.232.91.189) 507 ms * *
> 12 Irnet-One-gw.RoSprint.net (193.232.91.73) 1000 ms * 1596 ms
> 13 195.46.96.49 (195.46.96.49) 1183 ms !H 1525 ms !H 1718 ms !H
>
> where last address is different from what I pointed.
>
> Your ideas about the situation will be much appreciated.
> Thanks,
> Irene
>
>
Received on Thu Sep 24 1998 - 14:40:14 NZST
This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:38 NZDT