On Tue, 22 Feb 2005, Pekka Savola wrote:
> You have sent a number of messages on this, and it seems unproductive
> to respond. However, I'll address this one.
I agree, it seems unproductive to respond. These points have been brought
up repeatedly in the past, and you still don't get them. Why rehash this?
Only you continue to posit this draft with its many inconsistencies and
incorrect statements, and bad recommendations.
> First off, there are at least two ways to perform forward+reverse
> checking. I'm not sure you can see these as separate.
>
> 1) check that forward and reverse entries match, but don't check what
> the name actually is (this could be phrased as a "consistency check").
You check that there are two records, but you don't check them. How is
that a consistency check?
> 2) check that foeward and reverse entries match, and the name is
> included in a list of names.
>
> I agree that 1) appears to serve no security purpose. However, I
> think 2) is still useful as an additional security mechanism.
Your number 1 above makes no sense to me at all. I hadn't considered it.
> Obviously, property 2) is not needed for those hosts which won't be
> used in this kind of manner, so your argument about www.arin.net does
> not hold for 2).
www.arin.net is merely a high profile example where a check such as your
2) fails.
> Inline..
>
> On Tue, 22 Feb 2005, Dean Anderson wrote:
> >> For example, lots of people have tcp wrappers configuration in their
> >> SSHD, requiring that connection attempts come from host.example.com,
> >> .example.net or whatever (forward+reverse check). This is especially
> >> useful when the server is at example.net, but has a couple of pinholes
> >> to the world.
> >>
> >> In addition to that, there is a public key security or password
> >> authentication.
> >
> > The illogic of this can't be ignored.
> >
> > If public key or password authentication are "in addition" to some
> > security, then we can consider what security is left without 'public key
> > or password'. So lets do that: Well, this is exactly the bsd r-command
> > EXPLOIT. No security remains.
>
> I'll assume you meant method 2) above.
>
> I think this is an incorrect consideration. If reverse+forward
> matching to a specific hostname was done _after_ password or public
> key authentication, this might be closer (but not quite) the truth.
You didn't read my message. To find out what security was present before
'the addition' of either public key or password authentication, we
consider the security without them.
> However, applying a reverse+forward matching to a specific, configured
> hostname as the _first_ measure of check restricts the attackers to
> those which can control the particilar reverse and forward trees, or
> spoof the DNS in a particular way.
No, it provides NO RESTRICTION WHATSOEVER.
> This is certainly very useful. It'll prevent random script kiddies
> and port scanners (for example) from attacking a particular service.
Only in your dreams.
> It may not be 100% protection against the most determined crackers,
> but that's what the _additional_ protections are for.
Its 0% protection. Spoofing DNS is well within the reach of every script
kiddie.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
