On 03/20/2014 08:05 PM, Lennart Poettering wrote: > 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. I'd like to note that you can't just replace deny.hosts using Match block in sshd_config. - using libwrap, a connection is dropped before the protocol version exchange so a client can't even check the server's identification string. While using Match block, a client and a server exchange id strings, negotiate the transport layer parameters, exchange keys and establish encrypted connection. - in Match block, you can only change keywords related to authentication or ssh sessions - every change in sshd_config has to be confirmed by sshd restart, while changing hosts.deny doesn't need any other action Petr > 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... > -- Petr Lautrbach Security Technologies Red Hat Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com.
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct