BEZPEČNOSTNĚ PROVOZNÍ KALEIDOSKOP Tomáš Košňar CESNET 6. 2. 2018 Seminář o bezpečnosti sítí a služeb
NOVINKY Z MONITORINGU novinky v systému FTAS, krajský FTAS co se objevilo v provozu
FTAS REPUTAČNÍ DB FTAS systém pro systematické souvislé zpracování, uchování a zpřístupnění informací o síťovém provozu
FTAS REPUTAČNÍ DB Reputační DB - statistické zpracování detekovaných anomálií možnost konfigurace nezávislých datových sad (podle účelu - např. pro páteřní síť, pro síť uživatele, pro typ anomálie apod.) navázání 1-N detektorů ke konkrétní datové sadě přístup a vizualizace stejným způsobem jako u ostatních datových objektů
FTAS REPUTAČNÍ DB ukázka udp amplifikace vůči konkrétním IP (samostatný záznam) provázání s notifikacemi záznamy možno z DB administrativně vyjmout (false positive)
FTAS REPUTAČNÍ DB ukázka amplifikace vůči cílovým IP (agregát podle cíle) automatický policing proti UDP amplifikaci na hraně páteře
FTAS REPUTAČNÍ DB ukázka TCP syn/scan (agregát podle detektoru) ad-hoc blokace na základě notifikace detektoru a analýzy
FTAS REPUTAČNÍ DB ukázka TCP syn/scan (agregát podle GeoIP)
FTAS ROZŠÍŘENÍ VIZUALIZACE požadavky na analýzu trendů charakteru provozu apod. bars lines lines+points points value prev curr avg curr avg %
FTAS ROZŠÍŘENÍ VIZUALIZACE požadavky na analýzu trendů struktury provozu apod.
CO SE OBJEVILO V PROVOZU udp/ldap amplifikace partner (cíl útoku) výzva konkrétním sítím (zdroje odrazu) ukázka - provoz na udp/389 do sítě uživatele (tzn. na zesilující IP)
CO SE OBJEVILO V PROVOZU udp/ldap amplifikace ukázka zesílený (cca 17x) provoz z udp/389 z nalezených IP zobecněno na celý AS, řešeno individuálně zapomenuté otevřené porty :-(
CO SE OBJEVILO V PROVOZU IP adresy na prodej přístup prostřednictvím RDP tcp/3389 ověření věrohodnosti získaných informací ukázka - odchozí provoz z IP adres směrem z AS, port tcp/3389
CO SE OBJEVILO V PROVOZU ukázka rozšíření o cílovou IP adresu nejvýznamnější a nejméně významný zdroj z předchozí ukázky pro odhad relevance výsledků
KRAJSKÝ FTAS FTAS jako služba pro e-infrastrukturu CESNET pro uživatele (někteří - samostatná instalace systému) výzkum, vývoj, vzdělávání, zdravotnictví, ISP, IXP, samospráva, státní správa podpora pro správu sítě a služeb, systematická analýza provozu, řešení povinností dle ZEK, ZKB (provozní informace, detekce,..), naplnění podmínek pro členství ve FENIX (NIX.CZ) apod. 2016: výzva IROP, MMR Infrastruktura středních a vyšších odborných škol - v IT oblasti důraz na bezpečnost mj. povinnosti uchování provozních dat, překladových informací atd.. cíl: nízkonákladové a nezatěžující (pro personál škol) řešení, širší využití a spolupráce v rámci regionu
KRAJSKÝ FTAS Krajský FTAS služby více subjektům (krajské sítě + školy) v rámci jedné instance systému odborný personál kraje správa, konfigurace znalý uživatel personál školy nastavení exportu provozních dat
ARCHITEKTURA PŘIPOJENÍ PRO KRITICKÉ SLUŽBY...o čem stojí za to přemýšlet?
ARCHITEKTURA PŘIPOJENÍ PRO KRITICKÉ SLUŽBY..k zamyšlení neexistuje univerzální řešení pro všechny případy!!! umělý a zjednodušený případ vč. vymyšlených čísel (kompilát zkušeností z praxe) služba v síti instituce, DNS také,...(pomineme HA zapojení), 1 GE síť péče zpravidla soustředěna především na koncovou aplikaci (front-end, UI, testy výkonu apod.)
ARCHITEKTURA PŘIPOJENÍ PRO KRITICKÉ SLUŽBY..posuzujme komplexně celý síťový set-up posílení/odlehčení potenciálně nejslabších článků řetězu rozložení potenciální zátěže v extrémních situacích mezi prvky reálně potřebná vs. limitní kapacita/průchodnost/výkon komunikační schéma (služby, protokoly, porty, enkapsulace) analýza testovacího, produkčního provozu kdo neměří, nic neví... 30M 500M 350M 1G 1G 1G
ARCHITEKTURA PŘIPOJENÍ PRO KRITICKÉ SLUŽBY naměřená data vztahujeme ke znalosti provozu a limitů prvků příklad potřebná kapacita v síťovém řetězci (ve směru ke službě) produkčně (~1 hodnota 5 min. průměr) cca 150+26 Mb/s (do limitu pro službu) bude při 50% pravidlu stačit FW s průchodností 350Mb/s (pozn: délka paketů!!)?..a jak je to s např. TCP sessions (v případě TCP) kolik FW umí a kolik potřebujeme atd.? 350M celkový provoz služba
ARCHITEKTURA PŘIPOJENÍ PRO KRITICKÉ SLUŽBY provoz ke službě - produkční vs detailní měření (1 hodnota = průměr za 1s) vybraný interval odpovídá předpokladu - jsme na cca 2 násobku bit-rate pkt.-length
ARCHITEKTURA PŘIPOJENÍ PRO KRITICKÉ SLUŽBY celkový provoz - produkční vs detailní měření (1 hodnota = průměr za 1s) cca 7 násobek - 460M..? bit-rate pkt.-length
ARCHITEKTURA PŘIPOJENÍ PRO KRITICKÉ SLUŽBY provoz ke službě atd. dále detailní analýzy porty, protokoly, vazby na IP...
ARCHITEKTURA PŘIPOJENÍ PRO KRITICKÉ SLUŽBY shrnutí, doporučení znalost charakteru a objemu provozu analýza každého podstatného článku řetězu nominální vs. potřebný výkon (odvozováno od limitů aplikace/služby) souvisle monitorujeme strategie regulace provozu (abychom udrželi soustavu provozuschopnou a v extrému byly postupně regulovány části provozu podle našich priorit) spolupráce s ISP zabránit zahlcení přípojky, zabránit přetížení hraničního prvku (případně dalších), parametrická regulace provozu revize architektury sítě např. vysunuté DNS, jak s balancery apod. vyčlenění infrastruktury pro službu jasně definovaný provozní profil, více volné kapacity, více flexibility... začít řešit včas!!!
ARCHITEKTURA PŘIPOJENÍ PRO KRITICKÉ SLUŽBY příklad - spekulativní úprava síťové architektury pozn.: stále umělý případ vč. vymyšlených čísel varianta s oddělením infrastruktury pro službu, předsunutím DNS, vyjádřením potřebného a nominálního výkonu 30M 350M 30M 1G DNS 30M 500M 1G 1G 1G 1G 30M 350M 1G 1G 350M
FENIX OSTROVNÍ REŽIM...co by se fakticky stalo po překlopení do ostrovního režimu?..zeptal se kolega
FENIX OSTROVNÍ REŽIM FENIX projekt vznikl na půdě NIX.CZ v roce 2013 (reakce na DoS útoky) umožnit dostupnost internetových služeb v rámci zapojených subjektů i v případech extrémních útoků autonomní řízení a rozhodování - členové projektu technické podmínky mj.: organizační podmínky mj.: redundantní přípojky do nejméně aktivní člen NIX.CZ dvou uzlů NIX.CZ, IPv4 a IPv6 24/7 dohledové středisko DNSSEC podepsané domény zapojen v systému RTBH filteringu CERT/CSIRT tým s patřičným statusem použití FENIX Route Serveru BCP38, monitoring provozu a toků vnitřní procesy pro řešení incidentů systém na detekci a eliminaci ampl. reakční čas do 30 minut útoků
FENIX OSTROVNÍ REŽIM FENIX - členové zakládající: Active24, CESNET, CZ.NIC, Dial Telecom, NIX.CZ, O2 Czech rep., Seznam.cz aktuálně 20 členů 1. 2. 2018 - Master Internet, s.r.o. https://fe.nix.cz/
FENIX OSTROVNÍ REŽIM připojení k infrastruktuře NIX.CZ
FENIX OSTROVNÍ REŽIM peering pozn.: do FENIXu propagovány pouze ty prefixy, které splňují podmínky
FENIX OSTROVNÍ REŽIM útok přes síť uživatele NIX.CZ, který není součástí FENIX
FENIX OSTROVNÍ REŽIM překlopení do ostrovního režimu odpojení od veřejné infrastruktury pro peering
FENIX OSTROVNÍ REŽIM útok přes síť člena FENIX v ostrovním režimu nižší pravděpodobnost závazné standardy a opatření technická organizační
FENIX OSTROVNÍ REŽIM útok přes síť člena FENIX v ostrovním režimu snazší eliminace předpokládaná efektivní spolupráce last-resort pomocí povinných RS
FENIX OSTROVNÍ REŽIM dostupnost českých služeb českým uživatelům i v extrémních situacích pomocí FENIX
FENIX dostupnost českých služeb českým uživatelům i v extrémních situacích pomocí FENIX
DĚKUJI ZA POZORNOST DOTAZY?