On Tue, 22 Feb 2005, Pekka Savola wrote:
> On Tue, 22 Feb 2005, Dean Anderson wrote:
> > 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 [...]
>
> An interesting view. In contrary -- I think only you are one strongly
> opposed to this draft.
>
> >> 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?
>
> For example an SMTP might check that the SMTP session that initiated
> from IP address 1.2.3.4 would have the reverse for 1.2.3.4 point to a
> name, which refers back to the PTR record. The system, however, would
> not have white or blacklisted hosts or IP address which to check
> against -- this would be applied to all connections, with intention,
> "we don't want to allow sessions from anyone whose reverse and forward
> DNS entries aren't consistent, though we don't actually care at all
> what those DNS entries are as long as they are equivalent".
The above has been discredited as an anti-spam measure, with all but
certain small number of zealots. There are large blocks of space for
which IN-ADDR is not available in africa and elsewhere. There are many
examples where it is possible, but not done. Here is a recent example:
==============================================================
From: Pat <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: no reverse delegation policy
I recently switched connectivity providers (to save some $$$) and come to
find out they don't want to delegate reverse ip resolution to my name
servers.
==============================================================
Apparently, you don't have to exchange mail with all of the world. Or
perhaps you just want to require everyone to do IN-ADDR so complaints such
as the one above don't happen, and so that your wrong assertions about
SMTP in-addr checking don't dump so much genuine mail, which spammers
using stolen residential systems send tons of junk because the residential
ISPs are quite happy with the auto-generated IN-ADDR.
Rather than admit to being wrong about the validity of the IN-ADDR check,
just change the world to make it less obviously wrong.
> >The notion of r-command security seems to me to serve to discredit the
> >contents of this draft. I cannot believe we are actually debating the
> >view that the bsd r-commands security, that is, the in-addr based
> >"security" assumption, is actually a good idea.
>
> You are deliberately trying to confuse this issue, or just don't get
> it.
Err, no. I think its you who doesn't get it. I'm perhaps foolish to be
arguing with you about it.
> The r-command security was based on DNS, yes. But that was ALL.
> There was _no_ additional security at all.
Exactly. Not only was there no _additional_ security in the r-commands,
there was _NO_ security, as a result. In other words, an exploit. I refer
you back to your original message:
On Tue, 22 Feb 2005, Pekka Savola wrote:
> But yet, it _is_ a form of security.
>
> 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.
There is no security to be in addition to: Take out the "addition" of
public key and password and there is nothing left. There being nothing
left, there is no security in DNS checks, refuting your claim that it is a
form of security.
> Here, we have setups which are very secure already in itself (e.g.,
> SSH with a public key), but the administrator just wants to get
> additional security by cutting out 99.99% of attacks before they hit
> the servers' port 22 -- port scans, typical script kiddie attacks,
> etc.
There is no additional security. No real attacks are cut out. Only your
naive scans are cut out. Worse, additional real attacks are created: Bad
guys know you configure your firewalls using DNS information. So, a bad
guy can penetrate your security by spoofing DNS. It may be as simple as
getting your firewall to reboot, and getting it to treat his bad IP as a
trusted server. Meanwhile, you falsely conclude no one can penetrate your
naive "security", because you used tcp-wrappers, or whatever.
I guess you haven't read the draft where it says that. I'd say my point
about giving lip-service in the draft to DNS non-security but ignoring
that in practice, is pretty much at the
driven-home-through-concrete-losing-points-to-overkill stage.
--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
