Guerilla Security

  • Published on
    26-May-2015

  • View
    389

  • Download
    0

Embed Size (px)

Transcript

  • 1. SEC 318 Guerilla Security Securing Exchange 2000 and 2003 Infrastructures Fred Baumhardt and Rab Thynne Senior and Partner Strategy Consultant Microsoft UK

2. Why do we call this Guerilla

  • Guerilla as a type of warfare is exactly what we face in Internet Security
  • Expect attacks from anywhere, with any device, at any time, from the inside
  • Defences must be built exactly the same way, good monitoring, competent security forces, and ruthless execution of security policy on attackers

3. Session Overview

  • Core Security Concepts applied to Exchange
  • The Exchange Server Security Model
  • Implementing End to End Exchange Security
    • Implications of Client Selection
    • Securing Client/Server to Server Communications
    • Network Layer Security
    • Exchange Host Server Security
  • Questions

. 4. The Big Picture

  • Exchange is an Infrastructure product ergo: it is only as secure as the infrastructure
  • So design of Supporting Infra is critical :
    • DMZ design
    • DCs and their configuration
    • DNS infrastructure
    • Server Build
    • Management and Operations

5. Internet Security Roots and Mail

  • Lets be honest from a security perspective: IPv4 Sucks not designed for Security
    • Internet used to require Sec clearance to use physical access was restricted no need for protocol security
    • Resistance to Nuclear attack was more important than protecting traffic as people on the network were trusted
  • TCP/IP was thus designed without security in mind added as a bolt-on- SMTP has almost none
  • SMTP takes anonymous un-authenticated messages from the dirty world and puts them into heart of your network
  • No one thought mail storage would be mission critical

. 6. Core Security Concepts applied to Exchange

  • The OS is only one component of security ANDFirewalls are not a Panacea
  • Getting into the bank branch doesnt mean you get into the vault
  • In the real world security relies on multiple things. It should also do this in the IT world
    • People and Process
    • Internal and Edge Technologies
    • Management and Operations
  • Securing your Exchange system is securing your core systems there is no silver bullet wizard

. 7. Your Attack Sources for Comms

  • Answer:Everyone inside and out
  • The majority of attacks originate internally
    • Corporate espionage
    • People with Inside knowledge
    • Your Users playing with stuff they dont understand
  • Externallycould be anyone
    • Script kiddies armed with widely accessible tools
    • More serious attackers fun or profit

8. Exchange Comms Architecture . 9. Internal DMZ Firewall Ports

  • TCP 80 for HTTP143 for IMAP110 for POP 25 for SMTP
  • 691 for Link State Algorithm routing protocol
  • TCP/UDP port 389 for LDAP to Directory Service
  • TCP port 3268 for LDAP to Global Catalog Server
  • TCP/UDP port 88 for Kerberos authentication
  • TCP/UDP port 53 - DNS
  • TCP port 135 - RPC endpoint mapper
  • TCP ports 1024+ - RPC service ports(unless DC and Exchange Restricted)
  • If you use IPSec between the front-end and back-end, open the appropriate ports. If the policy you configure only uses AH, you do not need to allow ESP, and vice versa.
  • UDP port 500
  • RPC over HTTP can reduce this 600-2 and 593

. 10. Exchange Defence-in-Depth Orchestration

  • Perimeter Defences:Packet Filtering, Stateful Inspection of Packets, Intrusion Detection
  • NetworkDefences :VLAN Access Control Lists, Internal Firewall, Auditing, Intrusion Detection
  • Host Defences:Server Hardening, Host Intrusion Detection, IPSec Filtering, Auditing
  • Application Defences:AV, Content Scanning, Layer 7 (URL) Switching Source, Secure IIS, Secure Exchange
  • Data and Resources:ACLs on PFs, Correct mail permissions, Data, Relay Permissions

. Data & Resources Application Defences Host Defences Network Defences Perimeter Defences Assume Prior Layers Fail 11. Connection Strategies Full in None Out Medium/Low Full RPC over HTTP Medium High Low Medium/ High Complexity Full Full Secure RPC with ISA Full Full VPN PPTPv2 Full Moderate OWA via SSL with ISA Medium Basic POP3/IMAP4 via SSL with SMTP Security Experience Method 12. POP3/IMAP4 with SMTP

  • Uses SSL to secure POP or IMAP connection
  • Does not authenticate at front end
  • Requires SMTP at front-end to send mail OR separate SMTP relay (watch for relay spam)
  • Removes much of the rich functionality
  • Public Folder access can be tricky
  • Dont enable unless you absolutely have to

. 13. OWA via SSL with ISA

  • OWA is lightweight and available anywhere
  • Not totally functional but close
  • No Offline facility but great usability
  • SSL is an easy and proven security tool
    • Can be terminated at ISA with Feature Pack
    • Only used to Front-end server not FE-BE in 2000 2003 can use Kerberos for delegation
    • Pre-authentication with ISA is very strong

. 14. Protecting HTTPS for OWA Web server prompts for authentication any Internet user can access this prompt SSL tunnels through traditional firewalls because it is encrypted which allows viruses and worms to pass through undetected and infect internal servers! Basic authentication delegation ISA Server pre-authenticates users, eliminating multiple dialog boxes and only allowing valid traffic through URLScan for ISA Server ISA Server can decrypt and inspect SSL traffic inspected traffic can be sent to the internal server re-encrypted or in the clear. URLScan for ISA Server URLScan for ISA Server can stop Web attacks at the network edge, even over encrypted SSL . Traditional firewall OWAclient SSL ISA Server with Feature Pack 1 SSL or HTTP SSL Internet 15. VPN Inbound

  • Dedicated HW/SW VPN infrastructure
  • Requires opening of ports for VPN and authentication
  • Provides Full and Rich Network Access
  • Can be costly for enterprises to implement
  • RPC over HTTP can reduce need also secure RPC publishing with ALF

. 16. Using ISA for RPC Publishing

  • ISA Can Securely Publish RPC
    • Opens 135 and listens (can block by source)
    • Only Allows Specific UUID for Outlook (configurable)
    • Dynamically Port Filters subsequent connections
    • Can require Encrypted RPC only
  • Outlook can have full functionality without VPN

. 17. RPC Outlook to Exchange RPC 101 RPC server (Exchange) RPC client (Outlook) RPC services grab random high ports when they start, server maintains table Client connects to portmapper on server (port 135/tcp) Client knows UUID of service it wants {12341234-1111} Client accesses application over learned port Client asks, What port is associated with my UUID? Server matches UUID tothe current port 4402/tcp Portmapper responds with the port and closes the connection

  • Due to the random nature of RPC, this is not feasible over the Internet
    • All 64,512 high ports & port 135 must be opened on traditional firewalls

. Port UUID Service 9233 {19283746-7777 MMC 3544 {01020304-4444 AD replication 4402 {12341234-1111 Exchange 135/tcp 4402/tcp 18. Securing the Front Side

    • Exchange 2000 SP2+ doesnt require RPC for DSAccess from Front-end to Backend; However.
    • RPC is still required for IIS authentication (OWA), POP-IMAP
    • Exchange DMZ Tradeoff: is it better to
      • Allow RPC packets from the DMZ inward, or
      • IPSec Tunnel through Firewall (Bypass it), (no NAT Firewalls)
      • Allow anonymous requests from the FE to the BE?

Swiss Cheesed or Bypassed Firewall TCP 443: HTTPS Stateful Packet Filtering Firewall Front End Server Internet TCP 443: HTTPS (OWA) RPC: Outlook SMTP, POP3, IMAP4 Back End Server RPC and/or Defined Port HTTP (TCP80) . 19. Best Practice for the Front Side

    • A Flat DMZ Design
    • ISA layer 7 switching (OWA) or RPC filtration (Outlook)