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

[Lennart Poettering]

On Thu, 20.03.14 13:44, Stephen John Smoogen (smooge at gmail.com) wrote:

> > Well, all mails servers as well as sshd have much better ways to do
> > such filtering. sshd has "Match",  Postfix for example has
> > "smtpd_client_restrictions=", and so on.
> >
> 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. There are also
proper firewalls, for traffic-level filtering. But where's the place for
tcpwrappers in all of this? It's neither really generic, nor
domain-specific, and also crappy code. We really don't need 3 layers
checking the very same thing...

postfix and sshd have mechanisms to filter for on specific domain each,
however covering a multitude of domain-specific high-level, matches and
actions.

A firewall has mechanisms to filter for all domains, however only
covering a smaller number of generic, low-level matches and actions.

tcpwrap otoh is somewhere in the middle, it's neither really generic,
nor really powerful. It's not a convincing, a very redundant option,
since it gets you very little features on top of a firewall, and is not
that universal either.

> Look I am not saying it isn't horrible to look at from a coding side. From
> a systems administrators side it does stuff in a very clean, easily audited
> way. It is also a nice key place where every application is actually using
> the same syntax versus each custom version. Having spent several ITIL
> meetings where you have to explain the syntax of each application to
> non-sysadmins, then prove that the change is correct, then prove that the
> change is easily backed out, and then other parts.. having 1 syntax to do
> that versus doing every applications custom version makes it a lot easier
> to deal with.

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

> I am not saying rip it out, but I am saying that you need something that
> replaces that one syntax, one file control, simple syntax method.

Let that be the firewall. It does the same thing, just better.

> I am giving you a standard enterprise problem. You are constantly going on
> about how systemd solves enterprise level problems and enterprises will
> love them. I am giving you a standard problem that tcpwrappers solves and
> you need to come up with some sort of replacement for them.  Most real
> problems enterprise administrators deal with are people oriented and this
> is a tool which deals with those problems in a way that is clean and
> clear.

Yupp, here's my replacement: a proper firewall.

And no, it's not a standard enterprise problem that firewalls need
higher people's sign-off than tcpwrappers in your theoretic firewall..

> All I am trying to do is point them out to you so that you don't end up
> having to spend all of 2016 recoding a replacement because it became a deal
> breaker for the various enterprise downstreams. If you want to make this a
> "You dare question me?" then fine, I can go do something else and know in
> the future that you aren't really looking for feedback.

You know, we have more powerful replacements both high-level (in
postfix, sshd, ...) and lower-level, we really don't need tcp wrappers.

I posted this here for feedback, and yes I got it, please understand
though at I will at least try to convince you that tcpwrap is a
dead-end. I mean, take it as an indication that I am actually taking
your feedback seriously, that I spend a lot of time arguing against
it. If I wouldn't take it seriously I wouldn't have started this
discussion and would certainly not have replied to this message...

Lennart

-- 
Lennart Poettering, Red Hat