Maybe it's time to get rid of tcpwrappers/tcpd?
"Jóhann B. Guðmundsson"
johannbg at gmail.com
Sat Mar 22 10:04:51 UTC 2014
On 03/22/2014 04:20 AM, Miloslav Trmač wrote:
>
> I'm not in this thread to discuss technical merits of the existing
> implementation. It may be 100% crappy code. /All/ of what you say
> above may be true, but that being true about a widely-used feature
> /doesn't automatically mean that eliminating the feature increases
> securit/y.
>
> I'm not even in this thread to object to doing extra work to break
> users' systems, because you may be right that most users of
> tcp_wrappers that use it for the DNS functionality shouldn't, and it
> might be irresponsible for us to support such configurations.
>
> I'm participating in this discussion because, as a general rule, I
> assume most administrators configuring security, and most users in
> general, /aren't idiots/. So, the fairly large number of assumed
> non-idiots using this functionality suggests, as a first approximation
> to truth, that it is useful, and it's the few of us that discuss
> removal of the feature that are wrong about the consequences of our
> actions.
So here's the thing daemons and applications are inconsistent in their
support for libwrap like for example sshd supports it while smbd does
not which leads to incorrect configuration and administrative
expectation which in itself poses a security risk.
The only way administrator can figure out which daemon/service was built
with libwrap support, is via ldd/string grep magic since we as an
distribution have not provide them with a list which do support it and
which do not,nor do we have those component correctly depend on
libwrap.so.0.
The undisputed fact is you are truly better off security and performance
wize using netfilter to solve this which can be done via tcp-wrapper
like behavior so...
iptables -A INPUT -p tcp --dport <port> -m iprange --src-range
<ip-range>-<iprange> -j ACCEPT
iptables -A INPUT -p tcp --dport <port> -j DROP
We should have dropped tcp-wrappers as well as denyhosts etc. a long
time ago but you know old habits die hard and all that but if FESCo is
going to refuse to do that it should ensure at least there will be a
list which explains it to adminstrators which component support this and
proper package dependency on libwrab for administrators sanity and
expectations...
JBG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140322/b5c990ef/attachment.html>
More information about the devel
mailing list