Securing Exchange, IIS, and SQL Infrastructures Fred Baumhardt Infrastructure Solutions Consulting Microsoft Security Solutions, Feb 4th, 2003

Session Overview Microsoft Defence-in-depth Model Strategic Multi-Product Defence Implementing End to End Exchange Security Implementing End to End IIS Security SQL Security

Defense-in-Depth MANAGEMENT Perimeter Defences: Packet Filtering, Stateful Inspection of Packets, Intrusion Detection Network Defences: 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: Databases, Network Services and Applications, File Shares Data & Resources Application Defences Host Defences Network Defences Perimeter Defences Assume Prior Layers Fail MANAGEMENT

Strategic Defence Know what’s in your Datacenter Segment your Networks Most attacks, worms, can be defeated by network protection – to buy time for patches Internal IDS to clean up client VLANs IPSec Policies to contain breakouts Plan your management -incident response Application Inspection internal firewalls

Strategic Defence Cont. Reduce Attack Surface Disable unnecessary software and services Use MBSA – IISLockdown etc Use a third party vulnerability scanner Configure AD group policy and use role based security templates Restricted Groups Restricted Services Restricted Registry and File ACLs

The Total Trust Network Modern networks are generally one large TCP/IP space segmented by firewalls to the Internet Trust is implicit in all organisation TCP/IP was not designed for security THIS HAS TO STOP – Network Segmentation is now critical

Secure Your Networking Internet Redundant Routers First Tier Firewalls URL Filtering for OWA RPC Termination for Outlook ISA Firewalls NIC teams/2 switches VLAN Intrusion Detection Intrusion Detection Intrusion Detection VLAN Front-end VLAN DC + Infrastructure VLAN Backend Switches Implement VLANs and Control Inter-VLAN Traffic like Firewalls do .

An Alternate DMZ Approach A Flat DMZ Design to push intelligent inspection outwards ISA layer 7 switching (OWA) or RPC filtration (Outlook) No Firewalls between front-end and backend servers Front-end and backend servers authenticate clients IPSec if required between front-end and backend TCP 443: HTTPS Or TCP 443: HTTPS Internet TCP 80: HTTP Stateful Packet Filtering Firewall Application Filtering Firewall (ISA Server) Exchange Server

Exchange Specific Issues Exchange Client Selection crucial Exchange Supporting Infrastructure Security Top 10 Action Points to secure Exchange

Selecting an Exchange Client Experience Complexity Security POP3/IMAP4 via SSL with SMTP Basic Medium/ High Medium OWA via SSL with ISA Moderate Low Full VPN – L2TPw/IPSEC PPTPv2 High Secure RPC with ISA Medium/ Low

Security from Internet Clients Every time you connect into a network you extend the security perimeter VPN and to a lesser extent RPC Publishing both require care at the client Harden your clients on the Internet or hackers will attack clients and ride the VPN Require RPC encryption for Outlook Client Based IDS systems

Internal Security Don’t assume Internet is the only threat Assume internal people want to attack you – more than external people Defensive Tactics include: Client Network Segmentation Encryption of Client Traffic – e.g. require RPC Review of public folder/client permissions Third party – AV – IDS – Auditing Server Role – Security templates from Ops guide Extend the security scope to all infrastructure Exchange relies on: AD – DNS – SMTP Relay etc

Top 10 Ways to Get Exchange Secure Implement the Security Operations Guides for Windows and Exchange http://msdn.microsoft.com/practices Use MBSA to identify missing patches Implement IISLockdown based on role Secure Infrastructure Assets Use the EDSLock script to restrict groups .

Top 10 Ways To Get Exchange Secure Get adequate antivirus protection for servers and desktops Use perimeter SMTP scanning Automate Patch Management Use SSL, IPsec, and MAPI encryption where appropriate Plan your response to an intrusion/worm before it happens

IIS Security Basics Turn it off where not required Use IISLockdown tool – be aware of its impact on applications Use a layer 7 proxy like ISA Server Use W2K Security Operations templates and guides to lock down IIS by OU – and role

Legacy Firewalls and Data Attacks Internal Network Normal Firewall – Checks Rules - OK Internal Web Server Internal Exchange Server Virus Author Internet Internet Virus or attack inside data passes Overflow Attacker Reverse Proxy Used to accelerate the performance of your web site. Instead of your Web server responding to every requests of Internet clients, the ISA Server will respond with cached content if available. How ISA Reverse Cache works: Joe clicks on the a url for www.ms.com/ISA in his web browser The Internet via DNS servers will interpret the URL name and forward the request to the Servers that respond to “www.ms.com” The ISA Server is impersonating the Web Server and responds to requests for web content for www.ms.com. Since the ISA Server does not have the content cached locally, it will forward the request to the Web Server and then return the content to the user. This content is now cached locally so that the next request for the same content will be served from the ISA Server, rather than the Web Server. Normal Firewalls only check rules like source , destination and port – NOT DATA ITSELF Data passes through firewall unchecked and hits internal IIS box essentially intact – attacks pass through

Countering Application Level Attacks Internal Network Internal Web Server Internal Exchange Server ISA Checks Data inside traffic Virus Author Internet Internet Virus or attack inside data is blocked – alert is raised ISA Filters Overflow Attacker Reverse Proxy Used to accelerate the performance of your web site. Instead of your Web server responding to every requests of Internet clients, the ISA Server will respond with cached content if available. How ISA Reverse Cache works: Joe clicks on the a url for www.ms.com/ISA in his web browser The Internet via DNS servers will interpret the URL name and forward the request to the Servers that respond to “www.ms.com” The ISA Server is impersonating the Web Server and responds to requests for web content for www.ms.com. Since the ISA Server does not have the content cached locally, it will forward the request to the Web Server and then return the content to the user. This content is now cached locally so that the next request for the same content will be served from the ISA Server, rather than the Web Server. Security devices evolve to inspect data Application Filters that know what to look for: Web – Stop Overflows – check syntax of commands Intrusion Detection – scans for patterns of attack Force Internal Traffic to be Inspected by Internal Firewalls

ISA Server and IIS URLScan – syntax and http level checking of acceptable verbs – URLs, and characters Layer 7 URL blocking – EG mail.corp.com/exchange OK – mail.corp.com/£$%^^^£$” - Dropped HTTPS Termination – inspection and re-encryption – inspect the un-inspectable Defeats all known URL based overflows – itself is not susceptible as it has no IIS SMTP Scanner for IIS SMTP mail

SQL Server Security Understand the application Don’t let all machines talk to SQL – SEGMENT YOUR LAN Usually application servers talk to DB – not clients directly Know where MSDE is installed – include in your management plan Replace MSDE with managed SQL servers where possible

SQL and Slammer Bug should have never been there !!! Patches should be made easier and faster to deploy However……. Infrastructure defences could have prevented slammer: VLAN off SQL – nothing to infect Internal Firewalls – block ports to slammer External Firewalls – DMZ machines sending without being asked – should only reply App inspecting filters – FW blocks traffic IDS – recognises and sends RST – alerts admin

Understand Issues and Mitigate SQL in mixed mode has no lockout Can be brute forced so use Windows auth. SQL runs as local admin by default SA will have equivalent to machine admin Thus don’t run it on DC SQL and MSDE listen on known ports So change them where you can SA can go across multiple databases Plan your security model carefully Multiple instances give true account isolation

SQL Powered Applications Look at application end-to-end From client to app server to db Encrypt all network transports Avoid dependence only on client side validation – have SQL check the data as well/instead Client authentication – how does it get data to and from SQL Injection – always pass data to stored procedures – never queries