On 20 March 2014 13:05, Lennart Poettering <mzerq...@0pointer.de> wrote:
> On Thu, 20.03.14 12:20, Stephen John Smoogen (smo...@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. > > 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. > 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... > > 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. 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. > > 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... > > I don't see the need to make such crude references. > > 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 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. 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. > > 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] > > I never rely on dns in hosts.allow or .deny. I use just ip addresses. So I don't see what [0] has on this. > 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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- Stephen J Smoogen.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
