Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
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
Prochain SlideShare
Chargement dans…5
×

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

267 vues

Publié le

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!

Publié dans : Technologie
  • Soyez le premier à commenter

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

×