2014-03-21 1:00 GMT+01:00 Lennart Poettering <mzerqung@0pointer.de>:
On Thu, 20.03.14 13:44, Stephen John Smoogen (smooge@gmail.com) wrote:
> 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.

What's "unified" about that?

Also, most of the things you mention should be up to administrator's policy decision ("what authentication method or crypto is accepted") but not really subnet- or domain-specific.  As a heuristic, "If you can't build a reasonable GUI for it, you can't explain it or validate it and it will be misunderstood."  (... that heuristic would kill so much of our servers' options :) )
 
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...

Using firewall with RPC services is possible but essentially defeats the point of portmap, which is to avoid using dynamically allocated IP port numbers and to instead use protocol / RPC references.

DNS queries can't really be done within the firewall (and due to the circular dependency between having the firewall up before allowing access to the network and needing access to the network to resolve DNS names, they can't even be used in the on-disk firewall configuration).  Having a single centralized name->IP address repository instead of having a redundant copy in each host, and having the configuration use readable names instead of IP addresses, makes some difference in usability and management overhead.

Also, note that an organization can actually make DNS sufficiently secure by using their own DNS servers that have authoritative sources for the relevant domains, even without DNSSEC: this would keep out all script kiddies and internet-originating attackers who can't attack the link between the tcp_wrappers user and the DNS server, while still allowing attacks from a compromised computer within the organization—which is exactly the case where the domain-specific configuration would probably allow access anyway, so the attacker might have nothing to gain by subverting DNS.  (Yes, there are many possible configurations of tcp_wrappers where this argument does not apply, and it does require care from the administrators of the system.)


The RHEL documentation, apart from fully describing the abilities, specifically describes two uses: a ftpd banner, and running arbitrary shell to collect intrusion detection statistics.  Neither is reasonably easy to do with the firewall.  Now I'm not saying that these specific features are critical :)


We do need to actually understand the user's motivations for using tcp_wrappers, not just dismiss it as security theater—because even if it were security theater, if we don't know why the users are doing this they are likely to do it in the new system as well, and we will end up with even a bigger mess implementing the same security theater.
    Mirek