Mi a különbség a forgalomfigyelés és a szűrés között? Oroszországban nemzeti internetes szűrőrendszer lesz. Szűrés hozzárendelése a létrehozott szabályhoz

A cikk két módszerre hívja fel a figyelmet a hálózat forgalmának szűrésére. Az első módszer a bejövő csomagok nem egészen a szokásos szűrését használja a forrás IP-címek alapján, valójában hamisítás elleni védelmet valósít meg, a második - csomagszűrést a helyi hálózatban vagy DMZ-ben PVLAN technológiával.

Batrankov Denis, denisNOSPAMixi.ru

Remélem, hogy ez a cikk hasznos lesz mind a rendszergazdáknak, mind a hálózatbiztonsággal foglalkozóknak. Sajnos általában más emberekről van szó.

Bevezetés. A szűrésről általában.

Csak nézze meg az IP-csomag fejlécének formátumát (ez a struktúra a WinPCap forrásokból származik) typedef struct ip_header( u_char ver_ihl; // Verzió (4 bit) + Internet fejléc hossza (4 bit) u_char tos; // Szolgáltatás típusa u_short tlen; / / Teljes hossz u_short azonosítása; // Azonosítás u_short flags_fo; // Flags (3 bit) + Fragment offset (13 bit) u_char ttl; // Életidő u_char proto; // Protokoll u_short crc; // Fejléc checksum ip_address saddr // Forrás címe ip_address daddr // Cél címe u_int op_pad // Option + Padding )ip_header;

hány mező igényel érvényesítést már a hálózat bejáratánál. Nyilvánvaló, hogy minden mezőnek van egy értékkészlete, amelyek az RFC szabványban meghatározott jelentéssel bírnak. És nyilvánvaló, hogy sok olyan érték van, amely sehol nincs meghatározva, értelmetlen, és el sem tudjuk képzelni, hogyan fogja ezeket az értékeket érzékelni a fogadó gazda. Ha egy csomagban legalább egy mező hibás, akkor az egész csomag hibás, és nem szabad eltömíteni a hálózatunkat. Ez azonban jelenleg sok hálózatban nem így van. Az ilyen csomagokkal minden gazdagép saját támadásvédelmi rendszerrel (IPS) rendelkezik. Azt javaslom, hogy ne várja meg, amíg az ilyen csomagok megérkeznek a címzett gazdagépéhez, hanem öljék meg őket, amint belépnek a hálózatba. Sőt, szekvenciálisan szűrhetjük és blokkolhatjuk a forgalmat, kezdve a csatornától az alkalmazási szintig (az ISO OSI modellen belül). Ez tehermentesíti a hálózatot, és megvédi azokat a támadásokat, amelyek azt a tényt használják ki, hogy "hunyunk szemet" a rossz csomagokra.

Ez az ötlet nem új. A behatolásészlelő rendszerek szabályai tartalmaznak egy tippet arra vonatkozóan, hogy a hálózat mely csomagjai lehetnek rosszak. A behatolásjelző rendszerek már régóta ellenőrzik a csomagok összes mezőjét, és statisztikákat gyűjtenek a talált hibás csomagok elemzéséhez, amelyeket meg lehet tekinteni és a legbosszantóbb csomagokon intézkedni. A Snortot szeretem a legjobban, mert minden benne van a felhatalmazás előtt. Ez lehetővé teszi a szabványos szabályok megváltoztatását vagy saját írását, statisztikák elemzését, sőt szabályok hozzáadását az IP-címek blokkolásához a SnortSam segítségével szinte bármelyik jelenleg ismert FW-ben: Cisco PIX, MS ISA, Checkpoint FW-1, Watchguard Firebox és beépített Linuxra és FreeBSD FW-re.

Az általánosság elvesztése nélkül azonban elmondhatjuk, hogy azok, akik bármilyen behatolásjelző rendszert használnak, mint például a Cisco NetRanger, a RealSecure (Proventia) vagy a Snort, álmodoznak: mikor szűnnek meg végre a téves riasztások generálásával. Legalábbis nekem van egy ilyen álmom, mert a C osztály négy külső rácsában folyamatosan történik valami újdonság, bár az információáramlás típusai már régen rendeződtek. Már nem kapok sok olyan riasztást, mint a BAD-TRAFFIC hozzá nem rendelt/lefoglalt IP protokoll , BAD TRAFFIC nem szabványos IP protokoll , BAD-TRAFFIC loopback forgalom , BAD-TRAFFIC azonos SRC/DST , BAD-TRAFFIC tcp port 0 forgalom , nem azért, mert letiltottam ezeket a szabályokat, hanem azért, mert ezt a "rossz forgalmat" azonnal blokkoltam a bejáratnál. Sajnos ma már figyelmen kívül kell hagynom a különböző eseményeket, tudván, hogy ez egy gyakori téves riasztás, és nem tudom letiltani, hiszen egyetlen szolgáltató sem akadályozhatja meg a kliens felé irányuló forgalmat, legyen az veszélyes vagy egyszerűen haszontalan. De megengedem magamnak, hogy blokkoljam a "rossz" forgalmat: rossz címek, rossz zászlók, rossz vagy veszélyes portok.

Érthető, hogy miért vannak olyan IDS rendszerek, amelyek megmutatják az adminisztrátornak, hogy milyen rossz a forgalom, de nincsenek olyan programok, amelyek automatikusan kiszűrik a hálózatokba be- és kimenő forgalmat, hogy a Snortnak ne legyen min káromkodnia. A probléma a téves riasztások. Ugyanannak a Snort-nak számos szabálya van, amelyek nemcsak észlelik a nem szabványos viselkedést, hanem azonnal blokkolják is. Például logikus, hogy blokkoljuk a BAD-TRAFFIC ip lefoglalt bitkészlet feltételét kielégítő forgalmat, vagyis azokat a csomagokat, amelyeknél a fenntartott bit helytelenül van beállítva. (Egyébként emlékszel, melyik tűzfal képes ellenőrizni egy ilyen állapotot és blokkolni egy ilyen csomagot? ;-)) Másrészt vannak olyan figyelmeztetések, amelyek hasznosságáról lehet vitatkozni. Például a hálózatomra nemrég telepített eMule-ok felelősek a BACKDOOR gépelési hiba trójai forgalmi figyelmeztetéséért.

Ideális esetben tehát a behatolásjelző rendszerek szempontjából meg kell győződnünk arról, hogy azok a szabályok, amelyek egyértelműen azt mutatják, hogy a szűrés helytelenül van beállítva, ne működjenek. A helyes konfigurálás pedig az adminisztrátor fő feladata.

Durva szűrő. IP cím hamisítás elleni védelem.

Mivel nem könyvet írok, hanem cikket, ma az IP-csomag egyetlen mezőjének a végére jutok: a forráscím. Ismeretes, hogy ott van a csomag forrásának IP-címe. És amennyire én tudom, a Cisco SAFE technológia azt tanácsolja, hogy ezt a mezőt az RFC szerint szűrjék, és védekezzenek az IP-hamisítás ellen. Találjuk ki, hogy pontosan mely címeket kell blokkolnunk. (A célcímmezőnek az Ön számára kiosztott címkészleten belül kell lennie, ezért nincs itt semmi megvitatása.)

Tudjuk tehát, hogy 1983. január 1-től bevezették az IP-cím 4-es verziójának fogalmát, ami egy 32 bites szám, amit általában 4 tizedes számként írunk le ponttal elválasztva. Létezik az Internet Assigned Numbers Authority (IANA) nevű szervezet, amely címeket oszt ki az interneten. Négy regionális internetnyilvántartás (RIR) van terjesztve szerte a világon: APNIC (Ázsiai és Csendes-óceáni Hálózati Információs Központ), ARIN (Amerikai Internet Számok Nyilvántartó), LACNIC (Latin-amerikai és karibi IP-címek regionális nyilvántartása), RIPE NCC, amelyek címeket osztanak ki. az internetszolgáltatók (ISP) között. És végül az IANA honlapján van egy tábla, amely rögzíti, hogy melyik címblokkot kinek adják.

Ha megpróbáljuk osztályozni a címeket, akkor az A, B, C, D, E osztályok mellett (amelyeket az iskolában már tanulnak) azt találjuk, hogy nem csak az RFC 1918, hanem az RFC 3330 által meghatározott speciális címek is vannak. , és amelyeket nem szabad az interneten használni.

1. Privát címek – helyi hálózatokon való használatra fenntartva az RFC 1918 szerint.

10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255

2. Azok a címek, amelyeket úgy szereztek meg, hogy az IP-címet automatikusan hozzárendeljük saját magunknak, ennek hiányában DHCP szerverekés az RFC 3330 szerint sem léphet túl a helyi hálózaton.

169.254.0.0 - 169.254.255.255

3. A TCP-verem működésének tesztelésére használt visszacsatolási címek. Minden gazdagép csak saját magának használja.

127.0.0.0 - 127.255.255.255

4. Vizsgálati tartomány - a dokumentációban és a kódpéldákban kell használni.

192.0.2.0–192.0.2.255

5. A multicast címek nem lehetnek a forrás mezőben. Csak a csomag címzettje mezőben, mivel a gazdagépek csoportjára utalnak.

224.0.0.0 - 239.255.255.255

6. Fenntartott és senkinek nem kiosztott címek. Ezek a címek mind ugyanazon a táblán szerepelnek az IANA webhelyén. 2004. december 12-én a következő blokkok vannak tartalékban

0.0.0.0 - 2.255.255.255
5.0.0.0 - 5.255.255.255
7.0.0.0 - 7.255.255.255
23.0.0.0 - 23.255.255.255
27.0.0.0 - 27.255.255.255
31.0.0.0 - 31.255.255.255
36.0.0.0 - 37.255.255.255
39.0.0.0 - 39.255.255.255
41.0.0.0 - 42.255.255.255
49.0.0.0 - 50.255.255.255
73.0.0.0 - 79.255.255.255
89.0.0.0 - 126.255.255.255
173.0.0.0 - 187.255.255.255
189.0.0.0 - 190.255.255.255
197.0.0.0 - 197.255.255.255
223.0.0.0 - 223.255.255.255
240.0.0.0 - 255.255.255.255

Az utolsó lista lenyűgöző. És még mindig panaszkodunk, hogy nincs elég címünk. És kombináltam több címblokkot is, ha a közelben voltak a listában.

7. A címeknek van egy másik osztálya, amely nem lehet a források mezőben. Ezek az Ön saját címei. Azok az internetes címek, amelyeket a szolgáltató az Ön számára és csak Önnek oszt ki. Nyilvánvaló, hogy rajtad kívül senkinek nincs joga ezek használatára, és meg kell akadályoznia minden olyan kísérletet, amely egy forráscímmel rendelkező csomagot küld a címkészletéből. Sőt, a források mezőben a címének helyettesítése különféle támadások végrehajtására használható. Például egy szárazföldi támadásnál a SYN-csomag ugyanazzal a forráscímmel kerül elküldésre, mint a célcím.

Tehát kiderült, hogy van egy meglehetősen nagy címkészlet, amely nem lehet az IP-csomagjaink forrás mezőjében. Általános szabály, hogy ha a fent felsorolt címek egyike regisztrálva van a forrásokban, akkor ez vagy egy útválasztás, amely nem működik megfelelően az upstream szolgáltatónál (hibás címeket bocsát ki a külső felé), vagy egy lehetséges DOS-támadás. Ezért azt javaslom, hogy blokkolja a fent felsorolt összes címet a routerbe való belépéstől.

Összegezve a fentieket, egy elég tisztességes listát kapunk a küldőcímekről, amelyeket le kell tiltanunk. Például, ha Cisco útválasztót használ, akkor a hozzáférési lista így fog kinézni:

ip access-list kiterjesztett teljes_bogon	Megnevezett kiterjesztett hozzáférési lista használata
deny ip 0.0.0.0 1.255.255.255 any	IANA fenntartva
deny ip 2.0.0.0 0.255.255.255 any	IANA fenntartva
deny ip 5.0.0.0 0.255.255.255 any	IANA fenntartva
deny ip 7.0.0.0 0.255.255.255 any	IANA fenntartva
deny ip 10.0.0.0 0.255.255.255 bármilyen	RFC 1918
deny ip 23.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 27.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 31.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 36.0.0.0 1.255.255.255 bármilyen	IANA fenntartva
deny ip 39.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 41.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 42.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 49.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 50.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 73.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 74.0.0.0 1.255.255.255 bármilyen	IANA fenntartva
deny ip 76.0.0.0 3.255.255.255 bármilyen	IANA fenntartva
deny ip 82.0.0.0 1.255.255.255 bármilyen	IANA fenntartva
engedély 88.0.0.0 0.255.255.255 our_net	hozzáférés engedélyezése a 88/8-as címmel a hálózatunkhoz (hogy ne blokkolja alább)
deny ip 88.0.0.0 7.255.255.255 bármilyen	IANA fenntartva
deny ip 96.0.0.0 31.255.255.255 bármilyen	IANA Reserved és Loopback
deny ip 169.254.0.0 0.0.255.255 bármilyen	automatikusan hozzárendelt címek
deny ip 172.16.0.0 0.15.255.255 bármilyen	RFC 1918
deny ip 173.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 174.0.0.0 1.255.255.255 bármilyen	IANA fenntartva
deny ip 176.0.0.0 7.255.255.255 bármilyen	IANA fenntartva
deny ip 184.0.0.0 3.255.255.255 bármilyen	IANA fenntartva
deny ip 189.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 190.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 192.0.2.0 0.0.0.255 any	tesztcímek.
deny ip 192.168.0.0 0.0.255.255 bármilyen	RFC 1918
deny ip 197.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 198.18.0.0 0.1.255.255 bármilyen	IANA fenntartva
deny ip 201.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 222.0.0.0 1.255.255.255 bármilyen	IANA fenntartva
deny ip 223.0.0.0 0.255.255.255 bármilyen	IANA fenntartva
deny ip 224.0.0.0 31.255.255.255 bármilyen	Multicast, majd IANA Reserved
deny ip our_net any	blokkolja címeinket a bejáratnál
engedélyezze az ip-t bármely our_net	engedj meg minden mást

our_net Kijelöltem a címblokkját. Például a hozzáférési listák írásának szabályai szerint 194.194.194.0 0.0.0.255-nek tűnhet.

Nem mindegy, hogy a határrouteren, a tűzfalon vagy akár a szerveren hol van megvalósítva ez a szűrési mód, de a legfontosabb, hogy a támadót megfosztják attól a lehetőségtől, hogy nem létező hálózatokból származó címeket használjon. Szeretném megjegyezni, hogy ha Cisco IOS-t használ legújabb verziói(12.2 és újabb), akkor nem kell magának elkészítenie ezt a hozzáférési listát. Ugyanez a hozzáférési lista egy egyszerű (látszólag) automatikus biztonságos paranccsal jön létre.

Csapat automatikus biztonság MINDENT megcsinál egy számítógépes biztonsági szakembernek! Mindent, amit a Cisco útválasztók védelmére fejlesztettek ki, ez az egyetlen parancs hajtja végre. Természetesen el kell képzelni, mit csinál, amikor beírja, de ez a parancs mindent megtesz, még akkor is, ha nincs bizonyítványa és végzettsége ezen a területen. :(Amikor valóban megtudtam a lehetőségeket automatikus biztonság Úgy döntöttem, eljött az idő, hogy feladjam a biztonságot, és eladjam a vasakat – van fizetés, azt mondják, több, és nem kell felsőoktatás. ;-) Miért most szakemberek, ha mindent egy csapat csinál.

Ennek a módszernek azonban van egy hátránya: folyamatosan figyelnie kell az IANA honlapján http://www.iana.org/assignments/ipv4-address-space található táblázat változásait, hogy a lista módosítása után módosítsa a hozzáférési listát. . Például, utolsó változtatás ez év augusztusában volt: 71/8, 72/8 hálózatokat osztottak ki az ARIN számára. Nem tudom, hogy van-e kész forgatókönyv erre a munkára, de ha találsz egyet, vagy magad írod meg, akkor a társadalom hálás lesz neked. Van egy oldal, ahol a tényleges hozzáférési lista mindig tárolva van http://www.cymru.com/Documents/secure-ios-template.html , de ott a hozzáférési lista egy kicsit hosszú. Le lehet rövidíteni. A redukció elve az

deny ip 0.0.0.0 0.255.255.255 any
deny ip 1.0.0.0 0.255.255.255 any

váltani

deny ip 0.0.0.0 1.255.255.255 any

Ha nincs ilyen szűrő a hálózat bejáratánál, akkor érdemes beállítani egy szűrőt a hálózaton saját szerver vagy munkaállomáson. Ezt egyébként a személyes FW-k készítői igénybe vehetnék. Ez segít megvédeni a gazdagépet a DOS-támadásoktól. Íme egy példa a BIND hamisítás elleni szűrőjére.

Miután kitaláltuk a címeket, dolgozhatunk az IP-csomag többi mezőjén. Például gyakran jönnek a hálózatomra tcp csomagok a 0-s porttal. Miért nem látja, hogy milyen portokat használnak a hálón áthaladó csomagok?

Finom szűrő vagy izolált VLAN.

Most nézzük meg a belső hálózat forgalmát. A biztonságos hálózati konfiguráció felépítésének egyik kulcstényezője pontos meghatározás az összes hálózati objektumról, és annak pontos megértése, hogy ezeknek az objektumoknak kivel kell információt cserélniük, és milyen típusú forgalmat generálnak. Minden egyéb forgalmat ezen entitások között el kell utasítani.

Vegyük például a demilitarizált zónát (DMZ). Helyesnek tekinthető, ha a vállalat szervereit külön hálózathoz rendelik, védve mind az internetezőktől, mind a belső felhasználóktól. Ahogy mondják, bízz, de ellenőrizd. A képen két lehetséges megvalósítási lehetőség látható: a DMZ két tűzfal között található, a DMZ pedig a tűzfal egyik portján lóg.

Tehát a tűzfalak szűrik az internetről és a helyi hálózatról érkező forgalmat. És általában a hálózattervezők megnyugszanak ezen a sémán. Az összes szerver egyetlen kapcsolón keresztül csatlakozik, és ugyanabba a szórási tartományba kerül. Azonban a DMZ szervereinek kommunikálniuk kell egymással? Minden egyes esetet meg kell vizsgálni. Feltételezhető, hogy ha az egyik DMZ szervert feltörik, akkor egy szomszédos szerver támadása lehetséges erről a szerverről, különösen azért, mert a tervezési szakaszban nem védtük meg az egyik szervert a másiktól. Így azokban az esetekben, amikor a szervereknek nem kell egymással együttműködniük, ajánlatos több különálló DMZ-t készíteni. A legjobb megoldás azonban a PVLAN használata. Ha a portok, amelyekre a szerverek csatlakoznak, nem továbbítanak egymásnak csomagokat a kapcsolati rétegen, akkor nem lesz forgalom a szerverek között, és csak a tűzfalon keresztül tudnak egymással kommunikálni. ezt a kapcsolatot engedélyezni kell, és át kell vinni a megfelelő portra. Azokat a portokat, amelyek nem továbbítják egymásnak a forgalmat a kapcsolati rétegen, elszigeteltnek nevezzük.

Ugyanez vonatkozik a helyi hálózaton belüli számítógépekre is. Gondosan elemezze az információáramlást, és egy kapcsoló segítségével explicit módon állítsa be, amelyek között a számítógépek között adatokat lehet cserélni.

Ugyanezzel a mechanizmussal a felhasználókat csoportokba (közösségekbe) vonhatja össze, amelyeken belül a "dedikált" kommunikációjuk szerveződik. Ugyanakkor az elszigetelt felhasználók és csoportok is továbbíthatják forgalmukat az úgynevezett nyilvános (promiscuous) portokra, amelyeken a router, a tűzfal és a behatolásjelző rendszer működik.

A Cisco PVLAN úgy van megvalósítva, hogy a nem megfelelő portokra érkező forgalom elosztható bármely más portra, például elszigetelt és közösségi portokra. Az izolált porton érkező forgalom csak egy nem megfelelő portra irányítható. A közösségi kikötőbe érkező forgalom átirányítható egy kikötőbe és egyazon közösséghez tartozó portokra.

Így, még ha ugyanabban a VLAN-ban vannak is, azok a gazdagépek, amelyeknek nem kellene kölcsönös forgalmat bonyolítaniuk az információáramlási sémában, egyetlen csomagot sem kapnak egymástól. Az információcsere egyetlen módja, ha kifejezetten írunk egy szabályt a tűzfalra vagy az útválasztóra, amely lehetővé teszi a csomagok közötti átvitelt. Ez a szabály azonban már az OSI-modell harmadik szintjén működik, és ebben az esetben a hozzáférési lista és a tűzfalszabályok segítségével kifejezetten megadhatók az engedélyezett portok és protokollok.

Ha mélyebbre ásunk, amikor az 1. gazdagép ARP kérést küld (keresve a Mac címés a 2. gazdagép a szükséges IP-címmel ugyanabból az alhálózatból) a 2. gazdagép nem fogadja ezt a kérést, és nem válaszol az 1. hosztnak, mivel mindkettő egymástól elszigetelt porton ül. Elértük, hogy az 1. gazdagép úgy véli, hogy a 2. gazdagép nem elérhető, és fordítva. Így a hálózaton belüli forgalom szabályozásának problémája megoldódott, és ami a legfontosabb, nincs szükség a hálózat alhálózatokra való felosztására. A PVLAN technológiát fájdalommentesen rátelepíthetjük a meglévő hálózatokra.

Amikor szükségünk van arra, hogy a szerverek kommunikáljanak egymással, az útválasztó (vagy tűzfal) azt válaszolhatja, hogy ez a gazdagép elérhető rajta. Ezt a technikát Proxy ARP-nek hívják. Az 1. gazdagép úgy gondolja, hogy a 2. gazdagép egy másik szegmensben van, és IP-csomagot küld egy útválasztón (vagy tűzfalon) keresztül. Vagyis kiderül, hogy a csomag tartalmazza a router MAC címét és a 2. hoszt IP címét. De a router (vagy tűzfal) már eldönti, hogy elküldi-e a csomagot a 2. hosztnak vagy sem.

Meg kell jegyezni, hogy ennek a módszernek van egy sebezhetősége is: ha olyan útválasztót használ, amely nem rendelkezik hozzáférési szabályokkal, és habozás nélkül átirányítja az összes hozzá érkező csomagot, akkor az 1-es gazdagép támadója kifejezetten küldhet csomagot. az útválasztó MAC-címével, de a 2-es gazdagép IP-címével. Egy ilyen csomag az elkülönített porton keresztül jut el az útválasztóhoz, majd az útválasztó elküldi a 2-es gazdagépnek. Ezért vagy hozzáférési szabályokat kell hozzáadnia a útválasztó (vagy tűzfal), amely kifejezetten megtagadja vagy engedélyezi az ilyen csomagokat, vagy használja a kapcsolón található további VLAN-hozzáférési listát (VACL).

Korábban egy switchen belül volt egy hasonló, védett port nevű szolgáltatás, de ez csak egy switchen belül működött, és a védett portokról szóló információk nem kerültek továbbításra a fővonalakon. Most ez a koncepció bővült és közösségi portokkal egészült ki.

A PVLAN technológiát gyakorlatilag számos jelenleg gyártott terméken lehet megvalósítani kezelt kapcsolók 10/100/1000 megabit/s sebességű Ethernet portokkal.

Leírjuk ezen sémák konkrét megvalósítását Cisco switcheken.

Az információs folyamok szűrése abból áll, hogy azokat szelektíven továbbítjuk a képernyőn, esetleg bizonyos átalakításokkal, és értesítjük a küldőt, hogy adataihoz való hozzáférést megtagadták. A szűrés a képernyőre előre betöltött szabályok alapján történik, amelyek az elfogadott biztonsági politika hálózati vonatkozásait fejezik ki. Ezért célszerű a tűzfalat szűrők sorozatának tekinteni (A.2 ábra), amelyek feldolgozzák az információáramlást. Mindegyik szűrőt úgy tervezték, hogy a következő lépések végrehajtásával értelmezze az egyes szűrési szabályokat:

1. Az információk elemzése az értelmezett szabályokban meghatározott kritériumok szerint, például a címzett és a feladó címe, vagy az alkalmazás típusa szerint, amelyre ezt az információt szánják.

2. Az értelmezett szabályok alapján az alábbi döntések valamelyikének meghozatala:

Ne hagyja ki az adatokat;

Adatok feldolgozása a címzett nevében és az eredmény visszaküldése a feladónak;

Az elemzés folytatásához adja át az adatokat a következő szűrőnek;

Adatok kihagyása a következő szűrők figyelmen kívül hagyásával.

Rizs. A.2. Tűzfal szerkezete

A szűrési szabályok további műveleteket is megadhatnak, amelyek a közvetítő funkciókhoz kapcsolódnak, például adatátalakítás, eseményregisztráció stb. Ennek megfelelően a szűrési szabályok meghatározzák a feltételek listáját, amelyek mellett a megadott elemzési kritériumok alapján a következőket hajtják végre:

az adatok további továbbításának engedélyezése vagy tilalma;

kiegészítő védelmi funkciók ellátása.

A következő paraméterek használhatók kritériumként az információáramlás elemzéséhez:

hálózati címeket, azonosítókat, interfészcímeket, portszámokat és egyéb jelentős adatokat tartalmazó üzenetcsomagok szolgáltatásmezői;

az üzenetcsomagok közvetlen tartalmát, például ellenőrizve a jelenlétet számítógépes vírusok;

az információáramlás külső jellemzői, például időbeli,

frekvencia válasz, adatmennyiség stb.

Az alkalmazott elemzési kritériumok az OSI-modell azon rétegeitől függenek, amelyeken a szűrést végrehajtják. Általánosságban elmondható, hogy minél magasabb szintű az OSI modell, amelyen a tűzfal szűri a csomagokat, annál magasabb szintű védelmet biztosít.

Közvetítői funkciók ellátása

A tűzfal közvetítői funkciókat lát el speciális programok, úgynevezett shielding agentek vagy egyszerűen csak közvetítő programok segítségével. Ezek a programok rezidensek, és tiltják az üzenetcsomagok közvetlen továbbítását a külső és belső hálózatok között.

Ha hozzáférés szükséges a belső hálózatról a külső hálózatra, vagy fordítva, akkor először létre kell hozni a logikai kapcsolatot a képernyő számítógépen futó közvetítő programmal. A közvetítő program ellenőrzi a kért internetkapcsolat érvényességét, és ha engedélyezi, maga létesít külön kapcsolatot a szükséges számítógéppel. Továbbá a belső és külső hálózatok számítógépei közötti információcsere szoftveres közvetítőn keresztül történik, amely képes szűrni az üzenetáramlást, valamint egyéb védelmi funkciókat is ellátni.

Meg kell érteni, hogy a tűzfal közvetítő programok használata nélkül is képes szűrési funkciókat ellátni, átlátható interakciót biztosítva a belső és külső hálózatok között. Előfordulhat azonban, hogy a szoftverközvetítők nem szűrik az üzenetfolyamot. Az üzenetfolyam transzparens továbbítását blokkoló árnyékoló ágensek általában a következő funkciókat látják el:

a felhasználók azonosítása és hitelesítése;

továbbított adatok hitelesítése;

a belső hálózati erőforrásokhoz való hozzáférés differenciálása;

a külső hálózati erőforrásokhoz való hozzáférés differenciálása;

az üzenetfolyam szűrése és átalakítása, például dinamikus víruskeresés és információk átlátható titkosítása;

belső hálózati címek fordítása kimenő üzenetcsomagokhoz;

események nyilvántartása, adott eseményekre adott válaszadás, valamint a regisztrált információk elemzése és jelentések generálása;

a külső hálózatról kért adatok gyorsítótárazása.

A magas fokú biztonság érdekében a felhasználók azonosítása és hitelesítése nem csak akkor szükséges, ha külső hálózatról egy belső hálózatra csatlakoznak, hanem fordítva is. A jelszót nem szabad a címre elküldeni nyitott forma nyilvános kommunikáció útján. Ez megakadályozza az illetéktelen hozzáférést a hálózati csomagok elfogásával, ami lehetséges például a szabványos szolgáltatások, például a Telnet esetében. A hitelesítés legjobb módja az egyszeri jelszavak használata. Kényelmes és biztonságos a megbízható hatóságok, például kulcselosztó központok által kiadott digitális tanúsítványok használata is. A legtöbb proxyszoftver úgy van kialakítva, hogy a felhasználót csak a tűzfalmunka elején hitelesítik. Ezt követően az adminisztrátor által meghatározott ideig nem kell további hitelesítést végeznie. A közvetítő programok hitelesíthetik a fogadott és továbbított adatokat. Ez nem csak az elektronikus üzenetek hitelesítése szempontjából releváns, hanem a migrációs programok (Java, ActiveXControls) esetében is, amelyek ellen hamisítást lehet végrehajtani. Az üzenetek és programok hitelesítése azok ellenőrzéséből áll digitális aláírások. Ehhez digitális tanúsítványok is használhatók. A tűzfalhoz való hozzáférés során a felhasználók azonosítása és hitelesítése lehetővé teszi a belső vagy külső hálózati erőforrásokhoz való hozzáférésük megkülönböztetését. A belső hálózat erőforrásaihoz való megkülönböztetés módszerei nem különböznek az operációs rendszer szintjén támogatott megkülönböztetési módszerektől. A hozzáférés korlátozásakor nak nek A külső hálózati erőforrások leggyakrabban az alábbi módszerek egyikét használják:

csak meghatározott címekhez való hozzáférés engedélyezése a külső hálózatban;

kérések szűrése az érvénytelen címek frissített listái alapján, valamint az információs források nem kívánt kulcsszavak alapján történő keresésének blokkolása;

felhalmozása és frissítése a jogosult rendszergazda által információs források külső hálózat be lemezes tárolás tűzfal és a külső hálózathoz való hozzáférés teljes tiltása.

Az üzenetfolyam szűrését és átalakítását a közvetítő végzi egy adott szabályrendszer alapján. Itt kétféle közvetítő programot kell megkülönböztetni:

bizonyos típusú szolgáltatások, például FTP, HTTP, Telnet üzenetfolyam-elemzésére összpontosító átvizsgáló ügynökök;

univerzális átvizsgáló ágensek, amelyek a teljes üzenetfolyamot feldolgozzák, például olyan ágensek, amelyek a számítógépes vírusok megtalálására és semlegesítésére vagy az átlátható adattitkosításra összpontosítanak. A szoftverközvetítő elemzi a hozzá érkező adatcsomagokat, és ha valamelyik objektum nem felel meg a megadott kritériumoknak, akkor a közvetítő vagy blokkolja annak további előrehaladását, vagy megfelelő átalakításokat hajt végre, például semlegesíti az észlelt számítógépes vírusokat. A csomagok tartalmának elemzésekor fontos, hogy a védőügynök képes legyen automatikusan kicsomagolni az átmenő fájlarchívumokat.

A proxy tűzfalak lehetővé teszik biztonságos virtuális hálózatok (VirtualPrivateNetwork-VPN) megszervezését is, például több, az internethez kapcsolódó helyi hálózat biztonságos összekapcsolását egyetlen virtuális hálózatba. Az interneten keresztüli átvitel során nem csak a felhasználói adatok, hanem a szolgáltatási információk titkosítása is lehetséges - hálózati végcímek, portszámok stb. A közvetítő programok olyan fontos funkciót is elláthatnak, mint a belső hálózati címek fordítása. Ez a funkció a belső hálózattól a külső felé tartó összes csomagra vonatkozik. Ezeknél a csomagoknál a közvetítő automatikusan lefordítja a küldő számítógépek IP-címeit egyetlen „megbízható” IP-címre, amely a tűzfalhoz van társítva, amelyről az összes kimenő csomag továbbításra kerül. Ennek eredményeként a belső hálózatból minden kimenő csomagot a tűzfal küld el, ami kiküszöböli a közvetlen kapcsolatot az engedélyezett belső hálózat és a potenciálisan veszélyes külső hálózat között A tűzfal IP-címe lesz az egyetlen aktív IP-cím, amely belép a külső hálózatba.

Ezzel a megközelítéssel a belső hálózat topológiája el van rejtve a külső felhasználók elől, ami megnehezíti az illetéktelen hozzáférés feladatát. A biztonság javítása mellett a címfordítás lehetővé teszi, hogy saját címzési rendszere legyen a hálózaton belül, ami nem konzisztens a külső hálózatban, például az interneten történő címzéssel. Ez hatékonyan megoldja a belső hálózati címtér-bővítés és a külső hálózati címhiány problémáját. A közvetítő programok fontos funkciói az eseményregisztráció, az adott eseményekre való reagálás, valamint a regisztrált információk elemzése és jelentése. A jogosulatlan cselekmények végrehajtására irányuló kísérletek észlelésének kötelező válaszaként meg kell határozni az adminisztrátor értesítését, azaz figyelmeztető jelzések kiadását. Bármely tűzfal, amely nem tud riasztást küldeni támadás észlelésekor, nem hatékony tűzfal.

Számos tűzfal tartalmaz egy hatékony rendszert a statisztikák regisztrálására, gyűjtésére és elemzésére. A könyvelés a kliens és szerver címek, felhasználói azonosítók, munkamenet idő, csatlakozási idő, továbbított/fogadott adatok mennyisége, adminisztrátor és felhasználói műveletek alapján vezethető. A számviteli rendszerek lehetővé teszik a statisztikai elemzést, és részletes jelentéseket biztosítanak a rendszergazdáknak. Speciális protokollok használatával a közvetítők valós időben távolról értesíthetnek bizonyos eseményekről. Speciális közvetítők segítségével a külső hálózatról kért adatok gyorsítótárazása is támogatott. Amikor a belső hálózat felhasználói hozzáférnek a külső hálózat információforrásaihoz, minden információ a tűzfal merevlemez-területén halmozódik fel, amelyet ebben az esetben proxyszervernek nevezünk. Ezért, ha a következő kérésre a szükséges információk megjelennek a proxy szerveren, akkor a közvetítő azt a külső hálózat elérése nélkül biztosítja, ami jelentősen felgyorsítja a hozzáférést. Az adminisztrátornak csak a proxyszerver tartalmának időszakos frissítéséről kell gondoskodnia.

A gyorsítótár funkció sikeresen használható a külső hálózat információforrásaihoz való hozzáférés korlátozására. Ebben az esetben a külső hálózat összes engedélyezett információs erőforrását a rendszergazda felhalmozza és frissíti a proxyszerveren. A belső hálózat felhasználói csak a proxy szerver információs erőforrásaihoz férhetnek hozzá, a külső hálózat erőforrásaihoz közvetlen hozzáférés tilos. Az árnyékolószerek sokkal megbízhatóbbak, mint a hagyományos szűrők, és nagyobb fokú védelmet nyújtanak. Csökkentik azonban a belső és külső hálózatok közötti kommunikáció teljesítményét, és nem biztosítják az egyszerű szűrőkre jellemző átláthatóságot az alkalmazások és a végfelhasználók számára.

A tűzfal jellemzői az OSI modell különböző szintjein

A tűzfalak támogatják az internet biztonságát az OSI modell különböző szintjein. Ugyanakkor a referenciamodell különböző szintjein végzett védelmi funkciók jelentősen eltérnek egymástól. Ezért célszerű egy összetett tűzfalat oszthatatlan tűzfalak halmazaként ábrázolni, amelyek mindegyike az OSI modell egy külön rétegére összpontosít. A képernyő leggyakrabban a referenciamodell hálózati, munkamenet- és alkalmazásszintjén működik. Ennek megfelelően léteznek olyan oszthatatlan tűzfalak (A.3. ábra), mint egy átvizsgáló útválasztó, egy átvizsgáló átvitel (munkamenet szintű átjáró) és egy átvizsgáló átjáró (alkalmazás szintű átjáró).

Tekintettel arra, hogy a hálózatokban használt protokollok (TCP/IP, SPX/IPX) nem egyedileg felelnek meg az OSI modellnek, a felsorolt típusok képernyői funkcióik ellátása során a referenciamodell szomszédos szintjeit is lefedhetik. Például egy alkalmazás képernyője automatikusan titkosítja az üzeneteket, amikor azokat egy külső hálózatra továbbítja, valamint automatikusan visszafejti a titkosítással zárt fogadott adatokat. Ebben az esetben egy ilyen képernyő nem csak az OSI modell alkalmazási rétegében működik, hanem a prezentációs rétegben is. A session réteg átjáró működése során lefedi az OSI modell szállítási és hálózati rétegeit. Az üzenetcsomagok elemzésekor egy átvizsgáló router nem csak hálózati, hanem szállítási szinten is ellenőrzi azok fejlécét.

Minden típusú tűzfalnak megvannak a maga előnyei és hátrányai. A használt tűzfalak többsége vagy alkalmazásátjáró, vagy árnyékoló útválasztó, és nem nyújt teljes körű együttműködési biztonságot. Megbízható védelmet csak az összetett tűzfalak biztosítanak, amelyek mindegyike egy árnyékoló útválasztót, egy munkamenet-szintű átjárót és egy alkalmazásátjárót kombinál.

Rizs. A.3. Az OSI modell egyes rétegein működő tűzfalak típusai

Az internet-hozzáférés rugalmas szűrésének hiányában a teljes forgalom közel felét teszik ki a felesleges és veszélyes oldalak, amelyeket a munkavállalók naponta felkeresnek.

A nem kívánt erőforrások listáján a vezetők közösségi hálózatok, obszcén tartalmú portálok, online játékszerverek és olyan oldalak, amelyek úgynevezett "nagy" forgalmat generálnak, és videók és flash bannerek letöltésére és megtekintésére hívják a látogatókat.

Azok a potenciális veszélyek, amelyek abból fakadhatnak, hogy az alkalmazottak különböző, nem a munkájukkal összefüggő helyszínekre látogatnak, a munkaidővel való visszaélésen túl a következőképpen nézhetnek ki:

túlzott hálózati terhelés, amelyet az alkalmazottak nagyméretű fájlok internetről történő ellenőrizetlen letöltése okozott. Abban az esetben, ha állandó vagy dedikált kapcsolatról van szó fix csatornasebességgel egy szolgáltatótól, a videofájlok felhasználók általi megtekintése vagy letöltése negatívan befolyásolja a hálózati erőforrások elosztását és az internetes csatorna egészének terhelését, valamint a nem megfelelő forgalom költségei;
a hálózati erőforrások és a munkaidő irracionális felhasználása az online játékok rajongóinak videó- vagy hangcsevegési tevékenysége következtében;
az alkalmazottak ellenőrizetlen távoli kapcsolatai a vállalati hálózatok működő szervereivel VPN-kapcsolatokon vagy segédprogramokon keresztül, amelyek a helyi hálózat távoli számítógépen esetlegesen található vírusokkal való megfertőzésének kockázatával járnak;
a vállalati hálózat biztonsági szintjének csökkenése.

Az üzlet biztonságának és integritásának biztosítása, az esetleges információszivárgás csatornáinak blokkolása és az alkalmazottak termelékenységének növelése érdekében az internetes kérések szűrésével ellenőrizni kell a helyi hálózatba érkező internetes forgalom áramlását. Ha megtiltja bizonyos erőforrásokhoz való hozzáférést szűrők beállításával, akkor megoldhatja a nem célzott internetes erőforrások költségeinek csökkentését, valamint jelentősen csökkentheti a vállalati hálózat belső erőforrásainak fertőzésének kockázatát.

A NetDefend D-Link tűzfalakban történő szűrés használatáról az „IDP, WCF, AV Functions” című fejezetben olvashat („Web Content Filtering (WCF)”).

VLAN-ok

VLAN (Virtual Local Area Network – virtuális helyi hálózat). A virtuális helyi hálózat olyan eszközök logikai csoportja, amelyek képesek az adatkapcsolat szintjén közvetlenül kommunikálni egymással, bár fizikailag csatlakoztathatók különböző hálózati kapcsolókhoz. Ezzel szemben a különböző VLAN-okban található eszközök forgalma teljes mértékben el van szigetelve a többi hálózati csomóponttól a kapcsolat szintjén, még akkor is, ha ugyanahhoz a kapcsolóhoz csatlakoznak. Ez azt jelenti, hogy a keretek nem adhatók át különböző virtuális hálózatok között a MAC-cím alapján, függetlenül a cím típusától – egyedi, csoportos vagy broadcast.

A VLAN-oknak a következő előnyei vannak:

telepítési rugalmasság – a VLAN-ok azok hatékony mód a hálózati felhasználók virtuális munkacsoportokba csoportosítása a hálózaton való fizikai elhelyezkedésük ellenére;
a VLAN használata lehetővé teszi a broadcast üzenetek vezérlését, ami növeli a felhasználó számára elérhető sávszélességet;
a VLAN-ok használata lehetővé teszi a hálózat biztonságának növelését egy kapcsolón vagy útválasztón konfigurált szűrők használatával a különböző virtuális hálózatokból származó felhasználók interakciójára vonatkozó szabályzat meghatározásával;

NetDefendOS rendszeren a VLAN egy vagy több VLAN interfészt támogathat, amelyek egy adott fizikai interfészhez vannak társítva. A NetDefend tűzfalak a VLAN interfészeket logikai interfészként kezelik, és szabálykészletek és útválasztási táblák segítségével hozzáférhetnek más NetDefendOS interfészekhez. A DFL-xxx sorozatú tűzfalakban konfigurált VLAN-ok az L3 rétegen működnek.

A VLAN-t több esetben használják. Gyakori használat, amikor egy Ethernet interfész több interfészként jelenik meg. Ez azt jelenti, hogy a NetDefend tűzfalakon található fizikai Ethernet portok számát nem korlátozza a külső hálózati kapcsolatok száma.

A VLAN-okat az egyes felhasználók csoportosítására is használják, így forgalmukat teljesen elválasztják a többi VLAN-tól. A NetDefendOS alatt a forgalom áthaladhat a különböző VLAN-ok között, és a NetDefendOS rendszerszabályai által biztosított biztonsági házirendek segítségével szűrhető.

A NetDefendOS VLAN konfigurációja tartalmazza a VLAN-csatornák (trunkok) kombinációját a NetDefend tűzfalaktól a kapcsolókig, amelyek interfészei port alapú VLAN-ként vannak konfigurálva. Bármely fizikai tűzfal interfész képes egyszerre átadni mindkét forgalmat – egy vagy több VLAN VLAN-forgalmát és nem VLAN-forgalmat.

A NetDefendOS teljes mértékben támogatja az IEEE 802.1Q szabványt a VLAN-okhoz, amelyek úgy működnek, hogy VLAN azonosítót (VLAN ID) adnak hozzá az Ethernet keret fejlécéhez. A VLAN ID egy 0 és 4095 közötti szám, amely az egyes keretekhez tartozó VLAN azonosítására szolgál. Ezzel a mechanizmussal az Ethernet keretek különböző VLAN-okhoz tartozhatnak, és továbbra is ugyanazt a fizikai interfészt osztják meg. A NetDefendOS-ben egy fizikai interfészhez egyedi VLAN azonosító rendelhető, és ugyanaz a VLAN azonosító más fizikai interfészekhez, pl. azonos virtuális hálózat lehetővé teszi a különböző fizikai interfészekhez csatlakoztatott felhasználói számítógépek kombinálását (6.1. ábrán - VLAN1 és VLAN2).

Rizs. 6.1.

Egy vagy több VLAN van konfigurálva a NetDefend tűzfal fizikai interfészén, és közvetlenül csatlakozik a kapcsolóhoz. Ez a kapcsolat VLAN-csatornaként (trunk) működik. A switchnek támogatnia kell a port alapú VLAN-okat. A tűzfalhoz csatlakozó kapcsolóport konfigurációját úgy kell konfigurálni, hogy elfogadja a VLAN-csatornákon (trunk) keresztül továbbított VLAN-azonosítókat.

Csakúgy, mint a vezetékes LAN-ban, a VLAN-ok használatának lehetősége megjelenik, és be vezetéknélküli hálózat Vannak mechanizmusok a vezeték nélküli kliensek megkülönböztetésére.

Virtuális magánhálózatok (VPN)

Az internetet egyre gyakrabban használják a számítógépek közötti kommunikációs eszközként, mivel hatékony és olcsó kommunikációt kínál. Az Internet azonban nyilvános hálózat, és a biztonságos kommunikáció érdekében szükség van valamilyen mechanizmusra, amely legalább a következő feladatokat kielégíti:

az információk bizalmas kezelése;
adatintegritás;
információk elérhetősége;

Ezeket a követelményeket egy mechanizmus, az ún VPN(Virtual Private Network – virtuális magánhálózat) – olyan technológiák általános neve, amelyek lehetővé teszik egy vagy több biztosítását hálózati kapcsolatok(logikai hálózat) egy másik hálózaton (például az interneten) keresztül kriptográfiai eszközökkel (titkosítás, hitelesítés, nyilvános kulcsú infrastruktúra, az újrajátszások és a továbbított változtatások elleni védelem logikai hálózatüzenetek).

A VPN létrehozása nem igényel további beruházásokat, és lehetővé teszi a bérelt vonalak használatának abbahagyását. A használt protokolloktól és a céltól függően a VPN biztosíthat kapcsolatokat három fajta: host-host, host-network és network-network.

Az érthetőség kedvéért képzeljük el a következő példát: egy vállalkozásnak több területileg távoli fióktelepe van, és „mobil” alkalmazottak dolgoznak otthon vagy úton. Egy hálózatba kell egyesíteni a vállalat összes alkalmazottját. A legegyszerűbb módja, hogy modemeket helyezünk el az egyes ágakba, és szükség szerint megszervezzük a kommunikációt. Egy ilyen megoldás azonban nem mindig kényelmes és jövedelmező - néha állandó kapcsolatra és nagyra van szüksége áteresztőképesség. Ehhez vagy külön vonalat kell fektetni az ágak között, vagy bérelnie kell őket. Mindkettő elég drága. És itt alternatívaként egyetlen biztonságos hálózat kiépítésekor használhatja az összes vállalati fiók VPN-kapcsolatát az interneten keresztül, és konfigurálhatja a VPN-eszközöket a hálózati gazdagépeken.

Rizs. 6.5.

Ebben az esetben sok probléma megoldódik - az ágak bárhol elhelyezkedhetnek a világon.

A veszély itt az, hogy először is a nyílt hálózat nyitott a világ minden tájáról érkező behatolók támadásaira. Másodszor, az összes adatot tisztán továbbítják az interneten, és a támadók, miután feltörték a hálózatot, minden információt továbbítanak a hálózaton. És harmadszor, az adatok nem csak elfoghatók, hanem cserélhetők is a hálózaton keresztüli átvitel során. Egy támadó például veszélyeztetheti az adatbázisok integritását, ha valamelyik megbízható ág ügyfelei nevében jár el.

Ennek megelőzése érdekében a VPN-megoldások olyan eszközöket használnak, mint az adattitkosítás az integritás és titkosság biztosítására, a hitelesítés és a jogosultság ellenőrzése a felhasználói jogok ellenőrzésére és a virtuális magánhálózathoz való hozzáférés lehetővé tételére.

A VPN-kapcsolat mindig egy pont-pont kapcsolatból áll, más néven alagút. Az alagút egy nem biztonságos hálózatban jön létre, amely legtöbbször az internet.

Alagútépítés vagy Egységbezárás egy átviteli mód hasznos információ köztes hálózaton keresztül. Az ilyen információk egy másik protokoll keretei (vagy csomagjai) lehetnek. Beágyazás esetén a keret nem úgy kerül továbbításra, ahogyan a küldő gazdagép létrehozta, hanem egy további fejléccel van ellátva, amely útválasztási információkat tartalmaz, amely lehetővé teszi, hogy a beágyazott csomagok áthaladjanak a köztes hálózaton (Internet). Az alagút végén a kereteket kicsomagolják és továbbítják a címzetthez. Általában egy alagutat két szélső eszköz hoz létre, amelyek a nyilvános hálózat belépési pontjain helyezkednek el. Az alagútkezelés egyik nyilvánvaló előnye, hogy ez a technológia lehetővé teszi a teljes eredeti csomag titkosítását, beleértve a fejlécet is, amely olyan információkat tartalmazhat, amelyeket a támadók a hálózat feltörésére használnak (például IP-címek, alhálózatok száma stb.). ) .

Bár két pont között VPN-alagút van kialakítva, mindegyik gazdagép további alagutakat hozhat létre más gazdagépekkel. Például, ha három távoli állomásnak kell kapcsolatba lépnie ugyanabban az irodával, három különálló VPN alagút jön létre ehhez az irodához. Az összes alagút esetében az irodai oldalon lévő csomópont azonos lehet. Ez annak a ténynek köszönhető, hogy a csomópont képes titkosítani és visszafejteni az adatokat a teljes hálózat nevében, amint az az ábrán látható:

A felhasználó kapcsolatot létesít a VPN-átjáróval, amely után a felhasználó hozzáfér a belső hálózathoz.

Magánhálózaton belül maga a titkosítás nem történik meg. Ennek az az oka, hogy a hálózat ezen része biztonságosnak és közvetlen irányítás alatt áll, szemben az Internettel. Ez akkor is igaz, ha az irodákat VPN-átjárókkal csatlakoztatja. Így a titkosítás csak azon információk esetében garantált, amelyeket nem biztonságos csatornán továbbítanak az irodák között.

Számos különböző megoldás létezik a virtuális magánhálózatok kiépítésére. A leghíresebb és legszélesebb körben használt protokollok a következők:

PPTP(Point-to-Point Tunneling Protocol) - ez a protokoll meglehetősen népszerűvé vált a Microsoft operációs rendszerekbe való beépítése miatt.
L2TP(Layer-2 Tunneling Protocol) – egyesíti az L2F (Layer 2 Forwarding) protokollt és a PPTP protokollt. Általában az IPSec-cel együtt használják.
IPSec(Internet Protocol Security) egy hivatalos internetes szabvány, amelyet az IETF (Internet Engineering Task Force) közösség fejlesztett ki.

A felsorolt protokollokat a D-Link eszközök támogatják.

A PPTP protokoll elsősorban betárcsázós kapcsolatokon alapuló virtuális magánhálózatokhoz készült. A protokoll lehetővé teszi a szervezést távoli hozzáférés, amely lehetővé teszi a felhasználók számára, hogy telefonos kapcsolatot létesítsenek internetszolgáltatókkal, és biztonságos alagutat hozzanak létre vállalati hálózataikhoz. Az IPSec-től eltérően a PPTP-t eredetileg nem arra tervezték, hogy alagutakat biztosítson közöttük helyi hálózatok. A PPTP kiterjeszti a PPP képességeit, egy adatkapcsolati protokollt, amelyet eredetileg az adatok beágyazására és pont-pont kapcsolatokon keresztül történő továbbítására terveztek.

A PPTP protokoll lehetővé teszi, hogy biztonságos csatornákat hozzon létre az adatcseréhez különféle protokollok – IP, IPX, NetBEUI stb. – használatával. Ezen protokollok adatait PPP keretekbe csomagolják, a PPTP protokoll segítségével IP protokoll csomagokba zárják. Ezután IP-n keresztül, titkosított formában továbbítják őket bármely TCP/IP-hálózaton keresztül. A fogadó gazdagép kivonja a PPP-kereteket az IP-csomagokból, majd feldolgozza azokat szabványos módon, azaz kivon egy IP, IPX vagy NetBEUI csomagot egy PPP keretből, és elküldi a helyi hálózaton keresztül. Így a PPTP protokoll pont-pont kapcsolatot hoz létre a hálózatban, és adatokat továbbít a létrehozott biztonságos csatornán. A PPTP-hez hasonló protokollok tokozásának fő előnye a többprotokollos jellegük. Azok. Az adatkapcsolati réteg adatvédelme átlátható a hálózati és az alkalmazási réteg protokolljai számára. Ezért a hálózaton belül mind az IP-protokoll (mint az IPSec-alapú VPN esetében), mind pedig bármely más protokoll használható átvitelként.

Jelenleg a könnyű implementáció miatt a PPTP protokollt széles körben használják mind a vállalati hálózathoz való megbízható, biztonságos hozzáférés megszerzésére, mind az ISP-hálózatokhoz való hozzáférésre, amikor az ügyfélnek PPTP-kapcsolatot kell létrehoznia egy ISP-vel az internet eléréséhez.

A PPTP-ben használt titkosítási módszert a PPP-réteg határozza meg. Általában a PPP kliens az asztali számítógép a Microsoft operációs rendszerrel, és a Microsoft Point-to-Point Encryption (MPPE) protokollt használják titkosítási protokollként. Ez a protokoll az RSA RC4 szabványon alapul, és támogatja a 40 vagy 128 bites titkosítást. Sok ilyen szintű titkosítási alkalmazáshoz használja ezt az algoritmust elég, bár kevésbé biztonságosnak tartják, mint az IPSec által kínált számos más titkosítási algoritmus, különösen a 168 bites Triple-Data Encryption Standard (3DES).

Hogyan jön létre a PPTP kapcsolat?

A PPTP beágyazza az IP-csomagokat az IP-hálózaton keresztüli továbbításhoz. A PPTP-kliensek alagútvezérlő kapcsolatot hoznak létre, amely életben tartja a kapcsolatot. Ezt a folyamatot az OSI modell szállítási rétegében hajtják végre. Az alagút létrehozása után az ügyfélszámítógép és a kiszolgáló megkezdi a szolgáltatáscsomagok cseréjét.

A PPTP vezérlőkapcsolaton kívül egy kapcsolat jön létre az alagúton keresztüli adatok küldésére. Az adatok beágyazása az alagútba küldés előtt két lépésből áll. Először létre információs rész PPP keret. Az adatok fentről lefelé haladnak, az OSI-alkalmazási rétegtől a kapcsolati rétegig. A kapott adatokat ezután felküldik az OSI-modellbe, és felső rétegbeli protokollokba zárják be.

A kapcsolati rétegből származó adatok elérik a szállítási réteget. Az információ azonban nem küldhető el a rendeltetési helyére, mivel ezért az OSI kapcsolati rétege a felelős. Ezért a PPTP titkosítja a csomag hasznos mezőjét, és átveszi a PPP-hez általában tartozó második szintű funkciókat, azaz egy PPP-fejlécet (fejléc) és egy végződést (trailer) ad a PPTP-csomaghoz. Ezzel befejeződik a hivatkozási réteg keretének létrehozása. Ezután a PPTP a PPP-keretet egy általános útválasztási beágyazási (GRE) csomagba foglalja, amely a hálózati réteghez tartozik. A GRE olyan hálózati réteg protokollokat foglal magában, mint például az IP, IPX, hogy lehetővé tegye azok IP-hálózatokon történő átvitelét. A GRE protokoll használata önmagában azonban nem biztosítja a munkamenetek létrehozását és az adatbiztonságot. Ez a PPTP azon képességét használja fel, hogy alagútvezérlő kapcsolatot hozzon létre. A GRE beágyazási módszerként való használata csak az IP-hálózatokra korlátozza a PPTP hatókörét.

Miután a PPP-keret egy GRE-fejléccel rendelkező keretbe került, egy IP-fejléccel rendelkező keretbe kerül. Az IP-fejléc tartalmazza a csomag küldőjének és címzettjének címét. Végül a PPTP hozzáad egy PPP fejlécet és végződést.

ábrán. A 6.7. ábra mutatja a PPTP alagúton keresztüli továbbítás adatszerkezetét:

A PPTP alapú VPN felállítása nem igényel nagy kiadásokat és bonyolult beállításokat: elég egy PPTP szervert telepíteni a központi irodába (a PPTP megoldások Windows és Linux platformra is léteznek), és a szükséges beállításokat a kliens számítógépeken elvégezni. Ha több ágat kell kombinálnia, akkor az összes kliensállomáson a PPTP beállítása helyett jobb internetes útválasztót vagy PPTP-támogatással rendelkező tűzfalat használni: a beállításokat csak az internethez csatlakoztatott határútválasztón (tűzfalon) kell elvégezni, minden teljesen átlátható a felhasználók számára. Ilyen eszközök például a DIR/DSR multifunkcionális internetes útválasztók és a DFL sorozatú tűzfalak.

GRE alagutak

A Generic Routing Encapsulation (GRE) egy hálózati csomagbeágyazási protokoll, amely titkosítás nélkül biztosítja a forgalom alagútvezetését a hálózatokon keresztül. Példák a GRE használatára:

forgalom továbbítása (beleértve a műsorszórást is) olyan berendezéseken keresztül, amelyek nem támogatnak egy adott protokollt;
IPv6-forgalom alagútvezetése IPv4-hálózaton keresztül;
adatátvitel nyilvános hálózatokon a biztonságos VPN-kapcsolat megvalósítása érdekében.

Rizs. 6.8.

A két A és B router között (6.8. ábra) több router található, a GRE alagút lehetővé teszi a 192.168.1.0/24 és a 192.168.3.0/24 helyi hálózatok közötti kapcsolatot úgy, mintha az A és B router közvetlenül csatlakozna. .

Jegyzőkönyv L2TP a PPTP és az L2F protokollok egyesítésének eredményeként jelent meg. Az L2TP protokoll fő előnye, hogy nem csak IP hálózatokban, hanem ATM, X.25 és Frame relay hálózatokban is lehetővé teszi alagút létrehozását. Az L2TP UDP-t használ átvitelként, és ugyanazt az üzenetformátumot használja mind az alagútkezeléshez, mind az adattovábbításhoz.

A PPTP-hez hasonlóan az L2TP elkezdi összeállítani a csomagot az alagútba való továbbításhoz úgy, hogy először hozzáadja a PPP fejlécet, majd az L2TP fejlécet a PPP információs adatmezőhöz. Az így kapott csomagot az UDP kapszulázza. A választott IPSec biztonsági házirend típusától függően az L2TP titkosíthatja az UDP-üzeneteket, és hozzáadhat egy Encapsulating Security Payload (ESP) fejlécet és végződést, valamint egy IPSec-hitelesítési végződést (lásd: „L2TP over IPSec” szakasz). Ezután IP-be kapszulázzák. A rendszer hozzáad egy IP-fejlécet, amely tartalmazza a feladó és a címzett címét. Végül az L2TP egy második PPP-beágyazást hajt végre, hogy előkészítse az adatokat az átvitelre. ábrán. A 6.9. ábra az L2TP alagúton keresztüli továbbítás adatszerkezetét mutatja.

A fogadó számítógép fogadja az adatokat, feldolgozza a PPP-fejlécet és a végződést, és eltávolítja az IP-fejlécet. Az IPSec Authentication hitelesíti az IP információs mezőt, az IPSec ESP fejléc pedig segít a csomag visszafejtésében.

A számítógép ezután feldolgozza az UDP-fejlécet, és az L2TP-fejlécet használja az alagút azonosítására. A PPP-csomag most csak a feldolgozás alatt álló vagy a megadott címzettnek továbbított hasznos terhelést tartalmazza.

IPsec(az IP Security rövidítése) - protokollkészlet az Internet Protocol IP-n keresztül továbbított adatok védelmének biztosítására, lehetővé teszi az IP-csomagok hitelesítését és / vagy titkosítását. Az IPsec protokollokat is tartalmaz a biztonságos kulcscseréhez az interneten.

Az IPSec biztonságát további protokollok biztosítják, amelyek saját fejlécet adnak az IP-csomaghoz – tokozás. Mert Az IPSec egy internetes szabvány, akkor vannak RFC dokumentumok hozzá:

Az RFC 2401 (Security Architecture for the Internet Protocol) az IP-protokoll biztonsági architektúrája.
RFC 2402 (IP Authentication header) – IP hitelesítési fejléc.
RFC 2403 (A HMAC-MD5-96 használata az ESP-n és AH-n belül) – Az MD-5 hash algoritmus használata hitelesítési fejléc létrehozására.
RFC 2404 (A HMAC-SHA-1-96 használata az ESP-n és az AH-n belül) – Az SHA-1 hash algoritmus használata hitelesítési fejléc létrehozására.
RFC 2405 (Az ESP DES-CBC titkosítási algoritmus Explicit IV-el) – A DES titkosítási algoritmus használata.
RFC 2406 (IP Encapsulating Security Payload (ESP)) – Adattitkosítás.
Az RFC 2407 (The Internet IP Security Domain of Interpretation for ISAKMP) a kulcskezelési protokoll hatóköre.
RFC 2408( internet biztonság Association and Key Management Protocol (ISAKMP) - a biztonságos kapcsolatok kulcsainak és hitelesítőinek kezelése.
RFC 2409 (Internet Key Exchange (IKE)) – Kulcscsere.
RFC 2410 (A NULL titkosítási algoritmus és használata az IPsec-cel) – A NULL titkosítási algoritmus és annak használata.
Az RFC 2411 (IP Security Document Roadmap) a szabvány továbbfejlesztése.
RFC 2412 (The OAKLEY Key Determination Protocol) – Kulcs hitelességének ellenőrzése.

Az IPsec az IPv6 Internet Protokoll szerves része, és az Internet Protokoll IPv4 verziójának opcionális kiterjesztése.

Az IPSec mechanizmus a következő feladatokat hajtja végre:

felhasználók vagy számítógépek hitelesítése a biztonságos csatorna inicializálása során;
biztonságos csatorna végpontjai között továbbított adatok titkosítása és hitelesítése;
csatornavégpontok automatikus ellátása a hitelesítési és adattitkosítási protokollok működéséhez szükséges titkos kulcsokkal.

IPSec komponensek

Jegyzőkönyv AH(Authentication Header) – fejléc azonosítási protokoll. Az integritást azáltal biztosítja, hogy ellenőrzi, hogy a csomag védett részének bitjei nem változtak-e az átvitel során. Az AH használata azonban problémákat okozhat, például amikor egy csomag áthalad egy NAT-eszközön. A NAT megváltoztatja a csomag IP-címét, hogy lehetővé tegye az internet-hozzáférést egy privát helyi címről. Mert ilyenkor megváltozik a csomag, ekkor az AH ellenőrzőösszeg hibássá válik (e probléma kiküszöbölésére fejlesztették ki a NAT-Traversal (NAT-T) protokollt, amely UDP-n keresztül biztosítja az ESP átvitelt és a 4500-as UDP portot használja a munkájában). Azt is érdemes megjegyezni, hogy az AH-t csak az integritásra tervezték. Nem garantálja a titoktartást a csomag tartalmának titkosításával.

Jegyzőkönyv ESP(Encapsulation Security Payload) nem csak a továbbított adatok integritását és hitelesítését biztosítja, hanem az adatok titkosítását, valamint a hamis csomaglejátszás elleni védelmet is.

Az ESP protokoll egy beágyazó biztonsági protokoll, amely integritást és bizalmasságot egyaránt biztosít. Szállítási módban az ESP-fejléc az eredeti IP-fejléc és a TCP- vagy UDP-fejléc között található. Alagút módban az ESP fejléc az új IP-fejléc és a teljesen titkosított eredeti IP-csomag közé kerül.

Mert mindkét protokoll - AH és ESP - saját IP-fejlécet ad hozzá, mindegyiknek saját protokollszáma (ID) van, amely alapján meghatározhatja, hogy mi kövesse az IP-fejlécet. Az IANA (Internet Assigned Numbers Authority – az internet címteréért felelős szervezet) szerint minden protokollnak saját száma (ID) van. Például a TCP-nél ez a szám 6, az UDP-nél pedig 17. Ezért nagyon fontos a tűzfalon keresztüli munka során a szűrőket úgy konfigurálni, hogy a protokoll AH és/vagy ESP azonosítójú csomagjait továbbítsák.

Az 51-es protokollazonosító úgy van beállítva, hogy jelezze, hogy az AH jelen van az IP-fejlécben, az 50-es pedig az ESP esetében.

FIGYELEM: A protokollazonosító nem egyezik meg a portszámmal.

Jegyzőkönyv IKE(Internet Key Exchange) egy szabványos IPsec-protokoll, amelyet a virtuális magánhálózatok kommunikációjának biztosítására használnak. Az IKE célja az azonosított anyagok biztonságos egyeztetése és eljuttatása egy biztonsági egyesülethez (SA).

SA a kapcsolat IPSec kifejezése. A létrehozott SA (biztonságos csatorna, amelyet "biztonságos társításnak" vagy "biztonsági társításnak" neveznek - Security Association, SA) tartalmaz egy megosztott titkos kulcsot és egy kriptográfiai algoritmuskészletet.

Az IKE protokoll három fő feladatot lát el:

hitelesítési eszközt biztosít két VPN-végpont között;
új IPSec kapcsolatokat hoz létre (létrehoz egy SA-párt);
kezeli a meglévő kapcsolatokat.

Az IKE az 500-as UDP-portot használja. A NAT-bejárási szolgáltatás használatakor, amint azt korábban említettük, az IKE-protokoll a 4500-as UDP-portot használja.

Az adatcsere az IKE-ben 2 fázisban történik. Az első ütemben megalakul az SA IKE egyesület. Ezzel egyidejűleg a csatorna végpontjait hitelesítik, és kiválasztják az adatvédelmi paramétereket, mint például a titkosítási algoritmus, a munkamenet kulcsa stb.

A második fázisban az SA IKE-t használják protokollegyeztetésre (általában IPSec).

Egy konfigurált VPN-alagút esetén minden használt protokollhoz egy SA-pár jön létre. Az SA-k párban jönnek létre, as minden SA egyirányú kapcsolat, és az adatokat két irányba kell küldeni. A kapott SA párokat minden csomópont tárolja.

Mivel minden csomópont több alagutat is képes létrehozni más csomópontokkal, minden SA egyedi számmal rendelkezik, amely azonosítja, hogy melyik csomóponthoz tartozik. Ezt a számot hívják SPI(Biztonsági paraméter index) ill biztonsági paraméter index.

SA adatbázisban (DB) tárolva SZOMORÚ(Security Association Database).

Minden IPSec csomópontnak van egy második DB − is SPD(Security Policy Database) – Biztonsági szabályzat adatbázis. Ez tartalmazza a konfigurált gazdagép házirendet. A legtöbb VPN-megoldás lehetővé teszi több házirend létrehozását megfelelő algoritmusok kombinációjával minden egyes gazdagéphez, amelyhez csatlakozni kíván.

Az IPSec rugalmassága abban rejlik, hogy minden feladathoz többféle megoldási mód létezik, és az egy-egy feladathoz választott módszerek általában függetlenek a többi feladat megvalósításának módszereitől. Az IETF munkacsoport azonban meghatározta a támogatott szolgáltatások és algoritmusok alapvető készletét, amelyeket minden IPSec-kompatibilis termékben azonos módon kell megvalósítani. Az AH és ESP mechanizmusok különféle hitelesítési és titkosítási sémákkal használhatók, amelyek közül néhány kötelező. Például az IPSec meghatározza, hogy a csomagok hitelesítése az MD5 egyirányú funkciójával vagy az SHA-1 egyirányú funkciójával történik, a titkosítás pedig a DES algoritmussal történik. Az IPSec-et futtató termékek gyártói további hitelesítési és titkosítási algoritmusokat is hozzáadhatnak. Egyes termékek például támogatnak olyan titkosítási algoritmusokat, mint a 3DES, Blowfish, Cast, RC5 stb.

Bármilyen szimmetrikus titkosítási algoritmus, amely titkos kulcsokat használ, használható az adatok titkosításához az IPSec-ben.

Az adatfolyam-védelmi protokollok (AH és ESP) két módban működhetnek - be közlekedési módés be alagút mód. Ha szállítási módban működik, az IPsec csak a szállítási réteg információit kezeli; csak a TCP / UDP protokollokat tartalmazó csomag adatmezője titkosított (az IP csomag fejléce nem változik (nincs titkosítva)). A szállítási módot általában a gazdagépek közötti kapcsolat létrehozására használják.

Az alagút mód a teljes IP-csomagot titkosítja, beleértve a hálózati réteg fejlécét is. Ahhoz, hogy a hálózaton keresztül továbbítható legyen, egy másik IP-csomagba kerül. Lényegében ez egy biztonságos IP-alagút. Alagút mód használható távoli számítógépek virtuális magánhálózathoz történő csatlakoztatására ("host-hálózat" csatlakozási séma), vagy biztonságos adatátvitel megszervezésére csatornák megnyitása az átjárók közötti kommunikáció (például az internet) összekapcsolása Különböző részek virtuális magánhálózat ("hálózat-hálózat" csatlakozási séma).

Az IPsec módok nem zárják ki egymást. Ugyanazon a gazdagépen egyes SA-k szállítási módot, míg mások alagút módot használhatnak.

A hitelesítési szakaszban a csomag ICV ellenőrző összege (Integrity Check Value) kiszámításra kerül. Ez azt feltételezi, hogy mindkét csomópont ismeri a titkos kulcsot, amely lehetővé teszi a címzett számára, hogy kiszámítsa az ICV-t, és összehasonlítsa a küldő által küldött eredménnyel. Ha az ICV-összehasonlítás sikeres, a csomag feladója hitelesítettnek minősül.

módban Szállítás AH

a teljes IP-csomagot, kivéve az IP fejléc egyes mezőit, amelyek továbbítás közben módosíthatók. Ezek a mezők, amelyeknek az ICV számítási értéke 0, a szolgáltatás részét képezhetik (Szolgáltatás típusa, TOS), zászlók, töredékeltolás, élettartam (TTL), valamint ellenőrző összeg fejléc;
minden mező az AH-ban;
IP-csomagok hasznos terhelése.

Az AH szállítási módban védi az IP-fejlécet (kivéve a változtatható mezőket) és az eredeti IP-csomag hasznos terhelését (3.39. ábra).

Alagút módban az eredeti csomag egy új IP-csomagba kerül, és az adatátvitel az új IP-csomag fejléce alapján történik.

Mert alagút üzemmód AH a számítás során a következő összetevőket tartalmazza az ICV ellenőrző összeg:

a külső IP-fejléc összes mezője, kivéve az IP-fejléc egyes mezőit, amelyek az átvitel során módosíthatók. Ezek a mezők, amelyeknek az ICV számítási értéke 0, a szolgáltatás részét képezhetik (Szolgáltatás típusa, TOS), zászlók, töredékeltolás, élettartam (TTL), valamint ellenőrző összeg fejléc;
minden mező AH;
eredeti IP-csomag.

Amint az a következő ábrán látható, az AH alagút mód a teljes forrás IP-csomagot egy további külső fejléccel védi, amelyet az AH szállítási mód nem használ:

módban szállítás ESP nem hitelesíti a teljes csomagot, csak az IP hasznos adatot védi. Az ESP átviteli módban lévő ESP fejléc közvetlenül az IP-fejléc után kerül az IP-csomagba, és ennek megfelelően az adatok után az ESP-végződés (ESP Trailer).

Az ESP szállítási mód a csomag következő részeit titkosítja:

IP hasznos teher;
ESP Trailer.

A Cipher Block Chaining (CBC) titkosítási módot használó titkosítási algoritmusnak van egy titkosítatlan mezője az ESP fejléc és a hasznos adat között. Ezt a mezőt IV-nek (Initialization Vector) nevezik a CBC számításhoz, amelyet a vevőn hajtanak végre. Mivel ez a mező a visszafejtési folyamat elindítására szolgál, nem titkosítható. Annak ellenére, hogy a támadó meg tudja tekinteni az IV-et, a titkosítási kulcs nélkül nem tudja visszafejteni a csomag titkosított részét. Annak megakadályozása érdekében, hogy a támadók megváltoztassák az inicializálási vektort, azt az ICV ellenőrző összege védi. Ebben az esetben az ICV a következő számításokat végzi el:

az ESP fejléc összes mezője;
hasznos teher, beleértve az egyszerű szöveget IV;
az ESP Trailer összes mezője, kivéve a hitelesítési adatmezőt.

Az ESP alagút mód a teljes eredeti IP-csomagot egy új IP-fejlécbe, egy ESP-fejlécbe és egy ESP-előzetesbe foglalja. Annak jelzésére, hogy az ESP jelen van az IP-fejlécben, az IP-protokoll-azonosító 50-re van állítva, az eredeti IP-fejléc és a hasznos adat változatlan marad. Az AH alagút módhoz hasonlóan a külső IP-fejléc az IPSec alagútkonfiguráción alapul. Az ESP alagút mód használata esetén az IP-csomag hitelesítési területe mutatja, hogy hol készült az aláírás, amely igazolja annak integritását és hitelességét, a titkosított rész pedig azt, hogy az információ védett és bizalmas. Az eredeti fejléc az ESP fejléc mögé kerül. Miután a titkosított rész egy új, nem titkosított alagútfejlécbe került, az IP-csomag továbbításra kerül. Nyilvános hálózaton keresztül küldve az ilyen csomagot a fogadó hálózat átjárójának IP-címére irányítják, és az átjáró visszafejti a csomag titkosítását, és az eredeti IP-fejléc használatával elveti az ESP-fejlécet, majd a csomagot egy számítógépre irányítja. a belső hálózat. Az ESP alagút mód a csomag következő részeit titkosítja:

eredeti IP-csomag;
ESP Trailer.
Az ESP alagút üzemmódban az ICV kiszámítása a következőképpen történik:
az ESP fejléc összes mezője;
az eredeti IP-csomag, beleértve a IV. egyszerű szöveget;
minden ESP fejléc mező, kivéve a hitelesítési adatmezőt.

Az IPSec módok használatának összefoglalása:

Protokoll - ESP (AH).
Mód - alagút (közlekedés).
Kulcscsere módja - IKE (kézi).
IKE mód - fő (agresszív).
DH kulcs – 5. csoport (2. csoport, 1. csoport) – csoportszám a dinamikusan létrehozott munkamenetkulcsok kiválasztásához, csoport hossza.
Hitelesítés - SHA1 (SHA, MD5).
Titkosítás - DES (3DES, Blowfish, AES).

A házirend létrehozásakor általában lehetőség van algoritmusok és Diffie-Hellman csoportok rendezett listájának létrehozására. Diffie-Hellman (DH)– Egy titkosítási protokoll, amellyel megosztott titkos kulcsokat hoz létre az IKE, IPSec és PFS (Perfect Forward Secrecy) számára. Ebben az esetben a rendszer az első pozíciót használja, amelyik mindkét csomóponton megegyezik. Nagyon fontos, hogy a biztonsági politikában minden lehetővé tegye ennek a véletlennek az elérését. Ha a házirend egy részének kivételével minden más egyezik, a gazdagépek továbbra sem tudnak VPN-kapcsolatot létesíteni. Amikor VPN alagutat hoz létre a különböző rendszerek között, meg kell találnia, hogy az egyes oldalak mely algoritmusokat támogatják, hogy a lehető legbiztonságosabb házirendet tudja kiválasztani.

A biztonsági házirend főbb beállításai:

Szimmetrikus algoritmusok az adatok titkosításához/visszafejtéséhez.
Kriptográfia ellenőrző összegeket hogy ellenőrizze az adatok sértetlenségét.
Csomópont azonosítási módszer. A leggyakoribb módszerek az előre megosztott titkok vagy CA-tanúsítványok.
Akár alagút, akár szállítási módot használunk.
Melyik Diffie-Hellman csoportot kell használni (1. DH csoport (768 bit); 2. DH csoport (1024 bit; 5. DH csoport (1536 bit)).
Akár AH-t, ESP-t, akár mindkettőt használja.
Használja-e a PFS-t.

Az IPSec korlátja, hogy csak az IP protokoll rétegen támogatja az adatátvitelt.

Az IPSec használatára két fő séma létezik, amelyek a biztonságos csatornát alkotó csomópontok szerepében különböznek egymástól.

Az első sémában egy biztonságos csatorna jön létre a hálózat végállomásai között. Ebben a sémában az IPSec protokoll védi a futó gazdagépet:

Rizs. 6.13.

A második sémában egy biztonságos csatorna jön létre két biztonsági átjáró között. Ezek az átjárók adatokat fogadnak az átjárók mögötti hálózatokhoz csatlakozó végállomásoktól. A végállomások ebben az esetben nem támogatják az IPSec protokollt, a nyilvános hálózatra irányított forgalom a biztonsági átjárón halad át, amely a saját nevében végez védelmet.

Az IPSec-et támogató gazdagépeknél a szállítási mód és az alagút mód is használható. Átjárók esetében csak alagút mód engedélyezett.

VPN telepítés és támogatás

Mint fentebb említettük, a VPN-alagút telepítése és karbantartása kétlépéses folyamat. Az első szakaszban (fázisban) a két csomópont megállapodik egy azonosítási módszerben, egy titkosítási algoritmusban, egy hash algoritmusban és egy Diffie-Hellman csoportban. Egymást is azonosítják. Mindez három titkosítatlan üzenet cseréje (az ún. agresszív mód, agresszív mód) vagy hat üzenet, titkosított azonosító információ cseréjével (standard mód, fő mód).

A Fő módban lehetőség van a küldő és a fogadó eszközök összes konfigurációs paraméterének egyeztetésére, míg az Agresszív módban ez nem lehetséges, és bizonyos paramétereket (Diffie-Hellman csoport, titkosítási és hitelesítési algoritmusok, PFS) előre meg kell határozni. - minden eszközön azonos módon konfigurálva. Ebben a módban azonban mind a cserék, mind a küldött csomagok száma kevesebb, így kevesebb időre van szükség az IPSec-munkamenet létrehozásához.

Feltételezve, hogy a művelet sikeresen befejeződött, létrejön egy első fázisú SA - 1SA fázis(más néven IKE SA) és a folyamat a második fázisba lép.

A második lépésben a kulcsadatok generálódnak, a csomópontok megegyeznek a használandó szabályzatban. Ez a gyors módnak is nevezett mód abban különbözik az 1. fázistól, hogy csak az 1. fázis után hozható létre, amikor az összes 2. fázisú csomag titkosítva van. A második fázis helyes befejezése a megjelenéshez vezet 2SA fázis vagy IPSec SAés ezen az alagút beépítése befejezettnek tekintendő.

Először egy csomag érkezik a csomóponthoz egy másik hálózat célcímével, és a csomópont kezdeményezi az első fázist a másik hálózatért felelős csomóponttal. Tegyük fel, hogy a csomópontok közötti alagút sikeresen létrejött, és csomagokra vár. A csomópontoknak azonban újra kell azonosítaniuk egymást, és egy bizonyos idő elteltével össze kell hasonlítaniuk a házirendeket. Ezt az időszakot ún Első fázis élettartama vagy IKE SA élettartama.

A csomópontoknak meg kell változtatniuk a kulcsot az adatok titkosításához egy adott időtartam után Második fázis élettartama vagy IPSec SA élettartama.

A második fázis élettartama rövidebb, mint az első fázisé, mert a kulcsot gyakrabban kell cserélni. Mindkét csomóponthoz ugyanazokat az élettartam-paramétereket kell beállítani. Ha ezt nem teszi meg, akkor lehetséges, hogy kezdetben az alagút sikeresen létrejön, de az első inkonzisztens életszakasz után a kapcsolat megszakad. Problémák adódhatnak akkor is, ha az első fázis élettartama rövidebb, mint a második fázisé. Ha a korábban konfigurált alagút leáll, akkor az első dolog, amit ellenőrizni kell, mindkét csomópont élettartama.

Azt is meg kell jegyezni, hogy ha az egyik csomóponton módosítja a házirendet, a változtatások csak az első fázis következő kezdetén lépnek érvénybe. A módosítások azonnali érvénybe lépéséhez el kell távolítania az alagút SA-t az SAD-adatbázisból. Ez kikényszeríti a csomópontok közötti megállapodás felülvizsgálatát az új biztonsági házirend-beállításokkal.

Néha, amikor IPSec alagutat hoz létre a berendezések között különböző gyártók nehézségek merülnek fel a paraméterek koordinálásával az első fázis kialakításakor. Figyelni kell egy olyan paraméterre, mint a Helyi azonosító - ez az egyedi azonosító alagút végpontja (küldő és célállomás). Ez különösen fontos több alagút létrehozásakor és a NAT Traversal protokoll használatakor.

Halott társak észlelése

VPN működés közben, ha nincs forgalom az alagút végpontjai között, vagy ha a távoli gazdagép kezdeti adatai megváltoznak (például megváltozik a dinamikusan hozzárendelt IP-cím), akkor olyan helyzet állhat elő, amikor az alagút lényegében már nem , mintegy szellemalagúttá válik. A létrehozott IPSec alagútban az adatcsere folyamatos készenlétének fenntartása érdekében az IKE mechanizmus (az RFC 3706-ban leírta) lehetővé teszi az alagút távoli csomópontjából érkező forgalom szabályozását, és ha az egy meghatározott ideig nincs jelen, üdvözlő üzenetet küld (tűzfalakban a D-Link "DPD-R-U-THERE" üzenetet küld). Ha egy bizonyos időn belül nem érkezik válasz erre az üzenetre, a D-Link tűzfalakban a "DPD Expire Time" beállításaiban az alagút lebontásra kerül. Ezt követően a D-Link tűzfalak a "DPD Keep Time" beállításainak használatával (6.18. ábra) automatikusan megpróbálják visszaállítani az alagutat.

NAT bejárási protokoll

Az IPsec-forgalom ugyanazon szabályok szerint irányítható, mint a többi IP-protokoll, de mivel az útválasztó nem mindig tudja kinyerni a szállítási réteg protokolljaira jellemző információkat, lehetetlen, hogy az IPsec áthaladjon a NAT-átjárókon. Amint azt korábban említettük, a probléma megoldására az IETF meghatározta az ESP UDP-be ágyazásának módját, az úgynevezett NAT-T-t (NAT Traversal).

A NAT Traversal protokoll magába foglalja az IPSec forgalmat, és ezzel egyidejűleg UDP-csomagokat hoz létre, amelyeket a NAT megfelelően továbbít. Ehhez a NAT-T egy további UDP-fejlécet helyez el az IPSec-csomag elé, így azt normál UDP-csomagként kezeli az egész hálózaton, és a fogadó gazdagép nem végez integritás-ellenőrzést. Miután a csomag megérkezett a rendeltetési helyére, az UDP-fejléc eltávolításra kerül, és az adatcsomag tokozott IPSec-csomagként folytatja útját. Így a NAT-T mechanizmus használatával lehetőség nyílik a biztonságos hálózatokban lévő IPSec-kliensek és a tűzfalakon keresztüli nyilvános IPSec-gazdagépek közötti kommunikáció kialakítására.

Két szempontot kell figyelembe venni a D-Link tűzfalak konfigurálásakor a fogadó eszközön:

a Távoli hálózat és a Távoli végpont mezőben adja meg a távoli küldő eszköz hálózatát és IP-címét. Engedélyezni kell a kezdeményező (küldő) IP-címének lefordítását NAT technológia segítségével (3.48. ábra).
Ha megosztott kulcsokat használ több alagúthoz, amelyek ugyanahhoz a távoli tűzfalhoz vannak csatlakoztatva, és amelyek NAT-címmel lettek megadva, fontos gondoskodni arról, hogy a helyi azonosító minden alagútnál egyedi legyen.

Helyi azonosító a következők egyike lehet:

Auto– helyi azonosítóként a kimenő forgalmi interfész IP-címét használjuk.
IP– A távoli tűzfal WAN portjának IP-címe
DNS– DNS cím
Email– E-mail

IPSec a D-Link tűzfalakban

A NetDefend tűzfalak lehetővé teszik IPSec-alagutak létrehozását IKE-kulcsok és tanúsítványok alapján.

Kulcsok használata (előre megosztott kulcs)

Minimális beállításokkal a VPN-kiszolgáló működéséhez a következőket kell tennie:

Objektumok létrehozása (mappában Objektumok):
- a távoli pont IP-címe (például IPSec_remote_endpoint) és a távoli hálózat (például IPSec_remote_net);
- kulcs Előre megosztott kulcs (hitelesítési objektumok), egy tárgy IKE algoritmusokés tárgyat IPSec algoritmusok (VPN objektumok). Alapértelmezés a DFL-objektumokban IKE algoritmusok, IPSec algoritmusok valamint a titkosítási és kivonatolási algoritmusok már be vannak állítva, de módosíthatja vagy hozzáadhatja a kulcscserében (IKE algoritmusok) és magában a forgalom titkosításában (IPSec Algorithms) használható algoritmusokat.
Teremt IPSec alagút(mappában Interfészek).
Hozzon létre engedélyezési szabályokat (a mappában IP-szabályok) az alagútból a belső hálózatba irányuló forgalom eléréséhez és fordítva.

Tanúsítványok használata

Az X.509 tanúsítványok titkosítási módszeren alapulnak nyilvános kulcs. Minden tanúsítvány a többi információval együtt (érvényességi idő, tulajdonos neve stb.) tartalmaz egy nyilvános kulcsot. A tulajdonos a titkos kulcsot egy külön fájlba menti.

A tanúsítványokat az igazolási hatóság (CA) írja alá, hogy hitelesítse a tanúsítványt, a tanúsítványban található információkat és végül a távoli gazdagépet. A hitelesítésszolgáltató hitelességét a tanúsítványa alapján ellenőrzik, amely nyilvánosan elérhető.

A tanúsítványok a személyazonosság digitális igazolása, és felhasználhatók az egyéni felhasználók vagy más végfelhasználók hitelesítésére. Tanúsítványhitelesítéssel rendelkező VPN-alagút létrehozásához a tűzfalnak saját tanúsítvánnyal és a távoli tűzfal tanúsítványával kell rendelkeznie. Ezek a tanúsítványok lehetnek önaláírtak vagy egy tanúsító hatóság (CA) által aláírtak.

VPN-alagút beállításakor a tűzfalnak tudnia kell, hogy kiben kell megbíznia. Előre megosztott kulcsok használatakor minden egyszerű. A tűzfal mindenkiben megbízik, akinek ugyanaz a kulcsa van. Tanúsítványok használata esetén a tűzfalnak megbíznia kell mindenkiben, akinek a tanúsítványát ez a CA aláírta. A tanúsítvány elfogadása előtt a következő lépéseket kell végrehajtani a tanúsítvány hitelességének ellenőrzésére:

hitelesítési útvonalat hoznak létre egy megbízható gyökér CA-hoz;
a hitelesítési útvonalon lévő összes tanúsítvány aláírása ellenőrzésre kerül.

A VPN-alagút általában akkor jön létre, ha a CA által aláírt távoli gazdagép-tanúsítvány jelen van a mezőben gyökértanúsítványok lapon Hitelesítés a létrehozott VPN alagút menüjében. Bizonyos esetekben azonban szükségessé válik annak korlátozása, hogy ki létesíthet VPN-alagutat még az ugyanazon CA által aláírt partnerek között is. A személyiségek listája a mezőben választható ki Azonosítási lista A két mód közötti különbség az, hogy az Agresszív mód átmegy nagy mennyiség információ kevesebb csomagban (lerövidíti a kapcsolódási időt (IPSec alagút létrehozása)), de nem nyújt hitelesítési védelmet.

DH IKE kulcscsoport (IKE DH Group). A DH – Diffie-Hellman egy titkosítási protokoll, amely lehetővé teszi két nem biztonságos hálózaton (például az interneten) keresztül kommunikáló fél számára, hogy megosztott titkos kulcsot hozzanak létre, amelyet később a felek közötti adatok titkosítására használnak.

Az algoritmus kriptográfiai erősségét a kulcs mérete határozza meg: 1 (768 bit), 2 (1024 bit) vagy 5 (1536 bit). Az 1. DH csoport kulcsmérete 768 bit. A 2. DH csoport kulcsmérete 1024 bit. A DH group 5 kulcsmérete 1536 bit. Minél magasabb a csoport, annál kriptográfiailag biztonságosabbá válik az algoritmus, és a több forrást processzort fogyaszt.

PFS(Perfect Forward Secrecy - tökéletes továbbítási titok) - további titkosítás a kulcscsere során a második fázisban.

Ha a PFS engedélyezve van, akkor minden 2. fázisú kézfogásnál új Diffie-Hellman csere történik, új adatokat szolgáltatva a kulcsokhoz. Ennek eredményeként a rendszer jobban ellenáll a kriptográfiai támadásoknak. Ha az egyik kulcsot illetéktelenül érintik, egy másik kulcsot nem lehet beszerezni ugyanazzal az információval. Ez növeli a processzor terhelését és csökkenti összteljesítményét rendszerek.

NAT bejárás akkor használatos, ha az IPSec alagutat létrehozó mindkét eszköz NAT alatt működik. A következő lehetőségek állnak rendelkezésre:

Letiltva – a tűzfal nem küldi el a „szállító azonosítót”.

Bekapcsolva, ha támogatott és NAT-os – ha az egyik IPSec alagúteszköz NAT alatt működik, és a DFL erről tájékoztatja a második eszközt a „szállító azonosító” elküldésével.

Be, ha támogatott – mindig használja a NAT-ot az alagút létrehozásakor.

Életben tartani"ping" üzenetet küld, ha az egyik eszköz, amikor adatokat küld az alagúton keresztül, nem kap választ a második eszköztől. A következő lehetőségek állnak rendelkezésre:

Letiltás – az életben tartási mechanizmus le van tiltva

Automatikus – A tűzfal ICMP ping üzeneteket küld a VPN alagút beállításaiban automatikusan megtalált IP-címekre.

Forgalomszűrő eszközök

A forgalomszűrő eszközök feladata a hálózati forgalom (a hálózati csomagok tartalmának) szabályozása és a meghatározott biztonsági szabályoknak nem megfelelő forgalom blokkolása (szűrése). A forgalmi szűrők az alkalmazás szintjén szabályozzák és elemzik a hálózati csomagok tartalmát, de a tűzfalakkal ellentétben nem közvetítenek két csomópont között, hogy kizárják azok közvetlen interakcióját (tűzfalak és proxyszerverek). Az IDS/IPS eszközökkel ellentétben a forgalomszűrők nem észlelik és nem akadályozzák meg a hálózati behatolásokat és támadásokat.

A forgalomszűrő eszközök a következők:

hálózati protokollszűrők;
tartalomszűrők, beleértve az URL-szűrőket;
Spamszűrők;
webes forgalomszűrők a védelem érdekében webes alkalmazások(webbiztonság).

Ezek a forgalomszűrő eszközök be vannak építve és olyan egyedi védelmi eszközökben használhatók, mint például a tűzfal, a hálózati víruskereső, a proxyszerver, az IDS / IPS, az UTM, a WAF, az e-mail biztonság, a HIPS, megoldással különféle feladatokat vagy külön szoftverként és hardver-szoftver eszközként valósítják meg. Ezenkívül forgalomszűrő eszközöket használnak a számlázási rendszerekben, a forgalom elszámolásában és a számlázásban; ellenőrzés, statisztika, a felhasználók hálózati tevékenységének valós idejű monitorozása és az internethasználat stb.

Hálózati protokollok szerint szűr engedélyezze a forgalmat bizonyos hálózati protokollokon, és blokkolja a forgalmat más protokollokon. Ezeket az eszközöket a hálózat szélére telepítik, biztosítva, hogy csak a szükséges hálózati forgalom haladjon át bizonyos protokollokon a hálózat belsejébe és/vagy a külső hálózatba, pl. hálózati házirendek érvényesítése.

Tartalomszűrők

Tartalomszűrők(Content Monitoring and Filtering, CMF) blokkolja a hozzáférést a nem kívánt tartalmakhoz az interneten. Ezek webes forgalomszűrők (http/https protokollok).

Az internetes forgalmat a feketelistán szereplő webhelyek URL-címei (URL-szűrők) szűrik, kulcsszó, aláírás vagy fájltípus, az oldalak tartalmának megfelelően morfológiai elemzéssel A tartalomszűrőket hálózati átjárókba (tűzfalak, proxyszerverek stb.) vagy vírusirtók munkaállomásaira telepítik ("szülői felügyelet" funkció, az adathalász oldalak elleni védelem érdekében) ), személyi tűzfalak stb. Használható önálló szoftverként.

Webes forgalomszűrők (webBiztonság)

Webes forgalomszűrők (webBiztonság) arra szolgál, hogy megvédje a webes alkalmazásokat a webes forgalman keresztül érkező különféle fenyegetésektől, beleértve a rosszindulatú kódok behatolását. Ezek webes forgalomszűrők (http/https protokollok). A webes forgalomszűrő funkciókat olyan biztonsági eszközökben használják, mint például a WAF . A webes forgalomból származó fenyegetések elleni védelem érdekében a Web Security osztályba tartozó speciális megoldások használata javasolt.

A Web Security eszközök fő funkciói:

a webes forgalom védelme a vírusok és rosszindulatú programok ellen szoftver;
a rosszindulatú webhelyekhez való hozzáférés blokkolása;
adathalász támadások elleni védelem;
a különböző webes erőforrásokhoz való felhasználói hozzáférés szabályozása;
URL-szűrés és webhely-kategorizálás.

Amint azt sokszor elmondtam a Windows tűzfalról szóló cikkeimben fokozott biztonság működéstől kezdve Windows rendszerek A Vista és a Windows Server 2008 R2 rendszerben a Windows tűzfal alapértelmezés szerint javítja a szervezet minden számítógépének biztonságát azáltal, hogy blokkolja a kifejezetten nem engedélyezett bejövő forgalmat. Ha olyan alkalmazást vagy operációs rendszer-összetevőt telepít, amely bejövő kapcsolatokat igényel, az operációs rendszer automatikusan engedélyezi a bejövő tűzfalszabályokat, és a legtöbb esetben nem kell ezeket manuálisan konfigurálnia. Ha a beépülő modult közvetlenül a vezérlőpultról vagy a parancs futtatásával nyitja meg wf.msc a párbeszédpanelen "Fuss", vagy benne parancs sor, látni fogja, hogy bizonyos szabályok már automatikusan engedélyezve vannak. Ez lehet például egy szabály, amely automatikusan létrejön a beállítással Windows programokÉlő Messenger vagy a Hyper-V szerepkör telepítésekor, amint az az alábbi ábrán látható:

Rizs. 1. Automatikusan generált szabályok a bejövő kapcsolatokhoz

A Windows tűzfal bejövő szabályai azonban nem minden esetben jönnek létre automatikusan. Egyes alkalmazások esetében, amelyek alapértelmezés szerint nem hoznak létre bejövő szabályokat, manuálisan kell létrehoznia a szabályokat. Ha egy ilyen program egy számítógépre vagy több olyan számítógépre van telepítve, amelyek munkacsoport, akkor közvetlenül a pillanatban hozhat létre szabályokat "Windows tűzfal fokozott biztonsággal". De mi van akkor, ha az alkalmazottak számítógépei egy tartomány tagjai, és több tucat vagy akár több száz ilyen számítógép létezik? Ebben az esetben a Windows tűzfal szabályainak érvényre juttatásához a rendszergazdának a hasonló felületet biztosító csoportházirendet kell használnia.

Ebből a cikkből megtudhatja, hogyan kezelheti rugalmasan a Speciális biztonságot nyújtó Windows tűzfalat a csoportházirend segítségével, azaz hogyan hozhat létre bejövő és kimenő kapcsolatokat egy adott felhasználói csoport számára.

Hozzon létre egy csoportházirend-objektumot a Windows tűzfalak Speciális biztonsággal kezeléséhez

Mielőtt létrehozhatna bejövő és kimenő szabályokat a Windows tűzfalakhoz a szervezet ügyfélszámítógép-biztonsági módjában, meg kell találnia azokat a szervezeti egységeket, amelyek tartalmazzák Fiókok számítógépeket a szervezetében, és hozzon létre egy csoportházirend-objektumot, amely egy adott számítógépcsoportra jellemző beállításokkal rendelkező házirendeket tartalmaz. Ezt követően a beépülő modul használatával konfigurálnia kell a bejövő és kimenő kapcsolatok szabályait. Az objektum létrehozása során csoportszabályzat, amelyet a Windows tűzfalak Speciális biztonsággal kezelésére terveztek, semmi konkrét. Ehhez kövesse az alábbi lépéseket:

Miután elvégezte az összes előző lépést, folytathatja a bejövő és kimenő szabályok létrehozását a Speciális biztonsággal rendelkező Windows tűzfalhoz.

Szabály konfigurálása a bejövő és kimenő kapcsolatokhoz

Ebben a lépésben létrehozunk egy bejövő szabályt, amely a 64 bites 1900-as porton lévő Windows Live Messenger alkalmazásra vonatkozik. operációs rendszer Windows Vistaés Windows 7, valamint egy kimenő szabály, amely lehetővé teszi a kéréseket a következőről: internet böngésző Intéző a jelen cikk előző részében létrehozott csoportházirend-objektumban. Alapértelmezés szerint a helyi Rendszergazdák csoport tagjai bejövő és kimenő szabályokat is létrehozhatnak és módosíthatnak a beépülő modulban. "Windows tűzfal fokozott biztonsággal". Ezeket a szabályokat egyesíti a csoportházirendből kapott szabályokkal, és alkalmazza a számítógép konfigurációjára. Ha bejövő kapcsolati szabályt szeretne létrehozni a korábban létrehozott csoportházirend-objektumban, kövesse az alábbi lépéseket:

Csomóban "Csoportpolitikai objektumok" beépülő modulban válassza ki a korábban létrehozott csoportházirend-objektumot, ebben az esetben a csoportházirend-objektumot "A Windows tűzfal konfigurálása", kattintson rá jobb gombbal "Változás";
egy pillanat alatt Csoportházirend-kezelési szerkesztő a konzolfában bontsa ki a Számítógép konfigurációja\Házirendek\Windows-beállítások\Biztonsági beállítások\Windows tűzfal speciális biztonsággal\Windows tűzfal speciális biztonsággal\Bejövő szabályok elemet. Kattintson jobb gombbal egy elemre "A bejövő kapcsolatok szabályai"és től helyi menü válassz egy csapatot "Szabály létrehozása" az alábbi ábrán látható módon:

Rizs. 6. Hozzon létre egy új szabályt a bejövő kapcsolatokhoz

Az első oldalon "Új bejövő szabály varázsló" az alábbiakban részletezett lehetőségek közül választhat:
- A programhoz. Ez a típusú tűzfalszabály olyan szabály létrehozására szolgál, amely engedélyezi vagy blokkolja a kapcsolatokat egy adott végrehajtható fájlhoz, függetlenül a használt portszámoktól. A legtöbb ember számára ez a fajta szabály lehet a leghasznosabb, mivel nem mindenki tudja, hogy egy adott program mely portokat használja. A legtöbb esetben a legjobb az ilyen típusú szabályok használata, de meg kell jegyezni, hogy ez a típus nem használatos, ha egy adott szolgáltatás nem tartalmaz saját futtatható fájlt;
- Kikötőhöz. Ez a típusú tűzfalszabály olyan szabály létrehozására szolgál, amely engedélyezi vagy blokkolja a kommunikációt egy adott TCP- vagy UDP-porton, függetlenül a forgalmat generáló programtól. Egy ilyen típusú szabály létrehozásakor egyszerre több portot is megadhat;
- Előre meghatározott. Ez a fajta tűzfalszabály egy olyan szabály létrehozására szolgál, amely az operációs rendszer egy adott programjának vagy szolgáltatásának kapcsolatait vezérli, és amely a megfelelő legördülő listában jelenik meg. Egyes programok a telepítés után hozzáadják a bejegyzéseiket ehhez a listához, hogy leegyszerűsítsék a bejövő kapcsolatokra vonatkozó szabályok létrehozásának folyamatát;
- Testreszabható. Az ilyen típusú tűzfalszabályok olyan szabályok létrehozására szolgálnak, amelyek egyszerre kombinálhatják a program- és a portinformációkat.

Annak érdekében, hogy mérlegeljük maximális összeget a varázsló oldalain, válassza ki a típust "Egyéni szabály";

Rizs. 7. ábra: Az Új bejövő szabály varázsló Szabálytípus oldala

Az oldalon "Program" Az Új bejövő szabály varázsló lehetővé teszi annak a programnak az elérési útját, amelyet a Speciális biztonsággal rendelkező Windows tűzfal ellenőrzi, hogy a küldött vagy fogadott hálózati csomagok megfelelnek-e a szabálynak. Esetünkben állítsa a kapcsolót az opcióra "Programút"és a megfelelő szövegmezőbe írja be "C:\Program Files (x86)\Windows Live\Messenger\msnmsgr.exe" az alábbi:

Rizs. 8. ábra: Az Új bejövő szabály varázsló programoldala

Az oldalon "Protokoll és portok" Az Új bejövő szabály varázslóban megadhatja a hálózati csomagban használt protokollt és portokat, amelyek megfelelnek az aktuális szabálynak. Ha több portot kell megadnia, vesszővel elválasztva adja meg azokat. Ha pedig a portok teljes skáláját kell megadnia, válassza el a kisebb és nagyobb portokat kötőjellel. Vessünk egy pillantást a helyi portbeállításokra a bejövő csatlakozási szabályokhoz:
- Minden port. A szabály minden bejövő és kimenő kapcsolatra vonatkozik TCP vagy UDP protokollon keresztül;
- Speciális portok. Ebben az esetben megadhat konkrét portokat, amelyeket a TCP vagy UDP protokollon keresztüli bejövő vagy kimenő kapcsolatokhoz használ;
- RPC végpontleképező. Ez az érték csak a bejövő kapcsolatokhoz választható ki TCP protokoll. Ebben az esetben a számítógép az RPC-EM kérés 135-ös portján lévő TCP-n keresztül fogadja a bejövő RPC kéréseket, amely meghatározza a hálózati szolgáltatást, és bekéri a port számát, amelyen ez a hálózati szolgáltatás figyel;
- Dinamikus RPC portok. Az előző értékhez hasonlóan adott értéket csak a bejövő TCP kapcsolatokhoz választható, ahol a számítógép az RPC futási környezet által hozzárendelt portokon fogadja a bejövő RPC hálózati csomagokat;
- IPHTTPS. Ez az érték csak bejövő TCP-kapcsolatok esetén érhető el. Ebben az esetben megengedett a bejövő csomagok fogadása az IPHTTPS alagút protokoll használatával, amely támogatja az IPv6-csomagok befecskendezését IPv4 HTTPS hálózati csomagokba egy távoli számítógépről;
- Csomópont bejárás. Ezt az értéket csak a bejövő UDP kapcsolatokhoz választhatja ki, ami lehetővé teszi a bejövő Teredo hálózati csomagok fogadását.

Például a Windows Live Messenger megadásához TCP portok 80, 443 és 1900 csepp "Protokoll típusa" válassza ki "TCP", legördülő lista "Helyi kikötő" válasszon értéket "Különleges kikötők", és a fenti legördülő menü alatti szövegmezőbe írja be "80, 443, 1900". Hagyja a legördülő menü értékét "Távoli port" változatlanul, és kattintson a gombra "További";

Rizs. 9. ábra: Az Új bejövő szabály varázsló Protokoll és portok oldala

Az oldalon "Vidék" ezzel a varázslóval megadhatja a helyi és a távoli számítógépek, amelynek hálózati forgalma az aktuális szabályra vonatkozik. Itt két rész érhető el: helyi és távoli IP-címek, amelyekre ez a szabály vonatkozik. Mind az első, mind a második részben a hálózati forgalom csak akkor felel meg ennek a szabálynak, ha a cél IP-címe benne van ezt a listát. Az opció kiválasztásakor "Bármilyen IP-cím", a szabályt minden olyan IP-címmel rendelkező hálózati csomag teljesíti, amely címként lesz megadva helyi számítógép vagy amelyeket bármely IP-címről címeznek (bejövő szabály esetén). Ha konkrét IP-címeket kell megadnia, állítsa a választógombot az opcióra "Meghatározott IP-címek"és konkrét címet vagy alhálózat a gombra kattintva megnyíló párbeszédpanel segítségével "Hozzáadás". Esetünkben hagyja változatlanul ezt az oldalt, és kattintson a gombra "További";

Rizs. 10. ábra: Az Új bejövő szabály varázsló "Régió" oldala

Az oldalon "Akció" kiválaszthatja a bejövő vagy kimenő csomagokra vonatkozó műveletet ezt a szabályt. Itt a következő három művelet közül választhat:
- Csatlakozás engedélyezése. Ha ezt az értéket választja, akkor engedélyezi az összes olyan kapcsolatot, amely megfelel a varázsló összes előző oldalán megadott feltételeknek;
- Biztonságos kapcsolat engedélyezése. A Windows Firewall with Advanced Security szabály jelenlegi értéke csak akkor engedélyezi a kapcsolatokat, ha megfelelnek a korábban megadott feltételeknek, és az IPSec is védi őket. Ezzel az értékkel nem fogunk foglalkozni, mivel a következő cikkeimben részletesen lesz szó róla;
- Csatlakozás blokkolása. Ebben az esetben a Windows fokozott biztonságú tűzfala minden olyan csatlakozási kísérletet megszakít, amely megfelel a korábban megadott feltételeknek. Bár kezdetben a tűzfal minden kapcsolatot blokkol, ez az érték akkor hasznos, ha egy adott alkalmazás kapcsolatait szeretné blokkolni.

Mivel engedélyeznünk kell a hozzáférést a Windows Live Messenger programhoz, állítsa a kapcsolót az opcióra "Kapcsolat engedélyezése"és nyomja meg a gombot "További";

Rizs. 11. Az Új bejövő szabály varázsló "Művelet" oldala

Az oldalon "Profil" Az Új bejövő szabály varázslóban kiválaszthatja azt a profilt, amelyre ez a szabály vonatkozik. Három közül választhat egyet elérhető profilok vagy egyszerre több. Leggyakrabban vagy profilt választanak ki egy szervezet számára "Tartomány" vagy mindhárom profil. Ha szervezete nem használja a Domain Services szolgáltatást Active Directory vagy tűzfalszabályokat állít be otthoni számítógép, akkor elég lesz csak a profilt megadni "Magán". Profilszabályok "Nyilvános" nyilvános kapcsolatokhoz jönnek létre, ami elvileg nem biztonságos. Esetünkben jelölje be mindhárom profil négyzeteit, és kattintson a gombra "További";

Rizs. 12. ábra: Az Új bejövő szabály varázsló Profil oldala

Az oldalon "Név" adja meg a bejövő kapcsolathoz létrehozott új Windows tűzfal fokozott biztonságú szabályának nevét, írja be az aktuális szabály leírását, ha szükséges, és kattintson a gombra "Kész".

Rizs. 13. ábra: Az Új bejövő szabály varázsló "Név" oldala

Alapértelmezés szerint a Windows fokozott biztonságú tűzfala engedélyezi az összes kimenő forgalmat, ami lényegében kevésbé teszi ki a számítógépet a feltörési fenyegetésnek, mint a bejövő forgalmat. Bizonyos esetekben azonban nem csak a bejövő, hanem a kimenő forgalmat is szabályoznia kell a felhasználók számítógépén. Például az ilyen rosszindulatú szoftver termékek hogy a férgek és bizonyos típusú vírusok hogyan képesek replikálni magukat. Ez azt jelenti, hogy ha a vírus sikeresen képes volt azonosítani egy számítógépet, akkor minden elérhető (önmaga számára) módszerrel megpróbálja kimenő forgalmat küldeni a hálózat többi számítógépének azonosítására. Jó néhány ilyen példát lehet felhozni. A kimenő forgalom blokkolása szükségszerűen tönkreteszi az operációs rendszer és a telepített szoftver legtöbb beépített összetevőjét. Ezért a kimenő szűrés engedélyezésekor gondosan tesztelnie kell a felhasználói számítógépekre telepített alkalmazásokat.

A kimenő szabályok létrehozása némileg eltér a fenti eljárástól. Például, ha letiltotta az összes kimenő kapcsolatot a felhasználói számítógépeken, és engedélyeznie kell a felhasználók számára a böngésző használatát internet böngésző, csináld a következőt:

Ha kimenő Windows tűzfalszabályt kell hozzárendelnie egy új csoportházirend-objektumhoz, kövesse a szakasz lépéseit. "GPO létrehozása a Windows tűzfalak Speciális biztonsággal kezeléséhez";
egy pillanat alatt Csoportházirend-kezelési szerkesztő a konzolfában bontsa ki a Számítógép konfigurációja\Házirendek\Windows-beállítások\Biztonsági beállítások\Windows tűzfal speciális biztonsággal\Windows tűzfal speciális biztonsággal\Kimenő szabályok elemet. Kattintson jobb gombbal egy elemre "A kimenő kapcsolatok szabályai"és a helyi menüből válassza ki a parancsot "Szabály létrehozása";
A varázsló oldalán "Szabály típusa" Válassz egy lehetőséget "A programhoz"és kattintson a gombra "További";
Az oldalon "Program", állítsa a rádiógombot az opcióra "Programút"és írja be a megfelelő szövegmezőbe %ProgramFiles%\Internet Explorer\iexplore.exe vagy válassza ki ezt a végrehajtható fájlt a gombra kattintva "Felülvizsgálat";
Az oldalon "Akció" ezt a varázslót, válassza ki a lehetőséget "Kapcsolat engedélyezése"és kattintson a gombra "További";
Az oldalon "Profil" fogadja el az alapértelmezett értékeket, és kattintson a gombra "További";
Az utolsó oldalon, oldal "Név", adjon meg egy nevet ezt a szabályt, például, "Internet Explorer szabály"és kattintson a gombra "Kész".

A beépülő modul részletei ablaktáblában Csoportházirend-kezelési szerkesztő látnia kell a létrehozott szabályt az alábbi ábrán látható módon:

Rizs. 14. Szabály létrehozva a kimenő kapcsolathoz

Szűrés hozzárendelése a létrehozott szabályhoz

Most, hogy létrehozott egy csoportházirend-objektumot a kapcsolatok bejövő és kimenő szabályával, figyelnie kell a következő pontra. Amikor létrehoztuk a bejövő szabályt, megadtuk a Windows Live Messenger elérési útját a 64 bites operációs rendszerhez. A szervezet minden számítógépe fel van szerelve 64 bites operációs rendszerrel? Ha igen, akkor nagyon szerencsés vagy, és nem kell többet tennie. De ha 32 bites operációs rendszerű ügyfélszámítógépei vannak, akkor problémába ütközik. A szabály egyszerűen nem fog működni. Természetesen létrehozhat különböző partíciókat a 32 bites és a 64 bites operációs rendszerű számítógépekhez, de ez nem teljesen racionális. Más szóval, meg kell adnia a pillanatban "Csoportházirend-kezelés" hogy a csoportházirend-objektum csak 64 bites operációs rendszerrel rendelkező számítógépeken használható. Ilyen korlátozást WMI-szűrővel hozhat létre. A WMI szűrésről többet megtudhat az alábbi cikkek egyikében, de egyelőre érdemes egy ilyen szűrő létrehozásán elidőzni. Ha WMI-szűrőt szeretne megadni a 64 bites operációs rendszerek észleléséhez, kövesse az alábbi lépéseket:

Következtetés

Ebből a cikkből megtudta, hogyan hozhat létre Windows tűzfalat speciális biztonsági szabályokkal a beépülő és kimenő kapcsolatokhoz a beépülő modul segítségével. "Windows tűzfal fokozott biztonsággal", valamint csoportházirendek használata a szervezet azon számítógépeihez, amelyek egy Active Directory tartomány tagjai. Leírják az előmunkálatokat, nevezetesen egy számítógépes egység létrehozását, valamint egy csoportházirend objektumot. Példákat vettek figyelembe egyéni szabály létrehozására bejövő kapcsolatokhoz, valamint egy ilyen típusú szabályt "A programhoz" kimenő kapcsolathoz.