Is this a tcpwrapper bug?

John Summerfield debian at herakles.homelinux.org
Tue Dec 18 04:21:54 UTC 2007


Jonathan Underwood wrote:
> On 17/12/2007, Tom Horsley <tom.horsley at att.net> wrote:
>> On Tue, 18 Dec 2007 08:05:04 +0900
>> John Summerfield <debian at herakles.homelinux.org> wrote:
>>
>>> I don't see that tcpwrappers does a lot for you in this case than you
>>> can also do with iptables.
>> Sure it does: It achieves exactly what I want, and doesn't require
>> yet another daemon to be running with yet another obscure
>> command language to learn :-). (The hosts.allow syntax is only
>> about 1/10th as obscure as the iptables commands).
> 
> There's nothing wrong with the hosts.allow approach, but do note that
> using the iptables approach doesn't require yet another daemon to be
> running.

The hosts files can selectively allow and deny access to services, based 
on IP addresses and/or host names, provided that the program providing 
the service is configured to uses tcpwrappers.

iptables can do exactly the same, without the program implementing the 
service having any special characteristics wrt tcpwrappers or any like 
protection service, it's done in the kernel.

to that point, they're pretty well equivalent.

iptables has these advantages:
1. It can filter the packets on entry to the system and reject, drop or 
allow them at that point. In contrast, use of tcpwrappers requires the 
packet be accepted, and then the application (or xinetd in its stead) 
has to open a connection to some point to discover the source of the packet.
iptables uses less processing power.

2. iptables (or some other firewall software) can be running on another 
host in the route between client and server. Packets don't even arrive 
at the server, unless the firewall allows it.

3. iptables can direct services do different hosts, depending on the 
service requested and potentially the source of the request. I have in 
the past used iptables to direct some traffic (openvpn) to one internal 
system, ssh to another and process some (openvpn from a different 
source) itself.
tcpwrappers can't do this.

4. iptables can control the rate at which connexions are accepted.

tcpwrappers has an advantage, it can run user code:
false: ALL: spawn (echo attack from  @%h | \
                /usr/bin/mail -s %d-%h root) &
This could be very handy, if one were so inclined, to take out apparent 
attackers. The  technique would be to open ports to some services not 
used at your site, configure xinetd to run them, and protect them with a 
scripted based on this.

I have this on my telnet more, thus:
mail:~# cat /etc/xinetd.d/telnet
# default: off
# description: An internal xinetd service which gets the current system time
# then prints it out in a format like this: "Wed Nov 13 22:30:27 EST 2002".
# This is the tcp version.
service telnet
{
         disable         = no
         socket_type     = stream
         protocol        = tcp
         user            = games
         wait            = no
         flags           = NAMEINARGS
#port           = 23
         server          = /usr/sbin/tcpd
         server_args     = /bin/false
}
mail:~#
As it happens, the result is that I get mail, but a more creative script 
might write a firewall rule that blocks the source IP address and its 
32764 near neighbours.

Or I could open ssh to the source address, so I could ssh in from a 
remote site.

But generally, I don't see that tcpwrappers has much to offer over iptables.



-- 

Cheers
John

-- spambait
1aaaaaaa at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)




More information about the fedora-list mailing list