How Secure is ".Local?"

  • Thread starter Thread starter Dave
  • Start date Start date
D

Dave

Hi all,

I would like to run AD on my public DNS servers, 'hiding'
my private AD domain with a non-routable extension, like
the suggested '.local' (e.g., 'mycompany.local').

QUESTION: If the '.local' extension is common knowledge or
becomes a standard, it follows that 'mycompany.local' is
easily guessable. What will prevent eavesdroppers from
querying my public DNS servers for the private
'mycompany.local' AD names/addresses? Should I instead
employ something unobvious, like 'mycompany.abcxyz'?

Any advice is greatly appreciated.
 
: Hi all,
:
: I would like to run AD on my public DNS servers, 'hiding'
: my private AD domain with a non-routable extension, like
: the suggested '.local' (e.g., 'mycompany.local').
:
: QUESTION: If the '.local' extension is common knowledge or
: becomes a standard, it follows that 'mycompany.local' is
: easily guessable. What will prevent eavesdroppers from
: querying my public DNS servers for the private
: 'mycompany.local' AD names/addresses? Should I instead
: employ something unobvious, like 'mycompany.abcxyz'?
:
: Any advice is greatly appreciated.

http://www.windowsecurity.com/articles/Securing_Windows_2000_DNS_by_design_Part_1.html


--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Online Support for IT Professionals -
http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
How-to: Windows 2000 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
FAQ W2K/2K3 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382
 
Thank you, Roland, but this article only answers the
question by saying, "don't do it." Other authors, such as
the well-respected Mark Minasi, suggest that running AD on
a public DNS server is a viable solution.

FYI, I am running split-brain DNS already, as recommended
by the article you present. But our network is so small
that we no longer want to dedicate separate servers to DNS,
AD, backup DNS and backup AD. It's just too much hardware
for our modest needs. If we MUST have public DNS servers,
then it seems logical to also put our AD there, if at all
possible.

Thank you for your response. I do appreciate it.
 
In message <[email protected]> "Dave"
Thank you, Roland, but this article only answers the
question by saying, "don't do it." Other authors, such as
the well-respected Mark Minasi, suggest that running AD on
a public DNS server is a viable solution.

FYI, I am running split-brain DNS already, as recommended
by the article you present. But our network is so small
that we no longer want to dedicate separate servers to DNS,
AD, backup DNS and backup AD. It's just too much hardware
for our modest needs. If we MUST have public DNS servers,
then it seems logical to also put our AD there, if at all
possible.

Personally, I don't see the harm in having this information publicly
available -- In most cases an attacker will already be able to perform
DNS lookups within your network by the time they get far enough in to do
any damage.

All that being said, my DNS is in private name space. I use a
internal.example.com nomenclature where everything under internal is
only resolvable internally, externally most of it points to NXDOMAIN,
although a few hosts have valid external IPs (the VPN server being a big
one -- Some people VPN internally too, so it makes everybody's life
easier)
 
Dave said:

To start: .local is not secure at all.

It is not going to provide your zone info to anyone
on the Internet since local is NOT a zone in the
Internet namespace.

Don't think of this as "security" -- it's not, except
in the sense that you are definitely not publishing
your INTERNAL resource names on the Internet,
but then you should not do that no matter what name
you pick.
I would like to run AD on my public DNS servers, 'hiding'
my private AD domain with a non-routable extension,

Extentions have NOTHING to do with "routable" --
local doesn't appear in the Internet namespace so is
not resolvable from the Internet root (there is no local
top level domain on the Internet.)
like the suggested '.local' (e.g., 'mycompany.local').

It is impractical (and a very poor) design for your to run
your internal (AD support) DNS on a public server.
QUESTION: If the '.local' extension is common knowledge or
becomes a standard, it follows that 'mycompany.local' is
easily guessable.

You are misunderstanding the purpose of the local and
the actual effect.

It is merely to avoid registering on the Internet and publishing
the name there, as well as guarantee that you will not class
with anyone else (since they cannot register it either.)
What will prevent eavesdroppers from
querying my public DNS servers for the private
'mycompany.local' AD names/addresses?

Not a all. The way you prevent this is by NOT allowing
your internal DNS server to offer resolution on the
Internet. It doesn't matter what name you use, don't offer
the internal zone on the Internet.
Should I instead
employ something unobvious, like 'mycompany.abcxyz'?

No, you just should try to approach the problem as above.

Most people shouldn't even be running ANY public DNS
server themselves but should leave their public DNS as
the registray.
Any advice is greatly appreciated.

DNS for AD SHOULD be inside the firewalls -- obviously
there may be exceptions for those people deploying and
AD publicly but this is VERY uncommon and represents a
serious security task (keeping the whole thing safe.)

DNS for AD should GENERALLY be on the DCs for most
small business situations. (More exceptions to this but it
is a good practice.)

From another message you mention the need to avoid
addition hardware: This is among the reasons you do
NOT want to run your external DNS as all -- move it
(back) to the registrar in most cases.

You cannot practically run the internal and external
versions of a Shadow (or Split) DNS on the same
server in any case.

Once you choose a DNS name for your AD you cannot
change it anyway (in Win2000 and difficult in Win2003)
so you must BRING that zone which supports AD inside
(whether it is the same as you use outside or not).

In Shadow DNS, there really are two zones -- one version
on the Internet, and another SEPARATE version of the zone
on the internal Net. Once you realize that their are really
TWO zones with the same name it makes easier to think
about.

General checks on DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

....or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /server:DC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]
 
Personally, I don't see the harm in having this information publicly
available -- In most cases an attacker will already be able to perform
DNS lookups within your network by the time they get far enough in to do
any damage.

It is not a direct security threat (giving away
passwords or keys or some such) but it is
very analogous to making your internal telephone
directory available to non-company persons.

It allows the outsider to map your network to some
extent and can easily provide the information needed
to perform a "social hack" (e.g., call up and sound
like the hacker is 'official' since he knows all the
right names etc.)

This problem is more pronounced in large companies
which is again analogous to the telephone directory
problem.
 
Thanks a million, Herb.

I probably fall into one of those 'special' cases. I am
running a small, specialty web hosting company w/ roughly a
dozen servers and ~500 websites/public domains. In fact,
almost everything EXCEPT my AD domain controllers is
publicly accessible. [Exception: backend SQL db servers.]

Hence, I'm weighing the importance of split-brain DNS
(requiring two servers dedicated to internal DNS/AD) vs.
publishing everything (combining AD controllers/DNS servers
and obfuscating our internal domain). This would squeeze
me into a half-rack and save me a thousand or more per
month. [Competition in the hosting sector is downright
bloody anymore.]

Does this change anything? Do you still recommend against
AD on a public DNS server?

Thank you VERY, VERY much!!! I greatly appreciate your
time and effort. It may well save me a LOT of trouble.

Dave
-----Original Message-----
Dave said:

To start: .local is not secure at all.

It is not going to provide your zone info to anyone
on the Internet since local is NOT a zone in the
Internet namespace.

Don't think of this as "security" -- it's not, except
in the sense that you are definitely not publishing
your INTERNAL resource names on the Internet,
but then you should not do that no matter what name
you pick.
I would like to run AD on my public DNS servers, 'hiding'
my private AD domain with a non-routable extension,

Extentions have NOTHING to do with "routable" --
local doesn't appear in the Internet namespace so is
not resolvable from the Internet root (there is no local
top level domain on the Internet.)
like the suggested '.local' (e.g., 'mycompany.local').

It is impractical (and a very poor) design for your to run
your internal (AD support) DNS on a public server.
QUESTION: If the '.local' extension is common knowledge or
becomes a standard, it follows that 'mycompany.local' is
easily guessable.

You are misunderstanding the purpose of the local and
the actual effect.

It is merely to avoid registering on the Internet and publishing
the name there, as well as guarantee that you will not class
with anyone else (since they cannot register it either.)
What will prevent eavesdroppers from
querying my public DNS servers for the private
'mycompany.local' AD names/addresses?

Not a all. The way you prevent this is by NOT allowing
your internal DNS server to offer resolution on the
Internet. It doesn't matter what name you use, don't offer
the internal zone on the Internet.
Should I instead
employ something unobvious, like 'mycompany.abcxyz'?

No, you just should try to approach the problem as above.

Most people shouldn't even be running ANY public DNS
server themselves but should leave their public DNS as
the registray.
Any advice is greatly appreciated.

DNS for AD SHOULD be inside the firewalls -- obviously
there may be exceptions for those people deploying and
AD publicly but this is VERY uncommon and represents a
serious security task (keeping the whole thing safe.)

DNS for AD should GENERALLY be on the DCs for most
small business situations. (More exceptions to this but it
is a good practice.)

From another message you mention the need to avoid
addition hardware: This is among the reasons you do
NOT want to run your external DNS as all -- move it
(back) to the registrar in most cases.

You cannot practically run the internal and external
versions of a Shadow (or Split) DNS on the same
server in any case.

Once you choose a DNS name for your AD you cannot
change it anyway (in Win2000 and difficult in Win2003)
so you must BRING that zone which supports AD inside
(whether it is the same as you use outside or not).

In Shadow DNS, there really are two zones -- one version
on the Internet, and another SEPARATE version of the zone
on the internal Net. Once you realize that their are really
TWO zones with the same name it makes easier to think
about.

General checks on DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

....or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /server:DC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]



.
 
Thank you, DevilsPGD, but doesn't running a sub-domain
(e.g., 'example.domain.com') require another pair of AD
controllers? I was under the impression that each
additional level requires a separate AD space w/ respective
controllers.

Thanks again.

Dave
 
Dave said:
Thank you, DevilsPGD, but doesn't running a sub-domain
(e.g., 'example.domain.com') require another pair of AD
controllers?

No, it does not require it, but it is the usual practice.

Note, that this is again solved by leaving (returning)
the PUBLIC DNS to the registrar where it generally
belongs.
I was under the impression that each
additional level requires a separate AD space w/ respective
controllers.

AD will require a different (sub) domain name for
each domain of course, and each domain requires
a corresponding DNS zone, but those zones COULD
be placed on the same (set of) DNS server(s.)

It is not the usual practice however.
 
Dave said:
Thanks a million, Herb.

I probably fall into one of those 'special' cases. I am
running a small, specialty web hosting company w/ roughly a
dozen servers and ~500 websites/public domains.

You may actually be correct. Managing so many zones
is likely best done with (your own) automated scripts,
so if you regularly use Perl or some other scripts or
automated editing method to change MULTIPLE zones
then you likely are better off on your own.

If you always use the GUI, then the answer is likely "no",
except for the tediousness of moving so many zones back
to the registrar. said:
In fact,
almost everything EXCEPT my AD domain controllers is
publicly accessible. [Exception: backend SQL db servers.]

And that should be kept sepepate in practically ALL cases.
Hence, I'm weighing the importance of split-brain DNS

"Split brain" is an unfortunate term for something that already
has two (man) names: Shadow DNS (or Split DNS.)

Your problem (more DNS servers) has NOTHING to do with
the split brain issue. Whether you use child, internal private,
or public-Shadow DNS name you need to separate the internal
from the external.
(requiring two servers dedicated to internal DNS/AD) vs.
publishing everything (combining AD controllers/DNS servers
and obfuscating our internal domain).

Is your DC on the Internet?

If not, you use the DC for the Internal DNS.

If so, you have other security problems that make the
name issue PALE in comparison.
This would squeeze
me into a half-rack and save me a thousand or more per
month. [Competition in the hosting sector is downright
bloody anymore.]

You can rent a server for a fraction of that price.

Does this change anything? Do you still recommend against
AD on a public DNS server?

Where is your AD DC? Put your internal DNS on that machine.

If you really must run it on a public machine you might
even consider Virtual Server (or a similar product.)
Thank you VERY, VERY much!!! I greatly appreciate your
time and effort. It may well save me a LOT of trouble.

You can call me if you wish -- phone is on
my web site: www.LearnQuick.Com


--
Herb Martin


Dave said:
Thanks a million, Herb.

I probably fall into one of those 'special' cases. I am
running a small, specialty web hosting company w/ roughly a
dozen servers and ~500 websites/public domains. In fact,
almost everything EXCEPT my AD domain controllers is
publicly accessible. [Exception: backend SQL db servers.]

Hence, I'm weighing the importance of split-brain DNS
(requiring two servers dedicated to internal DNS/AD) vs.
publishing everything (combining AD controllers/DNS servers
and obfuscating our internal domain). This would squeeze
me into a half-rack and save me a thousand or more per
month. [Competition in the hosting sector is downright
bloody anymore.]

Does this change anything? Do you still recommend against
AD on a public DNS server?

Thank you VERY, VERY much!!! I greatly appreciate your
time and effort. It may well save me a LOT of trouble.

Dave
-----Original Message-----
Dave said:

To start: .local is not secure at all.

It is not going to provide your zone info to anyone
on the Internet since local is NOT a zone in the
Internet namespace.

Don't think of this as "security" -- it's not, except
in the sense that you are definitely not publishing
your INTERNAL resource names on the Internet,
but then you should not do that no matter what name
you pick.
I would like to run AD on my public DNS servers, 'hiding'
my private AD domain with a non-routable extension,

Extentions have NOTHING to do with "routable" --
local doesn't appear in the Internet namespace so is
not resolvable from the Internet root (there is no local
top level domain on the Internet.)
like the suggested '.local' (e.g., 'mycompany.local').

It is impractical (and a very poor) design for your to run
your internal (AD support) DNS on a public server.
QUESTION: If the '.local' extension is common knowledge or
becomes a standard, it follows that 'mycompany.local' is
easily guessable.

You are misunderstanding the purpose of the local and
the actual effect.

It is merely to avoid registering on the Internet and publishing
the name there, as well as guarantee that you will not class
with anyone else (since they cannot register it either.)
What will prevent eavesdroppers from
querying my public DNS servers for the private
'mycompany.local' AD names/addresses?

Not a all. The way you prevent this is by NOT allowing
your internal DNS server to offer resolution on the
Internet. It doesn't matter what name you use, don't offer
the internal zone on the Internet.
Should I instead
employ something unobvious, like 'mycompany.abcxyz'?

No, you just should try to approach the problem as above.

Most people shouldn't even be running ANY public DNS
server themselves but should leave their public DNS as
the registray.
Any advice is greatly appreciated.

DNS for AD SHOULD be inside the firewalls -- obviously
there may be exceptions for those people deploying and
AD publicly but this is VERY uncommon and represents a
serious security task (keeping the whole thing safe.)

DNS for AD should GENERALLY be on the DCs for most
small business situations. (More exceptions to this but it
is a good practice.)

From another message you mention the need to avoid
addition hardware: This is among the reasons you do
NOT want to run your external DNS as all -- move it
(back) to the registrar in most cases.

You cannot practically run the internal and external
versions of a Shadow (or Split) DNS on the same
server in any case.

Once you choose a DNS name for your AD you cannot
change it anyway (in Win2000 and difficult in Win2003)
so you must BRING that zone which supports AD inside
(whether it is the same as you use outside or not).

In Shadow DNS, there really are two zones -- one version
on the Internet, and another SEPARATE version of the zone
on the internal Net. Once you realize that their are really
TWO zones with the same name it makes easier to think
about.

General checks on DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

....or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /server:DC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]



.
 
: Thank you, DevilsPGD, but doesn't running a sub-domain
: (e.g., 'example.domain.com') require another pair of AD
: controllers? I was under the impression that each
: additional level requires a separate AD space w/ respective
: controllers.

No. I'm running internal.domain.com. I wish I had done it differently as
domain.local because the simple name would then be domain, instead of
internal.

Ex.
domain\administrator vs internal\administrator

You don't need the redundancy but is recommended as a secure model because
if you have one and it's down, everyone has issues.

Ex.

If I have a single DC, running AD/DNS. All my users will point to this box
for DNS resolution. If it is down, there is no backup so they cannot get to
the Internet.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Online Support for IT Professionals -
http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
How-to: Windows 2000 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
FAQ W2K/2K3 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382
 
in message
: In message <[email protected]> "Dave"
:
: >Thank you, Roland, but this article only answers the
: >question by saying, "don't do it." Other authors, such as
: >the well-respected Mark Minasi, suggest that running AD on
: >a public DNS server is a viable solution.
: >
: >FYI, I am running split-brain DNS already, as recommended
: >by the article you present. But our network is so small
: >that we no longer want to dedicate separate servers to DNS,
: >AD, backup DNS and backup AD. It's just too much hardware
: >for our modest needs. If we MUST have public DNS servers,
: >then it seems logical to also put our AD there, if at all
: >possible.
:
: Personally, I don't see the harm in having this information publicly
: available -- In most cases an attacker will already be able to perform
: DNS lookups within your network by the time they get far enough in to do
: any damage.

So why make it available without having to break in to get it? A hacker
should not be allowed to perform a zone transfer nor should she be able to
engineer internal informaton externally.

Keeping external entries on external servers and internal entries in
internal servers does not expose anything. Hackers look for these to be run
together so yes, then they do have recon information that can be used
against you, not to mention social engineering attacks.

Over 90% of what a hacker does is recon. That alone is the difference
between a hacker and a script kiddie. 99% of what a script kiddie does is
attack. I get *nix attacks against IIS and Windows attacks against STD
Linux. They have no clue and don't care. A true hacker will never attack
until she knows your network, your defenses, etc. and she will never attack
directly.

: All that being said, my DNS is in private name space. I use a
: internal.example.com nomenclature where everything under internal is
: only resolvable internally, externally most of it points to NXDOMAIN,
: although a few hosts have valid external IPs (the VPN server being a big
: one -- Some people VPN internally too, so it makes everybody's life
: easier)

Any door you create into your private network is another door for a
potential hacker to exploit. Doors should be kept at a minimum. MSFT was
hacked twice through a VPN into the private network. How? The user on the
other end was not secure and while conned into downloading a soon to be
released version of a game, also downloaded a trojan which gave the hackers
the ability to traverse the internal network through the tunnel. All they
had to do was wait until he opened the door and then they just walked right
in.

: --
: I walked into a bar the other day and ordered a double.
: The bartender brought out a guy who looked just like me.

Cute. (O:= I like silly tags. One of my favorites is:
Two cannibals are eating a clown.
One turns to the other one and asks, "Does this taste funny to you?"

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Online Support for IT Professionals -
http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
How-to: Windows 2000 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
FAQ W2K/2K3 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382
 
In
Roland Hall said:
No. I'm running internal.domain.com. I wish I had done
it differently as domain.local because the simple name
would then be domain, instead of internal.

Ex.
domain\administrator vs internal\administrator

This one is your own fault, you could have just as easily used the NetBIOS
name of domain instead of internal. There doesn't have to be any
relationship between the DNS and NetBIOS domain name at all. You could have
just as easily named the NetBIOS name 'ROLAND'.
 
: In : Roland Hall <nobody@nowhere> commented
: Then Kevin replied below:
: > No. I'm running internal.domain.com. I wish I had done
: > it differently as domain.local because the simple name
: > would then be domain, instead of internal.
: >
: > Ex.
: > domain\administrator vs internal\administrator
:
: This one is your own fault, you could have just as easily used the NetBIOS
: name of domain instead of internal. There doesn't have to be any
: relationship between the DNS and NetBIOS domain name at all. You could
have
: just as easily named the NetBIOS name 'ROLAND'.
:

The NetBIOS [computer] name is FS1. I named the AD internal.domain.com
(domain.com obviously an alias of what it actually is) I have a public
domain to match it (domain.com). I wouldn't name my AD domain the name of
my server.

However, unless I'm willing to scratch what I have...

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Online Support for IT Professionals -
http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
How-to: Windows 2000 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
FAQ W2K/2K3 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382
 
In message <[email protected]> "Roland Hall"
: Personally, I don't see the harm in having this information publicly
: available -- In most cases an attacker will already be able to perform
: DNS lookups within your network by the time they get far enough in to do
: any damage.

So why make it available without having to break in to get it? A hacker
should not be allowed to perform a zone transfer nor should she be able to
engineer internal informaton externally.

I didn't say anything about zone transfers, just that there is little
(to no) harm in allowing DNS lookups.

In general, by the time someone is far enough along that they can make
use of the knowledge of internal IPs they can likely just do resolution
anyway.

It might not be best practice, but it's not generally harmful either.
: All that being said, my DNS is in private name space. I use a
: internal.example.com nomenclature where everything under internal is
: only resolvable internally, externally most of it points to NXDOMAIN,
: although a few hosts have valid external IPs (the VPN server being a big
: one -- Some people VPN internally too, so it makes everybody's life
: easier)

Any door you create into your private network is another door for a
potential hacker to exploit. Doors should be kept at a minimum. MSFT was
hacked twice through a VPN into the private network. How? The user on the
other end was not secure and while conned into downloading a soon to be
released version of a game, also downloaded a trojan which gave the hackers
the ability to traverse the internal network through the tunnel. All they
had to do was wait until he opened the door and then they just walked right
in.

Agreed. My VPN is relatively secure since there are a limited number of
users with access, and an even smaller number of them know their own VPN
credentials (so they can't just walk into an internet cafe and VPN from
there)

The VPN doesn't completely bypass the firewall either, it just gives you
access to some internal resources that are otherwise inaccessible. It
would be a good place to start and attack, but the attacker had better
get the password within three tries if they want to go anywhere other
then to a syslog somewhere.

While this doesn't protect against a compromised user, that's not a huge
concern here, I trust all of the VPN-enabled users to maintain their
PC's security.
: I walked into a bar the other day and ordered a double.
: The bartender brought out a guy who looked just like me.

Cute. (O:= I like silly tags. One of my favorites is:
Two cannibals are eating a clown.
One turns to the other one and asks, "Does this taste funny to you?"

I like...
 
Is your DC on the Internet?

It is behind the same firewall that our publicly-accessible
DNS servers are behind. All can be managed remotely from a
trusted IP. This isn't a problem, is it?
Where is your AD DC? Put your internal DNS on that machine.

That's how things are setup now. I have two AD
controllers, also running DNS services for internal name
resolution ('mycompany.net'). Then, there are two public
DNS servers (yes, we employ lots of scripts) which hold the
~500 public domains, including a public (read 'false')
rendition of the 'mycompany.net' zone.

So, at the risk of overstaying my welcome, WHERE AM I
CONFUSED?! It occurs to me that the only reason I am
running separate private and public DNS servers is to hide
the internal 'mycompany.net' zone employed by AD. [And why
does this require separate DNS servers? Simply because
Microsoft's DNS service will not permit me to restrict zone
transfers for a specific domain to only trusted IPs. Such
restrictions are possible, but global.] It then follows
that if this zone cannot be individually secured, then
perhaps it can be obfuscated. Then, I wouldn't need two
separate sets of DNS servers. Being that AD and DNS run
together nicely, I would deploy a new pair of AD
controllers (with the new 'mycompany.local' or
'mycompany.abcxyz' domain), and complete with now
publicly-accessible DNS. Our security measures would
restrict access to our AD/DNS servers to only the DNS
server service through port 53.

Where has my logic or assumptions gone wrong?

Again, thank you so very much for your help.

Dave
 
: In message <[email protected]> "Roland Hall"
:
: >: Personally, I don't see the harm in having this information publicly
: >: available -- In most cases an attacker will already be able to perform
: >: DNS lookups within your network by the time they get far enough in to
do
: >: any damage.
: >
: >So why make it available without having to break in to get it? A hacker
: >should not be allowed to perform a zone transfer nor should she be able
to
: >engineer internal informaton externally.
:
: I didn't say anything about zone transfers, just that there is little
: (to no) harm in allowing DNS lookups.

I threw that in to strengthen my argument but I disagree with your
statement. Unless you're a network security professional you may not
realize how all information gained can and will be used against you. BTW...
I have found numerous DNS zones completely open. I've even seen OWA fully
exposing a companies private information with a link on their main web page.
The identity theives would have peed their pants to get it.

: In general, by the time someone is far enough along that they can make
: use of the knowledge of internal IPs they can likely just do resolution
: anyway.
:
: It might not be best practice, but it's not generally harmful either.

If I know the name of your users logon or system or their name for that
matter, or even the name of the main DC, I can use that to social engineer
your users. I'm generally an optimist, except with it comes to network
security. I trust nobody, including myself.

Whether you can perceive it to be harmful or not is not the point. The
point is there is no reason to expose it.

Have you ever ordered pizza over the phone for delivery and paid by credit
card that you gave to them over the phone? Did you hear them repeat it, so
as to make sure it was correct? Didn't they also take your address and
phone number so they could verify you were who you said you were and so they
could deliver it? At the time... did you feel it not generally harmful?

: >: All that being said, my DNS is in private name space. I use a
: >: internal.example.com nomenclature where everything under internal is
: >: only resolvable internally, externally most of it points to NXDOMAIN,
: >: although a few hosts have valid external IPs (the VPN server being a
big
: >: one -- Some people VPN internally too, so it makes everybody's life
: >: easier)
: >
: >Any door you create into your private network is another door for a
: >potential hacker to exploit. Doors should be kept at a minimum. MSFT
was
: >hacked twice through a VPN into the private network. How? The user on
the
: >other end was not secure and while conned into downloading a soon to be
: >released version of a game, also downloaded a trojan which gave the
hackers
: >the ability to traverse the internal network through the tunnel. All
they
: >had to do was wait until he opened the door and then they just walked
right
: >in.
:
: Agreed. My VPN is relatively secure since there are a limited number of
: users with access, and an even smaller number of them know their own VPN
: credentials (so they can't just walk into an internet cafe and VPN from
: there)

And who setup their end? Nobody mentioned an internet cafe. I'm talking
about the system they're on at home. How secure is it? Do their kids use
their system? Do they download applications from the Internet? When did
they last update their antivirus software? Is it enabled at all times? How
much spyware do you think they have on their system? If the spyware can get
in, just how secure are they? How many ports do they expose to the
Internet? Do they even have a firewall? Do they use file sharing like
eDonkey or Kazaa? Are they running host-based IDS? When is the last time
they checked their log files, for the OS, the personal firewall, IDS, border
firewall? How many Windows updates have they downloaded that have yet to be
installed? I was on a system the other day. All patches were downloaded
and none were installed and these were on Windows 2000. He had almost 600
spyware instances. You couldn't hardly do anything with all the popups.
Removing one removed part of Winsock. Winsock registry entries had to be
removed and TCP/IP reinstalled before connectivity could be restored.
BTW... he was running antivirus and sitting behind a firewall.

: The VPN doesn't completely bypass the firewall either, it just gives you
: access to some internal resources that are otherwise inaccessible.

You have internal resources outside your firewall? How is that possible?
How can something internal be outside? What exactly is an incomplete
bypass?

: It
: would be a good place to start and attack, but the attacker had better
: get the password within three tries if they want to go anywhere other
: then to a syslog somewhere.

It doesn't work that way. If your user is compromised, they just wait for
the user to unlock the door. You are logging successful and unsucceful
attempts right? Do you run a packet sniffer to log all traffic?

: While this doesn't protect against a compromised user, that's not a huge
: concern here, I trust all of the VPN-enabled users to maintain their
: PC's security.

You're very understanding. So, how do you protect your network from your
users? You do realize they are more dangerous than others, don't you?

: >: I walked into a bar the other day and ordered a double.
: >: The bartender brought out a guy who looked just like me.
: >
: >Cute. (O:= I like silly tags. One of my favorites is:
: >Two cannibals are eating a clown.
: >One turns to the other one and asks, "Does this taste funny to you?"
:
: I like...
:
: --
: If you've had half as much fun reading this as I've had writing it,
: I've had twice as much fun as you.

It's nice to see you don't take disagreements with your philosophy personal.
I always like to hear the other side. To date, I have not been on a network
that was not lacking in security somewhere.
 
It is behind the same firewall that our publicly-accessible
DNS servers are behind. All can be managed remotely from a
trusted IP. This isn't a problem, is it?


That's how things are setup now. I have two AD
controllers, also running DNS services for internal name
resolution ('mycompany.net'). Then, there are two public
DNS servers (yes, we employ lots of scripts) which hold the
~500 public domains, including a public (read 'false')
rendition of the 'mycompany.net' zone.

This is your largest problem -- you cannot hold
two DIFFERENT versions of the same zone on
the same DNS server.

(I can make it work with BIND "views" , but you will
need an additional NICs or at least IP on each NIC for
the distinction.)

But with BIND you would lose your ability to have
Secure Only Updates which ARE an absolute requirement
for a public DNS server which allows updates (ughhh!)
So, at the risk of overstaying my welcome, WHERE AM I
CONFUSED?! It occurs to me that the only reason I am
running separate private and public DNS servers is to hide
the internal 'mycompany.net' zone employed by AD.

And to keep it secure. Remember that AD requires not just
a DNS zone but a DYNAMIC one.

If you don't put it on a DC it cannot be "secure only."

[And why
does this require separate DNS servers? Simply because
Microsoft's DNS service will not permit me to restrict zone
transfers for a specific domain to only trusted IPs.

It will allow you to so restrict ZONE TRANSFERS what it
(MS DNS) will not allow you to is to offer different VIEWS.
Such
restrictions are possible, but global.]

Zone transfers are on a per zone basis; they must be logically
since the secondaries of one zone may not be the secondaries
of another zone.
It then follows
that if this zone cannot be individually secured, then
perhaps it can be obfuscated. Then, I wouldn't need two
separate sets of DNS servers.

AD DNS needs to be INSIDE and protected (secured and
almost certainly unreachable.)

The fact that you have another business supplying DNS (or
web sites etc) should not be confused with your AD.
Being that AD and DNS run
together nicely, I would deploy a new pair of AD
controllers (with the new 'mycompany.local' or
'mycompany.abcxyz' domain), and complete with now
publicly-accessible DNS. Our security measures would
restrict access to our AD/DNS servers to only the DNS
server service through port 53.

And you could JUST make this work with "Secure Updates
Only" but it is not something that I would ever recommend.

OF course this means destroying your current domain and
recreating it -- or upgrading it to Win2003 (special mode)
to rename a doman.
Where has my logic or assumptions gone wrong?

It's a bad architecture to consider exposing the internal
AD zone publicly.
 
In
Roland Hall said:
"Kevin D. Goodknecht Sr. [MVP]" <[email protected]>
wrote in message
In

This one is your own fault, you could have just as
easily used the NetBIOS name of domain instead of
internal. There doesn't have to be any relationship
between the DNS and NetBIOS domain name at all. You
could have just as easily named the NetBIOS name
'ROLAND'.

The NetBIOS [computer] name is FS1. I named the AD
internal.domain.com (domain.com obviously an alias of
what it actually is) I have a public domain to match it
(domain.com). I wouldn't name my AD domain the name of
my server.

However, unless I'm willing to scratch what I have...

I was referring to this line:
The simple name is the NetBIOS name i.e. the name you see in Network places.
You still could have used "domain" insted of "internal" You were given the
choice during DCPROMO, you can elect to accept the default name, or you
could have used a different name.

Personnaly I like the name I chose, HOME for the NetBIOS name with the DNS
name of 'home.domain.com'
This work very well, as I have delegated the name home in the public DNS to
the internal DNS server and private IP for the internal name. This is for
VPN clients, so the DNS resolution is seemless when they connect. No hosts
files are needed in this setup.
 
Back
Top