Re: Is this a tcpwrapper bug?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jonathan Underwood wrote:
On 17/12/2007, Tom Horsley <tom.horsley@xxxxxxx> wrote:
On Tue, 18 Dec 2007 08:05:04 +0900
John Summerfield <debian@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx  Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- 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:-)


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux