# how does tcp wrappers work on gentoo? [Solved]

## Bones McCracker

How can I check which services I can control access to with my hosts.allow and hosts.deny files?  I see what's listed in documentation as examples of what it can protect, but I want to verify.

Gentoo doesn't have inetd and I don't have xinetd installed.  With tcpd installed and the tcpd flag turned on I am able to control access to sshd.  And I trust this would also work for other packages with the tcpd flag, such as gdm, gnome-session, and esound).  

However, I'm wondering about other binaries that belong to packages not having the tcpd flag and not apparently linked to libwrap.a

For example, there is no tcpd flag for xsm.  And yet, xsm depends on net-misc/netkit-rsh, which means I've got rshd on my machines whether I like it or not.   So, in the event rshd is activated, would my /etc/hosts.allow and /etc/hosts.deny files control access?

One thing I tried was testing which binaries are linked to libwrap.a.  Based on what little I am capable of, it does not appear that rshd is (I checked as follows):

```
strings -f /usr/sbin/rshd |grep "hosts_access"
```

Can someone tell me the correct way to test this or a better way to determine what is actually controllable with tcpd?

Thanks.Last edited by Bones McCracker on Thu Apr 05, 2007 8:12 am; edited 1 time in total

----------

## Chris W

Given that almost everything is dynamically linked I would gone with this approach to see if a binary is (potentially) using TCP wrappers (libwrap): 

```
chrisw@newton ~ $ ldd /usr/sbin/sshd

        linux-gate.so.1 =>  (0xffffe000)

        libwrap.so.0 => /lib/libwrap.so.0 (0xb7f05000)

        libpam.so.0 => /lib/libpam.so.0 (0xb7efd000)

        libresolv.so.2 => /lib/libresolv.so.2 (0xb7eeb000)

        libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb7ead000)

        libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb7d79000)

        libdl.so.2 => /lib/libdl.so.2 (0xb7d75000)

        libutil.so.1 => /lib/libutil.so.1 (0xb7d70000)

        libz.so.1 => /lib/libz.so.1 (0xb7d5e000)

        libnsl.so.1 => /lib/libnsl.so.1 (0xb7d48000)

        libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7d1a000)

        libc.so.6 => /lib/libc.so.6 (0xb7bf3000)

        /lib/ld-linux.so.2 (0xb7f26000)

```

 which does use it as you indicated, and 

```

chrisw@ptolemy ~ $ ldd /opt/teamspeak2-server/server_linux

        linux-gate.so.1 =>  (0xb7fbb000)

        libpthread.so.0 => /lib/libpthread.so.0 (0xb7f9d000)

        libdl.so.2 => /lib/libdl.so.2 (0xb7f99000)

        libc.so.6 => /lib/libc.so.6 (0xb7e70000)

        /lib/ld-linux.so.2 (0xb7fbc000)

```

 which would appear not to.  

Another approach would be simply to try it.  Set TCP Wrappers to deny access from a machine to your service of interest and see if you are indeed blocked.  Remove the block and see if you can then get in.

----------

## Bones McCracker

Thanks, Chris.

This will be very helpful.  I think I'll use it to write a little script.    :Smile: 

----------

## Naib

or just list what ebuilds use the "tcpd" USE flag

----------

## Bones McCracker

Well, I did that first, of course.  But that itself is what raised the question.  This should demonstrate the thought process I've been through.  Where it leaves me currently is concluding that tcpd (at least in my case) is really doing squat, since it provides no protection to the most vulnerable of services, and can be disabled.

 *Quote:*   

> DESCRIPTION
> 
>        The tcpd program can be set up to monitor incoming requests for telnet,
> 
>        finger, ftp, exec, rsh, rlogin, tftp, talk, comsat and  other  services
> ...

 

But here is the list of packages on this system honoring the tcpd USE flag:

 *Quote:*   

> # dep -U tcpd
> 
> tcpd:
> 
> ...     app-admin/syslog-ng-1.6.11-r1: Adds support for TCP wrappers
> ...

 

But our systems do indeed have many of the services described by the tcp wrappers man page:

 *Quote:*   

> # ls /usr/sbin/in.*
> 
> /usr/sbin/in.fingerd  /usr/sbin/in.rlogind
> 
> /usr/sbin/in.rexecd   /usr/sbin/in.rshd

 

Can I use tcp wrappers as a second layer of protection (to block these daemons from communicating should they become active?)

 *Quote:*   

> # ldd fingerd
> 
>         linux-vdso32.so.1 =>  (0x00100000)
> 
>         libc.so.6 => /lib/libc.so.6 (0x0fe60000)
> ...

 Nope.

And of those daemons listed in the tcpd man page that I do have, none of them are linked to tcpd.  Many of them, however, are linked to PAM libraries.  Maybe this is a clue that tcp-wrappers is pretty much obsolete and I should instead be validating and fine-tuning my PAM configuration.)

So, can I simply remove them?  Let's see.  What owns fingerd?

 *Quote:*   

> # dep -F /usr/sbin/in.fingerd
> 
> /usr/sbin/in.fingerd:
> 
>     net-misc/netkit-fingerd-0.17-r3

 

Okay, do I have to have "netkit-fingerd"?

 *Quote:*   

> # dep -L netkit-fingerd
> 
> net-misc/netkit-fingerd:
> 
> ...     net-analyzer/gnome-nettool-2.16.0    net-misc/netkit-fingerd

 

Well, I can live without gnome-nettool.  What about say, rlogind and rsh (both of which I'd like to render completely inaccessible)?

 *Quote:*   

> # dep -F /usr/sbin/rlogind
> 
> /usr/sbin/rlogind:
> 
>     net-misc/netkit-rsh-0.17-r7
> ...

 

Hmm... both of them belong to netkit-rsh.  I wonder if it's got a use flag that will make it use tcp wrappers?

 *Quote:*   

> net-misc/netkit-rsh-0.17-r7:
> 
> +pam        : Adds support PAM (Pluggable Authentication Modules) - DANGEROUS to
> 
>               arbitrarily flip

 Nope.  (Although maybe this is a second clue that I should abandon tcp wrappers and rely upon PAM entirely for access control).

Well, can I trash netkit-rsh?

 *Quote:*   

> # dep -L netkit-rsh
> 
> net-misc/netkit-rsh:
> 
>         x11-apps/xsm-1.0.1                   net-misc/netkit-rsh

 Shit, it's required by the X session manager.

Is there an USE flag for xsm that might turn off the dependency?

 *Quote:*   

> # dep -u xsm
> 
> x11-apps/xsm-1.0.1:
> 
> -debug      : Enable extra debug codepaths, like asserts and extra output. If 
> ...

 

Nope.

----------

## Hu

Having rshd on the system is not automatically a risk.  You only have a problem if someone turns it on.  If you are concerned, you could try changing the permissions on rshd to forbid execution.

----------

## Chris W

I would hazard a guess that xsm only uses the client portion of the rsh package in order to launch any remote applications that might be in a session.  If this is not something you do then it will not use rsh at all.

----------

## Bones McCracker

My main question was whether tcp wrappers was providing any benefit.

I decided it's excessively redundant (with firewall and service-specific host-based access controls) in the few cases where it was actually doing anything.  None of the old daemons seem to be linked to it.  So I removed it.

rshd and the others are fairly well access-controlled by pam, so I'm not that concerned about something starting them up

tftpd is not, though.  So I think follow Hu's suggestion and chmod it from 755 to 750.  

I'm leaving it on my other machine (which actually provides several more services) as a redundant measure for when I screw up.

Thanks for the comforting second opinion.    :Smile: 

----------

## wswartzendruber

 *BoneKracker wrote:*   

> My main question was whether tcp wrappers was providing any benefit.
> 
> I decided it's excessively redundant (with firewall and service-specific host-based access controls) in the few cases where it was actually doing anything.  None of the old daemons seem to be linked to it.  So I removed it.
> 
> rshd and the others are fairly well access-controlled by pam, so I'm not that concerned about something starting them up
> ...

 

Can someone tell me what this does that IPTables can't do?

----------

## Bones McCracker

Nothing.  But it is a redundant layer of protection at the host level, and a certain amount of redundancy is good.  Firewalls can be defeated (for example, malware on one of your windows boxes can start an outbound connection that sets up a conntrack entry on the firewall machine which then allows an external host to penetrate it).

One thing I never mentioned was specifically that xinetd (which gentoo does use by default instead of inetd) provides tcpd-like protection for most services.  Network access controls are provided for rexec, rlogin, rsh, etc. in /etc/xinetd.d, and network access to these services is denied by default :

/etc/xinetd.d/rsh

```
service shell

{

        socket_type     = stream

        protocol        = tcp

        wait            = no

        user            = root

        group           = tty

        server          = /usr/sbin/in.rshd

        log_on_success  = PID HOST USERID EXIT DURATION

        log_on_failure  = USERID ATTEMPT

        disable         = yes

}
```

But again, tftpd is not protected.

----------

## wswartzendruber

I'm wondering if I even need this given an Apache and PostgreSQL server.

----------

## Bones McCracker

 *wswartzendruber wrote:*   

> I'm wondering if I even need this given an Apache and PostgreSQL server.

 

I haven't used either in a while, but don't they provide their own network access control facilities?

----------

## wswartzendruber

 *BoneKracker wrote:*   

>  *wswartzendruber wrote:*   I'm wondering if I even need this given an Apache and PostgreSQL server. 
> 
> I haven't used either in a while, but don't they provide their own network access control facilities?

 

Exactly.  But I am, however, on a mission of paranoid security...and for no apparent reason other than...it interests me.

----------

## Bones McCracker

Regarding my own concern with tftpd, it would seem the risk is minimal as tftpd will only handle world-readable or world-writable files.

From tftpd man page:

 *Quote:*   

> SECURITY
> 
>        TFTP protocol does not provide any authentication.  Due to this capital flaw tftpd is not able to restrict access to files and will allow only  pub-
> 
>        lically readable files to be accessed. Files may be written only if they already exist and are publically writable.
> ...

 

Although, it does indicate that tftpd is started by inetd, so I would assume it is possible to create an /etc/xinetd.d/tftpd file, and I'm wondering why one is not provided by default that disables network access by default (such as is provided with the other simple services).

Maybe tftpd should be installed with a default xinetd.d/tftpd file something like this?  Can anyone offer advice?

```
service tftp

{

        socket_type = dgram

        protocol = udp

        wait = yes

        #user = tftp

        #server = /usr/sbin/in.tftpd

        #server_args = -l /tftpboot

        #only_from = localhost

        disable = yes

}
```

----------

## melinux

Is tcp-wrappers on gentoo going to have CIDR format added to it ?

Because that would be very convenient to have.

----------

## desultory

While there is a bug open requesting the inclusion of patches providing that functionality, there has been no developer activity on that bug for over 2 years, though the package has not been otherwise updated during that time.

----------

