On Thu, 20.03.14 13:44, Stephen John Smoogen (smooge(a)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