tcpwrapper

tcpwrapper

Post by magm » Wed, 25 Jun 2003 01:01:51



Lo,

'm not sure to understand: is it actually possible to restrict
telnet access only to some users with tcpwrapper?

thx
--
Direct access to this group with http://web2news.com
http://web2news.com/?comp.security.unix

 
 
 

tcpwrapper

Post by Jay G. Sco » Wed, 25 Jun 2003 02:25:15




>Lo,

>'m not sure to understand: is it actually possible to restrict
>telnet access only to some users with tcpwrapper?

i think tcpwrapper is the same technique used in Red Hat.
so i'm pretty sure it is.  i'm a little rusty, sorry.
there should be a directory--i forget the name--something.d--
and in it there should be (or can be added) a file
for telnet.  sorry, my red hat stuff isn't close to hand...

j.

Quote:

>thx
>--
>Direct access to this group with http://web2news.com
>http://web2news.com/?comp.security.unix

--

Head of Sun Support, Sr. Operating Systems Specialist
Applied Research Labs, Computer Science Div.                   S224
University of Texas at Austin

 
 
 

tcpwrapper

Post by magm » Wed, 25 Jun 2003 16:03:15


Quote:> i think tcpwrapper is the same technique used in Red Hat.

yes xinetd has a lot of feature of the tcpwrapper.

But i'm working on Hp-UX, and i want to restrict the telnet
access to only 1 user. I'm not sure the control made by the
tcp wrapper always works: i think it depends if the client respects
the RFC931... anybody knows something about that?

my english is so bad :P
--
Direct access to this group with http://web2news.com
http://web2news.com/?comp.security.unix

 
 
 

tcpwrapper

Post by Stephan Neuhau » Thu, 26 Jun 2003 00:12:36



> 'm not sure to understand: is it actually possible to restrict
> telnet access only to some users with tcpwrapper?

TCP wrappers work essentially by looking at the source address of the
TCP connection attempt and then looking in a database to see whether the
connection should be allowed or not. (I have left out many details
here.) If it should, then control is handled to the appropriate daemon
(telnetd in your case) and TCP wrappers is no longer in the game.

To re-emphasize: TCP wrappers does not regulate access once control is
handled to the telnet daemon. It does not work on the application level.

Therefore, TCP wrappers cannot be used to control access to telnetd on a
per-user basis. TCP wrappers can only be used for access control on a
network (IP address) basis.

TCP wrappers is an excellent tool, but should only be used as one layer
of defense in depth.

Fun,

Stephan

 
 
 

tcpwrapper

Post by Rinaldi J. Montess » Thu, 26 Jun 2003 02:29:44



> TCP wrappers is an excellent tool, but should only be used as one layer
> of defense in depth.

Purely conjecture since I'm in no position to test it, but if the OP were to
make a group telnetusers, chown root.telnetusers /path/in.telnetd, chmod
0070 /path/in.telnetd, and add select users to group telnetusers, this
should give the desired results, yes?

Rinaldi
--
The opossum is a very sophisticated animal.  It doesn't even get up
until 5 or 6 PM.

 
 
 

tcpwrapper

Post by Mike Delane » Thu, 26 Jun 2003 03:29:48





: >
: > TCP wrappers is an excellent tool, but should only be used as one layer
: > of defense in depth.
:  
:  Purely conjecture since I'm in no position to test it, but if the OP were to
:  make a group telnetusers, chown root.telnetusers /path/in.telnetd, chmod
:  0070 /path/in.telnetd, and add select users to group telnetusers, this
:  should give the desired results, yes?

No.

 
 
 

tcpwrapper

Post by Bill Unr » Thu, 26 Jun 2003 05:12:33




]>
]> TCP wrappers is an excellent tool, but should only be used as one layer
]> of defense in depth.

]Purely conjecture since I'm in no position to test it, but if the OP were to
]make a group telnetusers, chown root.telnetusers /path/in.telnetd, chmod
]0070 /path/in.telnetd, and add select users to group telnetusers, this
]should give the desired results, yes?

No. Telnet has no idea when it starts up who it is that is trying to
start it up. Ie, it starts up as root (as do all of the daemons started
by inetd/xinetd unless told otherwise). There is no way that you can
control who on a remote machine uses telnet for this reason-- ie there
is no way telnet can know who it is that is requesting telnet. It is
only after the person has logged on that anything on your system can
know who it is that is trying to log on. That means that control has to
come through the login program, not telnet.

 
 
 

tcpwrapper

Post by Nick Maclar » Thu, 26 Jun 2003 06:23:12





>> 'm not sure to understand: is it actually possible to restrict
>> telnet access only to some users with tcpwrapper?

>TCP wrappers work essentially by looking at the source address of the
>TCP connection attempt and then looking in a database to see whether the
>connection should be allowed or not. (I have left out many details
>here.) If it should, then control is handled to the appropriate daemon
>(telnetd in your case) and TCP wrappers is no longer in the game.

>To re-emphasize: TCP wrappers does not regulate access once control is
>handled to the telnet daemon. It does not work on the application level.

>Therefore, TCP wrappers cannot be used to control access to telnetd on a
>per-user basis. TCP wrappers can only be used for access control on a
>network (IP address) basis.

This is factually false, but philosophically correct.

Not merely can you use tcpwrappers to restrict access on a per-user
basis, I did precisely that!  The "gotcha" is that it uses pidentd,
and therefore works only for machines that you can trust (i.e. you
can trust the superuser, both to be honest and to keep the system
secure).

I used it for controlling logins (i.e. allowing only administrators in)
for rsh etc. between login nodes and batch job nodes on a supercomputer
cluster.  For THAT, it is adequate.  In general, you can't trust the
user names.

Regards,
Nick Maclaren.

 
 
 

tcpwrapper

Post by chris ber » Fri, 27 Jun 2003 10:25:16



> Lo,
> 'm not sure to understand: is it actually possible to restrict
> telnet access only to some users with tcpwrapper?

hello. others have explained the benefits and limitations of using
tcpwrappers. but to achieve your desired effect, i would change the
login shell of those users whom you do not want to telnet in to
something like /bin/false.  note that this will not stop them from
using other services like ftp (unless /bin/false is not in /etc/shells)
or dtlogin.

or you can use pam to do this.  since you are using hpux, take a look at
the pam.conf and pam_user.conf man pages.

bye.

 
 
 

tcpwrapper

Post by magm » Fri, 27 Jun 2003 17:47:12


Quote:> i would change the login shell of those users whom you do not want to
telnet in to
> something like /bin/false.

those users will not be able to do anything anymore like cron, ... no?

Quote:> or you can use pam to do this.  since you are using hpux,

i think pam 's not supported by HP-UX 10.20 :{

for telnet: i test the pty in the .profile and disconnect the user if
its
pty is /dev/ttyp?
but for rlogin i don't have any good solution.

Quote:> bye.

--
Direct access to this group with http://web2news.com
http://web2news.com/?comp.security.unix
 
 
 

tcpwrapper

Post by cberg » Fri, 27 Jun 2003 23:44:16



>> i would change the login shell of those users whom you do not want to
> telnet in to
>> something like /bin/false.

> those users will not be able to do anything anymore like cron, ... no?

well, it depends on what this machine does before you decide on using
this as your solution.  for example, if this machine is used simply
for imap and pop access or to host a web application (and users log in
that way), or any other situation in which the user does not need a shell,
than this might work.  these users would be able to use cron, but im
not sure how they'd edit their cron entries - short of asking you to do it
for them.

Quote:>> or you can use pam to do this.  since you are using hpux,
> i think pam 's not supported by HP-UX 10.20 :{

a 10.20 machine i have has at least an /etc/pam.conf file and a manpage
for pam.conf, but it seems the pam support is not as full as it is in
versions 11+.

Quote:> for telnet: i test the pty in the .profile and disconnect the user if
> its
> pty is /dev/ttyp?
> but for rlogin i don't have any good solution.

be careful that you are not using their .profile ($HOME/.profile) as
this may be able to be bypassed (by deleting this through ftp, etc).
if you want to go this way, use a system-wide script that they cannot
change.
 
 
 

tcpwrapper

Post by Tim Kelle » Sat, 28 Jun 2003 06:45:27



> Lo,

> 'm not sure to understand: is it actually possible to restrict
> telnet access only to some users with tcpwrapper?

No, tcpwrappers doesn't do that.

You can accomplish this though, by giving everyone except the users
you want to have shell access "false" shells (e.g., /bin/false).  Then
they will not be able to log in.

--
Tim Kelley

 
 
 

1. identd and TCPwrappers

Hello All,

I am running Pidentd 3.0.4 in conjunction with TCPwrappers 7.6 and am
having some problems.
I have a small amount of entries (2) that allow me to telnet to
localhost
and login as another user. I have these for debug purposes.

This works fine.

ssh to remote host and then try to ssh to my local box. Although the
remote user at the remote host is defined locally in /etc/hosts.allow,
the acl matching constantly fails and prints my "no authorization"
banner.
My understanding of the identd protocol is that it returns the uid of
whomever initiates a given tcp/ip connection. Given this, I have seen
that for remote connections, identd does not correctly identify the

E,
getting the client port and the server port for a given connection and
feeding that to identd via a telnet session to port 113 on my box.
Given that, I am also wondering if I have identd's functionality
backwards.
All of this on my end of the connection is running on an SGI Indy,
IRIX6.2,
fully patched.
Any information to clarify the above would be appreciated.
Thank you.

Yours,

Josh...
_/_/_/ _/  _/ _/ _/
_/_/   _/ _/  _/ _/
_/_/_/ _/     _/ _/_/

2. Bash script help

3. Having (t)ftp problems with tcpwrappers

4. Looking for ATI 3D RAGE PRO AGP driver for Redhat 6.0.

5. portmap & tcpwrappers strangeness

6. software development mana

7. TCPWRAPPER

8. Problems with Lucent WaveLAN IEE

9. tcpwrappers are scaring me!!

10. tcpwrappers and lynx 2.2.5-release

11. Banners question for tcpwrappers

12. tcpwrapper 7.6

13. tcpwrapper log