1 F5 Users Group February 23 rd 2011 Agenda Intro & welcome to the Phoenix F5 User’s Group...

25
1 F5 Users Group February 23 rd 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

Transcript of 1 F5 Users Group February 23 rd 2011 Agenda Intro & welcome to the Phoenix F5 User’s Group...

1

F5 Users Group February 23rd 2011Agenda

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.1Dec 2009

BIG-IP v10.2April 2010

BIG-IP v10.2.1January 2011

• 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)

• 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

9

Exchange Migration – Barriers

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

12

Scalable TCP Connections with ASM

Applications

15K Connections (9.x)60K Connections (10.x)No Hard Limits (10.2.1)

BIG-IP® LTM + ASM or PSM

15

ihealth.f5.com

16

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

17

LTM - Securing the Enterprise

Native security capabilities of LTM

18

7 APPLICATION

6 PRESENTATION

5 SESSION

4 TRANSPORT

3 NETWORK

2 DATA LINK

1 PHYSICAL

• 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.

BIG-IP Security

19

BIG-IP Security

7 APPLICATION

6 PRESENTATION

5 SESSION

4 TRANSPORT

3 NETWORK

2 DATA LINK

1 PHYSICAL

• 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.

20

BIG-IP Security

7 APPLICATION

6 PRESENTATION

5 SESSION

4 TRANSPORT

3 NETWORK

2 DATA LINK

1 PHYSICAL

• 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.

21

BIG-IP Security

7 APPLICATION

6 PRESENTATION

5 SESSION

4 TRANSPORT

3 NETWORK

2 DATA LINK

1 PHYSICAL

• 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 { rateclass rateshape_na }

CA { rateclass rateshape_na }

MX { rateclass rateshape_na }

default { rateclass rateshape_isdn }

}

}

Rate shaping can be applied against a packet filter (L3), a virtual server (L4), or an iRule (L7).

22

BIG-IP Security

7 APPLICATION

6 PRESENTATION

5 SESSION

4 TRANSPORT

3 NETWORK

2 DATA LINK

1 PHYSICAL

• iRules (and Profiles) • One of F5’s key differentiators in the security realm.• iRules provide 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

23

BIG-IP Security

7 APPLICATION

6 PRESENTATION

5 SESSION

4 TRANSPORT

3 NETWORK

2 DATA LINK

1 PHYSICAL

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.

24

BIG-IP Security

7 APPLICATION

6 PRESENTATION

5 SESSION

4 TRANSPORT

3 NETWORK

2 DATA LINK

1 PHYSICAL

• SSL Offload• By terminating the SSL connection at the BIG-IP, we

now have full visibility into the application stream• Allows iRules use• 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

25

TCP Handshake

C S

SYNC

SYNS, ACKC

ACKS

Listening…

Spawn thread,store data(connection state, etc.)

Wait

Connected

26

SYN Flooding Attack

SYN Queue

SYNC1 Listening…

Spawn a new thread,store connection dataSYNC2

SYNC3

SYNC4

SYNC5

… and more

… and more

… and more

… and more

… and more

27

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?

28

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

t mod 32 MSS hash(client IP and port || server IP and port || t || K)

Server ISN

5 3 24

29

SYN Cookies[Bernstein and Schenk]

C S

SYNC Listening…

Does not store state

F(source addr, source port, dest addr, dest port, coarse time, server secret)

SYNS, ACKCsequence # = cookie

F=Rijndael or crypto hash

Recompute cookie, compare with with the onereceived, only establish connection if they match

ACKS(cookie)

Compatible with standard TCP;simply a “weird” sequence number scheme

More info: http://cr.yp.to/syncookies.html

30

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

31

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

33

• COMMENTS OR QUESTIONS?• Are others working on similar projects?

• Next User Group meeting in MayTopic is iRules and iControl