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

[Lennart Poettering]

On Sat, 22.03.14 01:20, Miloslav Trmač (mitr at volny.cz) wrote:

> > 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?

Isn't that obvious? You have a single language that centralizes your
access decisions in one place and opens up to you a variety of
credentials from all layers of the stack. And not just IP range
decisions...

> 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.

This is supposedly security functionality. You shouldn't build your
security functionality on top of DNS. If you do, then you gain no
security. 

> 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.)

And you honestly believe that people who are capable enough of setting
up DNS locally and across the company in a secure way to do something
like this, are also crazy enough to do their access control with tcpwrap
rather maybe firewalls and basically every other possibility?

Or, maybe there are people like that, there's always somebody crazy
enough for everything. But then the question is: should our product be a
toolbox with lots of crappy tools who are excessively hard to use in a
secure way, even though they are supposedly security tools, only useful
for extraordinarily capable administrators, who know exactly what they
have to make of them, and know that their supposedly "simple"
configuration files are really insecure unless you also are willing to
set up a massively complicated infrastructure of DNSSEC or otherwise
secured links so that nobody can poison your DNS?

You guys claim on one hand that tcpwrap is wonderfully designed and
super-easy to use. On the other hand you advise people using it to set
up DNSSEC, secured links and whatnot... So what is it now? Secure? Not
secure? Easy to setup? Difficult to set up?

> 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.

We *do* know that tcpd is 70% insecure non-sense, 100% crappy code, and
about 30% logic that is much better, safer, and more comprehensively
implemented in a firewall.

Lennart

-- 
Lennart Poettering, Red Hat