Maybe it's time to get rid of tcpwrappers/tcpd?

[Miloslav Trmač]

2014-03-21 1:00 GMT+01:00 Lennart Poettering <mzerqung at 0pointer.de>:

> On Thu, 20.03.14 13:44, Stephen John Smoogen (smooge at gmail.com) wrote:
> > And now I need to have X number applications special syntax to
> > whitelist/blacklist a site. I need to change X files to make that change.
> > Each of those could be a separate change control process depending on the
> > size of the organization. Or I have 1 file that I can make a change to
> > which has usually one syntax and one set of reviews.
>
> Well, if you filter in postfix or ssh, then you have a domain-specific,
> powerful language there. You can not only match on source addresses, but
> also on user names, groups, authentication methods, connection features
> SASL schemes, crypto algorithms, ... It's a very good thing being able
> to control this in a unified, but domain-specific way.


What's "unified" about that?

Also, most of the things you mention should be up to administrator's policy
decision ("what authentication method or crypto is accepted") but not
really subnet- or domain-specific.  As a heuristic, "If you can't build a
reasonable GUI for it, you can't explain it or validate it and it will be
misunderstood."  (... that heuristic would kill so much of our servers'
options :) )


> If you want that unified language that can actually cover all kinds of
> apps and traffic, then use a firewall. It is truly universal (unlike
> tcpwrappers), and at least as powerful...
>

Using firewall with RPC services is possible but essentially defeats the
point of portmap, which is to avoid using dynamically allocated IP port
numbers and to instead use protocol / RPC references.

DNS queries can't really be done within the firewall (and due to the
circular dependency between having the firewall up before allowing access
to the network and needing access to the network to resolve DNS names, they
can't even be used in the on-disk firewall configuration).  Having a single
centralized name->IP address repository instead of having a redundant copy
in each host, and having the configuration use readable names instead of IP
addresses, makes some difference in usability and management overhead.

Also, note that an organization *can* actually make DNS sufficiently secure
by using their own DNS servers that have authoritative sources for the
relevant domains, even without DNSSEC: this would keep out all script
kiddies and internet-originating attackers who can't attack the link
between the tcp_wrappers user and the DNS server, while still allowing
attacks from a compromised computer within the organization--which is
*exactly* the case where the domain-specific configuration would probably
allow access *anyway*, so the attacker might have nothing to gain by
subverting DNS.  (Yes, there are many possible configurations of
tcp_wrappers where this argument does not apply, and it does require care
from the administrators of the system.)


The RHEL documentation, apart from fully describing the abilities,
specifically describes two uses: a ftpd banner, and running arbitrary shell
to collect intrusion detection statistics.  Neither is reasonably easy to
do with the firewall.  Now I'm not saying that these specific features are
critical :)


We *do* need to *actually understand* the user's motivations for using
tcp_wrappers, not just dismiss it as security theater--because even if it
*were* security theater, if we don't know why the users are doing this they
are likely to do it in the new system as well, and we will end up with even
a bigger mess implementing the same security theater.
    Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140322/b2ff7a0e/attachment.html>