RE: PIX -> ISA -> OWA Configuration

["Paul Melson" <psmelson () comcast net>]

Against my better judgment, into the fray once again...

Responses in line. 

> -----Original Message-----
> Subject: RE: [fw-wiz] PIX -> ISA -> OWA Configuration
>
> There is real foolishness in the VPN suggestion - offering all of layers
> 2 and 3 to remote clients for the sake of a single application. This is
weak science, and "architecture by anecdote".

That makes a lot of assumptions about what constitutes 'VPN' access.
Minimally, most 'VPN' deployments can provide a degree of access control
within the tunnel akin to that of a firewall, and could be used to restrict
access to a single server and port for, say OWA. (Note: the author has a
distinct disdain for all things 'VPN' as there is such a glut of product
crap out there co-opting the term that it is no longer safe to assume that
'VPN' is synonymous with IPSec tunneling.)  This isn't even close to giving
away the keys to the castle, but it definitely has some other drawbacks,
most notably support costs. 


> Taken as a proposed method for limiting attack surface, I think that it
needs serious re-examination!
> Give me a threat model for full network client access, vs. that of an
application inspection firewall, proxying SSL - such as ISA 2004.  Good!
> Notice anything? Now supply me with motivated attackers.  OWA/ISA is the
safest bet for remote access of Exchange systems, and this can be quantified
> > using models, not by asserting a bias, or making category
generalizations.

Which brings me to my point, which is that the stereotypical client VPN
connection (think SecureRemote or Cisco VPN Client) typically improves your
security posture in three ways.  First, encryption.  Everybody do the
I've-got-privacy-and-integrity-on-the-wire dance, yay!  Second,
authentication.  So many people get this part of their remote access
deployment wrong.  "What?!  You mean using a PSK isn't enough?  And I should
authenticate the site to the client, too?"  And third is attack surface
obfuscation, or whatever you want to call it.  It's like tinted windows for
your network - I can't see inside!

So what do you get with a remote access client solution that you don't get
with a reverse proxy and SSL?  If done right, nothing.  Now, to cut the next
argument to the quick - Yes, a full client solution gives you the ability to
monitor, protect, and enforce policies on client machines... that until you
bought a full client solution were not attaching to your network.  So I
suppose remote network access is job security, anyway - constantly making
more work for yourself. :-)


> The only people who should ever get full VPN access are systems and
network administrators, with a demonstrated need.  They should be subject to

> extensive logging, and a separate audit. There are application-oriented
solutions that meet the needs of other users, without a "default allow"
policy.  > I often despair, that we will spend the next 20 years
rolling-back the broad remote access that was granted over the last 10.

That and broad outbound access.  If I had a dollar for every time I saw the
equivalent of:

access-list acl_inside permit ip any any

...on a firewall or router, I could have retired by now.  


PaulM (who, today at least, is tired of big-magic-box syndrome)


_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards