1. SEC 470 Using ISA Server for Application Layer Firewalling Frederico Baumhardt Senior Consultant – Infrastructure and Security Microsoft UK

2. Call to Action A quantum shift in thinking is needed to avoid a cataclysmic failure in global network security I don’t have all the answers in this session, lots of questions We have all been lucky major global worms have not carried class 0 (evil evil) payloads like format disk and flash BIOS Question all “experts” you hear and draw your own conclusion

3. Agenda The roots of the Internet and security The problem with conventional firewalls Advantage of application layer inspection Application inspection with ISA server Pre-authentication (OWA + IIS + Apache) Inbound SSL termination and inspection Filtration of HTTP content and URLs Other Application Filters Putting it all together

4. Internet Security Roots Lets be honest – from a security perspective: IPv4 is not great – not designed for Security The Internet used to require Security clearance to use – physical access was restricted – no need for protocol security Resistance to Nuclear attack was more important than protecting traffic Everyone on the network was trusted TCP/IP was thus designed without security in mind – added as a bolt-on

5. Typical Protocol Security Evolution Protocol suite created – TCP/IP We invent some sort of security (IPSEC) We run out of addresses so we NAT instead of CIDR (NAT apparently is better security ) NAT breaks IPSEC So we argue over standard to encapsulate NAT traffic in UDP (fix IPSEC) – NAT-T emerges We then say IPSEC could be insecure as traffic cant be inspected – whitepapers confirm both views as accurate and definitive

6. Tunneling When someone puts some sort of data in one port/socket– encapsulates it in some sort of packet – and sends it do a destination you allow (because you think it is doing something else) Example – HTTP-TUNNEL.com where you stick your terminal service traffic (otherwise blocked)- in TCP 80 and for 19.95 a month, they send it to the server you really want to talk to.

7. Demonstration of Tunneling

8. Some Common Network Security Myths People play by the rules (we trust our users) Internal Users are always nice – outside bad People will always use ports as a statement of intent (TCP 80== HTTP – right ??? ) I shouldn’t allow encrypted traffic through my firewall (as it cant inspect it) Tunneling through one port is far more secure than opening several others

9. But Its OK – I got a Firewall… False – fake – and irrelevant sense of security to people who don’t understand security (big boss says FW=Sec job done) ALF is not big enough to most customers Most firewalls don’t protect internally – conventional wisdom is you don’t have to End to End Security – and encryption invalidates most FW and IDS

10. But an expert told me…. Not to bother with firewalls or segmentation – they don’t work VLANs aren't useful as they cant guarantee total segmentation Performance cant keep up IPV6 is coming, and it will be harder to firewall that wont it ? Listen to what we all have to say. Draw your own conclusions

11. Firewalls are only one small part

12. Lets Rip open a packet Currently – most firewalls check only basic packet information Real world equivalent of looking at the number and destination of a bus – and not looking at the passengers

13. Fundamental Assumptions L3/L4 We trust that traffic on a port is what we think it should be (TCP80==HTTP) We implicitly trust that the traffic going through is clean (as we admit we cant scan it) We don’t place these devices to protect from internal networks as our users are trusted The user in machine 1.2.3.4 must be the one that always uses that machine TCP 80 is almost always open to everywhere – The Universal Firewall Bypass and Avoidance Protocol Most of these mistakes result in a security breach which is usually blamed on the OS, or the app – but came over network

14. Security and HTTP We assume that HTTP is good business protocol–block almost all others outbound SO: Developers start using tunnelling over port 80- to deliver apps and data- call it web services Microsoft does it with Outlook and Exchange 2003 – we call it a feature (easy Outlook Conn) Joe Smith tunnels and uploads your HR database to your competition – you call him a hacker More concerned at blocking porn (by dest) than checking that the content is valid (by deep insp)

15. OK Guys, how would you do it ? Some keys to application inspection Segmentation of Logical Components in network – ALF can only inspect to/from somewhere Encryption only where required – with trusted context – it usually invalidates inspection, IDS Understanding the purpose of the traffic you are trying to filter, and blocking non consistent traffic Strategic depth-countermeasures covering entire classes of attacks, especially against worms Heuristical systems supplemented with behavioural systems, and intelligence

16. RPC server (Exchange) RPC client (Outlook) ServiceUUIDPort Exchange{12341234-1111…4402 AD replication{01020304-4444…3544 MMC{19283746-7777…9233 RPC services grab random high ports when they start, server maintains table RPC – A typical ALF challenge RPC 101135/tcp 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 to the current port… 4402/tcp Portmapper responds with the port and closes the connection 4402/tcp 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

17. RPC Filter Security Learn the protocol and use its features to improve security Firewall only allows specific UUIDs Only DC Replication, or Only Exchange/Outlook Not defined UUIDs such as MMC, Printing blocked Takes back control of RPC behaviour Tunneling not allowed – as syntax is checked Exchange specific – like enforce client encryption ISA Server with Feature Pack 1 Exchange / RPC Server Outlook/ RPC Client RPCRPC Internal network External network

18. Protecting HTTPS Traditional firewall Web Srv/ OWA clientclient Web server prompts for authentication — any Internet user can access this prompt SSLSSL SSL tunnels through traditional firewalls because it is encrypted… …which allows viruses and worms to pass through undetected… …and infect internal servers! ISA Server with Feature Pack 1 Basic authentication delegation ISA Server pre-authenticates users, eliminating multiple dialog boxes and only allowing valid traffic through URLScan for ISA Server SSL or HTTP SSLSSL 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 Internet

19. Pre-Authentication No L7 password = no access to internal system – excellent failsafe Potential attackers go from 7 Billion to the number of people who have credentials to your network Worms will not have your credentials (hopefully ) ISA 2000 can also do this by RSA secure ID for HTTP (though not for RPC/HTTP with sec ID) Cookie means also under development by market

20. Protecting HTTP and (S) cont. The Big Picture Understanding the protocol – how it works, what its rules are, and what to expect is critical Inbound HTTPS termination is easy (you control the cert) outbound is difficult Human behaviour is easy – FW admins close all ports so we use 80, thus we need to learn now to filter 80

21. Web Publishing Protection (DNS) Worms usually go by IP or network range, they seldom know the FQDN (yet) Publish by FQDN https://mail.yc.com/exchangehttps://mail.yc.com/exchange Nothing gets in unless it asks firewall for the exact URL (in HTTP language) not just 212.30.12.1@TCP80 212.30.12.1@TCP80 Nimda, CodeRed etc, would not have infected my ISA server systems that published FQDNs Use URLScan in ISA to filter more sophisticated Next Generation HTTP filtration is on the way, use it when it arrives

22. Web Publishing FQDN filtration Run the Nimda Attack Vector against this – does it work? Viruses don’t do reverse lookups (yet), they also don’t usually ask for an explicit path Only something asking for exchange.lkm.ch/exchange will be connected Powerful and simple

23. DNS Protection Rudimentary protection General anti- tunneling protection through T/U 53

24. Mail Protection Lots of Antispam and antivirus vendors cover the relay points- what about: IS TCP 25 really SMTP? Is someone sending a buffer overflow to the RCPT: command ? Can I block someone using the VRFY command ? Can I strip an attachment, or block a user Why not do the Protocol level protection at the network device, use the firewall to add a layer of defence for the mail system.

25. Mail Filtration Examples Requires another box to do the storage of mail Must link the box to ISA via RPC Applies Protocol validation and some keyword and attachment stripping Def in Dep – not primary mail solution

26. Encapsulated Traffic IPSEC (AH and ESP), PPTP etc can not be scanned at ISA server if published or allowed through If you tunnel traffic through these ports ISA will log the tunnel – can not look inside Your call – open more ports with app filters or tunnel traffic through with no inspection – most DC protocols have no filters Be aware of the implications of NAT

27. Extending The Platform Firewalls are placed in different locations for different reasons. Understand the requirement and filter accordingly Extend core functionality with protocol filters covering your specific scenario No one device will ever be the silver bullet, solutions are more important than devices

28. One Vision for Secure Networking Internet Redundant Routers ISA Firewalls VLAN DC + Infrastructure NIC teams/2 switches VLAN Front-end VLAN Backend Intrusion Detection First Tier Firewalls URL Filtering for OWA RPC Termination for Outlook One or more Switches Implement VLANs and Control Inter-VLAN Traffic like Firewalls do – VLANs are not bullet proof (but neither are servers) Traffic is allowed or blocked based on requirements of the application, filters understand and enforce these requirements.

29. Debunking Network Security Myths People DON’T play by the rules – unless you make them and ports are not intent – you need to check Hardware devices are NOT more secure – they are more convenient – that’s all Invest in getting to know the device, what it can/t do – don’t buy what you know – buy what you need Don’t let just the network people control and purchase firewalls – it takes application awareness We will increasingly need the performance of software devices to handle the traffic coming

30. evaluations

31. © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.