Re: .local and .com

From: Scott Davis (sdavis_at_esctech.ca)
Date: 01/02/05 

Date: Sun, 02 Jan 2005 03:43:02 -0500
To: Dana Brash <dbrash@gmail.com>

Douglas, Dana,

Some of what Dana's written I agree with 150-ba-zillion-percent.

Some, however, of Dana'a comments, I think are entirely incorrect.

Dana Brash wrote:
> Hi Douglas,
>
> I would NOT recommend using the .local namespace, but to use create a
> sub-namespace of your publicly registered namespace. e.g.
> office.company.com. This is particularly helpful for mobile users so
> they're not switching back and forth between exchange.company.local and
> mail.company.com depending on their location.

The alternative is to config the client's outlook with
"mail.company.com" and provide this name/zone/DNS that when queried
points to the internal address or external address as required.

I suspect Dana has some issues with web services and hasn't wrapped
his/her head around internal/external name resolution entirely.

In common practice, "company.local" will do some mirroring of
"company.com". (i.e. mail. or owa. or wm. ) Really, company.local
should be further obfuscated because MS's products are kinda leaky..
(i.e. Exchange's SMTP banner).

I say you SHOULD use a .local domain name, but it shouldn't be the same
as your public "presence" name..

> Split DNS ~ For running internal network in same namespace as internet
> presence
>
> http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.
>
> Note that "This is not a recommended configuration" but does come in handy
> when you're already built up this way..

Okay, again, I disagree with Dana. Not about the use of split named
DNS, but because of the implicit advocation of ISA as a valid security tool.

I find the idea of using Vendor one's product to protect Vendor one's
product just plain old stupid. It's non-redundant, while it claims to
be so. It's akin to purchasing a backup car in case my "first" car
breaks. It's absurd. My car should work.

I'm sorry -- that's a very rude comment, but I feel strongly about this.

Defense in depth should be achieved by using Vendor two's product to
protect vendor one's product. This is basic security knowledge that's
been advocated for more than a decade.

I say "Stay the heck away from ISA, entirely."

Buy a PIX. Buy a NetScreen/Juniper. Buy a sonicwall. Blow $60 on a
Linksys.

Understand the difference between stateful packet filtering and
application layer exploits/prevention. (and hold vendor one accountable
for problems with their products..)

> Active Directory, ADSI and Directory Services Technical Articles
> Microsoft Windows 2000 Namespace Design ~ A more thorough Discussion
> http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnaractdir/html/Namespace_Design.asp
>
>
> Regarding your question about allowing external users to send you email and
> view your website, you'll have public DNS records that will point to your
> public IP. So your ISP will host DNS for www.company.com and an MX record
> for mail.company.com. Both these records will point at the public side
> (STATIC!) IP on your firewall, and your firewall/router will manage
> directing http/s (80/443)and smtp(25) traffic to the correct internal server
> for service by using port mapping.

The above is factually correct and I agree with.

>
> Steve makes very solid security recommendations, and I'd like to add one
> more: hosting web services and mail on your Domain Controller is like
> painting a target on your forehead. DC's shouldn't be exposed to that sort
> of traffic for any reason.

Here, I disagree with Dana.

The "DCs" in isolation idealogy that Microsoft (and I think Dana)
espouse is absurd. This is a mentality that MS utilizes to sell more
ISA licenses. Nothing more.

No kidding, I've thrown out $200/hr MCS (Microsoft Consulting Services)
  dweebs for being so ignorant that they buy into this "isolationist"
mentality.

Really, if I bang up OWA and let that machine refer the authority
queries back to my DC that's behind some stateful inspection device, how
is this magically more secure than letting people query that DC directly?

No, really.

The list of ports/services that have to be made available to the box
hosting the OWA is absurd. There's no isolation. There's no
significant security gained by the use of ISA.

It's just more cost and administration -- and managerial bliss,
regardless of the lack of real security provided.

Did ISA server prevent SQL-Slammer?

No, really, ISA was a product when the SQL-Slam blew up lots of boxes,
right?

Did it do *ANYTHING* of note?

Can anyone out there claim that ISA saved their network from ANYTHING?

Enough with the zero-result, poorly architected products.. like, ISA.

> If you are really limited in hardware, DC's
> generally don't need to be too powerful, get a high-end desktop class box
> and build it up instead.

Nope, this is silly talk. A high-end desktop is going to cost you what,
about 1000-US Dollars? You can purchase a machine with redundant
components (disk, power, fans) for like what, $2500..?

Dana's totally off the mark on this one. NEVER run a DC on a desktop.
You're shooting yourself in the foot if you do. I don't care how many
DCs s/he is considering. Even with multiple DCs, managing the FSMO
roles are going to have to be dealt with -- and if you're so broke that
you can't buy good hardware, I'll bet dollars to doughnuts that you've
got no clue how to deal with that..

If you're so broke that you can't purchase real hardware, you shouldn't
expose yourself to the risk of running the product(s). Pack up your
toys and go home. Really. Quit that job. You've not been authorized
to handle your responsibilities.

Also, in my experience, if you're so broke that you've got to run your
most critical services on a desktop PC -- chances are you're new to this
"network/OS" admin game. (Watch out -- learn how to restore your data
before you have to learn it the hard way..!) (you do backup your data,
right?)

> You're exposing your entire Active Directory to
> the internet otherwise.

Hunh? TCP 80/443/25 exposes AD to the entire planet?

I think you mean -- the application services commonly delivered on those
ports *COULD* expose some of your security details to unauthorized
people or processes -- assuming that the Directory or application(s)
have security flaws.

Please be a little more accurate, Dana. The language you've used is
entirely inaccurate, in my opinion.

Not only does your language "fear monger" -- but it implies that
Microsoft is not / should not be accountable for selling insecure
software to us.

> Not only will hackers and viruses have a field day,
> you're users should have to wait for web requests before they can
> authenticate and access resources internally.

This last, final statement is incoherant -- in my opinion. I have no
clue what it's supposed to mean.

If you mean exposing a "secure" authentication service (such as AD) to
the 'internet' .. is going to lead to breaking of that authentication
service.. I'd suggest we all get a new service.

Further, your assertion that hiding the security service behind a
magical nat-and-application-layer filtering tool (ISA server) based on
technology from the same vendor boggles my mind. What is ISA going to
do -- prevent this month's buffer overflow exploits? If ISA can do it
-- the product(s) should do it all on their own.

I'm not trying to attack you personally, Dana -- but I am trying to very
strongly stress how much I disagree with you on a couple points -- and
overall, the operational practices you're advocating.. because I think
your advice, if utilized, could result in people being fired from their
  jobs.

I say:

1) No protecting resources with the same vendors' tools.
2) No deploying required/critical services (such as AD) on cheap
desktop hardware.

====================================================
Scott Davis, 45 Dunfield Av, Unit 2117
Self-Employed Toronto, ON, Canada, M4S 2H4
Tech Consultant Mobile. (416) 432-4334

The IP addrs I use to post all UseNet:
66.207.215.240/29
====================================================

Relevant Pages

  • RE: Front End/Back End communication
    ... MVP -- ISA Firewalls ... There is no such thing as security perfection. ... single front-end/back-end Exchange Server will find this setup to be ...
    (Focus-Microsoft)
  • RES: ISA firewall
    ... If we want to judge ISA as a firewall product (or if you want to judge ... Linux) were compromised by a security hole that was identified days ago, ... flaws, so does every single bit of line of code out there. ...
    (Security-Basics)
  • Re: Forest/Domain in the "DMZ" to accomodate web, front-end servers
    ... Now as for ISA 2004 being a seamless application layer inpspection security ... out of it too, but I have 500 servers, and 3000 desktops to worry about. ...
    (microsoft.public.security)
  • RE: [fw-wiz] Microsoft ISA
    ... Believe it or not ISA is one of the first software packages from ... Depending on your security ... Server off the DMZ interface). ... other Microsoft Documentation. ...
    (Firewall-Wizards)
  • RE: Administrivia: Are you seeing portscans from source 127.0.0.1 source port 80?
    ... I've also seen a collection of reports from ISA customers (big surprise, ... Security Business Unit ... source port 80? ... most highly-anticipated industry event of the year. ...
    (Incidents)