Honnan ered és hogyan működik? Történet és fejlődés

Ellenőrzések, pásztázások

1. oldal [13] 2004-02-12 – Rigó Ernő – MTA-SZTAKI IKK– [email protected]

Honnan ered és hogyan működik? Történet és fejlődés. Az első hivatalos, hálózati pásztázásra is alkalmas eszköz, a „ping” 1983 decemberében született. Működése az operációs rendszer által megvalósított IP/ICMP protokoll üzenetein alapul: egy hálózatra kötött számítógépnek az echo-request üzenet fogadásakor az echo-reply üzenettel válaszolhat a feladónak, ezzel jelezve hálózati elérhetőségét. A feladó az üzenet feladása és vétele közt eltelt időből következtethet a hálózati összeköttetés késleltetésére. A ping létrejöttét a Berkeley Research Labs IP hálózatának rejtélyes működése ihlette, alkotójában nem merült fel az azóta minden Internetre kötött számítógépen fellelhető kis program hálózatbiztonsági alkalmazásának lehetősége. Ez a megállapítás a közelmúltig hivatalosan megjelenő ellenőrző, pásztázó alkalmazások mindegyikére igaz, ugyanis első sorban a „fekete kalapos” biztonsági szakértők munkáiról van szó: az élet többi területéhez hasonlóan először a rosszindulatú támadások és az ezeket támogató eszközök jelentek meg, majd ezeket követték a támadások elleni védekezés módszerei. Mint ahogy az autóiparban a törésteszt, az internetes hálózati védelem ellenőrzésében is nagyszerű módszernek bizonyult a kockázati tényezők csökkentésében a valós támadási szituációk mesterséges előállítása, ehhez azonban itt is szükség volt a támadásokat támogató eszközökre. Egy ilyen szimulált támadás menete, és ennek megfelelően főbb eszközei megfelelnek egy valódi támadásra jellemzőknek: első lépésben egy host scannerrel megkeresi azokat a számítógépeket (IP címeket), melyek a választott címtartományban elérhetőek, ezután az elérhető gépek által nyújtott szolgáltatások port scannerrel történő felderítésére van szükség, amit a szolgáltatások security scannerrel való ellenőrzése követ. A host scanner működése a már említett ping programhoz hasonló, sőt sok esetben teljesen azonos: az ellenőrzést végző gép egy próbacsomagot küld a célgép hálózati címére, majd válaszra vár. A válasz elmaradása egyet jelent azzal, hogy a célgép nem elérhető. Már ez az információ is nagyon fontos lehet, hisz alkalmas a hálózat alapvető logikai felépítésének feltérképezésére, felfedi azokat a gépeket is, melyek nem feltétlen nyújtanak szándékosan publikált szolgáltatásokat, de elérhetőek. A port scanner feladata a célgép egyenként 65535 TCP és UDP portja közül megkeresni azokat, amelyeket a gépen futó valamely alkalmazás nyitva tart. A működés alapvetően itt is a „kérésválasz” módszerrel zajlik: az ellenőrző gép kapcsolatot próbál kezdeményezni a célgép adott portján keresztül, ha sikerrel jár, tudja, hogy a kérdéses port nyitva van, azaz a porton a célgép valamilyen szolgáltatást nyújt. Ezután következik a legszerteágazóbb feladatot végrehajtó program, a security scanner, melynek tárházában a célgépen nyitva talált portokhoz tartozó szolgáltatások specializált ellenőrzésére alkalmas tesztek várnak kipróbálásra. Egy ilyen teszt két csoportba tartozhat: – A fenyegetettségi teszt csak a szolgáltatást végző kiszolgáló program létének, típusának, verziószámának eldöntéséből von le következtetést az ezekhez tartozó ismert hibák és támadási lehetőségek vonatkozásában. – A behatolási teszt a rosszindulatú felhasználó viselkedésének szimulációjából, elérési jogosultságok ellenőrzéséből, sőt, esetleg károkozásra alkalmas szolgáltatás túlterhelési támadásból (denial of service attack, DoS), vagy a kiszolgáló szoftver puffer-túlcsordulásának előidézéséből is következtethet egy valódi támadás lehetséges eredményeire. A figyelmet érdemes még felhívni arra, hogy az ellenőrzést végző és az ellenőrzött gép nem feltétlen különbözik egymástól, sőt léteznek olyan security scannerek, melyek nem is alkalmasak hálózati működésre. Ezek általában a helyi futtatásból származó helyzeti előny miatt fenyegetettségi tesztek végzésére különösen alkalmasak, viszont a behatolási tesztelés eredményeinek megbízhatóságát nagymértékben befolyásolhatja, ha egy gép saját magát teszi próbára. A host, port és security scannerek által begyűjtött információkat, a tesztek eredményeit egy teljes alhálózat ellenőrzésekor általában összesített statisztika formájában érdemes megtekinteni, ezután



nyílik lehetőség a kockázatok elemzésére és megfelelő kezelésére, vagyis a szükséges biztonsági frissítések, védelmi megoldások alkalmazására. Bizonyos idő elteltével érdemes lenne megismételni a teljes szimulált támadás alapú ellenőrzést, ez azonban sok erőforrást és időt vesz igénybe, ezért sok esetben előnyösebb úgynevezett „követő ellenőrzést” végezni, ahol csak az előző ellenőrzés óta nyilvánosságra került biztonsági rések vonatkozásában kell csak az egész alhálózatot újra áttekinteni. A hálózatbiztonsági pásztázások és ellenőrzések fejlődésére jellemző, hogy a támogató eszközök fejlődésével párhuzamosan nyílt csak lehetőség a teljes szimulált támadási folyamat automatikus elvégzésére, vagyis kezdetben csak a legegyszerűbb host scanner funkció volt bárki számára elérhető, majd később napvilágot láttak különböző port scanner eszközök, és csak az utóbbi években vállt jellemzővé a nem ritkán üzleti forgalomban kapható security scannerek elterjedése. A publikus eszközök hiánya azonban nem jelentette soha az ellenőrzés megvalósíthatatlanságát, csupán jóval több szakértelmet igényelt a művelet végzőjétől. A mai napig nem megoldott, és a mesterséges intelligencia további fejlődéséig nem is lesz automatikusan megoldható egy hálózat teljes körű biztonsági ellenőrzése.

Mi ellen véd? Kockázatcsökkenés módja. A hálózatbiztonsági pásztázások és ellenőrzések közvetlenül nem nyújtanak védelmet a támadások ellen, sőt a károkozásra alkalmas behatolási tesztek növelik is a közvetlen kockázatot, céljuk inkább az információszerzés, rávilágítás a kritikus, vagy erősebb védelemre szoruló pontokra egy hálózatban.

Melyiket a sok közül? Bemutatások, főbb típusok előnyei és hátrányai. Host scanning ping

A – már említett – ping program használata a legegyszerűbb, az icmp echo-request üzenetekre küldött echo-reply válaszüzenetek alapján legtöbbször ma már csak a hálózat működőképességét érdemes ellenőrizni, abban az esetben, ha a célgép ismerten válaszol az ilyen kérésekre. Egy ilyen felhasználásra példát mutatunk be az alábbiakban: [mcree@pakk:~]$ ping lutra.sztaki.hu PING lutra.sztaki.hu (193.225.86.11): 56 data bytes 64 bytes from 193.225.86.11: icmp_seq=0 ttl=254 time=0.4 ms 64 bytes from 193.225.86.11: icmp_seq=1 ttl=254 time=1.9 ms 64 bytes from 193.225.86.11: icmp_seq=2 ttl=254 time=1.4 ms --- lutra.sztaki.hu ping statistics --3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.4/1.2/1.9 ms

A ping parancs paraméterezése az első sorban láthatóan egyszerű, csak a célgép címét (lutra.sztaki.hu) kell megadni, ennek hatására 1 másodpercenként echo-request csomagot küld. A visszaérkezett válaszok fontos jellemzőit a „64 bytes from...” kezdetű három hasonló sor hordozza. Az icmp_seq a csomag sorszáma, a ttl a maradék „time to live”, vagyis a válasz visszairányítása során még közbeiktatható routerek maximális száma, a time pedig a választ kiváltó echo_request kérés, és a válasz megérkezte közt eltelt idő. Ha eltekintünk az adatok hálózat-minőségi értelmezésétől, vagyis csak a pásztázási célokra való felhasználhatóságukat tekintjük, a parancs kimenete egy soros is lehetne, mivel csak arra vagyunk kíváncsiak, az adott hálózati cím mögött



figyel-e valaki. Egyes operációs rendszerekkel szállított ping verziók alapértelmezésben ennek megfelelően csak „host is alive” vagy „no answer from host” üzenetekkel válaszolnak. Port scanner felhasználása host scannerként

Fontos megjegyezni, hogy sok tűzfal eldobja az icmp echo-request és echo-reply üzeneteket, ezért nem vonhatóak le feltétlen következtetések egy ping próba eredményéből, szükség lehet további ellenőrzésekre. Ennek legegyszerűbb módja az lehet, hogyha a host scannert teljesen kihagyjuk a pásztázási műveletből, és egyenesen a port scannert irányítjuk a letapogatni kívánt címtartományba, a ping módszer által eldöntendő kérdést úgy fogalmazzuk át, hogy egy host akkor elérhető, ha a port scanner talált rajta nyitott, vagy zárt portot, és akkor nem elérhető, ha semmilyen választ nem sikerült kapnia. A módszer hátránya természetesen a nagy időigényben rejlik: a ping program egy üzenetváltással eldöntötte az elérhetőséget, viszont a port scanner technikával nagyságrendekkel több üzenetre is szükség lehet. Példaképp megmutatjuk a 4 gépből álló 193.225.86.0/30 IP tartomány port scannerrel való végigpásztázásának eredményét. Az ellenőrzés során csak a 80-as TCP portot (-p 80), vagyis a web szolgáltatást vettük alapul a gyorsaság érdekében, további portok megadásával megbízhatóbb eredményeket érhettünk volna el: [root@pakk:~]# nmap -P0 -p 80 --randomize_hosts 193.225.86.0/30 Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-02-26 09:03 CET Interesting ports on ns2.sztaki.hu (193.225.86.1): PORT STATE SERVICE 80/tcp closed http Interesting ports on 193.225.86.0: PORT STATE SERVICE 80/tcp closed http Interesting ports on violin.sztaki.hu (193.225.86.2): PORT STATE SERVICE 80/tcp filtered http Interesting ports on debella.ikk.sztaki.hu (193.225.86.3): PORT STATE SERVICE 80/tcp open http Nmap run completed -- 4 IP addresses (4 hosts up) scanned in 0.055 seconds

A legfontosabb eredmény mezők a „STATE” alatt található állapotjelzések, ezek esetünkben a következő három értéket vehetik fel: – closed: a web szolgáltatás ugyan nem elérhető, de a tesztelt host működik, hisz a kapcsolatfelvételi próbálkozásra ICMP port-unreachable választ küldött. – open: a web szolgáltatás elérhető, vagyis a tesztelt host bizonyosan működik. – filtered: a tesztelt host felől semmilyen válasz nem érkezett, ezért a port scanner arra következtet, hogy tűzfal védi a web szolgáltatáshoz tartozó portot, és a rá érkező üzeneteket válasz nélkül eldobja. Ebből azonban arra is következtethetünk, hogy a célgép nem elérhető. Látható, hogy egy tűzfal által teljesen védett, és egy kikapcsolt gépet nehéz megkülönböztetni, azonban pásztázási és ellenőrzési szempontból ez a két állapot jóformán megegyezik, hisz nehezen található biztonsági rés olyan gépen, mely a külvilágot (vagy legalábbis az ellenőrzést végző gépet) semmilyen válaszra nem méltatja. Az eredmények alapján, a port scanner összesítő sorával ellentmondva megállapíthatjuk, hogy a 4 gépes tartományból egy gép nem elérhető, három gép elérhető, sőt ezek közül egy pedig még http szolgáltatást is nyújt.



Port scanning IP protokoll scan

A port scanner első feladata, hogy eldöntse, egyáltalán milyen IP alapú protokollok érhetők el a célszámítógépen. A scan során a pásztázó állomás egy olyan IP csomagot küld a célgépre, amelynek protokoll mezőjét az ellenőrizni kívánt protokoll kódjára állítja, azonban a protokoll-specifikus adatmezőt a csomagban 0 byte méretűnek jelzi. Az ilyen IP csomag kibontása során a célgép operációs rendszere megvizsgálja a protokoll-kód mezőt és ha számára ismeretlen kérést talál benne, a feladónak ICMP protcol-unreachable üzenetet küld. Egy ilyen ellenőrzésre mutatunk példát az egyik legelterjedtebb, általános mintaként is felhasználható port scanner, az nmap segítségével: [root@pakk:~]# nmap -sO lutra.sztaki.hu Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-02-26 08:27 CET Interesting protocols on lutra.sztaki.hu (193.225.86.11): (The 250 protocols scanned but not shown below are in state: closed) PROTOCOL STATE SERVICE 1 open icmp 2 open igmp 4 open ip 6 open tcp 17 open udp 103 open pim Nmap run completed -- 1 IP address (1 host up) scanned in 28.456 seconds

Fontos megjegyezni, hogy bizonyos operációs rendszerek nem foglalkoznak az ICMP protocolunreachable üzenet visszaküldésével, hanem az ismeretlen formátumot célzó IP csomagot egyszerűen eldobják. Ez lehetetlenné teszi a megbízható protokoll felismerést. TCP connect() scan

Mivel az internetes szolgáltatások java része TCP/IP protokollon működik, elsődleges fontosságú, hogy a port scanner a nyitott TCP portokról információt szolgáltasson. A legegyszerűbb módszer egy TCP port nyitottságának vizsgálatára, ha megpróbálunk csatlakozni hozzá a minden operációs rendszer által támogatott connect() rendszerhívással. Ez a rendszerhívás a TCP protokoll normál működésével összhangban háromutas kézfogást (3-way handshaking) végez a célgéppel. A későbbi port scan módszerek megértéséhez lássunk egy példát. Az ellenőrzést végző, vagyis kapcsolódni kívánó hostot hívjuk A-nak, az ellenőrzött hostot pedig B-nek. Kezdetben B célportja LISTEN állapotban van. Ekkor a sikeres kapcsolatfelvétel lépései: 1. A egy tetszőleges SEQ(A) sorszámmal SYN (synchronize sequence numbers) jelzéssel ellátott üzenetet küld B-nek, aki ettől SYN-RECEIVED állapotba kerül. példa: A ---[ <SEQ=100> ]---> B 2. B válaszként egy saját, szintén tetszőleges SEQ(B) sorszámmal, valamint SEQ(A)+1 ACK (acknowledgment) sorszámmal SYN,ACK jelzésekkel ellátott üzenetet küld A-nak. példa: A <---[ <SEQ=300> ]--- B 3. A válaszként egy SEQ(A)+1 sorszámú, SEQ(B)+1 ACK értékű ACK jelzéssel ellátott üzenetet küld B-nek, melytől B ESTABLISHED állapotba kerül, azaz a kapcsolat felépülését nyugtázza. példa: A ---[ <SEQ=101> ]---> B A folyamat során A már az első üzenet küldése után ICMP port-unreachable üzenetet kap, vagy nem kap választ, ha B célportja nem LISTEN állapotban van. A TCP connect() scan legnagyobb hátránya, hogy a pásztázni kívánt gépen futó alkalmazás a



kapcsolat teljes felépítése, majd annak azonnali lezárása révén feltétlenül értesül arról, hogy az port scanner leellenőrizte. Mivel minden egyes hoston 65536 portot kell leellenőrizni, a különböző programok „kapcsolat megszakadt”-jellegű hibaüzenetei teleszemetelik a naplófájlokat, sőt az erőszakos, rossz szándékú letapogatási próbálkozások ellen rendszerbe állított port scanner detectorok vészhelyzetet érzékelve az ellenőrző gépet kitilthatják vagy blokkolhatják ezzel meghamisítva az eredményeket. A probléma megoldására két lehetőség nyílik: vagy a port ellenőrzést kell jelentősen lassítani például egy egész IP tartomány párhuzamos ellenőrzésével, hogy egy célgépre adott idő alatt kevesebb próbálkozás jusson, vagy tartózkodni kell a TCP kapcsolatok teljes felépítésétől, lehetőleg a port scanner detector alkalmazások megtévesztésére is tekintettel kell más pásztázási módszereket keresni. TCP connect() scan példának ismét az nmap port scanner egy kimenetét hozhatjuk: [root@pakk:~]# nmap -sT lutra.sztaki.hu Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-02-26 10:21 CET Interesting ports on lutra.sztaki.hu (193.225.86.11): (The 1638 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 13/tcp open daytime 21/tcp open ftp 22/tcp open ssh 23/tcp open telnet 25/tcp open smtp 37/tcp open time 80/tcp open http 110/tcp open pop3 143/tcp open imap 221/tcp open fln-spx 223/tcp open cdc 443/tcp open https 993/tcp open imaps 995/tcp open pop3s 2049/tcp open nfs 3000/tcp open ppp 3306/tcp open mysql 4045/tcp open lockd 5001/tcp open commplex-link 8007/tcp open ajp12 10000/tcp open snet-sensor-mgmt Nmap run completed -- 1 IP address (1 host up) scanned in 51.578 seconds

SYN scan

Ezt a talán legelterjedtebb rejtőzködő letapogatási technikát „félig nyitott” (half-open) módszernek is nevezik, mivel ez volt az első olyan módszer, amely a port nyitottságának ellenőrzése során nem épít ki TCP kapcsolatot. Első lépésként normál kapcsolatfelvételnek látszó SYN jelzésű csomagot küld, és SYN,ACK csomagra vár. A csomag megérkezése a célport nyitottságát jelzi, ekkor az ellenőrző host azonnal RST (reset connection) üzenettel válaszolva megszakítja a kapcsolat felépülését és a portot nyitottnak jelentheti, a csomag megérkezésének elmaradása, RST vagy ICMP port-unreachable üzenet vétele esetén a port zártnak tekinthető. FIN, Xmas-Tree és Null scan

A SYN scan széleskörű elterjedése maga után vonta, hogy a tűzfalak és port scanner detectorok egy része a zárt portokra érkező SYN csomagokra a connect() scan által kiváltotthoz hasonló naplózási rohamba kezdenek, ezért újabb és újabb ötletek születtek az észrevétlen letapogatási módszerek területén.



Az eredményképp született FIN, Xmas-Tree és Null pásztázási módok a SYN scan továbbfejlesztéseinek is tekinthetők. Az alapötlet mindhárom esetben az, hogy a TCP szabvány alapján a zárt portoknak minden csomagra RST választ kell küldeniük, míg a nyitott portoknak az ismeretlen üzeneteket el kell dobniuk. A FIN scan egy FIN (final data from sender) jelzőbittel ellátott, az Xmas-Tree scan FIN, URG (urgent) és PSH (push) jelzőbitekkel ellátott, a Null scan pedig egy jelzőbitek nélküli IP csomagot küld a tesztelni kívánt portra, majd RST válaszra vár. Sajnálatos módon több elterjedt operációs rendszer (Microsoft termékek, Cisco, BSDI, HP/UX, MVS, IRIX, stb...) nem szabványosan implementálják a TCP protokollt és olyan portokról is RST választ küldenek, melyek egyébként nyitva vannak, így ezek a pásztázási módok nem minden esetben használhatók. Például egy windows rendszerű gép SYN scan eredménye: [root@pakk:~]# nmap -sS rhino.ikk.sztaki.hu Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-02-26 11:38 CET Interesting ports on rhino.ikk.sztaki.hu (193.225.87.44): (The 1655 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 1025/tcp open NFS-or-IIS Nmap run completed -- 1 IP address (1 host up) scanned in 0.463 seconds

Viszont a Null scan nem mutat nyitott portokat: [root@pakk:~]# nmap -sN rhino.ikk.sztaki.hu Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-02-26 11:39 CET All 1659 scanned ports on rhino.ikk.sztaki.hu (193.225.87.44) are: closed Nmap run completed -- 1 IP address (1 host up) scanned in 5.401 seconds

Idle scan

Az idle scan egy elosztott megoldást nyújt port scanneléshez, méghozzá olyan módon, hogy a pásztázást végző géptől egy csomag sem érkezik az ellenőrzött géphez. Sok operációs rendszer TCP/IP protokoll feldolgozó része ugyanis egy globális számot használ az egyedi IP fragmentációs számok (IPID) előállításához. Ezek a számok az útjuk során datagramokra szétszakított IP csomagok újbóli összerakásában és egyediségének megállapításában játszanak szerepet, azonban ha globálisan számítottak akkor egy kapcsolódó hostnak információt szivárogtatnak ki más hostokkal folytatott kommunikációjukról az IPID számsorozatban a host számára jelentkező kihagyások formájában. Ha az ellenőrzést végző host egy viszonylag forgalommentes (idle) úgynevezett „zombie” gépet talál amely kiszámítható IPID számokkal válaszol, elvégzi a következő tesztet (legyen A az ellenőrzést végző gép, B a célgép, Z a zombie host): 1. A egy váratlan, vagyis szabálytalan visszaigazoló SYN,ACK csomagot küld Z-nek 2. Z válaszul egy RST csomagot küld A-nak, aki a csomag IPID mezőjének értékét eltárolja 3. A egy TCP kapcsolatfelételre felszólító SYN csomagot küld Z nevében, vagyis hamisított forrás IP címmel B egy ellenőrizni kívánt portjára 4. Két eset lehetséges: – Az A által tesztelni kívánt port nyitva van, B a hamisított forráscím alapján SYN,ACK csomagot küld vissza Z-nek, aki számára ez váratlan, ezért egy RST csomaggal elutasítja, ám ekkor a globális IPID számlálóját is növeli – Az A által tesztelni kívánt port zárva van, B egy elutasító RST csomagot küld Z-nek, akit



ez szintén váratlanul ér, azonban Z a TCP szabvány alapján ilyenkor nem válaszol semmit 5. A ismét váratlan SYN,ACK üzenetet küld Z-nek 6. Z erre válaszul ismét RST csomagot küld A-nak, azonban a csomag IPID mezője a 4. pont két lehetősége alapján a 2. pontban A által eltárolt értékhez képest vagy egy, vagy kettő lépést tett. A ez alapján értesült arról, hogy B tesztelni kívánt portja nyitva, vagy zárva volt. A fenti lépéseket minden portra elvégezve az ellenőrző host letapogathatja a célgépet anélkül, hogy az egyetlen csomagot is látott volna az ellenőrző host forráscímével. Fontos, és hasznos mellékhatás, hogy az ellenőrzés nem az ellenőrző host számára nyitott portokat találja meg, hanem a zombie host által elérhetőket, ezért alkalmas a gépek közti bizalmi kapcsolatok feltérképezésére is. Az nmap port scanner idle scan támogatását szemlélteti a következő példa (zombie hostként a palcad nevű gépet használtuk fel, a -P0 az nmap automatikus kezdeti ellenőrző ping próbájának kikapcsolására szolgál, hogy tényleg egy csomag se érkezzen a lutra.sztaki.hu gépre az ellenőrzést végző pakk nevű gépről): [root@pakk:~]# nmap -P0 -sI palcad.ikk.sztaki.hu lutra.sztaki.hu Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-02-27 08:52 CET Idlescan using zombie palcad.ikk.sztaki.hu (193.225.87.20:80); Class: Incremental Interesting ports on lutra.sztaki.hu (193.225.86.11): (The 1638 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 13/tcp open daytime 21/tcp open ftp 22/tcp open ssh 23/tcp open telnet 25/tcp open smtp 37/tcp open time 80/tcp open http 110/tcp open pop3 143/tcp open imap 221/tcp open fln-spx 223/tcp open cdc 443/tcp open https 993/tcp open imaps 995/tcp open pop3s 2049/tcp open nfs 3000/tcp open ppp 3306/tcp open mysql 4045/tcp open lockd 5001/tcp open commplex-link 8007/tcp open ajp12 10000/tcp open snet-sensor-mgmt Nmap run completed -- 1 IP address (1 host up) scanned in 71.462 seconds

ACK scan

Az ACK scan közvetlen információt ugyan nem szolgáltat arról, hogy az ellenőrzött gépen mely TCP portok találhatók nyitva, azonban képet mutat a gépet esetlegesen védő tűzfal szabályairól és minőségéről. Segítségével eldönthető, hogy egy tűzfal állapottartó, vagy egyszerű csomagszűrő szolgáltatásokat nyújt. A módszer egyszerű: az ellenőrző gép egy nem létező TCP csatornához tartozó, véletlenszerű paraméterekkel ellátott ACK csomagot küld a tesztelendő portra. Ha a portot tűzfal védi, a csomagot nagy valószínűséggel eldobja, vagy esetlegesen egy ICMP port-unreachable üzenetet küld vissza. Ha azonban a portot nem védi tűzfal, a „gazdátlan” ACK csomag az operációs rendszerből egy RST választ vált ki a port nyitottságától függetlenül. Ez azért fontos eredmény,



mert feltérképezhetők a tűzfal által szabadon hagyott „lyukak”, következtetéseket lehet levonni a gép esetleges rejtett, vagy időlegesen nyitott, esetleg adott hostok kiszolgálására korlátozott szolgáltatásaira. Egy tűzfallal védett gép ACK ellenőrzését szemlélteti az alábbi példa: [root@pakk:~]# nmap -sA netpolice.ikk.sztaki.hu Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-02-27 09:39 CET Interesting ports on netpolice.ikk.sztaki.hu (193.6.16.125): (The 1656 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE 25/tcp UNfiltered smtp 80/tcp UNfiltered http 443/tcp UNfiltered https Nmap run completed -- 1 IP address (1 host up) scanned in 72.415 seconds

UDP scan

Eddig kizárólagosan a TCP/IP protokoll ellenőrzésére korlátoztuk figyelmünket, pedig a második legelterjedtebb internetes protokoll, az UDP is fontos sebezhetőségek forrása lehet: UDP protokollon működik az általános szolgáltatások közül a DNS, az SNMP, a TFTP, a NetBIOS-ra épülő windowsos kommunikáció, a Unixos távoli fájlelérést biztosító NFS, valamint az egyik legsebezhetőbb távoli eljáráshívás szolgáltatás, az RPC is, nem is beszélve a számtalan backdoor alkalmazásról (például a hírhedté vált Back Orifice), melyek jó része szintén UDP alapokon kommunikál. Az UDP port scannelés az IP protokoll scanhoz hasonlóan abból áll, hogy az pásztázást végző gép 0 byte méretű UDP csomagokat küld az ellenőrizni kívánt portokra, majd ICMP port-unreachable üzenetre vár. Az üzenet elmaradása esetén a portot nyitottnak feltételezi. A palcad.ikk.sztaki.hu nevű windowsos gép nyitott UDP portjai például: [root@pakk:~]# nmap -sU palcad.ikk.sztaki.hu Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-02-27 09:54 CET Interesting ports on palcad.ikk.sztaki.hu (193.225.87.20): (The 1470 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 123/udp open ntp 137/udp open netbios-ns 138/udp open netbios-dgm 427/udp open svrloc 445/udp open microsoft-ds 500/udp open isakmp 1028/udp open ms-lsa 1900/udp open UPnP Nmap run completed -- 1 IP address (1 host up) scanned in 5.538 seconds

Host fingerprintig, OS detection

Talán a legfontosabb ellenőrzési módról esik most szó. Valójában nem számítható a klasszikus értelemben vett port scannelés témakörébe, mégis itt említjük meg, mivel általában a port scanneléssel egy időben, vagy legalábbis egy szinten kerül sor a host fingerprintigre. A port scanner feladata a lehető legtöbb információ kinyerése a letapogatás során. Ilyen információt hordozhatnak a különböző időzítések, sorozatszámozási minták, keretméretek, és a hálózati réteg egyéb számmal mérhető jellemzői, melyek kombinációjából olyan messzemenő következtetéseket vonhatunk le, mint az ellenőrzött gép operációs rendszerének pontos verziója, legutóbbi újraindításának ideje, az általa kialakított TCP csatornákba való jogosulatlan beépülés veszélyének mértéke, és a már említett



IPID számítás mintázatának kiszámíthatóságára. Ezek az információk támadási felületek, például ismert operációs rendszer és alkalmazás hiányosságok megszüntetésére használhatók fel, valamint jelezhetik egy-egy host tűzfal általi védelmének szükségességét. Egy kiszolgáló „ujjlenyomatának” elemzése az nmap szerint: [root@pakk:~]# nmap -O -v lutra.sztaki.hu Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-02-27 10:06 CET Host lutra.sztaki.hu (193.225.86.11) appears to be up ... good. Initiating SYN Stealth Scan against lutra.sztaki.hu (193.225.86.11) at 10:06 Adding open port 21/tcp Adding open port 8007/tcp ... Adding open port 25/tcp The SYN Stealth Scan took 50 seconds to scan 1659 ports. For OSScan assuming that port 13 is open and port 1 is closed and neither are firewalled Interesting ports on lutra.sztaki.hu (193.225.86.11): (The 1638 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 13/tcp open daytime 21/tcp open ftp ... 10000/tcp open snet-sensor-mgmt Device type: general purpose Running: Sun Solaris 8 OS details: Sun Solaris 8 Uptime 51.674 days (since Tue Jan 6 17:56:39 2004) TCP Sequence Prediction: Class=random positive increments Difficulty=52181 (Worthy challenge) IPID Sequence Generation: Incremental Nmap run completed -- 1 IP address (1 host up) scanned in 54.213 seconds

security scanning A security scanning az ismertetett host és port scannerekre és egyéb hálózati folyamatokat végrehajtó programokra támaszkodik, de ahogy a bevezetőben is említettük, a biztonsági ellenőrzések csak egy kis része automatizálható, általában erős emberi segítséggel és nagy szakértelemmel hajtható csak végre, ezért ebben a szakaszban csak az általános alapelvek áttekintésére szorítkozhatunk, mivel a konkrét példák nagyrészt mélyreható termékismertetővé kéne hogy váljanak, vagy megmaradnának az „ezzel a programmal ellenőrizzük le ezt az IP címet” szinten. A konkrét szoftverrel támogatott megoldások elérhetőségét a fejezet végén található hivatkozástárban foglaltuk össze egy-egy megjegyzéssel kiegészítve. A biztonsági ellenőrzések egy része túlmutat a hálózatbiztonsági megoldásokon, mégis fontos szerepet játszik egy hálózat védettségének kialakításában, ezért fogalmi szinten érdemes velük megismerkedni: – Social engineering: sokszor nem is gondolnánk mekkora támadási felületet nyújthatnak egy hálózat jóhiszemű felhasználói, akik egy magát hálózati felügyelőnek vagy rendszergazdának kiadó személy telefonhívására vagy levelére hajlandók gépeikre ismeretlen eredetű programokat telepíteni, vagy jelszavakat és egyéb érzékeny információkat kiadni. A jóindulatú social engineering egyfajta „user scanner”-ként működve a felhasználók körében fellelhető ilyen jellegű biztonsági hiányosságokra próbál rátalálni. – War dialing: célja egy hálózatra való, a hálózat elsődleges védelmi peremeit (például a tűzfalat) megkerülő kapcsolódási lehetőségek felderítése. Általában az analóg telefonhálózat egyes



mellékeire a felhasználók által saját célokra felkötött modemes eléréseiről van szó, melyeket a hálózatra való kapcsolódásra alkalmas gépek mellől elérhető telefon vonalak feltárcsázásával lehet legegyszerűbben felderíteni (innen az elnevezés). – Source code analysis: a kiszolgáló szoftverek forráskódjának analízise hálózati és általános biztonsági szempontokból, főként buffer-túlcsordulás hibák és egyéb hálózati viselkedési hiányosságok után kutatva. – Public information search: több esetben előfordul, hogy a védeni kívánt adatok egy része valamilyen módon nyilvánosan elérhető. Előfordulhat például, hogy egy internetes elérhetőségű webszerver egy cég dolgozóinak intranet szolgáltatást is nyújt, az intranet és internet felület pedig közös keresővel rendelkezik. Ilyenkor hiába elérhetetlenek kívülről az intranetes oldalak, a kereső jól formázott keresési feltételek alapján apró részletekben átszivárogtathatja az egész információt a külvilágba. Ilyen, és ehhez hasonló problémák alapján célszerű minden lehetséges információ megszerzésére próbákat tenni, hogy időben elzárhatóak legyenek az adatszivárgási csatornák. Az említett, csak félig technikai jellegű ellenőrzéseken túl a fejezet bevezetésében említett security scan megoldásokat három fő szempont, a perspektíva, a behatás és az ellenőrzési mélység szerint csoportosíthatjuk. Perspektíva

Az ellenőrzés perspektívája határozza meg legjobban a feltételezett támadó kilétét, minél több információval rendelkezik az ellenőrzést végző személy vagy automatizált szoftver, annál nagyobb eséllyel ér eredményt jogosulatlan információszerzési vagy károkozási próbálkozásaival. – Zero knowledge (black box): nem megbízható külső megfigyelő esetén alaphelyzetben a rosszindulatú támadóról feltételezhetjük azt, hogy semmilyen információval nem rendelkezik a rendszer felépítésével kapcsolatban, vagyis a host és port scanner eredményekre alapozva kell eredményeket elérnie. Ez a perspektíva tükrözi legjobban egy ismeretlen hacker/cracker lehetőségeit a rendszerrel szemben. Ez a perspektíva a legjobban automatizálható, több kereskedelmi és ingyenes program létezik, mely ilyen módszerrel végez teszteket. – Valid account (gray box): ebben az esetben bizonyos alapvető információkkal látjuk el a biztonsági ellenőrzést végző személyt vagy eszközt. Ilyen alapvető információ lehet például egy kiemelt jogosultságokkal nem rendelkező felhasználói elérés (amit például egy titkárnőn végzett social engineering eredményeképp megszerezhet egy hacker), vagy a központi tűzfal pontos szabályrendszere. Ez a perspektíva egy ismeretlen cracker és egy megbízható belső személy együttműködését közelíti legjobban. Ez a perspektíva is viszonylag jól automatizálható, de bizonyos esetekben ez jelentős veszélyforrás lehet, hiszen belső, még akár privilegizálatlan eléréssel elképzelhető olyan DoS támadás, amit nagyon nehéz kivédeni. – Full knowledge (white box): ez az ellenőrzés leginkább a hálózat teljes áttekintését jelenti, miközben minden információ rendelkezésre áll. Ez a perspektíva egy megbízható belső személy felől induló támadással áll párhuzamban, de valójában nem célja egy valódi támadás szimulálása, hisz belülről, több belső személy közreműködésével minden rendszer megdönthető. Ez a típusú scan nagyon nehezen automatizálható, mivel az alapvető belső beállításokon kívül minden rendszer egyedi, nehezen általánosítható teszteket igényelne. Behatás

A behatás (impact) a biztonsági ellenőrzés erőszakosságát határozza meg. Minél erőszakosabb egy támadás, annál több sebezhetőségre hívhatja fel a figyelmet, de annál több kárt is okozhat. – Low impact (intelligence): csak információszerzés a cél, ide sorolhatók a fenyegetettségfeltérképező alkalmazások, vagyis a portscannelés és a verziószám-scannelés. Általában könnyen automatizálható, hisz az ellenőrizendő hoston nyitott portokon egy próba kapcsolatfelvételt követően a kiszolgálást végző szoftver a legtöbb esetben nevével és/vagy verziószámával



válaszol. A valós életben szinte minden támadó ezzel kezdi a behatolást, ha más úton nem értesülhetett a megtámadni kívánt hoston futó szolgáltatásokról. Egy verziószám-scanre példa: [root@pakk:~]# nmap -sV lutra.sztaki.hu Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-02-27 14:05 CET Interesting ports on lutra.sztaki.hu (193.225.86.11): (The 1638 ports scanned but not shown below are in state: closed) PORT STATE SERVICE VERSION 13/tcp open daytime Sun Solaris daytime 21/tcp open ftp? 22/tcp open ssh OpenSSH 3.5p1 (protocol 1.99) 23/tcp open telnet Sun Solaris telnetd 25/tcp open smtp qmail smtpd 37/tcp open time 80/tcp open http Apache httpd 1.3.20 ((Unix) (Red-Hat/Linux) ApacheJServ/1.1.2) 110/tcp open pop3 UW Imap pop3 server 2001.80 143/tcp open imap UW imapd 2002.328 221/tcp open ftp 223/tcp open telnet BSD-derived telnetd 443/tcp open ssl/http Apache httpd 1.3.22 ((Unix) mod_ssl/2.8.5 OpenSSL/0.9.6c) 993/tcp open ssl/imap UW imapd 2002.328 995/tcp open ssl/pop3 UW Imap pop3 server 2001.80 2049/tcp open nfs 2-3 (rpc #100003) 3000/tcp open ppp? 3306/tcp open mysql MySQL (unauthorized) 4045/tcp open nlockmgr 1-4 (rpc #100021) 5001/tcp open commplex-link? 8007/tcp open ajp12? 10000/tcp open http Webmin httpd Nmap run completed -- 1 IP address (1 host up) scanned in 151.054 seconds –

–

Moderate impact (exploit): ez az ellenőrzési mód már komoly károkozásra is képes, általában egy OS fingerprintinget és egy verziószám-scanelést követően a megállapított operációs rendszer és kiszolgáló-szoftver verziók ismert hiányosságait (például buffer túlcsordulás paraméterek átvételekor, esetleg speciális karakterek, tartományból kilógó adatok hibás kezelése, információszivárogtatás, gyenge jelszavak) tesztelő önálló kis programok (exploitok, scriptek) futtatásából épül fel. Ezek a scriptek már komoly, specializált programozói munkát igényelnek, ezért az automatizálás nehéz kérdés, hisz míg egy port scanner 10-20, előre definiált részfeladatot hajt végre egy host teljes letapogatása közben, addig egy moderate impact security scanner több ezer részfeladaton halad végig, ráadásul a feladatok változhatnak a verziószámok és részeredmények ismeretében. Ez a típusú biztonsági ellenőrzés valahol a közepes ismeretekkel rendelkező script kiddie támadások és a hálózati, operációs rendszer és alkalmazás szerkezeteket mélyen megértő szakemberek felkészültsége között elhelyezkedő, életszerű támadásokhoz hasonló. Teljeskörű elvégzése szinte lehetetlen, a széleskörű ellenőrzés pedig nagy szakértelmet, sokszor emberi támogatottságot kíván. High impact (Denial of Service, DoS): míg a moderate impact ellenőrzés nem mindig célozta egy szolgáltatás, vagy akár egy egész host használhatatlanná tételét, a high impact ellenőrzés során minden esetben a hálózat és az egyes gépek tűréshatárának tesztelése a cél. Általában a szabályszerű, de nem ritkán a speciálisan nagy feldolgozási igényű kérések nagy tömegű árasztásával valósítják meg, azonban előfordulhatnak az exploit-jellegű támadások ezen a szinten is. Az egyes támadások automatikus végrehajtása ezen a szinten általában követelmény, hisz az idő fontos tényező egy szolgáltatás használhatatlanná válásához szükséges leterhelése során, vagyis nem csak a szakértelem, de a teljesítmény is számít. A tesztek lehetnek elosztottak is (Distributed Denial of Service, DDoS), ez még közelebb áll a valós életben alkalmazott,



esetenként direkt erre a célra terjesztett vírussal fertőzött internetes „zombie” gépeken keresztül indított korszerű támadásokhoz. Mélység

Az ellenőrzés mélysége nem a részletességre utal, hanem a feltételezett behatolás mélységére. A vizsgálni kívánt hálózat és rendszer a külvilág (Internet) felé általában csak egy korlátozott felületen, például egy tűzfalon keresztül nyújt szolgáltatásokat, a hálózat belülről is több részből, biztonsági zónából állhat, melyek önálló támadási területeket, szinteket jelölhetnek ki az ellenőrzés során. Mélység szempontjából az ellenőrzések két csoportját különböztetjük meg: – single horizon scan: az ellenőrzés csak a megszerzett információk alapján haladhat mélyebbre, általában elégségesnek (olcsóbbnak) tűnik ugyanis azt feltételezni, hogy a rosszindulatú támadások az Internet felől érkeznek, és a tűzfalon keresztül akarnak a belső hálózatba betörni. A behatolási teszt alapján eldönthető, hogy a tűzfal átjárható-e, azonban ez nem ad messzemenő következtetésekre lehetőséget. – multiple horizon scan: az ellenőrzés a megszerzett információktól függetlenül mélyebbre halad a hálózatban, akár minden homogén hálózati részegységet külön vizsgálva. Ez a módszer biztosíthatja azt, hogy a tűzfal, vagy a hálózati részegységeket elválasztó határok fel nem derített áthatolási veszélyeztetettsége esetén továbbhaladó rosszindulatú támadó által kihasználható belső biztonsági gyengeségek is csökkenthetőek legyenek.

Bővebb információ? Ingyenes termékek, levelezési listák, egyebek. host scanning –

A ping program honlapja: http://ftp.arl.mil/~mike/ping.html

port scanning – – – –

Internet enciklopédia (IP, TCP működés, felépítés): http://www.freesoft.org/CIE/Course/index.htm A legelterjedtebb port scanner, a nmap honlapja: http://www.insecure.org/nmap Idle scan leírás: http://www.insecure.org/nmap/idlescan.html OS fingerprinting: http://www.insecure.org/nmap/nmap-fingerprinting-article.html

security scanning – – – – –

Az első ingyenes, széles körben elterjedt automatizált security scanner a SATAN (elavult): http://www.fish.com/~zen/satan/satan.html Az egyik legjobb automatizált low-high impact security scanner a nessus honlapja: http://www.nessus.org Hivatalos Microsoft automatizált low impact security scanner (pár medium impact funkcióval): http://www.microsoft.com/technet/security/tools/mbsahome.mspx Egy példa üzleti security scanning szolgáltatásra, szakemberek közreműködésével: http://www.engarde.com/consulting/pentest Security scannerek listája, leírással (elavult): http://www.cotse.com/tools/vuln.htm



– –

Security scannereket összehasonlító cikk (elavult): http://www.networkcomputing.com/1201/1201f1b1.html A 20 legfontosabb hálózati sebezhetőség listája (jó referencia a választott security scanner naprakészségének eldöntésében): http://www.sans.org/top20

Honnan ered és hogyan működik? Történet és fejlődés

Recommend Documents