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

[Lennart Poettering]

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

> > I doubt there are many people even using them anymore, firewalls are
> > more comprehensive and a lot more powerful, and while every admin knows
> > firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever
> > actively make use of them...
> >
> >
> Actually they are used quite a bit in various service worlds. Mainly for
> ssh and email for dealing with scanners. [DenyHosts is a boon in this
> area.] The reason for using a secondary tool is that depth of
> security.

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.

Again, I have no doubt that some people still use tcpwrappers. But I'd
argue that is clearly the excpetion, not the rule, and they'd better use
something different, and that we should be creating an excellent distro,
instead of a one that features horrible software...

> Over the years I have found that there are multiple of attacks which will
> nullify one layer of protection at one point or another. Having a second
> level or third level of protection is a boon when this happens.

Well, it certainly makes sense to combine a firewall with let's say
selinux with maybe postfix/ssh acls. Then you already have three layers
of protection, of very good protection. But of all possible options
tcpwrap is the absolute worst choice. And we should be able to deprecate
and remove stuff from our core OS if we think it is crap.

I mean, there are two sides of the medal: sure multiple layers of
protection might be a good thing, but you also make things a lot more
complex with each one, and you involve more possibly exploitable code --
and tcpwrap is simply bad code, that's a fact. So you have to balance
things out: is something a layer that is worth the trouble? Or does
having it around make things worse? I am of the opinion that tcpwrap
indeed does make things worse.

Sure, three layers of condoms probably make sex safer, but then again,
if one of them is made of 10 year old half-decomposed goat intestines,
then maybe the sex is a lot less fun, too...

> At the enterprise level firewalls can come under a different set of change
> control rules than something like tcpwrappers which is considered
> application level. While I would like to be able to make a simple change in
> a firewall, I can end up spending a month until I can. Application controls
> are usually an hour or so signoff. This means that if tcp-wrappers is going
> then something will need to be able to replace it to meet that large scale
> concern. [Automatic firewall controls like firewalld have to be disabled or
> put into a manual changes only mode in these areas for change control
> purposes. ]

Well, that really sounds like a specific issue of your
company... Really, I don't think the question whether the bureaucracy of
some hypothetical company makes a distinction between tcwrap and
firewalls has no place in the discussion whether we should support
tcpwrap in our distro or not.

> I can't argue on the code maintainability or layout. Not my area of
> expertise. I can say that if tcpd/libtcpwrappers were to go away that
> something equivalent would need to be built to replace it for the ability
> to fine tune at a layer below the firewall.

Why? Other than your hypothetical bureaucracy, is there anything that
tcpwrap can do that firewalls can't do, that really deserves to be
supported? I really can't see anything... [1]

tcpd comes from a time when there weren't local firewalls available in
all Unix systems, so they built something like them in userspace. But
that time is long long gone, and pretty much any Linux installation I
know nowadays has a firewall compiled into the kernel...

Lennart



[1] well, sure tcpwrap resolves DNS dynamically and can use that for
access control, but people who bind access control to DNS really should
find a different job than administrator...

-- 
Lennart Poettering, Red Hat