1

Leszek MiśIT Security ArchitectRHCA,RHCSS,Sec+lm@linuxpolska.plLinux 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

45

Dziękuję za uwagę.

Leszek MiśIT Security ArchitectRHCA,RHCSS,Sec+lm@linuxpolska.plLinux Polska Sp. z o.o.