[isapros] Re: ISA, Exchange 2007 and Perimeter Networks

  • From: "Greg Mulholland" <gmulholland@xxxxxxxxxxxx>
  • To: <isapros@xxxxxxxxxxxxx>
  • Date: Thu, 11 Jan 2007 15:02:03 +1100

Re: [isapros] Re: ISA, Exchange 2007 and Perimeter NetworksTrue that it did, 
but it is still the one instance of such.. in future there will be more and im 
not sure i will be prepared to not take other measures to prevent its infection 
on my network. but ill use it as a first method.

greg
  ----- Original Message ----- 
  From: Jim Harrison 
  To: isapros@xxxxxxxxxxxxx 
  Sent: Thursday, January 11, 2007 2:14 PM
  Subject: [isapros] Re: ISA, Exchange 2007 and Perimeter Networks


  "- me thinks not!" - I'll agree with that.

  ISA RPC publishing protected every swingin' Exch server that was published 
thusly from that nasty beasty known as Blaster.

  Literally No Other "firewall" can truthfully make that claim.



  From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jason Jones
  Sent: Wednesday, January 10, 2007 4:56 PM
  To: isapros@xxxxxxxxxxxxx
  Subject: [isapros] Re: ISA, Exchange 2007 and Perimeter Networks



  "It's as safe in the domain as in the DMZ if it's being protected by a 
properly configured ISA box..."



  Hmmm...so what if your FE *does* gets compromised? ISA is impressive, but it 
can't always protect against published server application vulnerabilites.



  As an example - does ISA protect FE servers against RPC attacks when 
publishing RPC over HTTP using web publishing then?? - me thinks not!

  When ISA is protecting RPC over HTTP all filtering is in the HTTP domain, so 
ISA has no way of knowing if the RPC data being tunnelled is valid or not. Once 
the packets reach the FE they are then decapsulated by the RPC proxy, and could 
in theory, be malicious. This is why using secure Exchange RPC publishing is 
the best security solution, but most people just publish RPC/HTTP and hence 
only really inspect HTTP data. 



  Don't forget, we are talking about Internet connections to Exchange services 
on a FE/CAS - even with ISA in place, there will still be ways to attack the 
FE. Yes they are greatly limited, but still there.  

  Jason Jones | Silversands Limited | Desk: +44 (0)1202 360489 | Mobile: +44 
(0)7971 500312 | Fax: +44 (0)1202 360900 | Email: jason.jones@xxxxxxxxxxxxxxxxx






------------------------------------------------------------------------------

  From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Steve Moffat
  Sent: 11 January 2007 00:36
  To: isapros@xxxxxxxxxxxxx
  Subject: [isapros] Re: ISA, Exchange 2007 and Perimeter Networks

  Oooohh..we're talking Exchange here..not SQL..



  It's as safe in the domain as in the DMZ if it's being protected by a 
properly configured ISA box...



  J



  From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Thor (Hammer of God)
  Sent: Wednesday, January 10, 2007 8:26 PM
  To: isapros@xxxxxxxxxxxxx
  Subject: [isapros] Re: ISA, Exchange 2007 and Perimeter Networks



  Because it's safer that way, that's why... That's what an authenticated 
access DMZ perimeter is for- with a CAS server that presents logon services to 
any Internet user, I would (and, in fact, require) that the server be in a 
least-privileged authenticated access perimeter network that limits that 
servers communications to the minimum required for required functionality - and 
only to the hosts it needs to talk to.

  Let's say there is a front-end implementation issue or coding vulnerability: 
the CAS on the internal network would allow unfettered, full-stack access to 
the internal network.  A CAS in a perimeter DMZ would mitigate potential 
exposure in the event of a 0day or configuration issue. 

  "Safer on the internal network" is a complete misnomer when it comes to 
servers presenting services to an untrusted network. 

  t


  On 1/10/07 3:04 PM, "Jim Harrison" <Jim@xxxxxxxxxxxx> spoketh to all:

  Why would you want to place a member of your internal domain in your DMZ, fer 
chrissakes?!?
  Hosting any domain member in the DMZ is a difficult proposition; especially 
where NAT is the order of the day.
  You can either use a network shotgun at your firewall or attempt to use your 
facvorite VPN tunnel across the firewall to the domain.

  Jim


------------------------------------------------------------------------------

  From: isapros-bounce@xxxxxxxxxxxxx on behalf of Jason Jones
  Sent: Wed 1/10/2007 2:35 PM
  To: isapros@xxxxxxxxxxxxx
  Subject: [isapros] Re: ISA, Exchange 2007 and Perimeter Networks

  From what I can gather, the new CAS role now uses RPC to communicate with the 
back-end (not sure of new name!) servers so I am guessing that this is an "RPC 
isn't safe across firewalls" type stance. Which I guess for a PIX, is a pretty 
true statement.

  Just think how much safer the world will be when firewalls can understand 
dynamic protocols like RPC...maybe one day firewalls will even be able to 
understand and filter based upon RPC interface...maybe one day... :-D ;-)

  Shame the Exchange team can't see how much ISA changes the traditional 
approach to DMZ thinking...kinda makes you think that both teams work for a 
different company :-(
  Jason Jones | Silversands Limited | Desk: +44 (0)1202 360489 | Mobile: +44 
(0)7971 500312 | Fax: +44 (0)1202 360900 | Email: jason.jones@xxxxxxxxxxxxxxxxx 
<mailto:jason.jones@xxxxxxxxxxxxxxxxx> 

   


------------------------------------------------------------------------------

  From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Greg Mulholland
  Sent: 10 January 2007 22:07
  To: isapros@xxxxxxxxxxxxx
  Subject: [isapros] Re: ISA, Exchange 2007 and Perimeter Networks

  I seriously hope that they have take different paths and these are not 
limitations on the software or it is going to mean a nice little redesign and 
break from custom..

  Greg

  ----- Original Message ----- 
  From: Jason Jones <mailto:Jason.Jones@xxxxxxxxxxxxxxxxx>  
  To: isapros@xxxxxxxxxxxxx 
  Sent: Thursday, January 11, 2007 8:25 AM
  Subject: [isapros] ISA, Exchange 2007 and Perimeter Networks


  Hi All, 

  I heard today from an Exchange MVP colleague that members of the Exchange 
team (Scott Schnoll) are saying that they (Microsoft) do not support placing 
the new Exchange 2007 Client Access Server (like the old Exch2k3 FE role) role 
into a perimeter network. Has anyone else heard the same? This sounds very 
similar to Exchange admins of old when they didn't really understand modern 
application firewalls like ISA could do - RPC filter anyone??? 
http://groups.google.co.uk/group/microsoft.public.exchange.design/browse_thread/thread/4ecab9cb8e50015e/4db165c21599cf9b?lnk=st&q=cas+dmz+isa&rnum=2&hl=en#4db165c21599cf9b
 
<http://groups.google.co.uk/group/microsoft.public.exchange.design/browse_thread/thread/4ecab9cb8e50015e/4db165c21599cf9b?lnk=st&amp;q=cas+dmz+isa&amp;rnum=2&amp;hl=en#4db165c21599cf9b>
 

  I have just about managed to convince Exchange colleagues (and customers) of 
the value of placing Exchange FE servers in a separate security zone from BE 
servers, DC's etc and now I here this.

  Are the Exchange team confusing the old traditional DMZ's with what ISA can 
achieve with perimeter networks? 

  From what I believe, it is good perimeter security practice to place servers 
which are Internet accessible into different security zones than servers that 
are purely internal. Therefore, the idea of placing Exchange 2003 FE servers in 
an ISA auth access perimeter network with Exchange 2003 BE servers on the 
internal network has always seemed like a good approach. It also follows a good 
least privilege model. 

  Is this another example of the Exchange and ISA teams following different 
paths???? 

  Please tell me that I am wrong and that I am not going to have to start 
putting all Exchange roles, irrespective of security risk, on the same network 
again!!!!

  Comments? 

  Cheers 

  JJ 

  All mail to and from this domain is GFI-scanned. 





  All mail to and from this domain is GFI-scanned.

Other related posts: