Upload
proidea
View
206
Download
0
Embed Size (px)
DESCRIPTION
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).
Citation preview
1
Leszek MiśIT Security ArchitectRHCA,RHCSS,[email protected] Polska Sp. z o.o.
Scalable and under control - open cloud architecture considering security standards.
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
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
Agenda
● Web (in)security
● OWASP
● Infrastructure as code
● Secure reverse Proxy
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
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
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
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
11
OWASP
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)
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
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
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
16
Infrastructure as code
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?
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
19
Infrastructure as code
20
Infrastructure as code
● Abstrakcja-> Oczekiwany status:
– SSL Cipher list
– Error handling/Output filtering
– Antibrute force mechanism
– Secure flags for cookies
– STIG compliance
21
Infrastructure as code
<% if @mod_security -%>
SecRuleEngine <%= @mod_security %>
<% end -%>
● vhost.conf.erb:
<%= scope.function_template(['wallf/apache/_secureheaders.erb']) -%>
22
Infrastructure as code
● Antibrute force
23
Infrastructure as code
● SSL
24
Infrastructure as code
● SSL:
– Sslscan
– sslLabs
25
Infrastructure as code
● Error Handling – modsecurity_crs_50_outbound.conf
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
27
Infrastructure as code
● Secure cookies:
– HttpOnly
– Secure
– Path=
29
Secure Web Gateway ->Open Source <- OWASP
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
31
WAF
● Architektura
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
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
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
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+$”
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"
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
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.
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)
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
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