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 Wed Sep 23 1998 - 04:48:45 NZST