[isalist] Re: New Articles on Tales
- From: "Thor (Hammer of God)" <thor@xxxxxxxxxxxxxxx>
- To: ISA Mailing List <isalist@xxxxxxxxxxxxx>
- Date: Mon, 17 Aug 2009 12:36:34 -0300
In-line, but quickly...
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On
Behalf Of Jerry Young
Sent: Monday, August 17, 2009 7:12 AM
To: ISA Mailing List
Subject: [isalist] Re: New Articles on Tales
Damn, guys... think maybe you should have gotten a room? :)
And here I thought all of yas were BFFs. :D
Thor, I never took offense at what Jim was driving at (maybe I'm thick
skinned??). I certainly didn't take it as "people who think installing Edge
(or anything) as a WG instead of a DM are a 'tinfoil hat crowd'". I
interpreted it (perhaps added to it??) as "people who think you must always,
absolutely, are completely ignorant and stupid for not installing as a WG
instead of a DM are a 'tinfoil hat crowd'".
[Thor]
Which was an out-of-the-blue response to a statement never made. No one ever
said anything about always, never, must or anything. I had given up on this,
as I've been through this type of conversation with Jim before. One thing is
said, then other ideas bolted to it, and by the end of it, you finally get
enough "meat" around it to where we both say, "Oh, that's what I said to begin
with." I apparently do the same thing. My reply was based on:
Q: So this is a bit of a contradiction to me. I would love to see guidance from
Microsoft on that.
A: There is no "always" or "never" to either of them. It's situational
and requires that the deployment team perform their own threat modeling.
Exchange supports placing the edge role on a WG server to appease the "no
domain members at the edge" tinfoil hat crowd
Simple as that...
The simple fact of the matter is that very few small/medium businesses are
mature when it comes to security. I don't have any supporting numbers but my
guess would be that most run in an Internet, Edge, Lan topology, if that.
[Thor] That's fine. Then run it as a DM-it gives you more security options in
that topology than not. It all depends on what your goals are. One thing
though... ISA/TMG will never get to be the "enterprise" product we want it to
be if people continue to lump it in with SoHo solutions. Particularly if the
PM calls true security professionals a "tinfoil hat crowd" right off the bat
without offering any insight, or more importantly, any details or specifics to
back up his point.
My current client is a financial company that manages around $11 billion in
capital resources. If I went to the CIO and said that they must build out a
fully fledged, edge completely separated, traffic tightly controlled edge
network topology and took serious issue with them for not doing so, I wouldn't
keep them as a client for long. The best I can possibly do is simply warn them
of their risks (which I have) and work with them as they mature to make it more
secure.
I got clobbered for being hardnosed about making an App Pool identity for a web
application accessible from the Internet an Administrator of the local server,
which was a domain member! And I mean clobbered! The client's need for
usability outweighed their perceived need for security in that instance and I
was told to, not so kindly, go pound sand.
[Thor] Then you've done your job. But examples of other people not choosing
to deploy a security mechanism doesn't obviate the technical merits of the
process.
While your reasoning for how making a box a DM reduces security provides some
solid examples, "security-adverse" users might respond as follows:
[Thor] If they are security-adverse, then the response are a waste of time.
Move on. That being said...
-Required authentication and management traffic into/out of the internal
network.
How is this a risk? How is it quantifiable? Can a successful attack be
demonstrated? Would an attacker find the effort worth the end results? How
else might this be mitigated, aside from simply making the machine a WG member?
[Thor] First and foremost, you "allow" authentication traffic to exit your
network. This is the basis for authentication protocol attacks. I've been
demonstrating it for years. I think the last "public" demo I did at Defcon was
about 10 years ago, and it wasn't all that new back then (mine was different
because I actually used an alternate port). Letting auth protocol traffic in
and out like that is crazy. Hell, before that it was as easy as getting
someone to click on \\servername<file:///\\servername> to have them happily and
automatically send you their username and password hash. Would a hacker find
the effort worth the result?? You really have to ask that? Obviously, it
depends on what they are after. Mitigation depends on the topology. If it is
indeed the Internet->TMG->LAN model, then that's fine. The issue arises when
you have a 'real' DMZ(s) or assets across the boundary you wish to seamless
connect to in order to manage. The most secure way is to use an alternate set
of credentials. If your admins can't handle that, get admins that can.
-Cached domain credentials on the server itself -- even if not cached, the
machine's account allows for leverage of exploitation on internal assets even
if a vulnerability requires authentication. Measures can be taken to reduce
these risks, but they MUST be taken if a DM, not so if a WG.
What would it take to exploit this and can a successful attack be demonstrated?
How are local cached credentials any more secure than domain cached
credentials? If hacked, the box still provides a platform for futher attacks,
even if a potential key to the domain isn't there. What would be the complete
set of steps to use to mitigate this risk, aside from making the machine a WG
member?
[Thor] Primarily, the issue exists when you have an asset in the DMZ that
contains credential information that can leveraged on the internal network.
Now, if your admins are stupid enough to put it in a WG but use the same
username and passwords and the internal network, then they've lost the edge
(pun intended). It's not the fact that the credentials themselves are cached,
it's that you've got credentials that are retrievable on the DMZ box that can
then immediately be used to leverage attacks internally. Since we are most
commonly talking about administrative credentials being used to manage a box in
the dmz, you now have admin to the internal network. The "platform for
attacks" point is obvious. That's why you don't immediately offer creds that
can used internally. And it's "when" not "if." Use the same logic that you
did when you arrived at "if it get's hacked" and keep going with that. And
I'll pretend like you really didn't ask for "a complete list of steps to
mitigate the risk."
-Domain credentials/tokens will very likely be in memory and can be leveraged
by an attacker, particularly if someone is logged on to the console of the box,
or if services are running under domain credentials.
Again, how is this quantifiable? Can a successful attack be demonstrated?
Yes, attacks can and have been demonstrated. See above.
-any user anywhere in the forest, or trusted entities, will be an
"authenticated user."
Can't this default behavior be changed with regards to what an authenticated
user has access to? Wouldn't it make more sense to understand the rights users
need based on roles and assign accessibilty accordingly rather than dumping the
box in its own WG?
[Thor] Sure it can. The point is that you will HAVE TO DO IT. Separate users
for DMZ/Edge (*real* edge, not non-dmz type deployments) obviates that in the
first place.
Regardless of the side I take on the usability versus security argument,
however, I am always told to prove by demonstration my stance. That's the
frustrating part! And that's why people like me look to Microsoft (or any
vendor) who provides software for specific guidance.
[Thor] Tell me about it. Like, the "list one reason to have dmz assets as
domains member the increases security." Still hasn't been answered - not a
single security benefit has been listed that's not linked to piling other
products on top of a role or hidden behind the "DMs are easier to manager, and
thus must be more secure, because even though they really are not easier to
manage, I'll say they are, and it they aren't I won't patch them". My
favorite so far is "well, you should put TMG on it anyway, and since TMG works
better in as a DM, then you then have to the make it a DM.
So, while I found the exchange here entertaining, it really didn't help me out
too much; I saw reflected my own struggles with exploring and explaining the
usability/security relationship. I do like the idea of fleshing out some of
the scenarios you and Jim traded, however, as samples of when to use which
approach; what I think might be helpful to the community at large is to put
together a list of risks and methods of mitigation. Then you simply let the
clients choose which best fits their needs and budget.
[Thor] Well, I'm sorry it didn't help. It was entertaining in the beginning,
but it really did drive home how easily people can get distracted from the main
point, even if by their own sleight of hand. Maybe that means we should spend
far more time on conversations like this where the details can be addressed in
more details. I personally feel this is because the entire issue was clouded
in a concatenation of non-sequiturs, but oh well. I'll try it from a
different angle with "what you have to do" and "what you can do to mitigate".
When you make DMZ assets DMs, you have to open authentication traffic to and
from the DMZ to the LAN. You can mitigate this by only allowing host-based
access rules (to/from specific machine) but you've now got a path to the
internal domain controllers from the DMZ, from machines that are trusted by the
domain, and that have domain credentials on them, and probably admins.
Typically, (let's say a web server for example) since you now have seamless
auth to the DMZ resources, people now just want to "send" data and files to the
DMZ. Shares are created. Oh, let's use FTP. Can't we just point them to our
internal WSUS servers? The list actually goes on and on. What starts off with
"good intentions" ends up a festering cesspool of filthy security issues. All
for single logon. And, more importantly, all for something that does not buy
you security. Honestly, it seems crazy to go through so much to effectively
implement something that doesn't do anything for you. If the point is that
"people are naturally stupid," then making it more difficult to secure creates
even more risk.
Just my $.02, which isn't worth much, I know. ;)
Hey, my .02 and your .02 both add up to just under a nickel. ;)
t
On Mon, Aug 17, 2009 at 8:40 AM, Amy Babinchak
<amy@xxxxxxxxxxxxxxxxxxxxxxxxxx<mailto:amy@xxxxxxxxxxxxxxxxxxxxxxxxxx>> wrote:
http://www.ISAserver.org<http://www.isaserver.org/>
-------------------------------------------------------
Doesn't matter really. The point is that Microsoft has a released firewall
product called TMG with the EE installed on the domain member server. It's the
same enough.
thanks,
Amy Babinchak
Harbor Computer Services | 248-850-8616 | Mobile 248-890-1794
Phone Number: 248-850-8616
Web
http://www.harborcomputerservices.net<http://www.harborcomputerservices.net/>
Client Blog
http://smalltechnotes.blogspot.com<http://smalltechnotes.blogspot.com/>
Tech Blog
http://securesmb.harborcomputerservices.net<http://securesmb.harborcomputerservices.net/>
Buy My House: http://
www.HomesByOwner.com/15490<http://www.homesbyowner.com/15490>
Are you an IT Pro? http://www.thirdtier.net<http://www.thirdtier.net/>
-----Original Message-----
From: isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>
[mailto:isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>] On
Behalf Of Steve Moffat
Sent: Monday, August 17, 2009 8:38 AM
To: ISA Mailing List
Subject: [isalist] Re: New Articles on Tales
http://www.ISAserver.org<http://www.isaserver.org/>
-------------------------------------------------------
Not the same TMG....
-----Original Message-----
From: isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>
[mailto:isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>] On
Behalf Of Amy Babinchak
Sent: Monday, August 17, 2009 9:35 AM
To: ISA Mailing List
Subject: [isalist] Re: New Articles on Tales
http://www.ISAserver.org<http://www.isaserver.org/>
-------------------------------------------------------
Microsoft has a released product where the TMG (with EBS) also running the
Exchange 2007 Edge role is a domain member.
thanks,
Amy Babinchak
Harbor Computer Services | 248-850-8616 | Mobile 248-890-1794
Phone Number: 248-850-8616
Web
http://www.harborcomputerservices.net<http://www.harborcomputerservices.net/>
Client Blog
http://smalltechnotes.blogspot.com<http://smalltechnotes.blogspot.com/>
Tech Blog
http://securesmb.harborcomputerservices.net<http://securesmb.harborcomputerservices.net/>
Buy My House: http://
www.HomesByOwner.com/15490<http://www.homesbyowner.com/15490>
Are you an IT Pro? http://www.thirdtier.net<http://www.thirdtier.net/>
-----Original Message-----
From: isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>
[mailto:isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>] On
Behalf Of Han Valk
Sent: Monday, August 17, 2009 1:37 AM
To: isalist@xxxxxxxxxxxxx<mailto:isalist@xxxxxxxxxxxxx>
Subject: [isalist] Re: New Articles on Tales
http://www.ISAserver.org<http://www.isaserver.org/>
-------------------------------------------------------
Ok I understand, that still leaves the point that some 'official' guidance from
Microsoft would be nice.
Han.
________________________________
From: isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>
[isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>] On Behalf
Of Jim Harrison [Jim@xxxxxxxxxxxx<mailto:Jim@xxxxxxxxxxxx>]
Sent: Sunday, August 16, 2009 4:32 PM
To: isalist@xxxxxxxxxxxxx<mailto:isalist@xxxxxxxxxxxxx>
Subject: [isalist] Re: New Articles on Tales
http://www.ISAserver.org<http://www.isaserver.org/><http://www.isaserver.org/>
-------------------------------------------------------
There is no "always" or "never" to either of them. It's situational and
requires that the deployment team perform their own threat modeling.
Exchange supports placing the edge role on a WG server to appease the "no
domain members at the edge" tinfoil hat crowd, but when you combine it with
TMG, the attack surface and thus the perceived threat of having the Exch edge
role as a domain member is greatly reduced; even over that offered by Windows
Firewall policies.
Jim
-----Original Message-----
From: isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>
[mailto:isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>] On
Behalf Of Han Valk
Sent: Saturday, August 15, 2009 11:54 PM
To: isalist@xxxxxxxxxxxxx<mailto:isalist@xxxxxxxxxxxxx>
Subject: [isalist] Re: New Articles on Tales
http://www.ISAserver.org<http://www.isaserver.org/><http://www.isaserver.org/>
-------------------------------------------------------
As far as I know Exchange Edge is to be installed on a workgroup server while
TMG does its best job when domain joined. So this is a bit of a contradiction
to me. I would love to see guidance from Microsoft on that. Maybe this can be
added to the Q&A in Understanding Email Protection on TMG.
Han.
> -----Original Message-----
> From: isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>
> [mailto:isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>]
> On Behalf Of Jim Harrison
> Sent: Sunday, August 16, 2009 00:35
> To: isalist@xxxxxxxxxxxxx<mailto:isalist@xxxxxxxxxxxxx>
> Subject: [isalist] New Articles on Tales
>
> http://blogs.technet.com/isablog/archive/2009/08/15/new-tales-from-the
> -
> edge-articles.aspx
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com<http://www.techgenix.com/><http://www.techgenix.com/>
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx<mailto:listadmin@xxxxxxxxxxxxx>
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com<http://www.techgenix.com/><http://www.techgenix.com/>
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx<mailto:listadmin@xxxxxxxxxxxxx>
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com<http://www.techgenix.com/>
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx<mailto:listadmin@xxxxxxxxxxxxx>
--
ExchangeDefender Message Security: Click below to verify authenticity
http://www.exchangedefender.com/verify.asp?id=n7HCZOeB031684&from=amy@xxxxxxxxxxxxxxxxxxxxxxxxxx
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com<http://www.techgenix.com/>
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx<mailto:listadmin@xxxxxxxxxxxxx>
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com<http://www.techgenix.com/>
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx<mailto:listadmin@xxxxxxxxxxxxx>
--
ExchangeDefender Message Security: Click below to verify authenticity
http://www.exchangedefender.com/verify.asp?id=n7HChniQ000721&from=amy@xxxxxxxxxxxxxxxxxxxxxxxxxx
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com<http://www.techgenix.com/>
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx<mailto:listadmin@xxxxxxxxxxxxx>
--
Cordially yours,
Jerry G. Young II
Microsoft Certified Systems Engineer
Other related posts:
