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:-)
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
