Re: Cracked by the Brazilians

[karthik_krish76 () YAHOO COM (karthik krishnamurthy)]

   I had made a later posting stating that i had made
a small mistake. the directive should be thus

listen-on {
   interface1;
   interface2;
};
I apologize for the mistake made.

While this should suffice for caching only nameservers
it is not enough for nameservers authoritative over
some domains.

   Considering the spate of recent named attacks I
shall take the liberty of prescribing a secure named
configuration for auth nameservers.

   Kindly note that the following examples have been
taken, almost verbatim, from "DNS and Bind" by Albitz
and Liu (O'Reilly Associates).

   Consider a nameserver that is authoritative over a
domain foo.org also serving internal hosts as a
caching only nameserver. In that case we cannot have
named listening only to the internal interface.
options {
   directory "/var/named";
   allow-query { internal-interface-only; };
};

zone "foo.org" {
   type master;
   file "db.foo.org";
   allow-query {any;};
   allow-trasnfer { foo-slaves; }
};

   In the preceding example internal-interface-only is
to be substituted with the address of the interface to
which your local lan is attached. This statement (as
is obvious) will allow queries (any kind) only on that
interface. It is also becomes the default.
The any in allow-query { any; } is literal. any is an
acl defined by default. This will allow queries from
anywhere only for the domain foo.org thus permitting
the nameserver to server any type of queries within
that domain.

   The allow-transfer directive will allow only zone
transfers to addresses in the acl foo-slaves (an acl
that should be defined as the slaves for that zone.
also add allow-transfer {none;}  in the slave's
named.conf) Though this is irrelevant to the current
discussion it will still not allow the attacker to get
the name of the hosts in your domain.

In the case where we are running only an authoritative
nameserver the following should suffice.
options {
   directory "/var/named";
   allow-recursion no;
   fetch-glue no;
};
zone "foo.org" {
   type master;
   file "db.foo.org";
   allow-trasnfer { foo-slaves; }
};

The allow-recusrsion and fetch-glue directives will
make the named refuse recursive queries which is
central the attack.

   I am sure most of you know that the attacker relies
on named allowing recursive queries to a zone under
his control. The shellcode is sent when named contacts
the exploit which is running in place of named on the
machine which is authoritative over that domain. Thus
refusing recursive queries should solve the problem.
A correctly configured nameserver should only return a
referral instead of recursively resolving the domain
that the attacker asks of it. Trying this at a
yahoo.com nameserver should show.
nslookup
> server ns1.yahoo.com
Default server:  ns1.yahoo.com
Address:  204.71.200.33
> luga.org

ns1.yahoo.com will return a referral to the root
nameservers which should be the case.

   In the caching & auth nameserver example this is
solved by not allowing any sort of queries at the
world at all (except for the domains over which we are
authoratitve). As any queries allowed will only be for
our domains the question of whether it is recursive or
not will not matter. ( I think).

   Please bear with any mistakes I might have made in
this posting too and sorry for a rather long one. I
have posted almost an entire chapter form "DNS and
Bind". Hope the authors don't mind :)

regards

--- Lance Spitzner <lance () spitzner net> wrote:
> On Sat, 1 Apr 2000, karthik krishnamurthy wrote:
>
> >   I dont think your named is listening only on
> your
> > private interface. i have made the changes which
> > should make it secure ( to the best of my
> opinion). As
> > you are running a caching only nameserver the
> > listen-on directive is all you need.
>
> Does the 'listen-on' option specify the interface
> that
> named listens to?
>
> Are there any other security options you can
> recommend
> for named?
>
> Thanks!
>
> > acl "valhall" {
> >         { 192.168.3.1/32; };
> >         { 192.168.3.0/24; };
> >         };
> >
> > options {
> >         directory "/var/named";
> >     listen-on {valhall; };
> > };
>
> Lance

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com