Atmosphere 2014: Scalable and under control - open cloud architecture considering security standards - Leszek Miś
0 likes320 views
The central server farm, called reverse proxy shall be the internet exchange point of every extensive cloud infrastructure. However it seems that configuration of such critical systems in a correct and safe way is strongly complex. It is time-consuming and requires great experience and focus to setup the following aspects: proxy/load balancing/clustering, HTTPS, access control, event logging mechanisms, WAF or platform hardening. We cannot deny that every single detail of such configuration is crucial and meaningful. Moreover, maintenance and development of Web Gateway type scalable infrastructure, composed of dozen/few dozen nods, is a big challenge for us. In this presentation, containing live demonstration, I will present you the concept of reverse proxy automated management, especially in terms of safety, with a use of Puppet open source supported platform and modsecurity as an open source Web Application Firewall. The main goal of my presentation is to show the idea of open, scalable cloud infrastructure, including general safety standards, as well as compliance with aspects described in the OWASP documents: Top Ten, Testing Guide, ASVS. And above all, I will show you how to eliminate those threats, before they are detected as a web application attack. Leszek Miś - IT Security Architect at Linux Polska sp. z o.o. WALLF Web Gateway Project Leader. Linux/Network Security Expert with an offensive approach to web application security. For over 10 years professionally engaged and privately fascinated with open source solutions, with special focus on IT (in) security. Red Hat skilled trainer and examiner, holder of RHCA/RHCSS/RHCE. Experienced author of several IT Security courses (Hardening, SELinux, ModSecurity).
![21
Infrastructure as code
<% if @mod_security -%>
SecRuleEngine <%= @mod_security %>
<% end -%>
● vhost.conf.erb:
<%=
scope.function_template(['wallf/apache/_secureheaders.er
b']) -%>](https://image.slidesharecdn.com/scalableundercontrol-140610021209-phpapp01/85/Atmosphere-2014-Scalable-and-under-control-open-cloud-architecture-considering-security-standards-Leszek-Mis-19-320.jpg)
Atmosphere 2014: Scalable and under control - open cloud architecture considering security standards - Leszek Miś
- 1. 1 Leszek Miś IT Security Architect RHCA,RHCSS,Sec+ lm@linuxpolska.pl Linux Polska Sp. z o.o. Scalable and under control - open cloud architecture considering security standards.
- 2. 2 #whoami ● Leszek Miś: – IT Security Architect – RHCA/RHCSS/Sec+ – Instruktor/egzaminator Red Hat – Splunk Certified Architect – Lider projektu WALLF Web Gateway ● Skupiam się głównie na: – Linux/Web/Cloud Security – SELinux/WAF/SSO – IdM/Domena ilnuksow – Pentesty
- 3. 3 O firmie Linux Polska ● Podstawowa działalność spółki: – Wsparcie lokalne dla systemów Open Source – Wdrożenia i migracje – Bezpieczeństwo IT – Szkolenia autoryzowane i autorskie
- 4. 4 Agenda ● Web (in)security ● OWASP ● Infrastructure as code ● Secure reverse Proxy
- 5. 5 Web (in)security ● Aplikacje webowe jako cel czyli zagrożenia kryją się wszędzie: – Aplikacja – Protokół – Implementacja HTTP – Język/Framework – Konfiguracja – System operacyjny
- 6. 6 Web (in)security ● Rzeczywistość weryfikuje: – Zimbra: priv_esc poprzez LFI: ● /res/I18nMsg,AjxMsg,ZMsg,ZmMsg,AjxKeys,ZmKeys,ZdMsg,Ajx%20TemplateMsg.js.zgz? v=091214175450&skin=../../../../../../../../../opt/zimbra/conf/localconfig.xml – OSSIM: SQL Injection – Apache Struts: RCE – F5 BigIQ – priv_esc – JIRA: directory traversal – Katello: users/update_roles – I wiele, wiele innych...
- 7. 7 Web (in)security ● Problem z patchowaniem podatności: – Wysoki koszt – Kod źródłowy firmy zewnętrznej – Ograniczony kontrakt/umowa – Brak zasobów – Brak skillsów – SDLC -> TST->ACC->PROD – Niedostępność aplikacji – Inne?
- 8. 8 Web (in)security ● Cross Site Scripting ● SQL Injection ● LDAP Injection ● XPATH Injection ● XML Injection ● Blind SQLi ● Time based SQLi ● Remote Command Execution ● Local File Inlusion ● Remote File Inclusion ● Session Hijacking ● HTTP Response Spliiting ● Sniffing/Spoofing ● ClickJacking ● MitB ● Open Redirect ● DOS/DDOS ● Cross Site Request Forgery (CSRF) ● Information/Path Dislosure ● Encoding ● Server Side Includes Injection ● Bruteforce ● Buffer overflow ● Misconfiguration ● Forced browsing ● Drive by Download
- 9. 11 OWASP
- 10. 12 OWASP Open Web Application Security Project Misja: Poprawa stanu bezpieczeństwa aplikacji „Make application security visible so that people and organizations can make informed decisions about true application security risk” • Projekty – dokumentacja, narzędzia • Edukacja • Współpraca (rządy, inne organizacje, twórcy standardów)
- 11. 13 Wybrane projekty OWASP DETECT PROTECT LIFE-CYCLE Documentation Top10 ASVS Testing Guide Code Review Guide Development Guide Secure Coding Practices – Quick Reference OpenSAMM Tools WebScarab Zed Attack Proxy JBroFuzz ESAPI AppSensor ModSecurity Core Ruleset WebGoat Education Project https://www.owasp.org/index.php/Category:OWASP_Project
- 12. 14 OWASP Top 10 ● Zbiór 10 najistotniejszych, kluczowych błędów w zabezpieczeniach aplikacji internetowych: – A1 – Injection – A2 – Broken Auth and Session MGMT – A3 – XSS – A4 – Insecure Direct Object References – A5 – Security Misconfiguration – A6 – Sensitive Data Exposure – A7 – Missing Function Level Access Control – A8 – CSRF – A9 – Known vulns – A10 – Unvalidated Redirects and Forwards
- 13. 15 OWASP ASVS – Security Verification Standard Testing guide – księga testów Appsensor – WAF wszyty w appkę ESAPI – Enterprise Security API Broken Web Application – poligon
- 15. 17 Infrastructure as code ● Problem dt. spójności infrastruktury: – Na których systemach zmiana została wprowadzona? – Czy pojawiła się na wszystkich systemach? – Czy została zaaplikowana tylko na tych systemach na których było to niezbędne? – Co z systemami, które w tym czasie były niedostępne? – Co z nowymi systemami, które dodamy do naszej infrastruktury?
- 16. 18 Infrastructure as code ● Zgodność ze standardami ● Powtarzalność: – skalowalność ● Weryfikacja: – kontrola wersji ● Gwarancja poprawności: – enforcing ● Współdzielenie: – TST->ACC->PROD ● Aktualność konfiguracji: ready for audit
- 18. 20 Infrastructure as code ● Abstrakcja-> Oczekiwany status: – SSL Cipher list – Error handling/Output filtering – Antibrute force mechanism – Secure flags for cookies – STIG compliance
- 19. 21 Infrastructure as code <% if @mod_security -%> SecRuleEngine <%= @mod_security %> <% end -%> ● vhost.conf.erb: <%= scope.function_template(['wallf/apache/_secureheaders.er b']) -%>
- 20. 22 Infrastructure as code ● Antibrute force
- 21. 23 Infrastructure as code ● SSL
- 22. 24 Infrastructure as code ● SSL: – Sslscan – sslLabs
- 23. 25 Infrastructure as code ● Error Handling – modsecurity_crs_50_outbound.conf
- 24. 26 Infrastructure as code ● Header manipulation: – unset X-Powered-By – unset Server – set X-XSS-Protection: "1; mode=block"' – set Header always set X-Frame-Options SAMEORIGIN
- 25. 27 Infrastructure as code ● Secure cookies: – HttpOnly – Secure – Path=
- 26. 29 Secure Web Gateway -> Open Source <- OWASP
- 27. 30 Secure Web Gateway - co jest istotne? ● Hardened Linux distro ● HA ● LB/Clustering ● WAF ● SSL configuration ● Access Control ● Change Mgmt ● Logging Mgmt ● Incident Response Mgmt ● Isolation ● Separation ● Scalability ● Monitoring ● Caching ● Performance tuning ● 2FA ● Auditing
- 29. 32 WAF ● Fazy filtrowania: ● Każda transakcja przechodzi przez 5 faz filtrowania: – 1: Request headers – 2: Request body – 3: Response headers – 4: Response body – 5: Logging
- 30. 34 WAF ● Ochrona przed atakami i integracja z DAST (Arachni,ZAP) ● Filtrowanie żądań ● 0-day protection ● Dynamiczne wstrzykiwanie - modyfikacja danych wychodzących w locie ● Wirtualne patchowanie
- 31. 35 WAF ● Wirtualny patch w uproszczonym przypadku: – Ograniczenie Request_Body_Size – Wykrywanie powtarzających się payloadów – Ograniczenie ilości ARGS – Weryfikacja/filtrowanie wartości ARGS – Analiza i filtrowanie RESPONSE_BODY
- 32. 36 WAF – tryby pracy ● Negative security model: SecRule REQUEST_FILENAME „@contains /owa/scriptname.asx” „chain, phase:1,block,log,msg:'XSS na mojej appce'” SecRule ARGS:parameter „@pm < > ( ) --” ● Positive security model: SecRule REQUEST_FILENAME „@contains /owa/scriptname.asx” „chain, phase:1,block,log,msg:'XSS na mojej appce'” SecRule ARGS:parameter „!@rx ^w+$”
- 33. 37 WAF ● Przykładowe reguły: – SecRule REQUEST_URI "@detectSQLi" "id:152,log,deny" – SecRule REQUEST_BODY "@detectXSS" "id:12345,log,deny" – SecRule REQUEST_HEADERS:User-Agent "@pm WebZIP WebCopier Webster WebStripper ... SiteSnagger CheeseBot" "id:166" – SecRule ARGS:foo "!@streq bar" "id:176"
- 34. 38 WAF ● Modsecurity to tylko silnik: – Apache – Nginx – IIS ● Musimy go „naładować”: – Tworzenie dedykowanych reguł od podstaw per aplikacja – Wykorzystanie gotowych reguł OWASP CRS – Hybryda czyli połączenie reguł CRS z własnymi regułami typu whitelist
- 35. 39 WAF – modsecurity CRS ● HTTP Protection - detecting violations of the HTTP protocol and a locally defined usage policy. ● Real-time Blacklist Lookups - utilizes 3rd Party IP Reputation ● HTTP Denial of Service Protections - defense against HTTP Flooding and Slow HTTP DoS Attacks. ● Common Web Attacks Protection - detecting common web application security attack. ● Automation Detection - Detecting bots, crawlers, scanners and other surface malicious activity. ● Integration with AV Scanning for File Uploads - detects malicious files uploaded through the web application. ● Tracking Sensitive Data - Tracks Credit Card usage and blocks leakages. ● Trojan Protection - Detecting access to Trojans horses. ● Identification of Application Defects - alerts on application misconfigurations. ● Error Detection and Hiding - Disguising error messages sent by the server.
- 36. 40 WAF ● Reguły OWASP CRS podzielone są na: – base_rules – experimental_rules – optional_rules – slr_rules ● Dostosowanie reguł CRS per aplikacja: – SecRuleRemoveById – SecRuleRemoveByMsg – SecRuleRemoveByTag ● (Konsola)
- 37. 41 WAF – advanced ● HMAC ● Content Security Policy ● Webhoneypots ● LUA ● JSON/XML ● AV Scanning ● GEO/IP reputation ● BEEF czyli Attack the attacker: – Browser as Pentester's gateway
- 38. 43 Podsumowanie ● WAF = ubezpieczenie ● Krytyczność reverse proxy ● Podejście devopsowe do zarządzania bezpieczeństwem ● WAF_Mgmt jako element Change_Mgmt ● Zasoby OWASP jako wzorce do naśladowania ● Open source “Some people, wether vemdors or customers, believe in "auto learning mode". My experiance with such systems is that the (generated) rule set becomes unmanageable after a couple of time.” - Achim Hoffman - OWASP
- 39. 45 Dziękuję za uwagę. Leszek Miś IT Security Architect RHCA,RHCSS,Sec+ lm@linuxpolska.pl Linux Polska Sp. z o.o.