On Sat, 22.03.14 01:20, Miloslav Trmač (mitr@volny.cz) wrote:Isn't that obvious? You have a single language that centralizes your
> > 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?
access decisions in one place
This is supposedly security functionality. You shouldn't build your
security functionality on top of DNS. If you do, then you gain no
security.
> Also, note that an organization *can* actually make DNS sufficiently secure
> by using their own DNS servers that have authoritative sources for the> attacks from a compromised computer within the organization--which is
> 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
> *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 ofAnd you honestly believe that people who are capable enough of setting
> tcp_wrappers where this argument does not apply, and it does require care
> from the administrators of the system.)
up DNS locally and across the company in a secure way to do something
like this,
are also crazy enough to do their access control with tcpwrap
rather maybe firewalls and basically every other possibility?
You guys claim on one hand that tcpwrap is wonderfully designed and
super-easy to use.
> 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 evenWe *do* know that tcpd is 70% insecure non-sense, 100% crappy code, and
> a bigger mess implementing the same security theater.
about 30% logic that is much better, safer, and more comprehensively
implemented in a firewall.