Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Ile warstw, tyle szans.
Defensive-Security.com
Leszek Miś
leszek.mis@defensive-security.com
# Leszek Miś
● Founder @ Defensive Security
● Chief Security Architect @ Collective Sense
● Offensive Security Certified P...
Agenda
● Stan aktualny
● Zagrożenia
● Potrzeby czyli stan porządany
● Podsumowanie
Stan aktualny
● Wygrzana wirtualizacja:
– Type 1:
● VMware ESX, Citrix XEN, KVM
– Type 2:
● Virtualbox, QEMU, VMware works...
Zagrożenia
● Escaping from:
– Guest to guest
– Guest to host
● Ataki cross-kontenerowe
● DOS:
– VM crash
– Host crash
● At...
Zagrożenia
● Nieograniczone operacje uprzywilejowane:
– uid=0, CAP_SYS_ADMIN
● Słaba konfiguracja domyślna:
– Host
– Netwo...
Zagrożenia
● Mnóstwo najróżniejszych CVE:
– CVE-2014-7975:
– CVE-2015-2925: double chroot attack
– CVE-2015-4176
– CVE-201...
Zagrożenia
● Peering into the Depths of TLS Traffic in Real Time.pdf
● Xen Hypervisor VM Escape.pdf
● Virtualization Syste...
Zagrożenia
● Błędy w tzw. rozwiązaniach „sprzętowych”:
– Palo Alto Next Generation FW:
● CLI over SSH → command line injec...
Potrzeby
Potrzeby
● Defense in depth → least privs → utrudnienie ataków
● Izolacja na wielu warstwach:
– Kernel
– Host OS
– Wirtual...
Potrzeby - kernel
● Kernel → do_brk(2) , do_remap(2) , vmsplice(2) / snmp, econet, CAN, SCTP, UDP
– Wyłączenie obsługi mod...
Potrzeby – host OS
● Separacja uprawnień
● Minimalizm implementacyjny
● Niskopoziomowe audytowanie zdarzeń:
– auditd, sysd...
Potrzeby – host OS
● OSSEC - Host Intrusion Detection System:
– Wsparcie dla Windows, Linux, Mac OSX, Solaris, HP-UX
– Fun...
Potrzeby – host OS
● OSSEC - Host Intrusion Detection System:
Potrzeby – host OS
● Analiza RAM:
– GRR
– Volatillity:
● Ukryte procesy / moduły / pliki / połączenia
● Połączenia sieciow...
Potrzeby – wirtualizacja
● sVirt → Secure Virtualization:
Potrzeby – konteneryzacja
●
NO root!
● Capabalities:
– Funkcjonalność ograniczająca dostęp do syscalli per proces
– Reduku...
Potrzeby – konteneryzacja
● Kernel namespaces:
– Partycjonowanie globalnej tablicy identyfikatorów i struktur
– Dedykowane...
Potrzeby – konteneryzacja
● SELinux / Apparmor:
– Ograniczenie wywołań systemowych
– „sandboxy” per proces / kontener
Potrzeby – konteneryzacja
● Seccomp-bpf:
– Filtrowanie syscalli:
● Kernel 4.X ma ich ~400
● V1.10:
– 310 syscalli na white...
Potrzeby – konteneryzacja
● Control groups – hierarchiczny kontroler dostępu do zasobów:
– lub inaczej ulimits/rlimits on ...
Potrzeby – konteneryzacja
● Aktywne monitorowanie/skanowanie kontenerów:
– Docker Bench for Security
– Clair
– Atomic Scan...
Potrzeby – aplikacje webowe
● Web Application Firewall:
– Walidacja metod HTTP
– Wirtualne patchowanie
– Ochrona przed:
● ...
Potrzeby – ruch sieciowy
● Wykrywanie wczesnej fazy enumeracji infrastruktury / systemu
● Aktywne / pasywne rozpoznawanie ...
Potrzeby – ruch sieciowy
● Security Onion → dedykowane Linux distro
– Snort/Suricara (alerty)
– Bro (sesje, transakcje, lo...
VPS / cloud
● Brak dostępności urządzeń typu TAP / SPAN port
● Security Onion Cloud Client:
– Daemonlogger lub netsniff-ng...
Testowanie
● Malware pcaps:
– Google query: „Mila malware pcap”
● Replay'owanie ruchu:
– tcpreplay, tcpreplay-edit, tcppre...
Podsumowanie
● Wielowarstwowa izolacja kluczem:>
● Minimum dla bezpiecznego „HW” produktu komercyjnego
● Kompletne i utwar...
Oferta Defensive Security
– Edukacja w postaci ochrona vs atak:
● „Open Source Defensive Security” -
http://defensive-secu...
Dziękuję za uwagę,
zapraszam do kontaktu.
http://defensive-security.com
Leszek Miś
leszek.mis@defensive-security.com
Upcoming SlideShare
Loading in …5
×

NGSec 2016 - Ile warstw, tyle szans. - Leszek Miś@Defensive-Security.com

240 views

Published on

W dobie rozwijającego się w szybkim tempie rynku sprzedaży exploitów typu 0-day i wszechobecnych backdoorów w tzw. „drogich zabawkach”, coraz trudniejszym staje się utworzenie i utrzymanie bezpiecznej infrastruktury krytycznej. Aktualizacje oprogramowania jak i tzw. „old-schoolowe” triki utwardzające systemy i urządzenia sieciowe nadal uznawane są za poprawne, ale zdecydowanie nie są wystarczające. Potrzebujemy mechanizmów profilowania zachowania zarówno sieci, systemów jak i administratorów i użytkowników końcowych. Potrzebujemy więcej dedykowanych, „szytych na miarę” defensywnych konfiguracji oraz przede wszystkim izolacji na poszczególnych warstwach infrastruktury. Jednocześnie zdobywanie przez kadrę techniczną aktualnej, niepowiązanej z żadnym vendorem wiedzy z zakresu „offensive vs defensive” staje się kluczową kwestią w rozwoju technologicznym zespołów IT/ITSec.

Podczas prezentacji, na bazie wieloletniej obserwacji „podwórka IT Security” postaram się przedstawić możliwości, jakie drzemią w rozwiniętych rozwiązaniach Open Source dedykowanych utwardzaniu, profilowaniu i monitorowaniu systemów i sieci. Na bazie rzeczywistych przypadków omówione zostaną wybrane sposoby ochrony i wykrywania zdarzeń wykorzystując:

– izolację (Apparmor, SELinux, Docker/LXC, chroot/jail) celem utrudnienia eskalacji uprawnień

– filtrowanie i profilowanie (seccomp, systemtap, sysdig, GRR, Volatility, modsecurity/naxsi)

– aktywną i pasywną analizę ruchu sieciowego celem wczesnego wykrywania zagrożeń

– hardening jądra systemowego i przestrzeni użytkownika

– centralne miejsce składowania logów i korelacji zdarzeń (Elastic, Logstash, Kibana)

Prezentacja jest swego rodzaju drogowskazem do zbudowania własnej „fortecy” w sposób odmienny od tego, jaki prezentują liderzy komercyjnego rynku. Zastrzyk merytoryki gwarantowany!

Published in: Technology
  • Be the first to comment

NGSec 2016 - Ile warstw, tyle szans. - Leszek Miś@Defensive-Security.com

  1. 1. Ile warstw, tyle szans. Defensive-Security.com Leszek Miś leszek.mis@defensive-security.com
  2. 2. # Leszek Miś ● Founder @ Defensive Security ● Chief Security Architect @ Collective Sense ● Offensive Security Certified Professional ● RHCA/RHCSS/RHCX/Sec+ ● Członek ISSA/OWASP Poland ● Skupiam się głównie na: – Linux & Network Security – Web Application Security – Penetration testing – Hardened IT Infrastructure (SSO/IdM/IDS) – Linux forensics
  3. 3. Agenda ● Stan aktualny ● Zagrożenia ● Potrzeby czyli stan porządany ● Podsumowanie
  4. 4. Stan aktualny ● Wygrzana wirtualizacja: – Type 1: ● VMware ESX, Citrix XEN, KVM – Type 2: ● Virtualbox, QEMU, VMware workstation ● Gorąca konteneryzacja: – CoreOS Rocket, LXC, Docker ● Środowiska: – PaaS – SaaS – mikroserwisy Co łączy powyższe technologie?
  5. 5. Zagrożenia ● Escaping from: – Guest to guest – Guest to host ● Ataki cross-kontenerowe ● DOS: – VM crash – Host crash ● Ataki na mgmt: – API – Web apps / restricted shells
  6. 6. Zagrożenia ● Nieograniczone operacje uprzywilejowane: – uid=0, CAP_SYS_ADMIN ● Słaba konfiguracja domyślna: – Host – Network → 0.0.0.0 ● Wyciek informacji → procfs, dmesg, sysfs, debugfs, /dev, inne ● Brak ochrony krytycznych elementów systemu → np. LKM / MAC ● Brak ograniczenia dostępu do zasobów: – (:(){ :|:& };:) / OOM – Random devices ● Brak aktualizacji → nowy kod → nowe błędy ● Kiepskiej jakości kod źródłowy → web apps ● Duże obrazy bazowe
  7. 7. Zagrożenia ● Mnóstwo najróżniejszych CVE: – CVE-2014-7975: – CVE-2015-2925: double chroot attack – CVE-2015-4176 – CVE-2015-1328: privilege escalation vulnerability when using overlayfs mounts inside of user namespaces – CVE-2015-1334: fake procfs for bypassing MAC – CVE-2014-6407: symlink attack – CVE-2015-1331: directory traversal – CVE-2015-3630: /proc/asound manipulation – CVE-2015-5165: QEMU: heap overflow in RTL8139 driver – CVE-2015-3209: floppy controller (Venom)
  8. 8. Zagrożenia ● Peering into the Depths of TLS Traffic in Real Time.pdf ● Xen Hypervisor VM Escape.pdf ● Virtualization System Vulnerability Discovery Framework.pdf ● Escape From The Docker-KVM-QEMU Machine.pdf
  9. 9. Zagrożenia ● Błędy w tzw. rozwiązaniach „sprzętowych”: – Palo Alto Next Generation FW: ● CLI over SSH → command line injection in SCP connection ● ApiWgetFilter bypass → PreAuth RCE ● DOS → /global-protect/login.esp – Fireye: ● Malware Input Processor → email + malicious attachment = Code Execution using JODE ● Priv Esc → snort autoupdate module http://conference.hitb.org/hitbsecconf2016ams/materials/D2T1%20-%20Felix%20Wilhelm %20-%20Attacking%20Next%20Generation%20Firewalls.pdf http://googleprojectzero.blogspot.com/2015/12/fireeye-exploitation-project-zeros.html
  10. 10. Potrzeby
  11. 11. Potrzeby ● Defense in depth → least privs → utrudnienie ataków ● Izolacja na wielu warstwach: – Kernel – Host OS – Wirtualizacja – Konteneryzacja – Sieć + usługi sieciowe – Aplikacje webowe – Użytkownicy, w tym root
  12. 12. Potrzeby - kernel ● Kernel → do_brk(2) , do_remap(2) , vmsplice(2) / snmp, econet, CAN, SCTP, UDP – Wyłączenie obsługi modułów: ● kernel.modules_disabled=1 ● CONFIG_MODULES=n – Utwardzona kompilacja – grsecurity+PAX(non-X,non-W): ● KASLR ● Address Space Protection ● Trusted Path Execution ● Chroot restriction ● FS restriction ● RBAC ● Network protection – CONFIG_CC_STACKPROTECTOR_STRONG
  13. 13. Potrzeby – host OS ● Separacja uprawnień ● Minimalizm implementacyjny ● Niskopoziomowe audytowanie zdarzeń: – auditd, sysdig, stap ● DAC vs MAC → ograniczenie roota ● Multi Category Security ● Okresowa analiza pamięci RAM ● Privchecki: – suid, sgid, world writeable dirs, etc.
  14. 14. Potrzeby – host OS ● OSSEC - Host Intrusion Detection System: – Wsparcie dla Windows, Linux, Mac OSX, Solaris, HP-UX – Funkcjonalność: ● Analiza logów ● Integralność systemu plików + IMA/EVM ● Monitoring zdarzeń systemowych ● Wykrywanie rootkitów ● Alertowanie oraz aktywna ochrona
  15. 15. Potrzeby – host OS ● OSSEC - Host Intrusion Detection System:
  16. 16. Potrzeby – host OS ● Analiza RAM: – GRR – Volatillity: ● Ukryte procesy / moduły / pliki / połączenia ● Połączenia sieciowe: – linux_netstat – linux_list_raw – linux_arp – connections – yarascan – hosts http://downloads.volatilityfoundation.org/releases/2.4/CheatSheet_v2.4.pdf
  17. 17. Potrzeby – wirtualizacja ● sVirt → Secure Virtualization:
  18. 18. Potrzeby – konteneryzacja ● NO root! ● Capabalities: – Funkcjonalność ograniczająca dostęp do syscalli per proces – Redukująca np. pełne SUID/SGID: ● Nasłuchiwanie na porcie <1024 (CAP_NET_BIND_SERVICE) ● Ładowanie modułów (CAP_SYS_MODULE) ● Tworzenie urządzeń (CAP_MKNOD) ● mount/umount ● Reboot (CAP_SYS_BOOT) ● Operacje sieciowe (CAP_NET_RAW) – include/linux/capability.h # docker run --cap-drop ALL --cap-add SYS_TIME ntpd /bin/sh # pscap | grep 2382 5417 2382 root sh sys_time
  19. 19. Potrzeby – konteneryzacja ● Kernel namespaces: – Partycjonowanie globalnej tablicy identyfikatorów i struktur – Dedykowane „widoki”: ● PID (CLONE_NEWPID) ● MNT (CLONE_NEWNS) ● IPC (CLONE_NEWIPC) ● UTS (CLONE_NEWUTS) ● NET (CLONE_NEWNET) ● USER (--userns-remap) – Brak NS dla: dev, time, syslog
  20. 20. Potrzeby – konteneryzacja ● SELinux / Apparmor: – Ograniczenie wywołań systemowych – „sandboxy” per proces / kontener
  21. 21. Potrzeby – konteneryzacja ● Seccomp-bpf: – Filtrowanie syscalli: ● Kernel 4.X ma ich ~400 ● V1.10: – 310 syscalli na whiteliście – 100 syscalli blokowanych by default – Wykorzystywane w: ● Chrome, vsftpd, OpenSSH(UsePrivilegeSeparation) prctl(PR_SET_SECCOMP , SECCOMP_MODE_FILTER , prog); docker run –d –security-opt seccomp:allow:clock_adjtime ntpd
  22. 22. Potrzeby – konteneryzacja ● Control groups – hierarchiczny kontroler dostępu do zasobów: – lub inaczej ulimits/rlimits on steroids – cgroup VFS ● CPU ● BLKIO ● Memory ● Network (tagowanie pakietów) ● Freezer (SIGSTOP / SIGCONT) ● PID (max. ilość procesów) – Wsparcie systemd
  23. 23. Potrzeby – konteneryzacja ● Aktywne monitorowanie/skanowanie kontenerów: – Docker Bench for Security – Clair – Atomic Scan ● Współdzielona sieć / port binding / FW ● Rest API / docker / gid=docker ● Private registry ● TLS ● Aktualizacje
  24. 24. Potrzeby – aplikacje webowe ● Web Application Firewall: – Walidacja metod HTTP – Wirtualne patchowanie – Ochrona przed: ● SQLi, XSS, LFI/RFI, CSRF, CE, brute-force, directory traversal, itp. itd.. – Web honeypots
  25. 25. Potrzeby – ruch sieciowy ● Wykrywanie wczesnej fazy enumeracji infrastruktury / systemu ● Aktywne / pasywne rozpoznawanie podatnych systemów / usług / aplikacji ● Wykorzystywanie pułapek ● Tworzenie baseline'ów: – Profilowanie ruchu sieciowego – Profilowanie zachowania systemów i urządzeń
  26. 26. Potrzeby – ruch sieciowy ● Security Onion → dedykowane Linux distro – Snort/Suricara (alerty) – Bro (sesje, transakcje, logowanie: http, dns, ftp, smtp, etc) – Netsniff-ng (full packet capture) – Sguil, Squert, ELSA, Snorby, Networkminer, Xplico (analiza) – Tryb pracy: sensor, serwer, standalone – Bardzo łatwy w instalacji (klik, klik)
  27. 27. VPS / cloud ● Brak dostępności urządzeń typu TAP / SPAN port ● Security Onion Cloud Client: – Daemonlogger lub netsniff-ng → eth0 → tap0 – OpenVPN + bridge
  28. 28. Testowanie ● Malware pcaps: – Google query: „Mila malware pcap” ● Replay'owanie ruchu: – tcpreplay, tcpreplay-edit, tcpprep, tcprewrite – nfreplay ● Kali Linux ● pytbull, testmyids.com, testShellcode.py ● Python scapy
  29. 29. Podsumowanie ● Wielowarstwowa izolacja kluczem:> ● Minimum dla bezpiecznego „HW” produktu komercyjnego ● Kompletne i utwardzone rozwiązania na bazie Open Source ● Nauczenie się zachowania sieci i systemów podstawą profilowania ● Otwarte standardy gwarancją rozwoju
  30. 30. Oferta Defensive Security – Edukacja w postaci ochrona vs atak: ● „Open Source Defensive Security” - http://defensive-security.com/ ● Analiza poziomu bezpieczeństwa aplikacji i usług - testy penetracyjne i audyty bezpieczeństwa ● Konsultacje i wdrożenia korporacyjnych rozwiązań Open Source z zakresu bezpieczeństwa i infrastruktury IT
  31. 31. Dziękuję za uwagę, zapraszam do kontaktu. http://defensive-security.com Leszek Miś leszek.mis@defensive-security.com

×