On Tue, 11 Jul 2000 [EMAIL PROTECTED] wrote:
> The original post doesn't specify what type of information is being
> transferred from their primary to the secondary. But if they do not want
It's not the primary->secondary transfer they're worried about, it's 3rd
pary transfers, which have typically been used to generate lists of hosts
to attack and/or attack methodologies. Most audits also use the same
metric about transferability to build pass/fail criteria.
> some of this information to be available to the world it would make sense
> for them to hide it using a stealth primary or secondary server.
If you want it hidden, provider-based servers are a no-no.
> I don't claim to be a DNS wizard but if you use the PTR record in the
> in-addr.arpa domain, you can "map in reverse from IP numbers to hostnames.
To *A* host name. You only get *one* PTR RR (Resource Record) per host,
but you can have *many* A RRs. That becomes more important as people
start fielding virtual-hosted servers where the server name in the request
defines which content gets sent back to the client. Also, as I pointed
out in another post, that only gets you hostnames in the same address
space as one you already know. Many organizations outsource www.whatever
(though not so many do so for their primary MX), so the address may be not
as useful to an attacker as the zone file.
> Many Internet protocols and applications rely on this pointer, by
> convention, so it is not likely to be absent on purpose. Unless the
Actually, I'd say that though it's gotten better over the last few years,
quite a large number of places still don't implement PTR RRs for
significant portions of their address space. Generally due to the fact
that address owners are providers rather than end-companies these days and
also due to the fact that many smaller providers (or places like cable and
residential DSL providers) don't get or don't want to try to manage the
complexity of handing out sub-/24 in-addr.arpa delegations.
TCPWrappers is the only *application* I can think of that relies on the
inverse mapping- and it can be set not to- almost everything else can be
made to ignore the lack of a PTR RR (at least for HTTP, SMTP, SSL, FTP,
NNTP, IGP/EGPs that I've dealt with, SSH, CVS, RPC, gopher, IRC, and a few
other protocols I've played with.) Could you enumerate "Many Internet
protocols" for me please, obviously I've either missed something or broken
quite a few protocol specifications :( (I rarely set up PTR mappings on
internal networks with non-Internet root servers.)
> address isn't being used, of course, but we don't want any of those
> anyway. By checking to see which IPs in the allocated address space have
> a pointer in the in-addr.arpa domain, we can narrow down the search
> space." This method for the most part will gather the same intel I can
> get from a AXFR. And then there is always NMAP and other such tools.
If you're an attacker, you're more likely to want to scan the address
space than limit the search space since a *great number of boxes* are the
things stuck up in the spur-of-the-moment or don't-tell-the-real-admin
kinds of modes that typically result in boxes that are full of holes, no
longer maintained and not even monitored. They're not likely to have PTR
records in that case, and they may not have A records (though there's a
lot of "before we learned how to play this for real" stuff still hanging
out there with A records but no PTR records.)
> Limiting zone transfers is IMO is not very effective security by
> obscurity. There are better way of limiting the proliferation of DNS
> information.
I agree somewhat, which is why I said:
> Relying on zone data which doesn't change often to be confidential is
> somewhat silly.
It is worth noting though that the per-execution unit workload at the
nameserver is significantly higher with zone transfers, so DoS on the DNS
is probably easier if they're on.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
