F5 Users Group February 23 rd 2011

1. F5 Users Group February 23rd 2011 Agenda Intro & welcome to the Phoenix F5 User’s Group What’s new at F5 LTM Security DDoS Demo and Best Practices ASM User Discussion Sony Dash drawings

2. You have a IPv6 Gateway

3. F5 Software Support Lifecycle Policy

4. Evolving Security and Access in the ADC BIG-IP v10.2.1 January 2011 BIG-IP v10.1 Dec 2009 BIG-IP v10.2 April 2010 • BIG-IP Access Policy Manager support in LTM VE and 1600 Support • Scale/simplified deployment for HVD • Vmware View • Citrix XenApp • Enable Exchange 2010 migration • Oracle Access Manager enhancements • Expanded Client Solutions • BIG-IP Access Policy Manager (3600, 3900, 6900, 8900) • BIG-IP Edge Gateway (1600, 3600, 3900, 6900, 8900) • Web access management • Secure and accelerated remote access • BIG-IP Local Traffic Manager Virtual Edition • BIG-IP Access Policy Manager for the 11050 • Integration with Oracle OAM • ICSA SSL VPN Certification • DTLS for UDP apps (ex. VoIP, video, PCoIP)

5. Exchange Migration – Barriers • Problems: • Migration requires outage window • Multiple URLs – 2007/2010 – user confusion • Barriers overshadow benefits = Delayed migration • Traditional proxies don’t scale

6. Scalable TCP Connections with ASM No Hard Limits (10.2.1) Applications 60K Connections (10.x) BIG-IP® LTM + ASM or PSM 15K Connections (9.x)

7. ihealth.f5.com

8. Popular Attacks • Pro-WikiLeaks attacks • Simple DDoS brought down Visa and MasterCard • Used a java based tool Low Orbit Ion Cannon that received instructions from a Twitter account via Twitter API • Oversized headers and more sophisticated attacks at layer 7 are becoming more common • Attacks from Eastern Europe and Asia-Pacific are still the most common sources

9. LTM - Securing the Enterprise Native security capabilities of LTM

10. BIG-IP Security • Packet filtering(Access Control Lists) • Provide granular control of ingress and egress for Mac addresses, IP networks, and Ports. • Similar to a network firewall, though without the same level of forensics logging. • Default Deny • The BIG-IP LTM is a hardened network device that does not allow any traffic through it that has not been specifically allowed. • There is a long laundry list of attacks such as Teardrop, Ping of Death, etc that never make it further than the BIG-IP simply by it’s default deny nature.

11. BIG-IP Security • SYN Flood, DDoS and DoS Attack Prevention • SYN Cookies* - The first method employed is SYN cookies to prevent these attacks. • Dynamic Reaping • BIG-IP is continually monitoring existing TCP connections to ensure the integrity of it’s connection table. • Dynamic reaping will remove the oldest idle connections if it needs to clear up more memory. • This protects the BIG-IP against configuration error or SYN attacks from non spoofed IP addresses that fully negotiate a connection. *http://cr.yp.to/syncookies.html provides an elaborate explanation of SYN cookies.

12. BIG-IP Security • TCP full proxy • The full proxy architecture is not merely an optimization feature, but has a very unique security impact. • The full proxy allows BIG-IP to ensure clean and sanitized packets are delivered to the server. • Malformed, out of order, or incorrectly flagged TCP extensions are blocked by BIG-IP. BIG-IP provides Protocol Sanitization and a Full TCP Termination point which independently manages client and server side connections, protecting all backend systems and applications from malicious attacks.

13. BIG-IP Security • Rate Shaping • By setting policies based on IP subnet, address, port, application, virtual server, content or user, the BIG-IP can guarantee quality of service for a site • Rate shape based on Geolocation using an iRule • when CLIENT_ACCEPTED { • switch [whereis [IP::client_addr] country] { • US { rateclassrateshape_na } • CA { rateclassrateshape_na } • MX { rateclassrateshape_na } • default { rateclassrateshape_isdn } • } • } Rate shaping can be applied against a packet filter (L3), a virtual server (L4), or an iRule (L7).

14. BIG-IP Security • iRules(and Profiles) • One of F5’s key differentiators in the security realm. • iRulesprovide inspection of all content, inbound and outbound, for any application. • Content scrubbing • SSN, credit cards, custom • Selective encryption • Server cookies, password fields, custom • Directory level or file type restrictions • Resource cloaking • Hide your IIS server’s version info

15. BIG-IP Security Request Throttling Once an HTTP session has been established, a client can request a page thousands of times, tying up servers and creating a denial of service scenario. With request throttling, the BIG-IP can limit the number of times per session, per user, or per second that a page request can be made. For HTTP, BIG-IP can track users per IP, cookie, jsession ID, or other unique data. It can also apply the same logic to proprietary TCP applications. when HTTP_REQUEST { set cur_time [clock seconds] if { [HTTP::request_num] > 3 } { if { $cur_time == $start_time } { if { $reqs_sec > 3 } { HTTP::respond 503 Retry-After 2 } incr reqs_sec return } } set start_time $cur_time set reqs_sec 0 } This simple iRule will allow the client to make up to 3 requests every 3 seconds. If they exceed that, then we force the browser to delay 2 seconds before trying again.

16. BIG-IP Security • SSL Offload • By terminating the SSL connection at the BIG-IP, we now have full visibility into the application stream • Allows iRulesuse • Allows compression • Allows a number of other advanced features • Consolidated Certficate and Key management • Support for FIPS hardware based key security • Enforce minimum encryption level (128bit), redirect others • Selectively insert SSL client cert info into HTTP header

17. TCP Handshake C S SYNC Listening… Spawn thread, store data (connection state, etc.) SYNS, ACKC Wait ACKS Connected

18. SYN Flooding Attack SYN Queue SYNC1 Listening… Spawn a new thread, store connection data SYNC2 SYNC3 … and more SYNC4 … and more … and more SYNC5 … and more … and more

19. SYN flood • A SYN flood leaves half-open connections • The “SYN queue” is a data structure which keeps track of these half-open connections • We track the source IP and port of client, server IP and port, seq# of client, seq# of server • Idea: Is all of this data in the SYN Queue necessary? • Store enough to recognize the ACK of the client • Can we get away without storing anything locally?

20. SYN Cookies: The Idea • Store nothing locally • ISN: Initial sequence number • Encode all we need to remember in the ISN we send back to the client • t: a 32-bit counter which increments every 64 seconds • K: a secret key selected by server for uptime of server • Limitations: MSS limited to 8 values • TCP window scale and timestamp options are stripped off in the SYN-ACK response when SYN cookie is enabled Server ISN t mod 32 MSS hash(client IP and port || server IP and port || t || K) 5 3 24

21. SYN Cookies [Bernstein and Schenk] C S SYNC Listening… Does not store state Compatible with standard TCP; simply a “weird” sequence number scheme SYNS, ACKC sequence # = cookie F(source addr, source port, destaddr, dest port, coarse time, server secret) F=Rijndael or crypto hash ACKS(cookie) Recompute cookie, compare with with the one received, only establish connection if they match More info: http://cr.yp.to/syncookies.html

22. SYN Cookies: Details • MSS: Maximum Segment Size • Suggested by client, server then computes best value • Details depend on whether they are on the same network, MTU on network, etc • Server can have only 8 values to encode here • What happens when client replies with ACK? • Client will reply with ISN+1 of server in the ACK • Server then subtracts 1 and checks against hash of client IP and port, server IP and port, t which matches in the lowest 5 bits, and K • If match, put in SYN queue • If not, ignore

23. ASM User Discussion • Keith Tyler – Manager of Information Security • CWIE Holding Company, Cavecreek hosting and Ecommerce companies • All sites with credit card data for PCI compliance • Over 50 virtual servers being protected • Syslog alerts to Splunk • sql injection alerts are emailed • Manually build policies - staging for 7 days and leave in transparent mode

24. COMMENTS OR QUESTIONS? • Are others working on similar projects? • Next User Group meeting in May • Topic is iRules and iControl