Analýza síťového provozu

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Analýza síťového provozu DIPLOMOVÁ PRÁCE

Pavel Kužel

Brno,2006

Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Vedoucí práce: Ing. Mgr. Zdeněk Říha, Ph.D. 11

Poděkování Na tomto místě bych rád poděkoval svému vedoucímu diplomové práce Ing. Mgr. Zdeňku Říhovi, Ph.D. za jeho odbornou pomoc a mnoho pod nětných rad a návrhů. Dále děkuji svým rodičům za podporu a trpělivost, kterou se mnou měli během tvorby této práce a během celého studia.

m

Shrnutí Tento dokument popisuje metadata síťového provozu nejrozšířenějších pro tokolů, které se používají v síti Masarykovy univerzity (MU). Zabývá se možnostmi a prostředky detekce síťových anomálií a útoků. Diskutuje ně kolik opensource přístupů k řešení problematiky sledování provozu. Část práce je věnována i sledování provozu v síti MU, z níž vychází i návrh a implementace softwaru pro detekci některých síťových anomálií. Práce také zmiňuje současné trendy ve sledování síťového provozu a požadavky na prostředky pro jeho sledování.

Traffic analysis, not cryptanalysis, is the backbone of communications intelligence." Susan Landau and Whitfield Diffie

IV

Klíčová slova bezpečnost, metadata, tok, provoz, sledování provozu, skenování portů, Network Intrusion Detection System, Snort, myNetWatchman, Prelude

Místo této strany bude vložena kopie zadání diplomové práce.

VI

Obsah 1 Úvod 2 Úvod do problematiky 2.1 OSI model 2.2 Protokol IPv4 2.2.1 Atributy Atributy hlavičky IP paketu, které IPstack ověřuje na správnou velikost a obsah Atributy významné pro analýzu provozu 2.3 Nové aspekty analýzy provozu v IPv6 2.4 Protokol ICMP 2.4.1 Atributy 2.5 Protokol TCP 2.5.1 Fáze TCP spojení 2.5.2 Vlastnosti TCP Velikost okna TCP Multiplexing — porty Reset TCP spojení 2.5.3 Atributy 2.6 Protokol UDP 2.6.1 Atributy 3 Techniky skenování portů 3.1 Techniky skenování přes protokol IP 3.2 Techniky skenování přes protokol TCP 3.2.1 Něco více o Idle skenu 3.2.2 Obrana proti Idle skenu 3.3 Techniky skenování přes protokol UDP 3.4 PortKnocking 3.4.1 Popis 3.4.2 Výhody PortKnockingu 3.4.3 Nevýhody PortKnockingu 4 Topologické možnosti sledování provozu 4.1 Span port

4 6 6 8 9 9 9 9 11 12 13 13 15 15 15 16 17 17 18 19 19 19 21 22 23 23 23 24 24 26 27 1

5

6

7

8

4.2 Hub 4.3 Tap zařízení Intrusion Detection/Prevention System 5.1 Úvod do IDS 5.2 Metody detekce využívané IDS 5.3 ObcházeníNIDS 5.4 Co nabízí současné IDS? 5.5 Způsoby reakcí IDS na incidenty 5.6 Shrnutí Software pro analýzu síťového provozu 6.1 SNORT 6.1.1 Popis, možnosti konfigurace Preprocesory Frag3 Stream4 sfPortscan HTTP Inspect Performance monitor 6.1.2 Výstupní plug-iny a reakce na incidenty 6.1.3 Shrnutí 6.2 myNetWatchman 6.2.1 Popis 6.2.2 Možnosti konfigurace 6.2.3 Reakce na incident 6.2.4 Shrnutí 6.3 Prelude 6.3.1 Popis 6.3.2 Bližší popis komponent Prelude-LML Libsafe Prelude-Manager 6.3.3 Možnosti konfigurace 6.3.4 Shrnutí Sledování provozu na MU 7.1 Právní kontext 7.2 Logická struktura sítě 7.3 Sledování provozu na MU 7.3.1 Shrnutí známých faktů 7.3.2 Optimistický závěr Vlastní program

28 29 32 32 34 35 39 41 46 48 48 48 49 49 49 49 51 51 51 52 53 53 55 56 57 58 58 62 62 63 63 64 66 67 67 67 68 68 71 72 2

8.1 Analýza 8.2 Popis 8.3 Možnosti konfigurace 8.4 Reakce na incident 8.5 Shrnutí 9 Závěr Literatura A Schéma zapojení pasivního 100Mbit Tap zařízení B Obsah CD

72 74 75 77 77 79 81 83 84

3

Kapitola 1

Úvod I když má analýza síťového provozu své kořeny ve vojenské (především výzvědné) činnosti, nachází své plné uplatnění i v mírové době v rozvinu tých demokratických zřízeních současnosti. S rozvojem a s masivním roz šířením informačních a komunikačních technologií (ICT) je tento jev stále více patrnější. Počítačová bezpečnost obecně již není předmětem studia ar mádních agentur za zavřenými dveřmi, ale zabývají se jí široké vědecké kruhy a komerční společnosti. S analýzou síťového provozu je úzce spojena kryptografie, o které bylo již napsáno mnoho a nebudu se jí v této práci významně zabývat. V porovnání s kryptoanalýzou poskytuje analýza síťo vého provozu podstatně méně kvalitní informace o obsahu, zato je řádově jednodušší a levnější tato data získat. Analýza síťového provozu je proto často využívána pro výběr vhodného subjektu k náročnějšímu (a dražšímu) útoku. Se zvětšujícím se počtem počítačů připojených k internetu a díky je jich stále snazší dostupnosti můžeme očekávat, že význam analýzy síťového provozu a zájem o její zjištění bude nadále růst. Z pohledu oběti analýzy síťového provozu tkví její nebezpečnost především v její dostupnosti a re lativní nenáročnosti na provedení. Nevládní instituce obvykle nemají velké rozpočty a možnosti odposlechu jakéhokoliv komunikačního kanálu, který je zajímá. Proto se výzkum zaměřil na alternativní nízkonákladové způsoby získávání informací a také na stejně nenákladné způsoby, jak se proti nim bránit (osobní firewally, používání passphrase, záznamy o navštívených webstránkách, veřejné anonymizery atp.). Z hlediska bezpečnosti představují metadata každého síťového spojení (vedle samotného obsahu) postranní informační kanál. Přičemž metadata mohou postkytnout informace o obsahu samotném, nehledě na to, zda je obsah šifrovaný či nikoliv. Při kapacitě linek dnešního internetu je i pro největší zpravodajské služby nereálné analyzovat obsah veškeré probíha jící komunikace. Naopak sběr a analýzu metadat je možné provádět i při velkém objemu provozu. Analýza metadat nám umožňuje zaměřit se (ve smyslu vybrat z mnoha existujících) na komunikaci konkrétních subjektů a sledovat dále podrobně její obsah. Tuto praxi běžně aplikují zpravodaj4

1. ÚVOD

ské služby, které mají přístup k velkému množství informačních kanálů a mohou tak těžit dodatečné informace z agregace dat. V době nastupující informační společnosti a korelace všech digitálních zařízení se nejedná jen o metadata internetového provozu, ale například i o záznamy o uskutečně ných telefonických hovorech, informace o registracích mobilních telefonů k dané BTS (Base Transceiver Station — u technologie GSM stanice pokrý vající signálem danou geografickou oblast). Z těchto údajů lze například zjistit, kdy, kdo, jakým způsobem, jak dlouho komunikoval a kde se při tom pohyboval. Proto může být v mnoha případech analýza metadat důležitěj ším zdrojem informací než samotný obsah dat. Potvrzením těchto tvrzení a dokladem důležitosti analýzy metadat je například aktuální rozprava or gánů Evropské unie o uzákonění povinné doby uchovávání metadat pro telekomunikační operátory na evropském trhu nebo usnesení Rady Ev ropy o kriminalitě v kyberprostoru[18] podepsané 38 státy. Toto usnesení obsahuje mimo jiné: „...nutnost pro operátory v rámci jejich technických možností shromažďovat nebo ukládat pomocí technických prostředků data o provozu a spolupracovat s kompetentními orgány na sběru nebo nahrá vání těchto dat." Informace o síťovém provozu mají úzký vztah k mnoha sociálním aspek tům našeho života — metadata elektronických bankovních operací, GSM lokační informace, kde, kdy a kdo se s kým stýká, seznam navštívených web. stránek, logy mailserveru, apod. Je zřejmé, že svým jednáním za sebou za necháváme digitální stopu, a jedním ze způsobů shromažďování takových informací je právě analýza síťového provozu. V mé diplomové práci se nebudu zabývat personifikací metadat ani vyu žíváním metadat ke sledování osob nebo počítačů. Budu se věnovat využití sledování síťového provozu pro zabezpečení systémů výpočetní techniky. Sledování síťového provozu má za úkol odhalit nezvyklé, nebezpečné nebo zakázané činnosti a pak na ně odpovídajícím způsobem reagovat. V teo retické části se zaměříme na popis dostupných technik detekce a reakce. V praktické části budeme diskutovat nasazení existujících opensource pro gramů pro analýzu síť provozu v akademické síti Masarykovy univerzity (MU) a aktuálně používaná řešení. Nakonec popíšeme implementaci jed noduchého programu určeného k detekci anomálií pro potřeby sekce ma tematiky Přírodovědecké fakulty MU. Veškeré faktické poznatky ohledně síťového provozu a jeho analýzy uvedené v mé diplomové práci jsou brány v kontextu sítě internet a v rámci prokolů v této síti používaných.

5

Kapitola 2

Úvod do problematiky 2.1

OSI model

Abychom si uměli lépe představit, o čem se budeme dále bavit, připo meňme si krátce OSI model (Open Systems Interconnection, h t t p : / / e n . w i k i p e d i a . o r g / w i k i / O s i _ m o d e l ) . Jedná se o abstraktní popis modelu pro návrh síťových protokolů. Skládá se ze 7 vrstev (viz obrázek 2.1).

OSI Model Data Data L

Data

10 J IB

Data

0 I

Segments] Packets u

^ f \ a n es

i

Bits

Layer Application Network Process to Application

Presentation Data Representation and Encryption

Session Inlerhost Communication

Transport End-to-End Connections and Reliability

Network Path Determination and IP (Logical Addressing)

Data Link

MAC and LLC (Physical addressing)

Physical Media. Signal, and Binary Transmission

Obrázek 2.1: 7 vrstevný OSI model 6

2. ÚVOD DO PROBLEMATIKY

Každá vrstva zajišťuje služby pro nadřazenou vrstvu. Proto například při vývoji nového síťového rozhraní stačí napsat příslušné ovladače pro 1. vrstvu OSI modelu a z toho vyplývá bezproblémový provoz této sí ťové karty při použití jakéhokoliv protokolu vyšších vrstev. Každý paket se skládá z hlavičky, kterou tvoří metadata protokolu, a datového obsahu. Z předchozích 2 faktů vyplývá jednoduchý mechanizmus zapouzdření pro tokolů vyšších vrstev. Konkrétní příklad si ukážeme na zapouzdření UDP paketu v IP paketu s popisem služeb jednotlivých vrstev OSI modelu.

UDP header IP header Frame header

Data

Application layer

UDP data

Transport layer Network layer

IP data Frame data

Frame trailer

Data link layer

Obrázek 2.2: Zapouzdření UDP paketu

Abychom věděli, s jakými metadaty soudobá analýza provozu, ať již softwarová nebo hardwarová, na internetu pracuje, představíme si síťové protokoly 3. vrstvy OSI modelu IP (Internet Protocol) a ICMP (Internet Con trol Message Protocol) a transportní protokoly 4. vrstvy TCP (Transmission Control Protocol) a UDP (User Datagram Protocol), s nimiž se na internetu setkáme nejčastěji. V současné době internet stojí na síťové vrstvě na „Internet Protokolu" verze 4 (IPv4, RFC 791 [2]) a v budoucnu se očekává postupný přechod k IP verze 6 (IPv6, RFC 2460 [2]). Podívejme se blíže na protokol IPv4, abychom věděli, z jakých dat bu deme vycházet při sledování provozu. U jednotlivých protokolů zmíním i nejznámější techniky skenování portů, které těchto protokolů využívají. Veškeré skenovací techniky vychází z chování počítačů v síti, které je defi nované příslušným RFC. Z pohledu obrany před těmito technikami pro nás není až tak důležité, aby námi chráněné počítače reagovaly dle definic RFC, 7


ale aby IDS (Intrusion Detection System — systém pro detekci průniku a jiných anomálií) reagoval shodně jako chráněné počítače. Jednotlivé skenovací techniky se liší používanými protokoly, úrovní oprávnění v operačním systému nutným pro provedení skenu a také (ne)snadností detekce, což je pro nás z hlediska detekce a obrany nejvýznamnější. 2.2

Protokol IPv4

Internet Protokol je datově orientovaný protokol pro komunikaci přes síť s přepínáním paketů (packet-switched networks). IP je protokol síťové vrstvy a je zapouzdřen do protokolu datové vrstvy (např. ethernet, wifi, tokenring). Oproti sítím s přepínáním okruhů (public switched networks) se cesta sítí neustanovuje před začátkem přenosu, ale jednotlivé pakety si hledají v sítí svoji cestu k cíli. IP je „best-effort" služba, tzn. neručí za doručení pa ketů, za přeposlání poškozených paketů, za doručení paketů ve správném pořadí, za znovusložení fragmentovaných paketů, neřeší duplicity obdr žených paketů atd. Jedinou kontrolu obdrženého paketu, kterou nám IP poskytuje, je kontrolní součet (checksum) hlavičky IP paketu. IPstack1 pa kety se špatným kontrolním součtem automaticky zahazuje bez notifikace odesílateli. Pro mapování IP adres a MAC (Media Access Control) adres datové vrstvy slouží Address Resolution Protocol (ARP, RFC 826[2]). Pro ilustraci si ukážeme, jak vypadá struktura IP paketu. 0

1

2

3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 |Version| | |

IHL

I Type of S e r v i c e |

Identification Time t o L i v e |

|Flags|

Protocol

|

T o t a l Length Fragment O f f s e t Header Checksum

| | |

|

Source Address

|

|

D e s t i n a t i o n Address

|

|

Options

|

Padding

|

Obrázek 2.3: Struktura IP paketu 1. IPstack — zásobník jádra operačního systému pro IP pakety, tzn. i pro pakety vyšších vrstev nad IP

8


2.2.1 Atributy Atributy hlavičky IP paketu, které IPstack ověřuje na správnou velikost a obsah Verze — verze IP protokolu. Délka hlavičky (IHL) — velikost hlavičky v 32bitových slovech. Typ služby — popis charakteru provozované služby (vysoký průtok, vysoká spolehlivost, nízké zpoždění...). Celková velikost — celková velikost paketu ve slovech (osmice bitů). Identifikační číslo — pomáhá při znovusestavení fragmentovaného paketu. Příznaky — různé kontrolní příznaky, viz RFC 791. Fragment offset — označuje pozici fragmentu v paketu. Kontrolní součet hlavičky (checksum) — jelikož se některé atributy paketu při jeho cestě sítí mění (např. TTL), přepočítává se kontrolní součet na každém uzlu, který paket zpracovává. Atributy významné pro analýzu provozu Time To Live (TTL) — indikuje maximální životnost paketu. TTL nastavuje odesílatel paketu, každý router snižuje hodnotu TTL o 1. Pokud hodnota TTL klesne na 0 předtím, než paket dojde do cílové destinace, je paket auto maticky zahozen. Následně je odesílateli odeslána ICMP zpráva Time t o l i v e e x c e e d e d . TTL slouží jako ochrana před zahlcením sítě pakety po hybujícími se sítí v cyklech. Protokol — protokol vyšší vrstvy. Zdrojová a cílová adresa — zdrojová a cílová IP adresa. Kontrolní součet hlavičky (checksum) — jedná se o lóbitový jedničkový dopl něk součtu (při kterém se používá jedničkový doplněk) všech lóbitových slov v hlavičce. Pro výpočet kontrolního součtu se do pole kontrolního součtu zadává 0.

2.3

N o v é aspekty analýzy provozu v IPv6

Jelikož se chci zabývat sledováním provozu na IPv4 síti, uvedu pouze ně kolik hlavních vlastností IPv6, které přímo ovlivňují sledování a analýzu provozu v této síti. 9


Z hlediska sledování provozu se stávají rozdíly mezi IPv6 a IPv4 více zřetelnými, zavedení IPv6 přináší do sledování nové vlastnoti i problémy:

1. Integrovaný IPsec — jak víme v IPv6 je implementován standard IPsec (IP security[l]). IPsec se skládá ze sady kryptografických prokolů, které na síťové vrstvě zajišťují zabezpečení toku paketů a ustanovení šifrovacího klíče/klíčů. Základními protokoly IPsecu jsou: Encapsu lating Security Payload (ESP), který zajišťuje autentizaci, důvěrnost a integritu toku a Authentication Header (AH) zajišťující autentifikaci a integritu toku. ESP se používá převážně k šifrování obsahu paketu, AH k zajištění integrity Mechanizmy AH i ESP mohou být použity samostatně nebo společně. V každém případě bychom neměli zapo mínat na fakt, že žádný z nich nechrání před analýzou provozu. Nevýhodou je, že při použití šifrování IPv6 paketů je funkce IDS silně omezena. Hledání šifrovaných vzorků v obsahu šifrovaných paketů je značně neefektivní. Návrhy možných řešení jsou pouze teoretické a pravděpodobně se své implementace nedočkají. Jedná se o: (a) Sdílení šifrovacího klíče se serverem, což by mělo IDS umož nit analýzu toku v reálném čase. V případě webserveru by to znamenalo sdílení klíče každého připojeného klienta a to je při výpočetní síle IDS nereálné. Představme si situaci, kdy by měl IDS dešifrovat obsah stovek až tisíců konkurentních připojení k webserveru a k tomu nad každým dešifrovaným paketem pro vádět analýzu jeho obsahu a zároveň v širším pohledu hledat anomálie všech protokolů použitých v toku. Takové množství operací nelze provádět se stávajícím veřejně dostupným hard warem v reálném čase. Úplně pominu situaci, kdy by měl IDS měnit některé atributy paketů jako reakce na zjištěnou anomálii. Pak by musel každý podezřelý paket ještě navíc znovu zašifro vat. (b) Ukládání šifrovacích klíčů na serveru umožňující zpětné dešif rování a analýzu odchycených paketů. 2. Velikost adresního prostoru — obrovská velikost adresního prostoru IPv6 sama o sobě významně ztěžuje širokoplošné skenování sítě. Ačkoliv při použití tradičního IPv4 modelu přiřazování adresního prostoru (IPv6 již nezná žádné třídy adresního prostoru) a přidě lování jeho spojitých částí je skenování sítí možné. Stejný problém 10


může způsobit používání odhadnutelných adres např. pro routery — (v IPv4 většinou IP adresa x.x.x.l). 3. (Automatické) tunely přechodu mezi IPv6 a IPv4[16] — (automatické) tunely přechodu umožňují provozovat IPv6 stroje v IPv4 sítích bez nutnosti mít přímo spojené IPv6 routery, popř. úplně bez provozo vání IPv6 routerů. Kompromitované stroje (s podporou IPv6) v IPv4 síti pak může útočník využít k budování tunelů pro IPv6 provoz bez nutnosti měnit cokoliv v infrastruktuře routerů a firewallů. Problém nastává, pokud firewall a IDS nepodporují IPv6 provoz, aťjiž nativní nebo přes různé tunely a metody zapouzdření. Takový provoz vů bec nedetekují nebo ho v lepším případě nejsou schopny analyzovat. Mezi nejrozšířenější tunelovací protokoly nad protokolem TCP patří 6to4 (RFC 3056,2893,3068 a 3964) pro automatické tunely — fungují podobně jako IPv6 routery — a SIT (Simple Internet Transition nebo Six In Tunnel). Oba protokoly jednoduše poznáme podle čísla IP proto kolu 41 a můžeme tunelování blokovat. Detekce tunelování IPv6 nad prokolem UDP při využití standardu Teredo (RFC 4380) vyžaduje sledování UDP paketu se zdrojovým portem 3544. Jelikož standard Teredo není zatím kompletně nadefinován, není jeho provoz příliš rozšířen. 4. Monitorování IPv6 protokolů (RFC 2461) na linkové vrstvě — IDS by měly detekovat broadcasty routovacích informací (Router Advertise ments) a protokoly pro zjišťování výskytu dalších počítačů na síťovém segmentu (Neighbor Discovery). 5. Přečíslování podsítě — v IPv6 lze jednoduše změnit prefix sítě v sí ťové adrese všech počítačů na síťovém segmentu přes broadcastové vysílání routerů. Pro paketový firewall a IDS je netriviální aplikovat změny ve filtrovacích pravidlech v reálném čase a udržovat si historii prefixů. 2.4

Protokol ICMP

Internet Control Message Protocol (ICMP, RFC 792[2]) slouží k posílání chy bových hlášení vztahujících se k IP toku, například o nedostupnosti služby, počítače nebo routerů. ICMP zprávy nemají zajistit spolehlivost (doručitelnost) IP protokolu. Z důvodu nekonečné smyčky ICMP zpráv se neposílají žádné ICMP zprávy o ICMP zprávách. ICMP zprávy jsou typicky genero vány jako odpověd při chybě v IP toku (RFC 1122) nebo pro diagnostické 11


účely. ICMP je označován jako protokol síťové vrstvy (jako IP), ale v pod statě je zapouzdřen a přenášen v síti IP protokolem jako transportní proto kol. Svým chováním se však od protokolů TCP a UDP liší v tom, že ho síťové aplikace samy nepoužívají. Jedinou aplikací používající protokol ICMP je p i n g , který posílá ICMP zprávu Echo R e q u e s t a čeká na obdržení ICMP zprávy Echo R e s p o n s e , ze které pozná, zda je počítač na síti dosažitelný a jak dlouho trvá paketu cesta k cílové destinaci a zpět. Pro příklad uvádím struktury 2 ICMP paketů: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | - I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I -

|

I n t e r n e t Header + 64 b i t s of O r i g i n a l D a t a Datagram

Obrázek 2.4: ICMP zpráva D e s t i n a t i o n

0

1

|

Unreachable

2

3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | | |

Type

| Identifier

Code

| |

Checksum S e q u e n c e Number

| |

Data) . . .

Obrázek 2.5:

ICMP zpráva Echo r e q u e s t nebo Echo r e p l y

2.4.1 Atributy Typ (type) — typ ICMP zprávy ( D e s t i n a t i o n u n r e a c h a b l e , Time e x c e e d e d , Echo r e q u e s t , Echo r e p l y . . . ) . Kód (code) — druh zprávy daného typu. Kontrolní součet (checksum) — kontrolní součet hlavičky ICMP zprávy. Pro výpočet se používá checksum rovný 0. Jedná se o lóbitový jedničkový do plněk součtu (při kterém se používá jedničkový doplněk) všech lóbitových 12


slov v hlavičce. Další atributy, v příkladech výše IP hlavička + 64 bitů původního paketu, identifikátor a sekvenční číslo jsou specifické pro daný typ ICMP zprávy. U zpráv Echo r e q u e s t a Echo r e p l y slouží identifikátor a sekvenční číslo k jejich párování. 2.5

Protokol TCP

Transmission Control Protocol (TCP) je transportní protokol, který posky tuje spolehlivé doručení dat ve správném pořadí. Aplikace posílají proudy bytů TCPstacku 1 pro přenos přes síť. Tyto proudy jsou rozděleny do seg mentů (obvykle podle hodnoty MTU— Maximum T r a n s m i s s i o n U n i t ) . Takto připravené pakety jsou předány IP protokolu pro doručení. Na roz díl od protokolu UDP, kdy mohou být pakety okamžitě odeslány, vyžaduje TCP ustanovení spojení před začátkem přenosu dat a uzavření spojení po jeho skončení. 2.5.1 Fáze TCP spojení TCP spojení má 3 hlavní fáze: 1. Navázání spojení — TCP navazuje spojení ve 3 fázích tzv. 3-cestným potřesením ruky (3-way handshake): (a) účastník komunikace A pošle účastníku B paket se SYN přízna kem se sekvenčním číslem X, (b) B odpovídá posláním paketu s příznakem SYN se sekvenčním číslem Y a zároveň ACK se sekvenčním číslem X+l, kterým po tvrzuje přijetí úvodního SYN paketu, (c) nakonec A potvrzuje obdržení paketu od B paketem s ACK příznakem a sekvenčním číslem Y+l. 2. Přenos dat — oproti UDP zaručuje TCP: (a) bezchybný přenos dat, (b) zpracování paketů ve správném pořadí, (c) přeposlání ztracených paketů, (d) vyřazení duplicitních paketů ze zpracování, (e) kontrolu zahlcení. 13


Pro přenos každého bajtu musí být zvýšeno sekvenční číslo o 1. Ve skutečnosti je sekvenční číslo přiřazeno pouze prvnímu bajtu a příjemce paketu potvrzuje přijetí dat sekvenčním číslem zvýšeným o počet přijatých bajtů, tzn. pokud si zvolíme sekvenční číslo rovné 200, přenáším 20 bajtů a data obdrží příjemce bez problémů, potvrdí příjem bajtů 200 až 220 ACK paketem se sekvenčním číslem 221 (= sekvenční číslo paketu, jehož přijetí dále očekává). Odpověď ACK pa ketem se sekvenčním číslem např. 205 signalizuje správné přijetí bajtů 200 až 204. Sekvenční čísla a jejich potvrzování řeší problém duplicit ních obdržených paketů, přeposlání ztracených paketů a zpracování paketů ve správném pořadí. Pro zajištění korektnosti doručených paketů se používá kontrolní součet v hlavičce paketu (podrobněji popsáno níže v této kapitole).

Ukončení spojení — ukončení spojení je možné provést ve 3 nebo více krocích, záleží na stavu spojení. Nejčastěji dochází k 3-fázovému ukončení spojení, kdy účastník komunikace A posílá účastníku B F IN paket, B odpovídá FIN+ACK paketem a A ukončuje spojení potvrzu jícím ACK paketem.

Na následujícím obrázku vidíme zjednodušený stavový diagram TCP spoiení. 14


CONNEŮTJSYN

n f » r I-ny-Ludahil*]

(Stirt) LISTENE SYNŮYN+ACK

(St-p ľ aí t l i

l-.iy-haed.liar*

— • Client/^rBCLBvar path —• Sonder^ssrvar path

SYN RECEIVED

ŮYtifSvM+ACK ( G i r a u l t a t i c o u s

opon)

SYN SENT

Data exchange o c c u r s ~ *

ESTABLISHED

|*

;.

..„

. -^rv-Ka;.1 kjLaj:«

'* P a s s i v e

A c t i v e Open FIN/ACK ~*|

CLOSING

I

FIN+ŕCKÍňCK

^3

[9o back t c s t a r t )

TIMED WATT

CLOSED

i«

Obrázek 2.6: Stavový diagram TCP spojení

2.5.2 Vlastnosti TCP Pro lepší pochopení některých technik spojených s analýzou provozu a obcházením nástrojů pro analýzu si zadefinujeme několik vlastností TCP. Velikost okna TCP Velikost TCP okna označuje množství dat, která mohou být odeslána před tím, než odesílatel obdrží potvrzení o přijetí paketů od příjemce. Velikost okna se může v průběhu komunikace měnit. Velikost okna upravuje pří jemce paketů. Multiplexing — porty Aby bylo možné provozovat simultánně více síťových služeb nad TCP pro tokolem na jednom počítači, jednotlivé služby rozlišují jednotlivé pakety 15

2. ÚVOD DO PROBLEMATIKY podle čísla portu, které je součástí hlavičky TCP paketu. Číslo portu ve spojení s IP adresou tvoří soket. Pár soketů jednoznačně identifikuje každé síťové spojení.

Reset TCP spojení Kromě stavu, kdy je paket s RS T (reset) příznakem obdržený po odeslání úvodního SYN paketu, jsou všechny RS T pakety kontrolovány, zda jejich sekvenční číslo je uvnitř TCP okna. Pokud je RS T paket obdržený jako od pověď na odeslaný SYN paket, je pro přijetí RS T paketu nutné, aby měl zároveň správné potvrzovací číslo, (sekvenční číslo + velikost datové části předchozího SYN paketu, viz přenos dat v TCP). Příjemce RS T paketu po jeho ověření změní stav spojení. Pokud byla služba ve stavu „LISTEN" (čekala na připojení, stavy viz stavový diagram TCP), pak RS T paket igno ruje. Pokud byla ve stavu „SYN-RECEIVED" (po obdržení inicializačního SYN paketu) a její předchozí stav byl „LISTEN", pak se vrací do „LISTEN" stavu, jinak příjemce zruší spojení a jde do stavu „CLOSED" (uzavřený so ket). Pokud byl příjemce v jakémkoliv jiném stavu, pak zruší spojení a jde do stavu „CLOSED". 0

1

2

3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |

Source Port

|

Destination Port

Sequence Number

| |

| Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|5|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent P o i n t e r | | Options | Padding | |

data

|

Obrázek 2.7: Hlavička TCP paketu

16


2.5.3 Atributy Zdrojový port Cílový port Sekvenční číslo — sekvenční číslo má dvojí roli. Jestliže je nastaven příznak SYN, pak se jedná o inicializační sekvenční číslo a první bajt datové části je sekvenční číslo + 1. Pokud není nastaven SYN příznak, první bajt datové části je sekvenční číslo. Potvrzovací číslo — pokud je nastaven příznak ACK, pak je hodnota potvr zovacího čísla rovna sekvenčnímu číslu, které příjemce očekává jako další. Data offset — specifikuje velikost TCP hlavičky v 32bitových slovech a uka zuje na počátek datové části TCP paketu. Příznaky (nebo také kontrolní bity) — dle RFC 793[2] jsou validní pouze určité kombinace příznaků. Jednotlivé příznaky mohou být: URG — atribut „urgent pointer" se má brát v úvahu. ACK — pole s potvrzovacím číslem se má brát v úvahu. P S H — „push" funkce zajišťuje odeslání všech neodeslaných dat v TCP bu fferu. RS T — reset spojení. SYN — synchronizace sekvenčních čísel. FIN — oznámení, že odesílající nemá žádná další data. Window — množství dat v bajtech, které je potvrzováno najednou (velikost TCP okna). Checksum — kontrolní součet není povinný, pak je roven 0. Jinak se počítá z hlavičky a dat shodným způsobem jako u IPv4. Urgent pointer — údaj je platný, pouze pokud je nastaven příznak URG. Uka zatel do datové části, která obsahuje urgentní data. Options — nepovinné pole proměnné délky určené pro volitelné parametry TCP, parametr je používán např. pro indikaci maximální velikosti segmentu, kterou je přijímající strana schopna zpracovat. Padding — zarovnání hlavičky nulovými bity.

2.6

Protokol U D P

User Datagram Protocol (UDP, RFC 768[2]) je bezstavový protokol, který nezaručuje spolehlivé doručení ve správném pořadí. Pokud vyžadujete po UDP spolehlivost, musí ji zajistit vyšší vrstvy. UDP postrádá mechanizmus pro kontrolu zahlcení sítě, které vede k zahazování paketů. Oproti TCP je vhodný pro jednoduché aplikace, pro něž je důležité doručení paketů v ur17


čitém čase. Je vhodný pro servery/démony s krátkými dotazy z velkého množství klientů. Typickými službami běžícími na UDP prokolu je Do main Name System (DNS), streamovaná média, Voice over IP, Trivial File Transfer Protocol (TFTP), Network Time Protocol (NTP), Dynamic Host Configuration Protocol (DHCP) nebo Simple Network Management Pro tocol (SNMP). Stejně jako TCP umožňuje UDP multiplexování síťového provozu přes specifikaci portu. Port je lóbitové číslo (1 - 65535, Oje rezervo vaná) v hlavičce UDP paketu. Pro porty platí stejná pravidla pro rozdělení jako pro protokol TCP. 2.6.1 Atributy Struktura UDP paketu je následující: 0

| |

7 8

15

Source Port

1 |

16

| |

23 2 4

Destination Port

I Length

|

31

| |

I Checksum

|

I I

data octets ...

Obrázek 2.8: Struktura UDP hlavičky

Jednotlivé atributy mají stejný význam jako u protokolu TCP. Kontrolní součet se počítá shodným způsobem z hlavičky a datové časti paketu.

18

Kapitola 3

Techniky skenování portů Ukázali jsme si, jak vypadají metadata, která můžeme na síti sledovat. Teď si představíme několik nejznámějších technik skenování portů na dostupné služby. Jednotlivé techniky si krátce představíme podle protokolů, přes které jsou realizovány. 3.1

Techniky skenování přes protokol IP 1. Protokol sken — funguje podobně jako TCP SYN1 sken jen s tím roz dílem, že nemění číslo cílového portu, ale číslo IP protokolu. Vytvoří se paket s prázdnou hlavičkou a prázdným datovým obsahem, od povědí bude ICMP zpráva o nedosažitelném protokolu (typ 3, kód 2) v případě, že protokolem skenovaný stroj nekomunikuje, nebo libovolná odpověd v daném protokolu, když je protokol používán.

3.2

Techniky skenování přes protokol TCP 1. TCP SYN — často nazývána jako „polootevřené skenování", protože nikdy nedokončí navazování TCP spojení. Pošleme SYN paket, pokud na portu poslouchá nějaká služba, jako odpověd nám přijde SYN/ACK paket, pokud ne, tak RS T paket. Jedná se o velmi rychlou techniku (tisíce portů za sekundu). Jelikož nedojde nikdy k úplnému navázání spojení, tak je i relativně nenápadná. 2. TCP connect — využívá systémového volání c o n n e c t ( ) , které patří do Berkeley Sockets API. Connect se snaží navázat spojení na daný port. Pokud se dokončí 3-fázové „potřepání ruky", na portu poslou chá nějaká služba. V opačném případě pokus o spojení skončí vypr šením časového limitu, daný port je zavřený. 3. TCP Null, FIN, PSH, URG — dle RFC by měl TCPstack na každý paket, který neobsahuje SYN, RS T nebo ACK příznak, odpovědět 19

3. TECHNIKY SKENOVÁNÍ PORTŮ

RS T paketem, pokud je port zavřený, a neodpovědět vůbec, pokud je port otevřený Takový paket tedy musí mít kombinaci příznaků FIN, PSH, URG nebo nemít žádný příznak (příznak v hlavičce roven 0). Prakticky nemožné je odhalení této techniky na IDS a firewallech bez sledování stavu spojení. 4. TCP ACK—technika pro zjišťování filtrovacích pravidel na firewallu. Na paket s ACK příznakem bychom měli obdržet RS T paket, a to v případě, že je port otevřený i zavřený. 5. TCP FIN/ACK — dle RFC 793 by měla být odpověď na paket s FIN a ACK příznakem RS T paket. Některé *BSD systémy při otevřeném portu takové pakety pouze zahazují. 6. TCP Idle — TCP Idle sken je extrémně nenápadná technika skenování portů, která zároveň mapuje filtrovací pravidla firewallu z pohledu libovolné IP adresy. TCP Idle sken využívá identifikačního čísla v hla vičce IP paketu (IPID). Celá procedura se skládá ze 3 fází. V 1. fázi pošle útočník např. SYN/ACK paket na stroj, přes který budeme chtít provést skenování — „zombie". Jako odpověď by mu měl přijít RS T paket, ze kterého zjistí aktuální sekvenční číslo TCPstacku. V 2. fázi pošle útočník SYN paket na běžící službu na skenovaném stroji, tzn. legitimní požadavek na navázání spojení, s tím, že jako zdrojovou IP adresu uvede IP adresu zombie. Skenovaný stroj odpoví zombii podle 3-fázového potřesení ruky SYN/ACK paketem. Zombie však o žádné předchozí komunikaci neví, takže odpoví skenovanému stroji RS T paketem. Ve 3. fázi pak útočník znovu pomocí SYN/ACK paketu a po následné odpovědi RS T paketem zjistí aktuální sekvenční číslo TCPstacku zombie. Celý trik spočívá v tom, že pokud je port na skenovaném stroji otevřený, mělo by se sekvenční číslo TCPstacku zombie zvýšit o 2 (= reset SYN/ACK paketu od skenovaného stroje + reset SYN/ACK paketu při zjišťování sekvenčního čísla ve fázi 3). Pokud se sekvenční číslo zvýší pouze o 1, pak je port na skenova ném stroji pravděpodobně zavřený, protože ve fázi 2 odpověděl ske novaný stroj zombii RST paketem. Zjednodušeně celou proceduru popisuje následující obrázek.

20


step i: Chooze a "zombie" and probe for its current IP Identification (IP_D) nunber;

IPID Probe SYN IACK Packet " Response; IPID=31337 * RST Packet Step

2; Ocnd

forged

packet

"iron"

Zombie

to target.

Pro&e to OPEM port ÖC

Session Request "from" Z SYN to port SO; Src IP: Ž

Dehavinr

differs

OR

depending

on port

state

probe t o CL0SE0 p o r t «2

Session Request "from" Z SYN to port 42; Src IP: Ž

Bogus Session; IPID=31338 jtep

0; Probe Zonbic

A

IPID

again:

IPID Probe SYNIACK Response; IPID=31339 RST

IPID increased by Z since =tcp m , so port 80 on target nuat be open I

A IPID only

IPID Probe SYNIACK Response; IPID=3133S RST incre&aed

b y 1, port

42 1=

CLOSED!

Obrázek 3.1: Příklad Idle skenu[9] při otevřeném a zavřeném portu

3.2.1 Něco více o Idle skenu Idle sken umožňuje skenovat libovolný počítač bez nutnosti poslat z útoční kova PC jediný TCP paket s jeho skutečnou IP adresou. Při odhalení skeno vání IDS bude za zdroj útoku považován počítač zombie a ne pravý iniciátor skenu. Ještě nebezpečnější je útočníkova schopnost mapovat „síť důvěry" IP sítě, kdy může zkoušet přístupy z různých IP adres přes paketový fi rewall. Typickou chybou bývá přístup do interní sítě přes „důvěryhodnou" IP adresu a ne přes VPN. Následující tabulka ukazuje, jaké z testovaných operačních systémů mají špatnou implementaci tvorby identifikačních čísel IP paketů umožňující Idle sken:

21


Operační systém Linux 2.4 Linux 2.6.11 FreeBSD4.11 OpenBSD 3.6 Windows 2003 Server (build 5.2.3790) Windows 2000 Server (build 5.00.2195) Windows XP SP2 (5.1.2600), bez fw

slabý gen. sek. čísel ANO ANO ANO NE ANO ANO ANO

Obrázek 3.2: Příklady testovaných IPstacků na slabý generátor IPID

Dodejme, že Idle sken nemusí být útočníkem využit jen pro skenování portů, ale Idle sken je vhodný i pro odhalení aliasů IP adres, zjištění počtu počítačů při rozkládání zátěže a pro odhalení, s jakým z nich právě ko munikujeme nebo zjištění počtu strojů za NATem1. Jedním z nástrojů, který umí konstruovat pakety s různými příznaky a zobrazovat atributy přijatých paketů včetně sekvenčního čísla, je h p i n g 2 (www. h p i n g . org). 3.2.2 Obrana proti Idle skenu V případě podvržené zdrojové IP adresy nemáte prakticky šanci zjistit sku tečného původce paketů. Obrana před tímto typem útoku nějakou auto matickou reakcí vůči IP adrese zdroje není vůbec efektivní. Bohužel nejsme schopni nijak poznat, že se jedná právě o útok s podvrženou zdrojovou IP adresou. Jako zombie je vhodné použít stroj s žádným nebo minimál ním síťovým provozem a „vhodným" operačním systémem (viz tabulka výše) nebo zařízení, která mají podobné vlastnosti, např. síťové tiskárny, elektronické pokladny apod. Jedinou možností detekce Idle skenu je záplava skenovaného stroje SYN pakety ve 2. fázi skenování. U strojů s velkým sí ťovým provozem se posílají desítky až stovky SYN paketů na každý port skenovaného stroje, aby byla odpověď, zda je port otevřený nebo zavřený, co nejpravděpodobnější. Z makropohledu představuje jistou ochranu proti Idle skenu: •

vytvoření antispoof2 pravidel na firewallu,

1. Network Address Translation — technika transparentní úpravy zdrojové nebo cílové IP adresy. 2. Antispoof pravidla — pravidla omezující možnost podvržení zdrojové IP adresy (spo-

22


•

udržování stavových informací na firewallu,

•

provozování operačních systému s méně prediktivními IPID po sloupnostmi (OpenBSD, Solaris, Linux),

•

kontrola odchozího síťového provozu na podvržené zdrojové IP ad resy

3.3

Techniky skenování přes protokol U D P 1. UDP — vytvoří se prázdná UDP hlavička a pošle se na daný port. Pokud jako odpověď obdržíme ICMP zprávu o nedostupnosti portu (typ 3, kód 3), pak je port zavřený. Pokud nám služba odpoví UDP paketem, pak je port otevřený. Tento druh skenování je velmi ča sově náročný. Otevřené porty velmi často neodpovídají. V mnoha současných operačních systémech (např. Linux s kernelem 2.4.x) je implementován limit na ICMP zprávy o nedostupnosti portu, což zpomaluje odezvu v případě zavřeného portu, ale zachytit takový sken bývá vzhledem k jeho rozložení v čase náročné.

3.4

PortKnocking

3.4.1 Popis Samostatnou kapitolu tvoří technika zvaná PortKnocking. Neslouží ke skeno vání portů, ale jde o techniku vzdálené skryté autentizace po síti. PortKnoc king („klepání na porty") je metoda autentizace založená na otevření urči tého portu na vnější straně firewallu k povolení síťového provozu zasláním předem domluvené posloupnosti paketů. Po obdržení této sekvence paketů firewall dynamicky upraví svá filtr ovací pravidla tak, aby povolil komuni kaci se vzdáleným uzlem v síti. Analogicky je možné využít PortKnoc king pro uzavření otevřeného portu na firewallu po skončení relace — za předpokladu, že otevření portu nebylo limitováno časem. Na implementaci PortKnockingu nejsou kladena žádná omezení, může jít o sekvenci paketů různých protokolů i obsahu, o jediný specifický paket, s časovým omeze ním pro přijmutí paketů i bez něj, apod. Při použití knihoven, které umí číst přijatý paket rovnou ze síťového rozhraní (jako je např. libpcap)[21], není ani třeba vyčleňovat pro PortKnocking zvláštní porty, ale portknock ofing), např. blokace přijatých paketů se zdrojovou IP adresou z interní sítě na rozhraní s externí sítí.

23


může směřovat i na otevřené porty, na kterých poslouchá nějaká služba. PortKnocking není vhodný pro veřejné služby jako jsou HTTP nebo SMTP, ale neveřejným službám poskytne na vyžádání filtrování na základě IP adresy bez omezení, která jsou obvykle spojena s údržbou IP filtrovacích pravidel. V případě jednorázového přístupu ke službě dostupné v interní síti zvenčí není potřeba provádět změny v nastavení filtrování paketů na firewallu a tyto změny po skončení práce manuálně vracet zpět. 3.4.2 Výhody PortKnockingu •

Nenápadná metoda autentizace a komunikace s počítačem, který má všechny porty zavřené. Implementace PortKnockingu jsou stavové, ale klient nemá v průběhu autentizace žádnou odezvu a až na konci sekvence paketů zjistí, zda byl úspěšně autentizován nebo ne. V tom případě ale neví, v jakém stavu udělal chybu.

•

I přes teoretickou možnost odposlechu provozu není pro útočníka prakticky možné zjistit, zda daný počítač v síti používá PortKnocking. Útok brutální silou je velmi neefektivní. Při posloupnosti 3 portů pro PortKnocking nám vychází 46908201271295 možných kombinací, a to bereme v úvahu pakety lišící se pouze v čísle cílového portu a po míjíme nutnost skenovat všechny porty po každém pokusu. Takový útok hrubou silou je velmi nápadný.

•

Autentizaci přes Portknocking zajišťuje zvláštní aplikace (klient-server), není nutné modifikovat stávající programy.

3.4.3 Nevýhody PortKnockingu •

PortKnocking klient (aplikace pro poslání autentizační sekvence pa ketů) musí být uchován v bezpečí jako např. heslo.

•

Nutnost nosit s sebou PortKnocking klient, např. na USB flashdisku.

Návrhy moderních systémů pro PortKnocking počítají s použitím hašovacích funkcí3 místo posloupnosti portů, aby tak zabránily sledování síťového provozu a opětovnému přehrání odchycených paketů. Zdrojová IP adresa, aktuální čas nebo jiný údaj může sloužit jako vstup pro hašovací funkci. Pokud PortKnocking server použije z příchozího paketu shodné atributy jako klient a zná hašovací funkci, vypočítá si haš těchto hodnot a 3.

Hašovací funkce — funkce, která ze vstupu libovolné délky vytvoří řetězec pevné délky.

24


porovná ho s přijatým hašem od klienta. Pokud jsou haše shodné, klient je autentizován. PortKnocking poskytuje dodatečnou bezpečnostní vrstvu při neznatelném zatížení sítě a procesoru. V nejhorším možném případě, kdy útočník zná posloupnost paketů pro PortKnocking, se uplatňují autentizační a přístupové mechanizmy, jako kdyby PortKnocking nebyl vůbec používán. Analýza síťového provozu nám neslouží pouze pro optimalizaci síťo vého provozu a hledání problémů v síti, ale může přímo sloužit jako jedna z fází útoku na operační systém a služby jím poskytované. Proto byly vyvi nuty systémy pro detekci a prevenci útoků — intrusion detection/prevention system (IDS/IPS), jejichž hlavním úkolem je zpětně nebo v reálném čase analyzovat síťový provoz a reagovat na podezřelý provoz. Síťový provoz musíme tedy někde zachytávat, a ť u ž ho budeme chtít zpracovávat v reál ném čase nebo zpětně z logu. Pokud budeme chtít analyzovat síťový provoz v reálném čase a zároveň provádět filtrování provozu, tzn. aby se nežá doucí provoz do sítě za NIDS vůbec nedostal, musíme odchytávat provoz „in-line" před routerem nebo firewallem naší sítě, popř. přímo na firewallu nebo routeru. Takové umístění má několik výhod: •

možnost filtrovat provoz na nežádoucí obsah před vstupem do naší sítě,

•

viditelnost veškerého firewallem nebo routerem nezměněného pro vozu,

•

možný provoz v bridge-módu 4 .

4. Bridge-mód — provoz na datové vrstvě, síťové rozhraní přijímá všechny ethernetové rámce, zařízení nemá přiřazenou IP adresu, neroutuje pakety.

25

Kapitola 4

Topologické možnosti sledování provozu O IDS si povíme více dále v textu, proto se nyní spokojím pouze s tvrze ním, že skutečně komplexní řešení analýzy provozu se skládá jak z IDS provozovaného in-line, tak IDS uvnitř naší sítě za perimetrem firewallu. Při sledování provozu in-line můžeme analyzovat provoz na firewallu ještě předtím, než projde paket filtrováním nebo na zvláštním stroji představe ném před firewallem. Z důvodu zajištění co největší spolehlivosti a integrity firewallu není žádoucí provozovat na firewallu jakékoliv další aplikace, které by mohly mít vliv na funkčnost a zátěž celého stroje. Pro lepší po chopení problému s umístněním IDS do síťové infrastruktury si nejdříve popišme rozdíl mezi přepínaným a sdíleným médiem. Sdílené médium znamená, že celkovou propustnost sdílí všichni uživa telé. Proto např. 16 portový lOOMbitový hub poskytne teoreticky každému připojenému zařízení 100Mbps/16 zařízení = 6,25Mbps průměrný datový tok na zařízení (za předpokladu, že každé zařízení generuje konstantně shodný objem provozu). Dnešní provoz není ani konstantní ani konzis tentní a kolize 1 na síti snižují propustnost pod 6,25Mbps, což je podstatně méně než je schopna lOOMbitová linka přenést. Přepínaná síť má dediko vanou šířku pásma pro každého uživatele. 16 portový lOOMbitový switch bude plně využívat lOOMbitový datový tok nehledě na hustotu síťového provozu. Jelikož médium není všemi zařízeními sdíleno, nedochází ke ko lizím a prakticky dosažitelná rychlost se blíží teoretické. Odposlouchávat provoz na sdíleném médiu je tedy jednodušší, stačí připojit IDS k hubu a přes síťovou kartu v „promiskuitním módu" 2 můžeme odchytávat veškerý provoz na hubu. V přepínané síti existují 3 hlavní způsoby, jak odchytávat provoz — Tap zařízení, huby a span porty.

1. Při poslání paketu na port hubu, pošle hub tento paket na všechny ostatní porty. Jestliže 2 zařízení pošlou paket ve shodný čas, jejich pakety kolidují a oba pakety musí být přeposlány. 2. Promiskuitní mód — síťová karta poslouchá na médiu všechny ethernet rámce, nejen ty s vlastní ethernetovou adresou.

26

4. TOPOLOGICKÉ MOŽNOSTI SLEDOVÁNÍ PROVOZU

4.1

Span port

Switch Port ANalyzer (SPAN) port je typicky využíván pro odchytávání provozu za účelem monitorování síťového provozu. Jedná se o port na swiť chi nakonfigurovaný tak, aby kopíroval odchozí/příchozí data/oba kanály z jednoho nebo více portů na určený port. Výhody tohoto řešení: •

jednoduchost instalace — pouze nastavení switche,

•

správa IDS nevyžaduje žádný dodatečný hardware, IDS je přístupný přes span port stejně jako kdyby byl připojený k libovolnému jinému portu,

•

odchozí provoz přes span port bez omezení—možnost rekonfigurace firewallu, ukončení podezřelého toku apod.

Nevýhody: •

možnost provozovat pouze 1 span port na switchi — pro monito rování více než jednoho portu je nutné nadefinovat interval portů, který má tvořit span port, například provoz na switchi na portech 1 - 4 bude sveden do portu 5,

•

při svedení provozu více portů do span portu může rychle objem provozu převýšit datovou propustnost span portu, zvlášť při moni torování plně duplexního provozu,

•

IDS je na síti lehce dostupný a může se stát cílem útoku (možné řešení ve správě IDS přes další rozhraní — sériový port, další síťová karta, lokální terminál),

•

některé span porty podporují pouze jednosměrný provoz, což zne možňuje IDS používat span port pro reakce na incident,

•

nelze do span portu kopírovat některé chybné pakety jako například příliš velké nebo příliš malé pakety, pakety se špatným kontrolním součtem apod.

27


s a n Port

P

ĚŠSH Swítch

IDS

Steft

dard Connection Resource

Obrázek 4.1: Zapojení IDS přes span port

4.2

Hub

Hub (nebo také rozbočovač) se pro sdílení provozu na síti vkládá větši nou v síťové topologii mezi 2 switche, router a switch, server a switch apod. Jelikož dnešním standardem v LAN (Local Area Network) je plně duplexní lOOMbps a pomalu se přechází ke gigabitu, není řešení s hubem vhodné. Z konstrukce hubu vyplývá omezení na poloduplexní provoz, což významně degraduje propustnost LAN. Výhody používání hubu: •

jednoduchá instalace,

•

správa IDS nevyžaduje žádný dodatečný hardware,

•

odchozí provoz přes span port bez omezení—možnost rekonfigurace firewallu, ukončení podezřelého toku apod.,

•

velmi nízká pořizovací cena hubu.

Nevýhody: •

degradace propustnosti sítě na poloduplexní provoz,

•

provoz generovaný správou IDS může způsobit další kolize paketů a tím degradaci propustnosti sítě.

28


| PDP gPPDPBDPBT

Switch

Hub

Resource Obrázek 4.2: Zapojení IDS přes hub

4.3

Tap zařízení

Použití hubu nebo Tap zařízení je velmi podobné. Tap je jakýsi jednosměrný rozbočovač síťového provozu. Hub i Tap zařízení se umísťují mezi uzly, je jichž komunikace má být sledována. Návrh Tap zařízení je „fault tolerant" (odolný proti výpadku/chybě), proto ani při jejich poruše nedojde k pře rušení spojení mezi komunikujícími uzly. Příklad návrhu pasivního Tap zařízení (nevyžaduje napájení elektrickým proudem) viz příloha A. Jednot livá Tap zařízení se odlišují pouze počtem výstupních portů. Výhody používání Tap: •

Tap nevyžaduje žádné napájení elektrickým proudem, jeho vnitřní zapojení je neměnné,

•

Tap nijak neovlivňuje síťovou infrastrukturu a síťový provoz,

•

Tap zabraňuje uživatelům v připojení k IDS,

•

přeposílá chybné pakety (špatná velikost, chybný kontrolní součet paketu apod.) IDS.

Nevýhody: •

Tap zařízení mohou být drahá,

•

jelikož umožňují pouze jednosměrný provoz, nepodporují reakce IDS (přes 1 Tap zařízení), 29


neumí skládat oba směry komunikace, je potřeba dodatečný hard ware nebo software.

í

TBPTHTiBTlt

Switch

Ch Tap

1 BBJ Resource

Obrázek 4.3: Zapojení IDS přes Tap zařízení

Přenosové rychlosti sítí rostou rychleji než rychlost procesorů, a tak cen tralizované řešení již dosáhlo svého výkonnostního stropu. Zvlášť to platí pro stavovou analýzu provozu ve více síťových vrstvách. Hub je nepouži telný v plně duplexních sítích, na switchích chybí možnost definovat více než jeden span port a výstupem Tap zařízení jsou 2 porty (1 s odchozím a l s příchozím provozem), které není možno dále škálovat. Existují zde 2 hlavní směry vývoje a výzkumu, jak daný problém řešit: 1. integrace kontroly provozu do switche — touto cestou se vydala hlavně firma Cisco, která vyrábí rozšiřující kartu pro své switche řady 6000. Karta bez snížení propustnosti switche kontroluje provoz na známé vzorky útoků do rychlosti 200 Mbps v plně duplexním režimu. Omezení na propustnost je dáno především výpočetním výkonem karty, proto má i svůj teoretický výkonnostní strop. V současné době například není dostupný hardware pro kontrolu provozu v reálném čase pro 48 Gigabitovych portů. I přesto kontrola provozu přímo na switchi obchází mnoho omezení v návrhu a implementaci tradičních IDS. 2. přepínání toku — firmy jako TopLayer Networks, Arrowpoint, Al teon nebo Foundry vyvíjí zařízení na zcela odlišném principu. Ne řeší analýzu provozu na vysokorychlostních sítích hrubou silou (jako 30


např. Cisco), ale rozkládáním provozu, který je analyzován po čás tech. Pokud bychom rozdělovali provoz náhodně, nemusely by mít senzory dostatek dat pro detekci incidentu, protože by různé části datového toku mohly být rozděleny do různých částí. Proto mají switche s přepínáním toku navíc implementovánu: (a) Schopnost definovat více než 1 span port. (b) Schopnost rozkládat zátěž z tap zařízení do více span portů — sledováním toku jako oboustranného provozu, kdy se z před chozího paketu určuje směrování následujícího paketu. Mů žeme tak rozkládat např. gigabitový provoz na 10 lOOMbitových portů. Zaručení koherence rozdělování provozu na dané porty je nutná podmínka korektní analýzy více IDS. Takové roz dělování umožňuje detekovat útoky prováděné ve více krocích v rámci jednoho toku. Skupina vědců prezentovala ve svém článku[15] návrh, implementaci a vý sledky experimentálního provozu softwarového distribuovaného síťového IDS s rozkládáním síťového provozu a přepínáním toku. Řekli jsme si, jak vypadají metadata síťového provozu, který chceme sledovat, a kde ho můžeme sledovat. Zbývá nám vysvětlit, jak k takovým datům přistupovat, a kde se skrývají objektivní problémy s jejich analýzou. Tuto úlohu by měly vykonávat IDS, proto si představíme teoretické principy, na kterých současné IDS pracují, ukážeme si jejich silné i slabé stránky.

31

Kapitola 5

Intrusion Detection/Prevention System 5.1

Úvod do IDS

Počet počítačových útoků rok od roku dramaticky roste. V roce 2000 bylo organizaci CERT Coordination Center (CERT/CC) 1 ohlášeno 21756 bez pečnostních incidentů. V roce 2003 jich bylo již 137529. Od roku 2004 se ČERT rozhodl nadále neuveřejňovat počet bezpečnostních incidentů, pro tože útoky se staly tak běžnou věcí, že údaje o jejich počtu se nedaly použít k odhadům o jejich rozsahu a dopadu 2 . Narůstající rychlost útoků na výpo četní a komunikační systémy si vyžaduje úměrně rychlé reakce na takové útoky. Proti naskriptovaným neinteraktivním útokům pomocí exploitů nebo proti akcím různého malwaru je prakticky nemožné okamžitě osobně za sáhnout a je potřeba přemýšlet o přístupu automatické reakce na incident. Jelikož se má diplomová práce věnuje analýze síťového provozu, omezím se nadále na diskusi systémů pro detekci a prevenci průniků založených na analýze síťového provozu (Network based Intrusion Detection System — NIDS). NIDS má oproti IDS zaměřeným na analýzu informací dostupných na konkrétním počítači (Host based Intrusion Detection System 3 , dále jen HIDS) několik charakteristických vlastností: •

Detekce a reakce v reálném čase — oproti analýze zpráv z logu, NIDS rozpoznají probíhající útok a dokáží na něj okamžitě reagovat.

•

Nezávislost na operačním systému — HIDS jsou programy psané pro konkrétní operační systém, NIDS může fungovat na síti transpa rentně nazávisle na ostatních zařízeních v síti.

1. CERT/CC byl prvním týmem zabývající se bezpečnostními incidenty a reakcemi na ně. ČERT je registrovaná známka Carnegie Mellon University.

2.

http://www.cert.org/stats/

3. HIDS používají informace z lokálně uložených logů (i přijatých z jiných počítačů přes sít), informace o systémových aktivitách a programy pro detekci vzorků virů, červů a malware, které signalizují, že je počítač zneužíván hackerem.

32

5. INTRUSION DETECTION /PREVENTION SYSTEM

•

Neznalost kontextu — při analýze paketů mají NIDS problém oproti HIDS, které znají kontext (běžící procesy, kompletní komunikační historii, historii procesů...). V případě útoku NIDS neví, zda byl útok (ne)úspěšný — chybí odezva.

•

Některé útoky mohou být identifikovány pouze inspekcí (hlaviček) paketů, např. odepření služby (denial of service), útoky založené na fragmentaci paketů (Teardrop).

•

Při správném návrhu a realizaci může NIDS analyzovat firewallem nefiltrovaný provoz, nejen upravené a přefiltrované pakety, které dorazí k cílovému počítači za firewallem nebo IPS.

•

Vysoké procento planých poplachů.

Tradiční návrh IDS počítá s jeho umístěním do interní sítě, aby „kontroloval" provoz propuštěný firewallem. Tento návrh IDS trpí již od počátku několika spornými aspekty: •

Omezení plynoucí z umístění v síťové topologii — IDS, zpravidla umístěný za firewallem, pracuje pouze s informacemi, které pro jdou firewallem, tzn. nezná celý kontext a historii síťového provozu. Útoku na nějakou službu předchází obyčejně skenování portů počí tačů v síti za firewallem. Pokud je firewall nakonfigurován tak, že propustí pouze pakety na IP adresy a porty, kde programy poslou chají, zůstane skenování sítě nezjištěno. Při použití firewallu jako aplikačního proxy serveru se k IDS dostane již přefiltrovaný provoz. Může jít například o různé útoky přetečení bufferu na webserveru, databázovém serveru atp. Většina paketových filtrů žádným způso bem neuspořádává své logy, tzn. administrátor při určitém objemu provozu není schopen z logů získat přehled nad kontextem, popř. doplnit jím záznamy IDS a provést forenzní analýzu incidentu.

•

Omezení dané kooperací s ostatními programy — např. kompletace logů firewallu a IDS, přílohy odfiltrované firewallem, konfigurace filtrů firewallu na aplikační a transportní vrstvě a buffer overflow útoky 5 .

•

Reakce na incident — rozeznáváme 2 druhy reakcí na incident:

5. Buffer overflow — přetečení bufferu, tento útok se v praxi provádí zdánlivě korektním dotazem na danou službu, tento dotaz je na úrovni protokolu formálně správný a odpovídá také pravidlům firewallu pro transportní vrstvu, snaží se o přetečení bufferu aplikace a tak umožnění spuštění útočníkova kódu.

33


-

Pasivní — IDS se omezuje na podrobné logování incidentu a nějakým způsobem upozorňuje na nutnost osobního zásahu ad ministrátorů. Nijak aktivně nepůsobí na akce útočníka.

-

Aktivní — IDS podniká aktivní kroky k přerušení nebo zpoma lení akce útočníka. Jedná se například o: * * *

5.2

Omezení nebo odmítnutí uživatelského přístupu. Blokování síťového provozu na firewallech a routerech. Zrušení aktivních síťových spojení.

Metody detekce využívané IDS

Proto vznikl návrh „vylepšeného IDS", tzv. IPS, který částečně odstraňuje některá omezení klasického IDS. IPS jsou v síťové topologii umístěny před perimetrem firewallu, čímž mohou analyzovat veškerý nefiltrovaný pří chozí provoz a jsou schopny útok nejen detekovat (jako IDS), ale mohou mu i aktivně bránit. IPS nebyl navržen, aby nahradil IDS, ale spíše aby jeho funkcionalitu doplnil. Pokud nebude v textu výslovně uvedeno, budu zkratkou IDS označovat systém složený ze subsystémů IDS (umístěného za firewallem) a IPS (před firewallem). Bohužel díky vysokému procentu poplašných zpráv IDS spolu s mož ností zneužití automatických opatření (např. pro DoS útok) se administrá toři striktním nastavením zmíněným výše vyhýbají. S aktivními opatřeními IDS souvisí i nutnost definice expozice rizik plynoucích z přijmutí aktiv ního opatření v případě planého poplachu. Metody detekce anomálií po dezřelého síťového provozu dnešních komerčních IDS vychází z výzkumu prováděného v 80. letech 20. století. Jedná se hlavně o následující metody založené na: 1. Detekci průniků přes protokolové anomálie — někdy nazývaná „ana lýza protokolu", kdy IDS analyzuje tok paketů (tokem rozumíme jed nostrannou komunikaci mezi dvěma systémy) a snaží se detekovat odchylky od standardní komunikace popsané v RFC nebo výrobcem hardwaru/softwaru. Takové anomálie IDS dále klasifikuje a rozho duje o následné reakci. Mezi výhody tohoto přístupu patří: •

Schopnost detekovat neznámé a nové útoky, pokud se jejich realizace nedrží standardů.

•

Schopnost detekovat útoky založené na modifikaci formátu zná mých útoků bez omezení síly jejich útoku, které takto upravené nedetekují systémy pro vyhledávání vzorků. 34


Detekce anomálií využívá: •

frekvenční nebo prahový průsečík — sledování frekvence spe cifických paketů, jejichž přijetí charakterizuje daný útok nebo sken,

•

korelace méně častých událostí.

Tento typ detekce je vhodný například pro odhalení útoku přete čení bufferu, FTP bounce útoku 6 , skenování portů a útoku odepření služby 2. Detekce průniků přes hledání vzorků (útoků) — tato metoda je za ložená na prohledávání obsahu paketů na vzorky (známých útoků) uložené v databázi IDS. V tomto případě není problém vyhledávání tak triviální jako u aplikací na vyhledávání adware nebo antivirů. Je žádoucí, aby IDS/IPS v sobě implementoval techniky pro správnou interpretaci a reprezentaci toků, jako jsou IP (de)fragmentace, přeuspořádávání TCP paketů, sledování toku pro logické spojování více spojení a normalizace obsahu paketů. Pro zvýšení efektivity prohle dávání se využívají regulární výrazy. 3. Detekce backdoorů 7 — není proveditelná přes hledání vyhledávání vzorků ani přes detekci anomálií, provádí se sledováním interaktiv ního provozu, porovnáváním s pravidly a s provozem povoleným administrátorem, využívá detekce statistické anomálie. 5.3

Obcházení N I D S

Pasivní IDS, které paket po paketu monitorují síťový provoz, musí při ana lýze toku nejdříve rozhodnout, zda paket dojde k cílovému počítači a ná sledně ho musí interpretovat shodně jako cílový počítač. Toto by měl IDS zajišťovat pro všechny počítače, pro které analyzuje provoz. Největším pro blémem je nejednoznačnost ve vyhodnocování příchozích paketů v kontex tech různých síťových topologií a implementací TCP/IPstacku operačních 6. FTP bounce útok využívá definice proxy serveru v protokolu FTP (definován v RFC 959). Po přihlášení na FTP server útočník pomocí příkazu PORT může posílat data na různé IP adresy a porty. Návratová hodnota příkazu PORT slouží jako portsken ke zjištění, zda je daný port otevřený nebo zavřený. 7. Backdoor neboli „zadní vrátka" je software nebo nastavení softwaru, které umožňuje vzdálený přístup k počítači nepovoleným způsobem, a tak obchází obvyklý proces autenti-

35


systémů. Výsledkem je divergence mezi tím, jak počítač interpretuje sek venci paketů a představou o vyhodnocení shodné sekvence IDS. Obcházení IDS vychází z možných situací, které mohou nastat při komunikaci na trans portní vrstvě (např. TCP). Dochází ke ztrátám paketu, jejich opětovnému poslání, (de)fragmentaci, segmentaci zprávy apod. IDS chybně (ne)použije část paketu pro znovusložení a pak v podstatě analyzuje data rozdílná od těch, která „vidí" počítač. Obcházení IDS není pouze teoretickou hrozbou. Ptacek a Newsham popsali[19] několik specifických metod útoku založe ných na nejednoznačnosti na TCP/IP vrstvě. Z jimi popsaných exploitovatelných nejednoznačností na TCP/IP vrstvě jich může být několik ošetřeno již na paketovém firewallu: kontrola kontrolního součtu v IP hlavičce, fil trování příchozího a odchozího provozu na daných rozhraních, blokování broadcastů a adres z privátních IP prostorů, kontrola velikosti IP paketu. Z ostatních[12,17] exploitovatelných technik jmenujme:

1. TCP pakety s neplatným kontrolním součtem — cílový stroj takový paket zahodí, NIDS, který neověřuje kontrolní součty, nikoliv.

2. Data mimo TCP okno — cílový stroj akceptuje pouze data uvnitř jeho TCP okna, ostatní data ignoruje, pokud pasivní NIDS pouze analy zuje odposlechnuté pakety a ne celou TCP transakci, nemůže znát aktuální velikost okna. Existenci podezřelých/nejednoznačných pa ketů také nahrává značná složitost některých standardů popsaných v RFC, která je pak zdrojem různých implementací téhož standardu. Nezřídka jsme svědky vědomých i neúmyslných změn (především stran světových vedoucích softwarových firem) ve specifikacích již přijatých standardů. Za těmito deviacemi standardů musíme bohužel často hledat především obchodní zájmy.

3. Překrývající se nebo neslučitelné IP fragmenty — RFC 791 hovoří pouze o překrývajících se částech datového obsahu paketů, ne o sa motných překrývajících se nebo neslučitelných fragmentech. Rozdíly ve způsobu defragmentace ilustruje obrázek níže. 36


11 012345676901 — > higher IP Offset Data Sent 111 22333 (Fragments 1,2,3} 4444 555666 (Fragments 4,5,6) Data Received 111442333666 BSD policy 144422555666 BSD-right policy 111442555666 Linux policy 111422333666 First policy 144442555666 Last/RFC791 policy Obrázek 5.1: Způsoby defragmentace IP paketů

4. Překrývající se nebo neslučitelné TCP segmenty — dle RFC 793 by se měly přijaté TCP segmenty uspořádávat podle algoritmu „First", tzn. měly by se vždy použít prvně obdržené hodnoty na daných off setech. Tomu by odpovídal příklad:

01234É789CI12 SHK 2.0-talah\r\n £

TCP Seq. O f f s e t ( F i r s t segment) (Second segment) ( T h i r d segment)

Obrázek 5.2: Algoritmus defragmentace TCP paketů „First"

Kdy znovuuspořádáním TCP segmentů dostaneme řetězec: "SSH2.0-blah\r\n". Například OpenBSD uspořádá do shodného řetězce i následující posloupnost segmentů. 37


012346789012 SH + X-2.0-blah\r\n S

TCP S e q . O f f s e t ( F i r s t segment} {Second segment) (Third segment) (Fourth segment)

Obrázek 5.3: Příklad defragmentace TCP paketu v OpenBSD, který zřejmě neodpovídá použití algoritmu „First".

5. Počet hopů — útočník může vhodně nastavenou hodnotu TTL v hla vičce paketu nepřímo určit, jaké pakety (ne)dojdou k cílovému počí tači.

-> ztracený paket

- » zahozen ttl=17, seq=1

* r

ttl=23, seq=1

i

o

ttl=21, seq=2

-> zahozen

ttl=15, seq=2 ttl=13, seq=3

* zahozen

ttl=20, seq=3

ttl=25, seq=4

-í zahozen ttl=14, seq=4 M/M/M/M/M/M/M/M/

Odesilatel

IDS n nebo r? o nebo i? c nebo o? t nebo e?

Příjemce noat? noce? roct? nice? root? rice? riet? rooe?....?

Obrázek 5.4: Příklad obcházení IDS přes TTL

6. PMTU 8 — NIDS by měl znát PMTU, jinak se může stát, že bude 8.

Path Maximum Transmission Unit — označuje v bajtech velikost největšího datagramu,

38


zahazovat všechny TCP pakety s nastaveným DF bitem a velikostí větší než je MTU. Dle RFC 1009 má být maximální velikost MTU na ethernetu 1500 bajtů. Pozitivní je, že podezřelé pakety lze relativně jednoduše poznat, ale bez dalších znalostí o síti za IDS a o počítačích v ní, není NIDS schopen nijak odhadnout, jak je cílový počítač vyhodnotí. U. Shankar a V. Paxson při šli s metodou „aktivního mapování"[23], která je založena na klasifikaci metod na obcházení IDS, publikovaných Ptacekem a Newshamem. Metoda „aktivního mapování" je založena na vytvoření profilů pro IPs tacky jednot livých operačních systémů. IDS pak při analýze paketů používá pro danou IP adresu počítače jeho profil a tím výrazně snižuje riziko planého popla chu. V krajním případě může IDS snadno zajistit nedoručitelnost takových podezřelých paketů. Zvláštním případem obcházení NIDS je šifrovaný provoz. Ať už šifro vání zajišťuje na síťové vrstvě protokol (např. IPSec šifrovaní a EPS pakety) nebo na aplikační vrstvě samotná aplikace. Dešifrovaný obsah paketů vidí jen koncové 2 body komunikace a prostředky IDS na cestě sítí mohou prová dět analýzy pouze z údajů hlavičky paketu. Každý šifrovaný komunikační kanál z interní sítě za firewallem je významným zásahem do bezpečnostní politiky — data, která chodí přes tento kanál neprochází filtrováním firewallu (ať už paketovým filtrem či aplikační proxy), nejsou kontrolovány antivirem, antispamem ani prostředky IDS. Proto by měl být výskyt šifro vaného provozu monitorován. Šifrování na síťové vrstvě je podle protokolu snadno zjistitelné a také moderní IDS umožňují analýzu šifrovaných paketů v reálném čase, přičemž používaný privátní klíč je v plaintext podobě pouze v paměti IDS zařízení. Šifrování na aplikační vrstvě je obtížné strojově de tekovat, tady pomůže pouze manuální analýza provozu a běžících služeb na koncových uzlech kanálu. 5.4

Co nabízí současné IDS?

Jakou přidanou hodnotu nabízí aktuálně nabízené komerční IDS dostupné na trhu? Co se týká funkcionality, jsou hardwarová řešení IDS nadmnožinou čistě softwarovým řešením, proto zde zmíním metody implemen tované v hardwarových řešeních a později budeme diskutovat dostupné opensource softwarové IDS implementace. Cílem většiny vylepšení me tod detekce průniku bylo minimalizovat poplašné zprávy (false positives), které jsou největším problémem IDS.Technika detekce průniků přes hledání který může daná vrstva komunikačního protokolu přenést.

39


vzorku byla v případě protokolu TCP vylepšena o sledovaní stavu spojení, tzn. IDS vyhodnotí provoz jako útok, jen pokud je spojení v relevantním stavu. Zajímavé je například také to, jak firma Forescout přistupuje ke skenování sítě. Jejich algoritmus „Active response" funguje tak, že při pokusu o skenování jejich sítě odpoví IPS smyšleným seznamem dostupných slu žeb (IP adresy s otevřenými porty). Zdrojovou IP adresu IPS zablokuje až při detekci připojení na některou z podvržených služeb. Doménou hard warových IDS je paralelní inspekce paketů ve 2. až 7. vrstvě OSI modelu v reálném čase s možností provozu na vysokorychlostním ethernetu (řešení firmy Tippingpoint[? ] až 5Gbps). Čím více se zvyšuje propustnost přeno sové linky, tím výrazněji roste potřeba hardwarového IDS, zvlášť pokud je řešení schopno nabídnout paralelní kontrolu více vrstev. Časové zpož dění analyzovaných paketů je pro služby typu streamovaného videa, audia nebo VoIP kritický parametr. Zajímavou iniciativou je aktivita firmy Tippingpoint (divize firmy 3com známé především v oblasti vývoje a výroby aktivních síťových prvků) nazvané „Zero Day Initiative".Tato firma „od kupuje" od veřejnosti (většinou odborníci na bezpečnost, hackeři, ale také crackeři) ještě nereportované (a tedy neopravené) chyby (zero day) v zabez pečení různých softwarů a hardwarových zařízení, ochranu před zneužitím těchto chyb implementuje ve svých IDS zařízeních a tím se snaží svým zá kazníkům zajistit nejaktuálnější možnou ochranu. V kapitole o obcházení NIDS jsem se zmínil o IDS, které jsou schopny analyzovat šifrované pakety v reálném čase. Taková zařízení této vlastnosti dále využívají a umožňují i QoS dat uvnitř VPN tunelu. Další technikou, se kterou se můžeme setkat v dnešních IDS, je ohodnocování důvěry (confidence indexing) síťového provozu. Jedná se o analogii ohodnocování e-mailů při použití bayesiánských filtrů[13]. Síťový provoz je IDS automaticky ohodnocován a pokud skóre dosáhne určité hodnoty, aplikují se předdefinovaná pravidla. Nasazení hw. IDS má oproti sw. řešení několik výhod: •

Rychlost v in-line režimu — analyzuje paralelně více vrstev (2. - 7.) v reálném čase.

•

Možnost provozu na vysokorychlostním ethernetu (až 5Gbps); hard warové řešení „brutální silou" je zároveň nevýhodou, má svůj vý konnostní strop.

•

Vysoká dostupnost a spolehlivost — disponuje hardwarovým watchdogem 9 pro korektní funkci hardwaru i softwaru.

9.

Hardwarový watchdog — neboli „hlídací pes", elektronické obvody hlídající správnou

40


•

Nezávislost na operačním systému.

•

Skálovatelnost — umožňuje udržování stavových informací o ak tivních spojeních na redundantní lince, např. 2 routy interní sítě do internetu, na každé trase jedno zařízení IPS.

•

Široká funkcionalita — např. inspekce EPS paketů při sdílení static kého klíče, QoS apod.

•

Integrace s dalšími proprietárními řešeními (firewall, router, VPN...).

Výhody sw. IDS: •

Cena — u opensource řešení jen cena instalace a PC výkonnostně dostačujícího rychlosti linky.

•

Otevřenost novým technologickým přístupům a řešením — na jednu stranu nedostačující pro práci na vysokorychlostním ethernetu, na druhou stranu překonávající výkonnostní strop hardwarových IDS např. distribuovaným přístupem k analýze provozu. Také implemen tace nových protokolů a trendů do softwarových řešení je snazší.

Jelikož si IDS (bez IPS) pro svou co největší efektivitu vynucuje interakci s ostatními zařízeními jakou jsou IPS, paketový firewall, aplikační proxy, VPN, router a aktivní síťové prvky (a stejně tak si implementaci komuni kace s těmito již existujícími zařízeními vynucují zákazníci), logicky pomalu dochází ke konvergenci těchto zařízení. Takováto komplexní řešení mohou teoreticky zastávat i funkci antispamu a antiviru — vždyť jaký je rozdíl mezi vyhledáváním vzorků známých backdoorů a malwarů při inspekci paketů TCP toku a vyhledáváním vzorků známých virů? Pro získání cel kového obrazu nad potenciálním útokem je klíčová správná zpětná rekon strukce celého incidentu. Dnes již klasický koncept IDS s IPS byl doplněn IDS senzory umístěnými v topologii sítě tak, aby pokrývaly co možná nej více přenosových kanálů. Tyto senzory sbírají data pro IDS, jsou „očima" IDS. 5.5

Způsoby reakcí IDS na incidenty

Doposud jsme hovořili o technikách prevence a detekce průniků. S rostoucí rychlostí přenosových linek roste i rychlost útoků, proto se již nemůžeme spoléhat na interaktivní zásah administrátora při známce útoku. Stejně tak funkčnost systému. Při zjištění anomálie v běhu systému provedou automatický restart.

41


absolutní počet útoků v čase narůstá. Automatická reakce nemusí posti hovat pouze síťový provoz, ale může také pomoci analytikovi rozhodovat o adekvátní reakci na ohlášenou událost. 1. TCP reset — jedné nebo oběma komunikujícím stranám se pošlou pakety s příznakem RST, po jejichž obdržení má počítač okamžitě přerušit spojení. Nutnou podmínkou je správně nastavená zdrojová IP, port a sekvenční čísla paketů. Sekvenční číslo musí být zároveň v aktuálním okně příjemce. Pokud útočník může posílat pakety vy sokou rychlostí a často mění velikost vysílacího okna, nemusí být pro IDS snadné správné sekvenční číslo vygenerovat. V době, kdy si 4Mbit připojení k internetu můžete bez problému koupit domů (tzn. cca 1000 paketů/s), zůstává tato technika spíše teoretickým řeše ním. O aplikaci ve vysokorychlostním ethernetu a rychlostech v řádu gigabitů za sekundu ani nemá smysl přemýšlet. Dalším důvodem, proč nemusí TCP reset fungovat je způsob, jakým IPstack operačního systému počítače, kterému se reset posílá, zpracovává pakety s dupli citním sekvenčním číslem — buď akceptují první paket s korektním sekvenčním číslem a ostatní ignorují nebo předají dál poslední přijatý paket s vyhovujícím sekvenčním číslem. 2. ICMP zprávy — jelikož existují nestavové síťové protokoly (jako UDP), není možné použít pro vynucené ukončení spojení příznaku RST. Abychom nemuseli použít vyšších vrstev OSI modelu (jejichž obsah bychom stejně pravděpodobně neznali), můžeme útočníkovi začít posílat ICMP zprávu o nedostupnosti sítě, počítače nebo portu oběti. V optimálním případě by měl útočník jako v předchozím pří kladu sám přestat vysílat, nehledě na to, jaká data do té doby poslal. Bohužel mnoho utilit pro provádění útoků nevyužívá IPstack ope račního systému, s velkou pravděpodobností ani nedodržují RFC a příchozí ICMP přímo zahazují. 3. Úprava filtrovacích pravidel — NIDS má právo editovat filtrovací pravidla firewallu. Většinou se jedná o blokaci útočníkovy IP adresy v nejužším místě sítě, kde je vaše podsíťpřipojená k cizí síti. Přístup může být útočníkovi zakázán na cílovém počítači, aktivních síťových prvcích, routerech, firewallech apod. I když se tento způsob reakce může zdát optimální, ve skutečnosti se často nepoužívá. Důvodem je relativně snadná zneužitelnost, kdy útočník může s podvrhnutou zdrojovou IP adresou generovat pakety, které následně IDS vyhod notí jako pokus o útok a zakáže připojení legitimních počítačů. Pak 42


by se z našeho firewallu stal jednoduchý, ale efektivní nástroj distri buovaného útoku odepření služby. 4. Neblokující reakce •

Spouštění skriptů — tento přístup se hodí pouze tam, kde máme jistotu, o jaký útok se jedná. Dovoluje nám nadefinovat sadu inverzních akcí k akcím útočníka/viru/červa.

•

Přesměrování — podezřelý provoz přesměrujeme na firewall s přísnějšími pravidly filtrování, vyšší úrovní logování nebo úplně změníme cílovou destinaci paketů. Zvláštním typem pře směrování je přesměrování na honeypot 10 , což umožní admi nistrátorovi lépe monitorovat útok bez ohrožení produkčních serverů.

5. (Rozšířené) upozornění e-mailem — kromě zaslání upozornění o bez pečnostním incidentu na administrátorskou konzoli, do systémového logu a e-mailem administrátorům je možné automaticky e-mailem upozornit všechny v podezřelé komunikaci zainteresované strany (správce stroje pravděpodobného útočníka; správce domény útoční kova stroje; ISP11, přes kterého je útočník připojen; náš ISP..). Otáz kou tedy je, koho kontaktovat a jak získat jeho kontaktní údaje. Tyto informace můžeme (strojově) vyhledávat na: •

Whois serverech — jedná se o databáze obsahující informace o doménách. Ve všech Whois databázích je nyní registrováno přes 94 mil. domén, což z ní dělá největší databázi domén. Whois je podrobněji popsána v RFC: 1714,1834,1835,1912,1913,1914 a 2167. Whois databáze je přístupná buď přes webový formu lář, např. www. whois . o r g , www. r i p e . n e t nebo z příkazové řádky přes whois klienta: ' w h o i s - h jmeno_whois_serveru domenove_jmeno \

•

Abuse.net—v této doméně je hostována databáze internetových domén (k dnešnímu datu přes 200 000 domén). Registrací domé nových údajů je vytvořen alias [email protected] na kontaktní e-mail pro danou doménu. Informace v této databázi jsou brány z:

10. Honeypot je software a/nebo hardware představující svými prostředky pro útočníka návnadu, která slouží pro detekci a zkoumání pokusů o neautorizované použití prostředků ICT. 11. ISP — Internet Service Provider

43


-

•

určitých Whois serverů, doménových stránek (e-maily), testů běžných poštovních schránek (support, abuse...), volání traceroute a dotazů Whois serveru Arin na ISP ne komunikujících domén, Abuse.net databáze je přístupná z webuna: h t t p : //www. a b u s e . n e t / l o o k u p . p h t m l , přes whois server: ' w h o i s - h w h o i s . a b u s e . n e t jmeno_domeny' nebopresdotaznaDNSserveryabuse.net: 'nslookup jmeno-domeny.contacts.abuse.net' (více na h t t p : //www. a b u s e . n e t / u s i n g , phtml). DNS — pokud je IP adresa útočníka registrována v nějaké do méně, můžeme najít kontaktní e-mailovou adresu v hlavičce „Authority records" za direktivou SO A (Start Of Authority).

6. Protiútok — možnost zahájit protiútok na stroj (domnělého) útoč níka je spíše teoretická. V praxi ji provází velké množství možných ošidností: podvržení útočníkovy IP adresy a následný útok na ab solutně nevinný počítač, útok na stroj s multiuživatelských operač ním systémem a postihnutí ostatních nevinných uživatelů, útok na stroj s nainstalovaným backdoorem, který skutečný majitel neovládá atp. Pomineme-li legální aspekty protiútoku, je reálně mnohem větší šance, že se ve svém útoku z výše zmíněných příčin zmýlíme a naše akce nám nijak nepomůže zastavit útok na nás. 7. Zvýšit úroveň logování — vhodné pro pozdější forenzní analýzu a rekonstrukci incidentu, např. skládáním logů z více počítačů a aktiv ních prvků (nutná časová sychronizace!). 8. Limitování rychlosti připojování a počtu spojení — nejprve vysvět lím princip front pro zpracování paketů. Zařadit paket do fronty znamená, že čeká na zpracování. V kontextu počítačových sítí jsou odchozí pakety zařazovány do fronty, kde čekají na zpracování ope račním systémem. Plánovač operačního systému pak rozhodne, z jaké fronty se zpracuje jaký paket. Na algoritmu plánovače tedy do značné míry závisí výkon celého síťového subsystému. Uvedu krátký pří klad: uživatel je přihlášen přes SSH ke vzdálenému stroji mimo lo kální síť a zároveň stahuje soubor přes FTP z téhož stroje. Pokud router neprioritizuje SSH provoz, může se velmi rychle stát, že velké množství FTP paketů způsobí stárnutí SSH paketů, které se projeví zvýšenou dobou odezvy (až zahazováním paketů vedoucím k přeposílání paketů = zpoždění), pokud fronta není dost dlouhá. Pokud 44


by se „zdržely" mírně FTP pakety, pravděpodobně by si tohoto na výšení doby stahování uživatel ani nevšiml. Modifikací front a plá novače jsme schopni zajistit férovost využívání sítě mezi různými aplikacemi, uživateli a počítači. Z výše zmíněného je jasné, že modifikace front nám může být uži tečná pouze pro odchozí síťový provoz. Jakmile paket ze sítě přijde na síťovou kartu (obecně rozhraní), už je na jakékoliv operace s frontou pozdě — paket již byl sítí přenesen. Jediné řešení pro příchozí provoz je nakonfigurovat fronty na „sousedním" routeru nebo pokud stroj, který paket přijal, funguje jako router, tak nakonfigurovat fronty pro rozhraní vnitřní sítě. Pro následující demonstrování možností konfi gurace plánovače a front použiji jádro operačního systému OpenBSD. Vybral jsem si OpenBSD pro jeho zaměření na práci v síťovém pro středí a důraz jeho vývojářů na bezpečnost. Plánovač v OpenBSD fun guje jako FIFO (First In First out) fronta. Pokud se fronta zaplní, jsou příchozí pakety zahazovány, dochází k tzv tail-dropu. Konkrétně, jednoduchým pravidlem pro paketový filtr v jádře: p a s s i n e t p r o t o t e p from any t o $ i n t _ i f : n e t w o r k port $tcp_services \ f l a g s S/SA k e e p s t a t e \ ( m a x - s r c - c o n n 100, m a x - s r c - c o n n - r a t e 1 5 / 5 , \ overload flush global)

\

Je možné určit: max-src-conn — maximální počet simultánních připojení z jednoho počítače, v tomto případě 100 spojení. max-src-conn-rate — maximální rychlost navazování nových spojení z jednoho počítače, v tomto případě 15 spojení za 5 sekund. overload — hodnota atributu overload určuje tabulku (skupinu) IP adres, do které je počítač přidán, pokud překročí výše uvedené limity. Následně je možné generovat filtrovací pravidlo pro všechny adresy v dané skupině. flush global — při nastavení tohoto atributu dojde k přerušení všech spojení s postiženým počítačem, který překročil limity výše. Díky limitování rychlosti připojování a maximálního počtu simultán ních spojení končí většina útoků hrubou silou velmi rychle vypršením časového limitu pro připojení a zakázáním zdrojové IP 45


5.6

Shrnutí

Automatické reakce na incident měly anulovat prodlevu vzniklou nutností aktivního zásahu analyzátora na ohlášené (nejednoznačné) incidenty. Při podrobnějším zkoumání metod reakce je patrné, že je často větší negativní dopad automatické reakce na planý poplach než expozice rizika samot ného průniku. Proto je pro efektivní systém reakce nutné zajistit, aby riziko odepření přístupu legitimním uživatelům bylo vždy menší než riziko ztrát vyvolané útokem. Takové chování IDS není možné zajistit při každém síťo vém provozu. Automatické reakce IDS mohou fungovat pouze za určitých podmínek nebo na určitém typu provozu. Současný trend masového skenování sítě s aplikací připraveného exploitu v počtu několika málo paketů při pozitivní odezvě úlohu IDS pouze ztě žuje. Jak ukázaly praktické testy rychlosti propagace červů jako je CodeRed[3] nebo Nimda[4], kdy se červy šíří sítí v sekundách či minutách za použití malého množství paketů, použití technik reakce pro přerušení spojení (TCP reset) je absolutně neefektivní. V takových případech pomůže pouze co nej rychlejší odpojení zavirovaného počítače od sítě, což je stále snesitelnější než následné odpojení zavirovaného serveru, který by byl obětí dalšího šíření viru. Stanovení jednoduchých metrik pro frekvenční nebo prahový průsečík nám zaručí jistou reakci na incident, ale nevyloučí možnost planého po plachu. Pokud bychom pouze automaticky blokovali všechny zdrojové IP adresy, může náš firewall někdo lehce zneužít proti nám a např. na nás pustit skenování portů z podvržené zdrojové IP adresy. Pokud nechceme rovnou provoz z podezřelé IP adresy blokovat, mů žeme pouze zmenšit rychlost vytváření nových spojení a uvědomit admi nistrátora, který zvolí odpovídající reakci. Rozhodnutí o blokování provozu z podezřelé IP adresy také nemusí být jednoznačné, ale může záviset na mnoha dalších kritériích jako je čas, kdy k incidentu došlo, na aktuální dostupnosti administrátora, doména, ze které je zdrojová IP adresa apod. Příkladem takového chování může být skenování portů univerzitního stroje z domény MU. Pokud se takový sken uskuteční z univerzitního multiuživatelského serveru, bylo by asi krátkozraké hned zakazovat veškerý příchozí provoz z daného serveru, ale bude rozumnější pouze zpravit administrá tory o takové činnosti a zahájit pátrání po „neposlušném" uživateli. Na druhou stranu pokud se zdrojová IP útočníkova stroje vyskytuje v několika veřejných databázích hackerů, tak můžeme veškerý provoz klidně zabloko vat, protože riziko, že se z takového stroje chtěl připojit legitimní uživatel je zanedbatelné. I kdyby se tak stalo, tak je mnohem střízlivější zablokovat 46


dočasně přístup jednomu uživateli z internetová kavárny v Číně než mnoha legitimním uživatelům univerzitního serveru.

47

Kapitola 6

Software pro analýzu síťového provozu 6.1

SNORT

www.snort.org 6.1.1 Popis, možnosti konfigurace Snort (nyní ve verzi 2.6) je v oblasti softwarových NIDS v podstatě prů myslový standard. Snort je možné provozovat ve více instancích současně (např. pro různá síťová rozhraní). Je napsán v jazyce C a k zachytávání paketů používá knihovnu libpcap. Snort umí pracovat stejně jako hardwa rový IPS na síťové vrstvě (v tzv. bridge módu), kdy nemusí mít přiřazenou IP adresu. Samotný Snort „pouze" podle definovatelných pravidel analy zuje hlavičky a obsah paketů. Detekci anomálií provádí u protokolů: TCP, UDP, ICMP a IP Funkčnost Snortu[20] je definována především prepro cesory a plug-iny Právě silně modulární architektura dovoluje vývojářům funkcionalitu Snortu dále rozšiřovat, přičemž jádro (detekční rutina) zů stává nedotčeno. Detekční mechanizmus hledá (i za pomoci regulárních výrazů) v datové části paketů daný řetězec znaků. Signatury známých virů, internetových červů, exploitů, malware apod. jsou dostupné na webu Snortu ( h t t p : / / w w w . s n o r t . o r g ) nebo stránkách iniciativy „The blee ding Snort" ( h t t p : / / w w w . b l e e d i n g s n o r t . c o m ) , která se zaměřuje na co nejrychlejší updaty detekčních pravidel Snortu. V rámci jednoduché syn taxe pravidel Snortu také není problém si po analýze útoku potřebná pra vidla vygenerovat sám. Příklad pravidla pro detekci exploitů SSH démona níže: alert tep $EXTERNAL_NET any -> $HOME_NET 22 \ (msg:„EXPLOIT ssh CRC32 overflow NOOP"; f low: to.server, \ established; content:,, | 90 90 90 90 90 90 90 90 90 \ 90 90 90 90 90 90 90|"; reference:bugtraq,2347; \ reference:cve,2001-0144; reference:cve,2001-0572; \

48

6. SOFTWARE PRO ANALÝZU SÍŤOVÉHO P R O V O Z U

classtype:shellcode-detect;

sid:1326;

rev:6;)

Preprocesory Preprocesory byly prvně uvedeny ve verzi 1.5. Preprocesor je kód, který se na odchycený paket aplikuje ještě před předáním detekčnímu algoritmu jádra, ale již po dekódování (jednotlivých „vrstev") paketu. Mezi hlavní a v instalačním balíčku dodávané preprocesory patří: Frag3 Preprocesor Frag3 zajišťuje IP defragmentaci odchycených paketů. Jak jsem již popsal dříve, díky rozdílné implementaci IPstacku IDS a operačních systémů počítačů, pro které Snort defragmentuje IP pakety, může útočník v určitých případech IDS „obejít". Frag3 používá techniku „aktivního ma pování " pro IP defragmentaci 5 způsoby, což by mělo pokrývat chování většiny známých operačních systému pro různé platformy včetně operač ních systému aktivních prvků. Autoři plug-inu slibují implementaci no vého profilu aktivního mapování v co nejkratší době po jeho ohlášení nebo uvedení. Frag3 je schopen rozpoznat 8 typů anomálií, které mohou při IP defragmentaci nastat, včetně kontroly TTL (time to live) v hlavičce paketu. Stream4 Streamá provádí znovusestavení TCP toku a analýzu stavu spojení. Tím Snort eliminuje bezstavové útoky. Tok je unikátní pro čtveřici zdrojová IP, cílová IP, zdrojový port, cílový port. Stream4 dokáže teoreticky sledovat přes 100 000 konkurentních toků. sfPortscan Tento preprocesor rozpoznává skenování sítě, které je většinou prvním kro kem v útoku na vzdálený stroj. Skenování sítě má za úkol zmapovat, jaké typy síťových protokolů počítač používá a jaké služby počítač poskytuje. Skenování portů můžeme z relačního pohledu rozdělit na: 1. „1 —> 1" — kdy jeden počítač skenuje více portů jednoho počítače. 2. „1 —> N " — kdy jeden počítač skenuje právě 1 určitý port na více počítačích. Jedná se o typické chování, když vyjde nový exploit na danou službu. 49


3. „N —> 1" — tzv distribuovaný sken, kdy více počítačů skenuje více portů jednoho počítače. Snort detekuje následující skeny: 1. TCP (distributed) Portscan 2. UDP (distributed) Portscan 3. IP (distributed) Portscan Více o jednotlivých skenech například v manuálu k nmapu[9]. U Snortu lze nastavit několik úrovní citlivosti detekce: 1. Nízká — Snort primárně detekuje skenování portů podle negativních odezev skenovaného počítače. Tato metoda detekce generuje velmi malé množství falešných poplachů, ale není schopná detekovat filtro vané skenování (protože pakety negativní odezvy jsou zahazovány firewallem). Délka časového okna pro detekci anomálií je 60 sekund. 2. Střední — sleduje počet připojení za jednotku času, takže dokáže detekovat filtrované skenování. U velmi aktivních počítačů (např. NAT proxy, DNS cache, atd.) může naopak docházet díky prahovým průsečíkům k více planým poplachům. 3. Vysoká — Snort pracuje jako při střední citlivosti, navíc používá buf fer pro detekci pomalého skenování 1 — na velikosti bufferu a objemu síťového provozu závisí velikost časového okna, pro detekci poma lého skenování. Snort používá pro rozhodování o legitimnosti útoku následující metriky: •

počet všech připojení/počet unikátních IP za jednotku času,

•

počet připojení na různé porty/počet unikátních IP za jednotku času,

•

počet všech připojení/počet připojení na různé porty za jednotku času.

1. Pomalé skenování je založeno na posílání malého množství paketů rovnoměrně rozlo žených do velkého časového intervalu. Takový typ skenování sítě je pro jeho povahu velmi těžké detekovat.

50


HTTP Inspect HTTP Inspect provádí dekódování protokolu http včetně jeho normalizace. HTTP Inspect je schopen zpracovávat http požadavky klientů i odpovědi serveru. Modul neprovádí sledování stavu spojení, ale kontroluje paket po paketu. Performance monitor Performance monitor vypisuje na systémovou konzoli nebo do souboru údaje o výkonových charakteristikách Snortu. 6.1.2 Výstupní plug-iny a reakce na incidenty Snort dokáže směřovat výstup do syslogu, na systémovou konzoli, do unixového socketu, do databází: MSSQL, MySQL, PostgreSQL, Oracle a pod poruje rozhraní ODBC. Na všechny generované zprávy je možné aplikovat prahový průsečík, tak můžeme generovat nad množinou pravidel další pravidla. Nejde jen o nastavení maximálního počtu daných paketů (tzn. paketů, které odpovídají nějakému pravidlu) za jednotku času, ale i logování každého n-tého paketu, prvních n výskytů paketu nebo aplikace obou předchozích kritérií zároveň. Snort umí reagovat na pozitivní nález paketu dle jeho předdefinovaných pravidel: 1. výpisem upozornění — viz výše, 2. zalogováním paketu včetně datového obsahu, 3. zahozením paketu a zalogováním události* — paket je zahozen a událost se zaloguje ve formátu Snortu (libpcap), 4. odmítnutím paketů* — paket je zahozen, událost se zaloguje a dojde k pokusu o shození spojení — v případě protokolu TCP o TCP reset, u UDP ICMP zprávu o nedostupnosti. Pokud Snort pracuje v bridge módu, nemá tedy přidělenou IP adresu a není schopen vytvořit a odeslat RAW paket s TCP řešetem, popř. ICMP paket. Je ale schopen odeslat reset spojení přes ethernet, přičemž zdrojová MAC adresa je konfigurovatelná, 5. tichým zahozením* — paket je zahozen. * implementováno pouze při použití linuxu s iptables pro filtrování provozu a běhu Snortu v in-line módu.

51


Snort může pracovat v následujících 4 módech: 1. sniffer mód — Snort pracuje jako klasický sniffer, síťová karta je v pro miskuitním módu, Snort zachytává a zobrazuje na konzoli veškeré pakety na síťovém segmentu. Tento mód zobrazuje ethernetové hla vičky, hlavičky IP, TCP, UDP a ICMP paketů. Umí zobrazovat i obsah zachycených paketů. 2. packet logger mód — tento mód se od předchozího liší možností záznamu zachycených paketů na disk. Snort umožňuje logování pa ketů v plaintextu i binárním formátu. Pokud zvolíme logování v plaintextu, Snort při zadání naší podsítě vytváří logovací soubory pro jednotlivé zdrojové IP adresy (tzn. IP adresy relativní k naší podsíti). Binární formát logu je shodný s formátem tcpdumpu, proto není problém tento log dále zpracovávat obrovským množstvím dostup ných opensource programů (např. ethereal), popř. si napsat aplikaci vlastní. Snort je schopen uložené logy zpětně zobrazit na konzoli včetně jejich filtrovaní přes BPF rozhraní (více o filtrování přes BPF v manuálových stránkách tcpdumpu[21]). 3. Network Intrusion Detection System (NIDS) — v tomto módu se Snort chová jako NIDS, implicitně nezaznamenáva žádné pakety a chová se podle předem definovaných pravidel. Opět si můžeme zvo lit, zda chceme logovat v plaintextu nebo v binárním formátu. V NIDS módu existuje 7 způsobů, jakými lze zpracovávat oznámení o udá losti včetně přeposílání oznámení o události na jiný unix socket, kde může poslouchat další program. 4. In-line mód — v tomto módu funguje Snort jako IPS. Pakety neodchytává přes libpcap API (Application Programming Interface), ale z iptables (přes knihovnu LibNet) jsou předávány do user space Snortu. Z čehož vyplývají i případné problémy, pokud knihovna Lib Net není portována na váš operační systém. Snort také umí v in-line módu měnit obsah datové části paketů. Tady platí jediné omezení na délku nahrazovaného řetězce, která musí být shodná s délkou řetězce, kterým nahrazujeme původní obsah. 6.1.3

Shrnutí

Při implementaci Snortu nebyly použité sledy, proto je Snort velmi náchylný na jakákoliv přerušení. Toto je hlavní důvod, proč Snort neumí posílat upo zornění o incidentu e-mailem, na pager, sms apod. Autoři také silně ne52


doporučují volání externích programů přímo ze Snortu. Volání externího programu by blokovalo běh Snortu a výrazně by se tak zvyšovalo nebez pečí zahazování paketů. Zvlášťto platí pro operační systémy Windows, kde je vytvoření nového procesu o dost náročnější než v systémech unixového typu. Z toho důvodu bude vůči Snortu mnohem šetrnější provozovat pro analýzu logů nějakou aplikaci, která poběží po celou dobu analýzy paketů a nebude se volat při každém poplachu. Možnosti automatické reakce jsou silně omezeny na použitý operační systém. Při použití Linuxu s iptables jste schopni pakety zahazovat a po koušet se o přerušení spojení. Každopádně se o tom administrátor dozví až při zpětném procházení logů, a to už může být v případě blokování paketů z daného stroje dost pozdě. Pokud neprovozujete Linux, můžete pouze vy pisovat události na systémovou konzoli nebo do logu. Snort je šířen pod licencí GNU GPL. 6.2

myNetWatchman

http://www.mynetwatchman.com 6.2.1 Popis MyNetWatchman není klasickým IDS systémem. Jedná se o službu, která automaticky agreguje logy z firewallů, routerů a aktivních síťových prvků z velkého množství počítačů. K tomu využívá volně stažitelného klienta, který zajišťuje odesílání logů na centrální server služby myNetWatchman. Tyto logy jsou prohledávány na výskyt útoků hackerů, internetových červů nebo signatury virů. Agregace logů mu pomáhá ke korelaci časů, typů a zdrojů útoků a tvorbě různých statistik jako je například: pořadí portů, na které směřuje nejvíce útoků; naposledy hlášené incidenty; vyřešené in cidenty; incidenty podle ISP; uživatelem nahlášené incidenty a jejich stav apod. Pokud detekuje bezpečnostní incident, zajistí notifikaci ISP (Internet Service Provider). O stavu každého incidentu včetně kompletních přijatých relevantních logů a e-mailové komunikace se může registrovaný uživatel informovat přes webové rozhraní. MyNetWatchman vystupuje v roli: •

agregátoru bezpečnostních zpráv,

•

centralizovaného analyzátoru bezpečnostních zpráv s webovým frontendem, 53


•

plně automatizovaného systému pro notifikaci bezpečnostních inci dentů.

Obrázek 6.1: Funkční model služby myNetWatchman

Myšlenka takového systému vychází z předpokladu, že většina strojů na internetu generující útoky po síti není pod správou hackerů/útočníků, ale jedná se o kompromitované stroje, ať už útokem hackera, internetového červa nebo viru. Taková situace následně vede k zprostředkovaným a těžko stopovatelným útokům. Tento software tedy útokům sám nebrání, ale snaží se pomocí e-mailových notifikaci omezit počet kompromitovaných systémů na internetu a minimalizovat dobu, kdy zůstávají v kompromitovaném stavu. Když myNetWatchman objeví systém, který je zranitelný známým exploitem, tzn. pozná to z obdržených logů, sám testování slu žeb neprovádí, pošle administrátorovi e-mail s popisem problému a radou, jak ho řešit. Vyhodnocování velkého množství agregovaných logů dopl ňuje klasický přístup ochrany a zabezpečení vlastních zařízení a sítí tím, že se snaží nacházet infikované počítače, které mohou být zneužity k dalším útokům. Tento přístup aktivně brání možnosti distribuovaných útoků na nedostupnost služby (DDoS), které mohou takové infikované počítače ini ciovat. Právě tyto útoky jsou společně s internetovými červy a botnety hlav ním bezpečnostním problémem současného Internetu. Botnetem se označuje síť počítačů, na kterých hackeři provozují programy pro centralizovanou vzdálenou správu. Tyto programy se z hlediska síťového provozu chovají jako obyčejné IRC servery. Tvůrce botnetu kontroluje počítače v botnetu ze vzdáleného IRC serveru. Botnety slouží k provádění DoS útoků, rozesílání spamu, ke sběru privátních informací z hostitelského počítače atd. 54


MyNetWatchman se svým přístupem: 1. Minimalizuje úsilí nutné k ohlášení incidentu — zpětné, ve smyslu resolvování doménového jména, stopování zdroje útoku vyžaduje určité úsilí, zvlášťpokud se jedná o zdroje v Koreji, Tchaj-wanu, Číně apod. Takové zdrojové IP adresy často nemají reverzní DNS záznam, žádné informace na Whois serverech atd. 2. Potlačuje falešné poplachy — při detekci založené na prahovém prů sečíku nebo při hlášení o incidentu personálním firewallem vznikají situace, kdy není zcela jisté, zda se jedná o něčí aktivní útok na náš systém nebo shodu náhod vyvolávající falešný poplach. ISP jsou pak zahlceny hlášeními o planých poplaších a jsou nuceni je ignorovat někdy na úkor skutečných incidentů. Agregace logů nám dovoluje se zaměřit na hackery, kteří provádí skenovaní stovek až milionů IP adres. 3. Informuje o incidentu odpovědné osoby — ISP nebo majitel stroje připojeného k internetu často potřebují důkazy o incidentu z více ne závislých zdrojů, než vyvodí důsledky. Ačkoliv více uživatelů ohlásí incidenty ze shodné zdrojové IP adresy, je možné, že bez nástroje pro korelaci hlášení nebude útok správně diagnostikován. Odeslání jednoho informačního e-mailu shrnujícího veškeré poznatky o útoku přispěje k rychlé a odpovědné reakci více než několik jednotlivých e-mailů s částečným popisem.

6.2.2 Možnosti konfigurace V případě operačního systému Windows je k dispozici reportovací démon pouze jako binární instalační soubor, pro unixové operační systémy je ke stažení perlový skript. Perlový skript běží na hostitelském počítači jako démon, který odesílá logy na server mynetwatchman.com přes protokol HTTP. Nastavení filtrování logovacího souboru lze nastavit. Démon filtruje logovací soubor paketového filtru a odesílá na centrální server pouze hla vičky TCP, UDP a ICMP paketů. Informace o incidentu lze vkládat i přes webový formulář. Atributy jsou: datum a čas, zdrojová IP, zdrojový port, typ IP protokolu, cílová IP, cílový port a počet případů. MyNetWatchman podporuje následující formáty logů firewallů a IDS v operačních systémech Windows a OS unixového typu: 55

6. SOFTWARE PRO ANALÝZU SÍŤOVÉHO P R O V O Z U OPERATING SYSTEM FIREWALLS / REPORTING SYSTEMS OR ENVIRONMENT SUPPORTED

myNETWATCHMAH AGENT Installation Instructions

Windows 95/98IME/NT/2K/XP

BlacklCE Defender Computer Associates sTrust EZ (follow Zone Alarm setup) DlinkDI-704 Linksys Router (Logging to Kiwi or WallWatcher) Microsoft KP ICF Netgear Cable/DSL Router Sonic Wall (logging to Kiwi) SMC Barricade Zone Alarm

Win32 Aaent. version 1.25-1

See installation instruction here.'

Kerio Winroute Firewall 5.x and 6.x.

Deroao Aaent

This agent converts Kerio 's log into Zone Alarm 's format. Instructions are included with the downloaded file.

PerlAaent - Linux. Built with RPM v3 and should be compatible with most Linux distributions.

Instructions are included I with the downloaded file.*

* * * * * * + * + •

Linux, Unix

• • • * * * *

Cisco PIX Cisco router logs freebsd ipfw ipchains iptables portsentry Snort (Requires the Snort CSV patch. See the manual pages included with the download.) * Sonic Wall

PerlAaent - Unix. Tar file for generic Unix (ie, Sun Solaris, HPux, DECux, etc.).

LaBrea TarPH

LaBrea TarPit System

LaBrea TarPit Aaent

Other

If your configuration is not shown, you WebAgent (no download can still report events using our necessary) Web Agent Form. After completing the registration, select "Report a possible Attack" from the myREPORTS menu to the left.

Instructions is included on the download site.* Use the guidelines here to submit incident details.

I

Obrázek 6.2: Přehled podporovaných reportovacích systémů (převzato z www.mynetwatch.com)

6.2.3 Reakce na incident Uvědomme si, že obsah logu závisí pouze na nastavení paketového fil tru na firewallu a nastavení filtrovacích pravidel démona zodpovědného za odesílání logu na server. Proto ani v případě útoku na více strojů/sítí najednou není jisté, že centrální systém tyto útoky správně vyhodnotí a na útok patřičně zareaguje. Z definice služby myNetWatchman vyplývá, že nijak nereaguje na ojedinělé skenování a útoky, tzn. myNetWatch vám pouze s vysokou pravděpodobností určí útočníka (= jeho zdrojovou IP), 56


ale není schopen vyloučit útok lokálního charakteru ve smyslu zaplavení sítě. Démon myNetWatchman pravidelně stahuje seznam IP adres aktivních útočníků a umožňuje spuštění libovolného spustitelnéhou souboru s argu mentem jako položkou seznamu útočníků. Primárně je tento způsob reakce určen pro zakazování a povolování IP adres útočníků na lokálním paketovém firewallu. Tomu odpovídá i název direktiv „addfw" a „delfw". Příklad nastavení těchto direktiv pro operační systém Linux: addfw /usr/sbin/iptables -I input 1 -s $SOURCE$/32 \ -d 0/0 -1 -j REJECT delfw /usr/sbin/iptables -D input -s $SOURCE$/32 \ -d 0/0 -1 -j REJECT 6.2.4 Shrnutí

S používáním myNetWatchmana je spojeno několik závažných problémů: 1. zajištění důvěrnosti a integrity přenášených dat — data jsou na server odesílána v plaintextu, takže je může kdokoliv po cestě odchytit a případně modifikovat. 2. Riziko zneužití dat uložených na centrálním serveru — viz úvodní pojednání o metadatech síťového provozu a jejich zneužití. 3. Omezení na hardwarovou /softwarovou platformu — viz tabulka podporovaných formátů logů výše. I když je perl rozšířeným inter pretem, není dostupný na všech platformách. U platformy windows chybí zdrojové kódy a to představuje vždy určité bezpečnostní riziko při případném nasazení do produkčního prostředí. Centralizovaný přístup k analýze síťového provozu přináší rozhodně mnoho pozitiv a výhod oproti autonomním IDS. Statistika založená na agregaci dat nám dokáže zprostředkovat velké množství zajímavých informací o síťo vém provozu. MyNetWatchman je zajímavým příkladem centralizovaného přístupu (který by se měl určitě dále zkoumat), ale kompletní návrh a reali zace může sloužit pouze pro testovací provoz. Otázky bezpečnosti přenosu logů a zajištění jejich nezneužitelnosti autoři zřejmě vůbec neřešili. Z hle diska dostupných způsobů reakcí na incident představuje myNet Watchman doplněk ostatním IDS. Nesnaží se v reálném čase analyzovat a blokovat podezřelý provoz, ale až zpětně generuje seznam útočníků a snaží se včas nými oznámeními o incidentu předcházet vážnějším škodám. Dle informací 57


autorů, centrální server myNetWatchman posílá 500 - 1000 (přes 10 000 emailů v době uvolnění červa Code Red) e-mailů denně, často již 60 sekund od doby, kdy první démon oznámí incident. MyNetWatchman je šířen pod licencí GNU GPL. 6.3

Prelude

http://www.prelüde-ids.org http://prelüde-ids.com 6.3.1 Popis

Při analýze softwarových IDS vhodných pro nasazení v univerzitním pro středí bych preferoval co nejvíce modulární řešení, které by bylo možné v případě širšího nasazení modifikovat pro konkrétní účely. Možným řeše ním je hybridní IDS Prelude (aktuálně ve verzi 0.9), který v sobě kombinuje HIDS a NIDS. Už při návrhu IDS Prelude byl kladen velký důraz na interoperatibilitu s nejrozšířenějšími opensource i proprietárními řešeními. Prelude využívá jako komunikační formát objektově orientovaný IDMEF (Intrusion Detection Message Exchange Format[5]) založený na XML. Cí lem IDMEF je definovat datové formáty a procedury pro výměnu informací mezi subsystémy detekce, reakce a mezi řídícími systémy, které s těmito systémy komunikují. Existují 2 typy IDMEF zpráv: „heartbeat" a „alert". „Heartbeat" se používají pro udržování stavu senzoru, tedy jde o zprávu manažeru (viz níže) „jsem živý a pracuji". „Alert" zprávy obsahují veš keré informace o detekované události, jakou může být detekce útoků, de tekce virů, portsken atd. Formát IDMEF zpráv také dovoluje centralizovat logy z různých senzorů (= aplikacím, které generují zprávy o potenciálních incidentech). IDMEF je standard IETF (Internet Engineering Task Force, h t t p : //www. i e t f . org).

58


I IDHEF-Message | + + /_\ I + + I + + + | Heartbeat | o - | Analyzer + + +

+ + + | Alert | o - 1 + + + + o-1 CreateTinie | + + + + O-1 DetectTime | + + + + + O-1 AnalyzerTime | + + + + + -t o-1 Source | o - | Node | + + + -t | + 4 I | O-1 User | I | + + I | + + I | o - I Process | I | + + I | + + I | I<>-I Service | + + + + + + + + O - 1 Target |<>-| Node | + + + + | | + + | I<>-I User | | | + + | o - I Process | +

<><><>-

I

Analyzer

+ | +

+

+

Io - 1 CreateTinie | I + + I +. + |<>-| AdditionalData | + + +

| +

| + + | O - | Service | + | + + +_ - | C l a s s i f i c a t i o n | + + | + + |<>-| FileList | | -+ | H 1 Assessment* + | + + + | AdditionalData +

+ | + + | + + | +

Obrázek 6.3: Formát IDMEF zprávy

59


* Alert: ident=43344 * Classification type: vendor-specific * Classification: CheckpointSmartDefense: Mise logs * Creation time: 0xclfdc7ae.0xc979500 (2003-02-19 10:00:54.787+0100) * D ete ction time: 0 xc 1 fdc 7 ae.Ox c 96 8 800 (2003-02-1° 10:06:54.786+0100) * Analyzer ID: 13799021524060081805 * Analyzer model: Prelude Log Monitoring Lackey * Analyzer class:Hostbased Intrusion DetectionSystem * Analyzer manufacturer: The Prelude Team http://www.prelude-ids.org * Analyzer OS type: Linux * Analyzer OS version: 2.4.20-19.8.0 * N ode [unknown]: name :1ml location:my_checkpoint_fw * Process: pid=24975 name=prelude-lmlpath=/usr/local/prelude/bin *

*** Additional data within the alert * Log received from: m.m.m.m * Original Log: >d:\winlogger.pl[1612]: 19Feb2003 10:00:53 drop x.x.x.x »eth-slp2c0useralertproduct:SmartDe fens e; AttackInfo: Echorequest » t o o long; attack: Large ping; sre: y.y.y.y; dst: z.z.z.z; » p r o t o : iemp, iemp-type: 8, iemp-code: 0,

Obrázek 6.4: Příklad alert zprávy v IDMEF formátu v plaintextu

Senzory se logicky dělí na senzory monitorující síťový provoz a hostbased senzory analyzující logy na zařízení, kde host-based senzor běží. Host-based senzorem, který je dostupný v balíku Prelude IDS, je „PreludeLML". Od verze Prelude 0.9 je nahrazen původní Prelude-NIDS pro analýzu síťového provozu Snortem, který od verze 2.4 umí reportovat manažeru Preludu ve formátu IDMEF. Proto se již nevyvíjeným a nepodporovaným Prelude-NIDS nebudu zabývat. Prelude se skládá z 5 hlavních částí: 1. Knihovna prelude (libprelude) — definuje API rozhraní, přes které všechny části IDS Prelude komunikují ve standardu IDMEF. Její funkce také zajišťují šifrovanou komunikaci s manažery. Knihovna 60


prelude je napsána z největší části v jazyce C, menší části jsou napsány v Pythonu a Perlu. 2. Senzory — senzory jsou rozmístěny na strategických místech v síti (a/neb o na důležitých stanicích v síti) a zasílají informace Prelude Manageru. Mohou to tedy být systémy NIDS i HIDS. Komunikace senzorů s manažery probíhá přes protokol TCP šifrovaně pomocí SSL (Secure Socket Layer). Senzory slouží k detekování podezřelé aktivity na hostitelském počítači nebo na síti. Senzor může být stejně komplexní jako IDS, stejně tak to může být jednoduchý program reportující síťovou aktivitu na určitém TCP portu. Používání senzoru v Prelude IDS je podmíněno předchozím procesem „registrace sen zoru". Ta se skládá z 3 kroků: •

Vytvoření unikátního identifikátoru senzoru.

•

Vytvoření lokálního adresáře pro ukládání zpráv v případě ko munikačních problémů s manažerem.

•

Obdržení X509 certifikátu pro komunikaci mezi senzorem a ma nažerem. Komunikace přes SSL pomocí X509 klientských certi fikátů zajišťuje integritu a autenticitu dat.

Jelikož komplexnost jednotlivých senzorů není předem určena, mo hou být platformami senzorů: •

unixové systémy,

•

operační systémy, které logují v syslog formátu (např. MS Win dows NT/2k/XP s programem Ntsyslog),

•

switche a routery,

•

firewally,

•

tiskárny.

3. Manažeři — centralizované jednotky pro zpracování dat senzorů a jejich uložení. Manažeři monou přeposílat obdržená data dalším ma nažerům nebo komponentám „protiopatření". Manažeři mohou fun govat i v distribuovaném prostředí, kdy několik manažerů přeposílá data jedinému centrálnímu manažeru. Primárním manažerem je v ba líčku Prelude Prelude-manager. 4. Komponenta „protiopatření" — provádí akce vedoucí k zastavení po dezřelého síťového provozu. Jednají na popud manažerů, kteří vy hodnocují obdržené informace od senzorů. 61


5. Frontend — webové rozhraní poskytující přehled nad jednotlivými činnostmi Prelude IDS. S Prelude IDS se distribuuje frontend Prewikka, který nad daty z databáze (kam je uložil Prelude manažer) generuje požadované výstupy. Prewikka je kompletně napsaná v Pythonu.

6.3.2 Bližší popis komponent Prelude-LML Prelude-LML (Prelude Log Monitoring Lackey) je host-based analyzátor logů. Hledá v ložích vzorky zpráv známých služeb. Může pracovat ve 2 módech:

Analyzovat logy syslog démona na lokální stanici — je možné na konfigurovat syslog, aby přijímal i syslog zprávy z ostatních síťových stanic, a tím analyzovat logy z celé sítě.

Analyzovat syslog zprávy obdržené přes protokol UDP ze sítě od dalších stanic — v tomto módu Prelude-LML poslouchá na síti a přijímá syslog logy ze síťových stanic. Prelude-LML přijaté zprávy neloguje, nemůže být proto použit jako náhrada klasického syslog démona.

Prelude-LML je napsán v jazyce C a používá pro hledání vzorků kni hovnu PCRE (Perl Compatible Regular Expression) pro regulární výrazy. S balíčkem Prelude-LML jsou distribuovány regulární výrazy pro více než 40 nejznámějších služeb a zařízení. Pravidla Prelude-LML jsou definována v IDMEF objektovém formátu, kdy samotné zpracování přijatého logu se provádí pomocí regulárních výrazů v PCRE formátu. 62

6. SOFTWARE PRO ANALÝZU SÍŤOVÉHO P R O V O Z U #LOö:Dec 30 20:09:0Í hacklab honeyd[J711]: Connection to closed port: udp (127.0.0.1:37S06 192.168.1.20:1) re gex= Connection to closed port: (tcp|udp) $([Vd\.]+):(Vd+) - <[M.]+):(Vd+)$; \ classification.text=Connection to closed port, \ id=2601;\ revision= 1; \ analyze r(0) .name=honeyd; \ analyzer(0).manufacturerwww.honeyd.org; \ analyze r(0). c las s=Honeypot; V source(ü).node.address(ü).category=ipY4-addr; V source(P).node.address(D).address=$2; \ source(10).service.port=í3; \ source(0).service.iana_protocol_name=íl; \ target^.node.address(ü).category=ipv4-addr; V targetťu).node.address(10).address=í4; \ target{10).service.port=$J; \ targeUlO). s ervic e .iana_proto c ol_name= $ 1; \ assessment.impact.completion=failed; \ assessment.impact.type=recon; \ assessment.impact.severity=medium, \ as s essment.impact.de s cription=So me one tried to connect to a closed port on the honeypot; \ last

Obrázek 6.5: Příklad Prelude-LML pravidla

Libsafe Libsafe je host-based senzor dostupný pouze pro Linux. Nebyl vyvinutý vý vojovým týmem Prelude, ale Navjotem Singhem z laboratoří Avaya. Jedná se o dynamicky zaveditelnou knihovnu, která se zavádí do paměti přes proměnnou prostředí LD_PRELOAD nebo přes záznam v /etc/ld.so.conf. Odchytává volání funkcí a nahrazuje je vlastními implementacemi těchto funkcí. Zabraňuje tak přetečení bufferu a zranitelnosti při nesprávném po užití formátovacích funkcí jako jsou sprintf, střepy, strcat a další. O pode zřelých procesech pošle Libsafe zprávu Prelude manažeru. Je také schopen posílat zprávy o přetečení bufferu e-mailem přes SMTP protokol. Prelude-Manager Prelude-manager je vícevláknový démon, který přijímá šifrované spojení od distribuovaných senzorů nebo ostatních manažerů a ukládá přijatá data ve specifikovaném formátu (databáze, log ovací soubor, e-mail apod.). Může poslouchat příchozí zprávy na unixovém soketu, na IPv4 nebo IPv6 adrese. Přijaté zprávy ukládá do jednotlivých front podle klienta, aby byla zaručena 63


férovost jejich zpracování. Při zpracování prochází zpráva také komponen tou „protiopatření", která může být nakonfigurována tak, aby reagovala na danou zprávu/útok. Zpráva z komponenty „protiopatření" končí v subsys tému reportování, kde je zpráva v IDMEF formátu převedena do různých jiných plaintext formátů a uložena do: •

Databáze mysql

•

Databáze Postgres

•

Databáze Oracle

•

Dokumentu XML v IDMEF formátu

•

Plaintextového dokumentu

Stav implementace všech vlastností Prelude-mangeru ukazuje následující tabulka. Vlastnost IDMEF komunikace se senzory SSL komunikace se sonzory Řízení protiopatření Textový výstup MySQL výstup PostgreSQL výstup XML výstup Manažer jako relay Admin konzole Reportovaní do Dshield.org*

Plán

Vývoj

Dokončeno X X

X X X X X X X X

Obrázek 6.6: Stav implementace

* Dshield.org je podobná iniciativa jako myNetWatchman, 3. osoba agregující logy ostatních. 6.3.3 Možnosti konfigurace Jelikož Prelude IDS kromě host-based IDS modulů Prelude-LML a Libsafe využívá různých komerčních i volně dostupných opensource NIDS i HIDS, které reportují zprávy o incidentech Prelude-manageru, nelze jednoznačně 64


určit, jaké protokoly Prelude IDS podporuje. Jediným jeho omezením je tak schopnost poslouchat na IPv4 nebo IPv6 adrese pro příchozí zprávy od sen zorů. Prelude IDS je možné provozovat teoreticky na všech operačních sys témech unixového typu, kde jsou dostupné balíky: GnuTLS, Python, PCRE, MySQL a PostgreSQL. Zpracování logů v operačních systémech Windows NT/2k/2k3/XP může být realizováno 2 způsoby: 1. Použitím volně dostupné aplikace NTSyslog ( h t t p : / / n t s y s l o g . s o u r c e f o r g e . n e t / ) , která je schopna posílat logy v syslog formátu Prelude-LML komponentě. Toto řešení však používá přenos dat přes UDP protokol, který nezajišťuje spolehlivé doručení. 2. Použitím lokálně nainstalovaného Prelude-LML na počítači s Win dows, zkompilovaného pod Cygwinem ( h t t p : / /www. cygwin . com), což je volně šiřitelné „linuxové" prostředí pro Windows s funkciona litou linuxového API. V každém případě musíme nadefinovat pravidla pro Prelude-LML, podle kterých se převedou zprávy logovacího démona do formátu IDMEF. Pro snadnější implementaci podpory Prelude IDS do ostatních IDS po skytuje libprelude všechny funkce senzoru nutné pro komunikaci s Preludemanagerem. V tabulce níže je vidět současný stav podpory Prelude IDS v ostatních IDS, které mohou fungovat jako senzory. Senzor Snort Nessus Nagios Argus Honeyd LibSafe SysTrace Bro IDS Hogwash AIDE

Plán

Vývoj

Dokončeno X X X X X X X X

X X

Obrázek 6.7: Stav implementace

65


6.3.4

Shrnutí

Hlavní výhodou Prelude-IDS oproti ostatním volně dostupným opensource projektům je jeho distribuovaný hybridní návrh, který není závislý na im plementaci vlastních komponent. Díky použitému IDMEF formátu zpráv je schopný Prelude-manager šifrovaně komunikovat s komerčními (pře vodem proprietárních logů do IDMEF formátu přes lokálně instalovaný Prelude-LML) i opensource senzory. Knihovna libprelude poskytuje mož nost si vytvořit vlastní komunikační rozhraní s libovolným opensource sen zorem. Tato schopnost komunikace spolu se schopností Prelude-manageru fungovat jako relay (= uzel pro přeposílání zpráv daného protokolu dal ším uzlům v síti) pro další manažery umožňuje centrálně spravovat logy senzorů distribuovaných v síti. Prelude-IDS trpí 2 zásadními problémy: 1. Neexistující komponenta protiopatření — bohužel API pro komu nikaci mezi Prelude-managerem a komponentou protiopatření ještě není vyvinuto, tak neexistuje ani žádná taková komponenta. 2. Žádné automatické notifikace — Prelude-IDS žádným způsobem au tomaticky neupozorňuje na ohlášený incident. Chybí tak jakákoliv notifikace v reálném čase incidentu. Frontendové webové aplikace (jako je Prewikka) jen na vyžádání prezentují data z databáze shro mážděná hlavním manažerem. Zdrojové kódy Prelude-LML, Prelude-manager a Prewikka jsou šířeny pod GNU GPL licencí. Pokud chcete přispívat do některé z těchto komponent pod jejich jmény, musíte převést vlastnictví vašeho kódu na společnost PreludelDS Technologies SARL. Kromě webových stránek volně šiřitelného opensource w w w . p r e l u d e - i d s . o r g existují ještě stránky komerční části projektu www. p r e l ü d e - i d s . com. Tým Prelude-IDS zde nabízí mimo jiné rošiřující komponenty pro Prelude-IDS, které jsou ale již placené. V sou časné době jsou nabízené 4 placené plug-iny: import XML výstupu softwaru Nessus; ukládání zpráv senzorů do databáze efektivnějším způsobem zajiš ťujícím rychlejší zpracování dat; propracovanější grafické webové rozhraní s integrovaným tiketovacím systémem a plug-in pro zasílání notifikací o ob držených zprávách e-mailem.

66

Kapitola 7

Sledování provozu na MU 7.1

Právní kontext

Dle směrnice č. 2/03 o Užívání počítačové sítě Masarykovy univerzity v Brně: „Síť MU je distribuovaná síť s určitým stupněm hierarchie. Síť se skládá z jednotlivých domén (podsítí), které jsou vytvářeny podle jednotlivých částí MU a jejich lokalit. Univerzitní síť je zapojena do větších celků — brněnské metropolitní sítě BAPS, české akademické sítě CESNET a glo bální sítě Internet. Globálním správcem sítě je Ústav výpočetní techniky MU (ÚVT MU), který odpovídá za provoz celouniverzitní páteře a za při pojení jednotlivých fakult a ústavů s celouniverzitní působností. Jednotlivé domény jsou spravovány těmi součástmi MU, které je vytvořily, a to v úzké spolupráci s ÚVT. Konkrétní výkon správy zabezpečují zaměstnanci Center informačních a komunikačních technologií, Laboratoří nebo Center výpo četní techniky (CIKT, ĽVT, CVT) příslušných fakult, nebo oficiálně pověření pracovníci jednotlivých kateder či ústavů (dále jen „administrátoři"). Tito pracovníci jsou zároveň styčnými osobami pro komunikaci se správcem nadřazené domény." 7.2

Logická struktura sítě

Z logického hlediska můžeme síťrozdělit na 4 části: 1. Univerzitní síť metalická nebo optická — sem patří i uživatelé při pojující se přes univerzitní VPN server ( h t t p : / / p p t p . i c s . muni . cz). 2. Univerzitní bezdrátová síť— Bezdrátová síťMU slouží k připojování mobilních počítačů studentů a zaměstnanců Masarykovy univer zity v Brně a dalších uživatelů v rámci projektu eduroam ( h t t p : / / www. eduroam. o r g , h t t p : / /www. eduroam. c z). V současné době je WiFi síť v testovacím provozu a nejsou dostupné všechny pláno vané služby (autentizace pomocí 802.1X,atd.). ( h t t p : / / p p t p . i c s . 67

7. SLEDOVÁNÍ PROVOZU NA MU

m u n i . c z ) Univerzitní bezdrátová síť stejně jako univerzitní VPN vy užívá jako šifrovaný kanál PPTP tunel. Bezdrátová vrstva je nešifrovaná, bezpečnost je zaručena nutnou autentizací vůči PPTP serveru a následným dohodnutím šifrování (přes MPPE — Microsoft Pointto-Point Encryption). Na datové vrstvě je pak zakázaná přímá komu nikace klientů mezi sebou, čímž se redukuje riziko rychlého šíření internetových červů a virů od neautentizovaných uživatelů. 3. Fakultní bezdrátové sítě — proprietární řešení přístupu k internetu přes bezdrátovou síť pod správou příslušného LVT. Taková řešení nabízejí v současné době Fakulta informatiky (dále jen FI) a sekce matematiky Přírodovědecké fakulty (dále jen Př.F.). Obě fungují na principu nezabezpečené komunikace bezdrátových klientů s přístu povými body a autentizací přes zabezpečenou webovou proxy, která umožňuje přístup bezdrátových klientů do internetu. Dokud se klient neautentizuje, je mu umožněn přístup pouze na DNS server, DHCP server (který mu přidělí veřejnou IP adresu) a webovou autentizační proxy 4. Mimouniverzitní síť. Všichni uživatelé univerzitní sítě by měli být připojeni do sítě způsobem, který jasně určuje míru zodpovědnosti za jejich práci v síti, tzn. wifi kli enti na FI se autentizují přihlašovacími údaji na unixové fakultní stroje, klienti univerzitní VPN se autentizují heslem, které je vygenerováno po au tentizací Informačnímu Systému MU, uživatelé svého počítače v kanceláři mají pevnou IP adresu atd. Jakýkoliv provoz na síti MU by měl být tedy auditovatelný ve smyslu dohledání zodpovědnosti. 7.3

Sledování provozu na M U

7.3.1 Shrnutí známých faktů Ústav výpočetní techniky (ÚVT) v současné době eviduje kolem 170 IPv4 podsítí s 24bitovou maskou sítě a přes 10 tisíc síťových uzlů s alespoň 1 IP adresou. Z hlediska používaných operačních systémů, služeb a protokolů všech vrstev je prostředí univerzitní sítě obrovsky heterogenní. Nesmíme zapomínat na specifika univerzitní sítě, jakými jsou síťová topologie a šířka přenosových pásem vysokorychlostního ethernetu (až lOGbps). lGbps je dnes naprosto běžná rychlost na páteřních metropolitních univerzitních linkách, které spojují jednotlivé organizační celky MU. Proto i efektivní 68


sledování síťového provozu v reálném čase v této síti může představovat velmi složitý problém. Nejde jen o technickou náročnost, v současné době neexistuje žádná univerzitní koncepce na sledování provozu. Podle univer zitní směrnice č. 2/03 spadá jakákoliv správa sítě do působnosti lokálních ĽVT, proto ani ÚVT nemůže do sítí spravovaných jednotlivými LVT nijak zasahovat. Podle shromážděných informací většina fakult MU provoz nijak systémově nesleduje, ale používají prostředků pro sledování sítě (programy pro odposlechy provozu, softwarové IDS apod.) až v případě jejich potřeby (např. ohlášený útok z počítače z jejich podsítě, preventivní krátkodobé sledování provozu při hledání aktivních klientů peer-to-peer sítí apod.). Výjimkami jsou: Fakulta informatiky — provozuje detekční program Jana Kasprzaka, který používá cyklický buffer pro ukládání přijatých SYN paketů a kon troluje, zda nebyly překročeny prahové průsečíky pro počet SYN paketů za jednotku času z jedné IP Tímto způsobem umí odhalit „vertikální" a „horizontální" portsken. O incidentu je poslán e-mail administrátorům, kteří podezřelé zdrojové IP adresy přidají do fakultního „blacklistu" za kázaných strojů uloženého v databázi. Z tohoto blacklistu se periodicky několikrát denně generují pravidla pro iptables, které zahazují pakety z po dezřelých IP v prerouting fázi, ještě než jsou pakety předány skupinám pravidel k filtrování. Při použité technice monitorování příchozích SYN pa ketů je možné dosáhnout jednoduše DoS útoku, když útočník podvrhne zdrojovou IP adresu paketů. Uvedené řešení je poloautomatické, adminis trátoři mohou zkontrolovat zakazované IP adresy při jejich přidávání do blacklistu, zdali např. nejsou ze sítě MU apod. Filozofická fakulta — monitoruje objem provozu přes SNMP (Simple Network Management Protocol) čítače v aktivních fakultních síťových prv cích. SNMP pracuje na aplikační vrstvě, k přenosu dat používá TCP/IP pro tokolu. SNMP má klient-server architekturu, klientská část se nazývá agent a serverová část manažer. Agent poskytuje rozhraní pro přístup k objektům v datové struktuře nazvané management information base (MIB). Všechny ob jekty jsou uspořádány do stromu, kdy ke každému objektu vede unikátní cesta. Aktuální verze MIB je MIB-II definovaná v RFC 1213. Manažer pro vádí 2 příkazy: g e t - r e q u e s t pro vyžádání si určitého objektu ze struktury MIB a s e t - r e q u e s t pro nastavení hodnot MIB objektům. SNMP řídí pří stup k MIB na základě 2 oprávnění přístupu. Public dovoluje přístup ke všem objektům MIB pouze pro čtení. Private oprávnění umožňuje hodnoty objektů i nastavovat. Jako SNMP manažer provozují na filozofické fakultě MRTG (Multi Router Traffic Grapher, h t t p : / / o s s . o e t i k e r . c h / m r t g / ) 69


na operačním systému Linux. MRTG ze vstupních dat generuje HTML stránky s grafy za různá časová období. Kromě toho má MRTG implemento ván protokol SNMR Implementace SNMP je napsána v Perlu, zbytek MRTG v jazyce C. Kromě sledování objemu provozu používají linuxový paketový firewall (iptables). Na firewallu běží IDS Snort pro notifikaci o anomáliích bez další vazby na filtrovací pravidla. ÚVT — každé 2 hodiny stahuje přes protokol UDP z centrálního switche MU logy Netflow o provozu. Netflow je technologie pro monitorování pro vozu vyvinutá společností Cisco Networks. Tok v terminologii Netflow je jednosměrný tok dat definovaný sedmicí: zdrojová IP adresa, cílová IP ad resa, typ protokolu síťové vrstvy, zdrojový port, cílový port, typ služby, vstupní logické rozhraní, ( h t t p : / / n e t f l o w . c e s n e t . c z / n _ n e t f l o w . php) Netflow umí také exportovat z aktivních prvků sumarizované infor mace o počtech paketů, objemu provozu v bajtech, TCP příznacích paketů apod. Tyto logy jsou zpětně analyzovány perlovým skriptem založeným na prahových průsečících pro jednotlivé toky, např. vysoký počet připojení z jedné IP za jednotku času symbolizující napadení stroje červem apod. ÚVT by mělo v procesu sledování hrát roli poslední instance. Odpo vědnost za monitorování vnitřního a odchozího provozu by měly převzít LVT, CVT, CIKT, které následně i incidenty řeší. Sledovat provoz na aktiv ních prvcích, přes které jsou všechny fakulty připojené, je určitě možné, ale stahovat takové objemy dat z aktivních prvků a analyzovat je by bylo jistě velmi výkonově (= časově) náročné. Při použití NetFlow se samozřejmě ne bavíme o analýze v reálném čase, spíše o data miningové aplikaci. Vzhledem k tomu, že jednotlivé faktulty v síti MU jsou připojeny gigabitovým plně duplexním ethernetem, tzn. max. teoretická propustnost sítě činí 2Gbps a využití sítě díky rostoucímu počtu připojených PC do sítě stále stoupá, není vícevrstevná analýza provozu realizovatelná na obyčejném PC. Nabízí se několik řešení: •

Paralelizace procesu analýzy — využitím hardwarového zařízení pro rozdělování provozu s následnou analýzou toků pomocí běžných PC a opensource NIDS. Z pohledu nákladů se jedná o kompromis mezi čisté softwarovým a hardwarovým řešením[14].

•

Selektivní odchytávání provozu — sleduje se pouze část síťového provozu. Jelikož se část provozu zahazuje, je důležitý způsob výběru paketů pro analýzu. Ten přímo determinuje přesnost a efektivitu analýzy. Existují 3 hlavní způsoby vzorkování: 70


1. Vzorkování náhodných paketů — z provozu vybírá každý n-tý paket. 2. Vzorkování toku — analyzuje pouze určitý tok provozu. 3. Vzorkování podle obsahu — pakety jsou vybírány podle haše jejich obsahu, který je porovnán s vybranou množinou hašů. •

Pouze analýza metadat (hlaviček paketů, informací o toku atd.) a ne obsahu paketů. Toto je proveditelné při relativně vysokých rychlos tech ethernetu i softwarovými prostředky.

•

Investovat do hardwarového NIDS.

7.3.2 Optimistický závěr Chybějící jakýkoliv koncept analýzy síťového provozu v síti MU je problém, který se musí vyřešit nejdříve pro uspokojivé systémové řešení. Vždyťv pří padě nasazení centrálně řízených NIDS, které by pomohly agregovat inci denty, by se velmi výrazně zjednodušil proces vyhodnocování podezřelého provozu. Právě vyhodnocování podezřelého provozu je pro NIDS bez zna losti širšího kontextu nejnáročnější. Stejně tak následná redistribuce nových filtrovacích pravidel na všechny NIDS by činila celý systém ještě efektivněj ším. To je výhoda, kterou v jiných necentrálně spravovaných sítích nemáme, a proto bychom ji měli využít. Webové rozhraní správy takového systému by zahrnovalo hlášení o incidentech, sledování stavu jejich řešení, tiketovací systém pro zajištění nápravy atd. Věřím, že je na jakých opensource řešeních stavět (např. použití Snortu jako in-line NIDS) a mohlo by to být tématem dalšího výzkumu na FI nebo ÚVT.

71

Kapitola 8

Vlastní program 8.1

Analýza

Jedním z úkolů mé práce bylo vytvořit pro sekci matematiky Přírodově decké fakulty Masarykovy univerzity jednoduchý program pro detekování síťových anomálií, který by různými způsoby automaticky reagoval na zjiš těný incident. Nejdříve bylo vhodné zjistit, kterými protokoly síťová zaří zení na sekci matematiky komunikují s vnější sítí. Pro tento účel jsem se rozhodl sledovat po dobu 5 pracovních dnů metadata veškerého síťového provozu mezi sekcí matematiky a okolní sítí. Celá síť sekce matematiky je připojena do metropolitní univerzitní sítě lGbps plně duplexním ethernetem přes sekční router. Routerem je PC PentiumlI 300Mhz s operačním systémem FreeBSD 4.11, který slouží zároveň jako paketový firewall. Aby nedocházelo při sledování provozu k nepřijatelné zátěži sekčního firewallu, měl jsem přístup ke všem nefiltrovaným datům na síti a nezasáhl žádným způsobem do nastavení síťových zařízení v síti sekce, zvolil jsem sledování provozu na bridgei, který jsem umístil před sekční router. Na sekci mate matiky je přibližně 130 počítačů připojených lOOMbitovým plně duplexním ethernetem. Při 100% využití šířky pásma by mohlo dojít při ukládání zachy cených paketů na disk k jejich ztrátě. Z toho důvodu jsem nejdříve několik dní pomocí programu Cacti ( h t t p : //www. c a c t i . n e t ) sledoval využití šířky pásma, kterým je sekce připojena do vnější sítě, abych měl jistotu, že následné zachytávání provozu bude realizovatelné bez ztrát paketů. Ke sledování jsem použil PC s procesorem AMD Sempron 3000+, 1GB DDR2 RAM, 2x 1Gb síťovou kartou a 160GB SÁTA pevným diskem. Bridge pra coval na operačním systému Linux, neměl přiřazenou žádnou IP adresu a síťové karty pracovaly v promiskuitním módu. Pro samotné zachytávání provozu jsem použil program t e p dump. Abych co nejvíce omezil zátěž ce lého systému, potlačil jsem vypisovaní odchycených dat na konzoli a data ukládal na disk v binárním formátu. 5 pracovních dnů jsem odchytával hla vičky všech paketů. Za tu dobu narostl celkový objem odchycených dat na 15,5 GB v binárním formátu tcpdumpu, což představovalo přes 135 mili72

8. V L A S T N Í P R O G R A M

ónů paketů. Při analýze odchycených metadat jsem se zaměřil na protokoly transportní vrstvy a protokoly vyšších vrstev. Ze statistiky odchycených paketů níže vidíme, že počítače na sekci komunikují pouze přes transportní protokoly UDP a TCP. Protokol TCP UDP ICMP Celkem

počet paketů 133270738 1691838 512962 135475538

část v % 98,37 1,25 0,38 100

Obrázek 8.1: Statistika odchycených paketů transportních protokolů a pro tokolu ICMP

Následující tabulka ukazuje statistiku pokusů o navázání spojení (po čet TCP SYN paketů) na služby poskytované sekčním serverem queen za 1 den. Zajímavý je poměr celkového počtu připojení na běžící služby (na něž pro zjednodušení můžeme pohlížet jako na legitimní připojení) a počtu pokusu o připojení na zavřené porty, kde žádné služby neběží (v tabulce jako „ostatní"). Název služby ftp ssh telnet smtp pop3 netbios imap samba imaps pop3s ostatní Celkem

číslo portu 21 22 23 25 110 139 143 445 993 995 X

počet paketů 2 10 1 12 23 0 7 22 15 0 213

X

X

část v % 0,66 3,28 0,33 3,93 7,54 0 2,30 7,21 4,92 0 69,84 100

Obrázek 8.2:

73


8.2

Popis

Primárním požadavkem na detekční program nebylo vytvořit komplexní IDS s obrovskou funkcionalitou, ale spíše realizovat vhodné (třeba i minima listické) konfigurovatelné řešení pro potřeby sekce matematiky s možností automatické reakce na incident. Detekční program jsem se rozhodl nasadit přímo na sekčním routeru/firewallu ze 2 hlavních důvodů: 1. na routeru je možné monitorovat oba směry komunikace, čímž mohu omezit možnost „obelhat" detekční algoritmus, viz použité metriky — výhoda symetrického routování je zřejmá. V komerční sféře není výjimkou routování asymetrické dané cenovou politikou, politickými důvody apod. Naštěstí zajištění symetrického routování by pro jed notlivé podsítě univerzity neměl být žádný problém. 2. snadná interakce s paketovým firewallem umožňující efektivní re akce na incidenty. Návrh řešení vychází z potřeby detekovat anomálie TCP provozu za ložené na vyčerpání systémových prostředků (např. SYNflood), řešení by mělo také detekovat vertikální a horizontální skenování portů. Použité me triky a technika detekce umožňuje také zachytit šíření některých počíta čových červů a virů. K detekci jsem použil techniku agregace. Při použití agregace jsem musel řešit 2 problémy: 1. Problém nevhodného predikátu agregace — může vést ke generování poplašných zpráv nebo může existující útok agregovat způsobem, který naopak žádný poplach nespustí. 2. Problém cíleného oklamání algoritmu — útočník může empirickým výzkumem odhalit princip detekčního algoritmu a pak vytvořit zprávy, které jsou škodlivé, ale vypadají jako legitimní provoz nebo se snaží přesvědčit detekční algoritmus o cizí identitě útočníka. Program využívá několik jednoduchých metrik s prahovým průsečíkem, které také determinují jeho funkcionalitu: 1. Počet TCP paketů s unikátní dvojicí cílová IP adresa, cílový port za jednotku času — detekuje synflood, vyčerpání síťového bufferu. 2. Počet TCP paketů s unikátní dvojicí zdrojová IP adresa, cílová IP ad resa za jednotku času — tato metrika popisuje „vertikální" portsken, tedy skenování portů síťového uzlu. 74


3. Počet TCP paketů s unikátní dvojicí zdrojová IP adresa, cílový port za jednotku času — tato metrika popisuje „horizontální" portsken (viz portsweep). Všechny metriky jsou založeny na sledování stavu čítače (periodicky v určitých intervalech nastavovaného na 0), který se inkrementuje při při jetí příchozího TCP paketu se SYN příznakem a dekrementuje se při přijetí odchozího paketu s FIN příznakem. Směr toku je relativní ke konfiguraci naší podsítě, viz 8.3 Možnosti konfigurace níže. Využívám symetrického routování a k dekrekmentaci čítače toku používám odchozí FIN paket, aby útočník nemohl posílat stejné množství příchozích SYN a FIN paketů a tím maskovat svůj provoz jako legitimní. Podvržené FIN pakety pošle s dosta tečně nízkým TTL, aby paket prošel detekčním algoritmem na vstupu do naší sítě, ale již nedorazí k cílovému počítači (více v kapitole 5.3 o obcházení IDS). Donutit vzdálený síťový uzel k poslání F IN paketu „na vyžádání" bez předchozího navázání TCP spojení není možné. V optimálním případě, kdy je každé TCP spojení zahajováno příchozím SYN paketem a ukončováno obousměrným posláním FIN paketu, by měl být čítač stále roven 0. V praxi to tak ale z následujících důvodů nebývá: •

Spojení může být delší než časové okno detekce, SYN paket legitim ního spojení pak může být v jiném okně než korespondující F IN paket na konci tohoto spojení.

•

Prioritizace paketů při routování může způsobit analogický problém jako v 1. bodě, kdy SYN a F IN pakety jsou v různých časových oknech.

•

Asymetrie mezi počty SYN a FIN paketů. SYN paketů bývá v praxi více než FIN paketů, například z důvodu určení správného MTU. Při ukončování spojení je již správné MTU známo, tak není potřeba posílat více FIN paketů. Z důvodů ztráty paketu po projití naším detekčním programem může docházet i k přeposlání FIN paketu.

•

Některá spojení jsou místo FIN paketu ukončována RS T. Bohužel dle RFC 793 odpovídá TCPstack na S YN paket na zavřený port RS T pake tem, takže není možné dekrementovat čítač toku po přijetí odchozího RS T paketu.

8.3

Možnosti konfigurace

Program běží jako démon, který pro odchytávání paketů ze sítě využívá knihovnu libpcap[21] s těmito konfiguračními volbami: 75


Listening device — síťové rozhraní, na kterém budeme odchytávat pakety. Homenetwork(s) — definování vlastních podsítí, aby bylo možné rozlišit odchozí a příchozí provoz. Používá se formát adresa_sítě/počet_bitů_masky Příklad nastavení: 147.251.80.0/24. TCP_detect — určuje aktivní detekční pravidla protokolu TCP. Výsledné na stavení tvoří součet jednotlivých možností: 0 - nic nedetekovat, 1 - synflood, 2 - portsken, 4 - portsweep. Příklad nastavení: 7. TCP_synflood_time_window — časový interval (v sekundách) pro prahový průsečík pro synflood. Tento interval musí korespondovat s velikostí paketového bufferu dle šířky pásma provozované linky. Příklad nastavení: 30. TCP_synflood_threshold — prahový průsečík detekce synfloodu. Příklad nastavení: 10. TCP_synflood_react_type — typ reakce na zjištěný synflood incident. Vý sledné nastavení tvoří součet jednotlivých možností: 0 - nereagovat, 1 upozornění e-mailem, 2 - blokace zdrojové IP adresy na firewallu, 4 - na stavení limitů připojení pro danou IP adresu. Validní nastavení je současné nastavení pouze jedné z možností 2 nebo 4. Příklad nastavení: 3. TCP_portsweep_time_window — časový interval (v sekundách) pro pra hový průsečík pro portsweep. Tento interval musí korespondovat s velikostí paketového bufferu dle šířky pásma provozované linky. TCP_portsweep.threshold — prahový průsečík detekce portsweepu. TCP-portsweep_reac_type — typ reakce na zjištěný portsweep incident. Vý sledné nastavení tvoří součet jednotlivých možností: 0 - nereagovat, 1 upozornění e-mailem, 2 - blokace zdrojové IP adresy na firewallu, 4 - na stavení limitů připojení pro danou IP adresu. Validní nastavení je současné nastavení pouze jedné z možností 2 nebo 4. TCP_portscan_time_window — časový interval (v sekundách) pro prahový průsečík pro portsken. Tento interval musí korespondovat s velikostí pake tového bufferu dle šířky pásma provozované linky. TCP_portscan_threshold — prahový průsečík detekce portskenu. TCP_portscan_react_type — typ reakce na zjištěný portsken incident. Vý sledné nastavení tvoří součet jednotlivých možností: 0 - nereagovat, 1 upozornění e-mailem, 2 - blokace zdrojové IP adresy na firewallu, 4 - na stavení limitů připojení pro danou IP adresu. Validní nastavení je současné nastavení pouze jedné z možností 2 nebo 4. Packet_buffer_size — velikost bufferu (počet paketů) pro příjem TCP pa ketů ze sítě. Velikost paketového bufferu by měla korespondovat s časovým intervalem pro detekci jednotlivých anomálií. Nastavení je závislé na šířce 76


přenosového pásma použité linky a jejím vytížení. Příklad nastavení: 1000. TCP_exclude_port — z detekce TCP anomálií se vyloučí připojení na zadané porty. Příklad nastavení: 25, 80,143. SMTP_server — IP adresa SMTP serveru pro odesílání notifikací o zjištěné anomálii e-mailem. Příklad nastavení: 147.251.80.11. Alert_e-mail — seznam e-mailových adres adresátů upozornění o anomálii. Příklad nastavení: [email protected]. Add_fw-command — název spustitelného souboru pro nastavení filtrovacích pravidel firewallu. Příklad nastavení: \sbin\pfctl. React_max_conn — maximální počet připojení ze zdrojové IP, slouží k na stavení limitů pro připojení. Příklad nastavení: 5. React_max_conn_rate — maximální počet připojení za počet sekund ze zdro jové IP, slouží k nastavení limitů pro připojení. Příklad nastavení: 15/5 (na stavení 15 připojení za 5 sekund).

8.4

Reakce na incident

Vzhledem k ne zcela efektivní technice zasílání TCP RST paketů pro přeru šení spojení jsem možnost reakce na incident omezil na zablokování zdro jové IP adresy na firewallu nebo na nastavení limitů připojení z dané IP adresy. Obě reakce jsou realizovány vygenerovaním pravidel pro lokální paketový firewall (konkrétně ipf), ale může být volaný libovolný spusti telný soubor, takže je možné pro reakce použít např. linuxové iptables nebo pfz OpenBSD. Notifikaci o incidentu je možné posílat e-mailem na zvolené adresy, takže administrátoři jsou o incidentu okamžitě uvědomeni a mohou na něj odpovědně reagovat. 8.5

Shrnutí

Program je kompletně napsán v jazyce C, kromě binárních souborů pro úpravu filtrovacích pravidel v jádře operačního systému nevolá žádné další externí binární soubory. Je snadno konfigurovatelný a měsíčním provozem v ostrém provozu je ověřena jeho funkčnost. Problémem může být neexistu jící procedura pro nastavení počátečních konfiguračních hodnot pro danou linku a síťový provoz, ale to bychom se již zabývali tématy nad rámec mé práce. Věřím, že se mi podařilo implementovat jednoduše konfigurovatelný detekční program schopný uspokojivě fungovat v reálném prostředí síťo77


vého provozu sekce matematiky Př.F..

Kapitola 9

Závěr Počet zařízení v internetu neustále roste. Společně s připojováním nových stanic roste i potřeba vyšších přenosových rychlostí sítí, a to nejen z dů vodu více síťových klientů, ale také nástupem služeb náročnějších na rych lost připojení. Dnes se pomalu stávají standardem hlasové služby, video na vyžádání nebo televizní vysílání, které jsou poskytovány po datových sítích, nejčastěji po internetu. Dnešní hardware osobního počítače je na po dobné služby dostatečně dimenzovaný, ale nepodařilo se mu udržet krok s rychlostí evoluce v počítačových sítích. V roce 1965 zformuloval Gordon Moore, spoluzakladatel Intelu, tzv „Moorův zákon", který tvrdil, že počet tranzistorů v procesorech se každých 18 měsíců zdvojnásobí. Tomu zhruba odpovídá i nárůst výkonu. Ve skutečnosti je růst rychlosti počítačových sítí ještě rychlejší, jak předpovídal „Gilderův zákon[10]". V roce 1995 George Gilder prohlásil, že přenosová šířka pásma sítě roste minimálně 3x rychleji než výkon procesoru. Tato tvrzení potvrzuje fakt, že za posledních 10 let vzrostl výkon procesorů osobních počítačů zhruba 15x, zatímco přenosová rychlost sítí se zvedla lOOx, a to se bavíme o hardwaru, který bychom našli pomalu v každé kanceláři. S rostoucí rychlostí sítě roste také rychlost pro vádění jednotlivých útoků, která si vynucuje adekvátně rychlou reakci. Za takových podmínek je potřeba hledat nové cesty vývoje NIDS, které by byly schopné analyzovat provoz v reálném čase bez významného zpoždění. Ve své diplomové práci jsem představil současné techniky analýzy sí ťového provozu a teoretické základy, na kterých stojí. Ukázal jsem několik technik obcházení NIDS ze strany útočníka i to, jaké techniky by měly mít moderní NIDS implementovány, aby těmto útokům úspěšně čelily. Popsal jsem několik softwarových NIDS, které by měly reprezentovat různé přístupy k problematice sledování provozu. Prezentované softwa rové NIDS nejsou vzhledem k jejich zcela odlišným návrhům přímo porov natelné. I přesto že Snort ovládá řadu detekčních technik nestandardního provozu, chybí mu, stejně jako ostatním v mé práci uvedeným programům, jakákoliv možnost notifikace v době události. Při každodenní práci systé mových administrátorů je těžko představitelné procházet několikrát denně 79

9. ZÁVĚR logy a hledat v nich podezřelé zprávy. Také tento nedostatek jsem se snažil odstranit návrhem a implementací vlastního programu pro detekci ano málií síťového provozu. Kód programu je poměrně dobře strukturován a umožňuje tak v budoucnu jednoduché rozšíření o nové detekční techniky a podporu dalších protokolů. Za zhruba měsíc, kdy byl detekční program nasazen v ostrém provozu na sekci matematiky Př.F., detekuje průměrně 1 incident denně. Plané po plachy se vyskytují minimálně a jsou zapříčiněny hlavně nepřesným po čátečním nastavením prahových hodnot detekčních algoritmů. Proto se je jich počet v čase postupným upřesňováním parametrů rapidně snižuje. Po krátkém přiblížení specifického prostředí univerzitní sítě a možnosti sle dování provozu v ní, jsem došel k závěru, že implementovaný detekční program může být vhodným doplňkem některého robustnějšího IDS jako je například Snort. Přitom pro hostitelský počítač nepředstavuje můj detekční program žádný významný nárůst zátěže.

80

Literatura [1] Ip security h t t p : / / e n . w i k i p e d i a . o r g / w i k i / I P S e c . [2] Request for comments. rfcsearch.html.

http://www.rfc-editor.org/

[3] Cert advisory ca-2001-19 „code red" worm exploiting buffer overflow in iis indexing service dll. h t t p : //www. c e r t . o r g / a d v i s o r i e s / CA- 2 0 0 1 - 1 9 . h t m l , 2001. [4] Cert advisory ca-2001-26 nimda worm, h t t p : / / w w w . c e r t . o r g / a d v i s o r i e s / C A - 2 0 0 1 - 2 6.html,2005. [5] The intrusion detection message exchange for mat, http://www.ietf.org/internet-drafts/ d r a f t - i e t f - i d w g - i d m e f - x m l - 1 6 . t x t , březen 2006. [6] P. Biondi. Network packet manipulation with scapy h t t p : / /www. s e c d e v . o r g / p r o j e c t s / s c a p y , 2005. [7] G. Danezis. Introducing traffic analysis: Attacks, defences and public policy issues... h t t p : / / , 2005. [8] Mark W. Eichin and Jon A. A. Rochlis. With microscope and tweezers: An analysis of the internet virus of november 1988. In Proceedings of the 1989 IEEE Computer Society Symposium on Security and Privacy, Oakland, Ohio, 1989. [9] Fyodor. nmap. h t t p : //www. i n s e c u r e . o r g / n m a p / m a n / , 2001. [10] G. Gilder. Fiber keeps its promise. Forbes, duben 1997. [11] J. Hall. Multi-layer network monitoring and analysis. PhD thesis, 2003. [12] horizon <[email protected]>. Defeating sniffers and intrusion de tection systems. Phrack Magazine, Volume 8, prosinec 1998. 81

9. ZÁVĚR [13] S. Lee K. Johansen. Cs424 network security: Bayesian network intrusion detection (bnids). h t t p : //www. e s . j h u . e d u / ~f a b i a n / c o u r s e s / CS60 0.42 4 / c o u r s e _ p a p e r s / s a m p l e s / B a y e s i a n . p d f , květen 2003. [14] R. Kompella, S. Singh, and G. Varghese. On scalable attack detection in the network, 2004. [15] C. Kruegel, F. Valeur, G. Vigna, and R. Kemmerer. Stateful intrusion detection for high-speed networks, květen 2002. [16] M. Patrignani L. Colitti, G. D. Battista. Ipv6-in-ipv4 tunnel discovery: methods and experimental results. In IEEE Transactions on Network and Service Management, duben 2004. [17] Ch. Kreibich M. Handley, V. Paxson. Network intrusion de tection: Evasion, traffic normalization and end-to-end protocol seman tics, h t t p : / / w w w . u s e n i x . o r g / e v e n t s / s e c 0 1 / f u l l _ p a p e r s / h a n d l e y / h a n d l e y . pdf, 2001. [18] C. of Europe. Cets no. 185 - convention on cyber crime, h t t p : / / c o n v e n t i o n s . c o e . i n t / T r e a t y / e n / T r e a t i e s / Html / 1 8 5 . htm, listopad 2001. [19] Thomas H. Ptacek and Timothy N. Newsham. Insertion, evasion, and denial of service: Eluding network intrusion detection. Technical re port, Secure Networks, Inc., Suite 330, 1201 5th Street S.W, Calgary, Alberta, Canada, T2R-0Y6, leden 1998. [20] M. Roesch. Snort: Lightweight intrusion detection for networks. In: Proc. 13th Systems Administration Conference (LISA), 1999. [21] C. Leres S. McCanne and V. Jacobson. t e p d u m p . o r g / p c a p 3 _ m a n . h t m l , 1994.

Libpcap.

http://www.

[22] Scampi. Recommendations for next generation monitoring systems. h t t p : //www. i s t - s c a m p i . o r g / p u b l i c a t i o n s / d e l i v e r a b l e s / D l . 4 .pdf, leden 2005. [23] U. Shankar and V. Paxson. Active mapping: Resisting nids evasion without altering traffic, 2002.

82

Příloha A

Schéma zapojení pasivního 100Mbit Tap zařízení

• • • • HOST

TAP A

TAPE

HOST

Obrázek A. 1:

Pokud chcete použít Tap zařízení na plně duplexním ethernetu, pak bude jeden směr toku v portu „Tap A" a opačný směr toku v portu „Tap B".

83

Příloha B

Obsah CD

dp.pdf dp.tex dp.bib /sniffer/

Diplomová práce ve formátu PDF. Zdrojový soubor diplomové práce ve formátu KTpX. Zdrojový soubor použité literatury ve formátu KTj;X. Adresář se zdrojovým kódem vlastního programu pro sledování nestandardního síťového provozu.

84

Analýza síťového provozu

Recommend Documents