On Thu, 20.03.14 12:20, Stephen John Smoogen (smooge@xxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
