[4303] in WWW Security List Archive
Re: Access Logfile Question
daemon@ATHENA.MIT.EDU (Dennis Glatting)
Sun Feb 9 02:42:39 1997
From: Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us>
Date: Sat, 8 Feb 97 20:58:00 -0800
To: "Phillip M Hallam-Baker" <hallam@ai.mit.edu>
cc: "Paul F. Haskell" <phaskell@skyserv1.med.osd.mil>,
<www-security@ns2.rutgers.edu>
Reply-To: dennis.glatting@plaintalk.bellevue.wa.us
Errors-To: owner-www-security@ns2.rutgers.edu
> Preventing outside access to DNS servers is a very well
> established idea and is in no way a breach of Internet
> regulations. I would always advise an organization with a
> confidentiality need to take this step because machine names
> can be very revealing, machines frequently end up being given
> project names and there is a tendency for project names to
> reveal information.
>
In other words, they make stupid name choices. If an
organization is concerned about confidentiality, as you
suggest, I recommend they amend their security policy,
assuming they have one, and address the naming issue.
Placing their hosts behind a firewall would be a valuable step
too. With a firewall, such as CheckPoint's, the internal hosts
need to be registered in the externally visible DNS.
> The general principle for securing a sensitive server is to
> disable every facility that is not required. Telling the rest
> of the world your DNS names is certainly not required. In fact it
> is not even necessary to have a DNS address. My PPP dialup is
> bound to an address but there is no reason why anyone would need
> it. If we used DHCP there would be no point in the name at all.
>
Obviously there is good reason to place dynamic addresses into
DNS; otherwise, dynamic update would not be on the IETF's
agenda.
> I would generally employ router level filtering to prevent any
> access to internal DNS systems. Bringing down a DNS server is an
> effective denial of service attack. If you are serious about
> security you have to justify every facility the machine
> provides and provide an analysis of potential
> vulnerabilities. That costs a considerable amount of time and
> I don't think anyone would want to pay for it as far as reverse DNS
> goes.
>
Often internal DNS servers access external ones requiring a
return path. Packet filtering offers no protection from
spoofing or denial of service attacks against those servers.
> Security through obscurity is a dangerous accusation to make.
> Five years ago people were ridiculing the idea of shadow
> passwords in UNIX as security through obscurity. Today
> programs like crack are far better known and nobody would make
> the accusation. I've known as many people get bitten by asinine
> pride in dismissing sensible precautions as obscurity as have
> been fooled into thinking security alone would be sufficient.
>
> Then again, you probably don't deal with sites that have quite
> the number of hackers out to bring them down as I do :-)
>
Not placing hosts into DNS has an opposite effect, as it did
here: it makes people curious. The value of registering or not
registering is debatable. Regardless, one are not protected
from the curious or scan searches.
If an attacker is interested in an organization, there are
other avenues to learn their addresses such as searching the
rwhois database, searching for archived e-mail and news
articles across the Internet and examining their headers, or
simply monitor the organization's route points.
-dpg
