TCP wrappers (hosts.allow/deny): do you use them anymore?
TCP wrappers (hosts.allow/deny): do you use them anymore?
Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore? And, would you care strongly if it went away (or would you just migrate to something else)?
I bring this up because we are discussing dropping it from Fedora. This would be far enough in the future that it wouldn't impact RHEL 7, and therefore won't affect anyone here for Quite Some Time*, but here in the new world order of CentOS, I thought it might be useful to check with some actual downstream users.
What do you think? Do you rely on hosts.allow/hosts.deny a primary security mechanism? As defense-in-depth? Do you have policies which mandate it?
Your feedback appreciated. Thanks!
* and the standard caveats that Fedora doesn't necessarily determine the path for RHEL apply, of course.
I bring this up because we are discussing dropping it from Fedora. This would be far enough in the future that it wouldn't impact RHEL 7, and therefore won't affect anyone here for Quite Some Time*, but here in the new world order of CentOS, I thought it might be useful to check with some actual downstream users.
What do you think? Do you rely on hosts.allow/hosts.deny a primary security mechanism? As defense-in-depth? Do you have policies which mandate it?
Your feedback appreciated. Thanks!
* and the standard caveats that Fedora doesn't necessarily determine the path for RHEL apply, of course.
Re: TCP wrappers (hosts.allow/deny): do you use them anymore
I still do on some systems. This does not mean I'm against it being removed. This must be part of the efforts of removing old (unmaintained?) code?
CentOS Forum FAQ
Re: TCP wrappers (hosts.allow/deny): do you use them anymore
Yep, denyhosts uses it.
- eugene.ievlev
- Posts: 19
- Joined: 2014/02/07 10:41:03
- Location: Ukraine
- Contact:
Re: TCP wrappers (hosts.allow/deny): do you use them anymore
Hi all,
Sometimes in closed systems (which are installed on multiple servers, and should be available only for each-other), it is more convenient to use hosts.allow \ hosts.deny instead of a large firewall ...
Sometimes in closed systems (which are installed on multiple servers, and should be available only for each-other), it is more convenient to use hosts.allow \ hosts.deny instead of a large firewall ...
Re: TCP wrappers (hosts.allow/deny): do you use them anymore
I'm asking for cases where people are using it, not software dependencies.pajamian wrote:Yep, denyhosts uses it.
DenyHosts hasn't been maintained in years. I recommend replacing it with fail2ban, which can also manipulate firewall rules (even using firewalld if available). So I don't think that that's a showstopper.
Re: TCP wrappers (hosts.allow/deny): do you use them anymore
Yes, I use it to limit vsftpd (FTP) access. The vsftp server explicitly supports TCP Wrappers.mattdm wrote:Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore? And, would you care strongly if it went away (or would you just migrate to something else)?
I know we shouldn't use FTP any longer, but this is the real world. Sometimes it is still required. In our case we know in advance that we can limit FTP access to a small number of IP addresses. This is a neat way to control an otherwise fragile protocol. The hosts.allow can be changed on the fly and takes immediate effect, so it becomes very straightforward to add/remove a new FTP client.
I'm willing to change to something else. What? It is hard to imagine anything being simpler than this approach. Just my 2c.
Richard
Opus75, Inc.
Re: TCP wrappers (hosts.allow/deny): do you use them anymore
mattdm wrote:Do you rely on hosts.allow/hosts.deny a primary security mechanism?
(Hell) No. I prefer and promote the use of ipset for almost anything that requires OTF changes like access lists or fail2ban blocks.
mattdm wrote:As defense-in-depth?
Yes, in a layered security approach it may help prevent other measures from becoming a single point of failure.
Company policies, yes.mattdm wrote:Do you have policies which mandate it?
- Super Jamie
- Posts: 310
- Joined: 2014/01/10 23:44:51
Re: TCP wrappers (hosts.allow/deny): do you use them anymore
I personally don't use the TCP wrappers, and I don't really see the point of them.
The only use case I can see for wrappers is when a service changes port.
eg: If the port can be dynamic like the NFS services, though if you're putting NFS behind a firewall then you need to hard-set all the ports anyway.
Or if the port change is built into the protocol like FTP, there is a conntrack module to allow the FTP data connection.
Is there anything that wrappers can do that a firewall can't? If not, then I wouldn't miss the wrappers.
The only use case I can see for wrappers is when a service changes port.
eg: If the port can be dynamic like the NFS services, though if you're putting NFS behind a firewall then you need to hard-set all the ports anyway.
Or if the port change is built into the protocol like FTP, there is a conntrack module to allow the FTP data connection.
Is there anything that wrappers can do that a firewall can't? If not, then I wouldn't miss the wrappers.
Re: TCP wrappers (hosts.allow/deny): do you use them anymore
I think IPTables are much easier and most secured
Re: TCP wrappers (hosts.allow/deny): do you use them anymore
using hosts.allow/hosts.deny as secondary to iptables
hoste that are not allowed to ssh my virtual server are blocked in hosty.deny
IP ranges of my ISP are in hosts.allow, to prevent myself of being locked out ...
hoste that are not allowed to ssh my virtual server are blocked in hosty.deny
IP ranges of my ISP are in hosts.allow, to prevent myself of being locked out ...
Greetings from Austria,
Walter H.
--
VMware Machines:
- IMAP/SMTP (Cyrus,Postfix,SpamAssassin,ClamAV)
- DNS (BIND)
- Apache,MySQL,...
- SSL-Proxy (Squid,ClamAV)
Mini-PC as Router/Firewall:
- HE IPv6 Tunnel, DHCPv6, RADVD, DNS (BIND)
Walter H.
--
VMware Machines:
- IMAP/SMTP (Cyrus,Postfix,SpamAssassin,ClamAV)
- DNS (BIND)
- Apache,MySQL,...
- SSL-Proxy (Squid,ClamAV)
Mini-PC as Router/Firewall:
- HE IPv6 Tunnel, DHCPv6, RADVD, DNS (BIND)