Az icmp-forgalom megtagadása a VPN-hez. Cisco ACL haladóknak. Kibővített hozzáférési listák. Adott MAC-címekről érkező forgalom visszaállítása vagy engedélyezése
Tehát foglalkozzunk tovább az ACL-ekkel. Ezúttal kiterjesztettük az ACL-eket. A topológiát az előző cikkből vesszük, remélem alaposan áttanulmányoztad. Ha nem ez a helyzet, akkor erősen ajánlom elolvasni, hogy a cikkben szereplő anyagok érthetőbbek legyenek.
Először is azzal kezdem, hogy mik azok a kiterjesztett ACL-ek. A kiterjesztett ACL-ek lehetővé teszik a protokoll, a célcím és a portok megadását a forráscímen kívül. Valamint egy bizonyos protokoll speciális paraméterei. A legjobb, ha példákból tanulunk, ezért hozzunk létre egy új feladatot, bonyolítjuk az előzőt. Egyébként valakit érdekelhet, hogy ezek után foglalkozzon a forgalom prioritás szerinti elosztásának kérdéseivel, ajánlom a QoS osztályozást és jelölést jó cikk, bár angolul. Nos, most térjünk vissza a feladatunkhoz:
Feladat.
- Engedélyezze a 192.168.0.0/24 hálózaton lévő gazdagépektől érkező visszhangkéréseket a szerver felé.
- A szerverről – tiltja a visszhang kéréseket a belső hálózatra.
- Webes hozzáférés engedélyezése a kiszolgálóhoz a 192.168.0.11 csomópontról.
- FTP-hozzáférés engedélyezése a 192.168.0.13-as gazdagéptől a kiszolgálóhoz.
Összetett feladat. Azt is átfogóan megoldjuk. Először is megnézem a kiterjesztett ACL használatának szintaxisát.
Kibővített ACL-beállítások
<номер от 100 до 199> <действие permit, deny> <протокол> <источник> <порт> <назначение> <порт> <опции>
A portszámok természetesen csak a TCP / UDP protokollokhoz vannak feltüntetve. Előtagok is lehetnek ekv(a megadott portszámmal egyenlő), gt/lt(a port száma nagyobb/kisebb a megadottnál), neq(a portszám nem egyenlő a megadottal), hatótávolság(port tartomány).
Elnevezett ACL-ek
A hozzáférési listák egyébként nem csak számozhatók, hanem el is nevezhetők! Talán ez a módszer kényelmesebbnek tűnik az Ön számára. Ezúttal pontosan ezt fogjuk tenni. Ezeket a parancsokat a globális konfiguráció kontextusában hajtják végre, és a szintaxis a következő:
Router(config)#ip hozzáférési lista kiterjesztve<имя>
Tehát kezdjük a szabályok kialakítását.
- Pingek engedélyezése a hálózatról 192.168.0.0/24
a szerverre. Így, visszhang-a kérések egy protokoll ICMP, akkor forráscímként az alhálózatunkat, célcímként a szerver címét, az üzenet típusát választjuk ki – a bejövő felületen visszhang, a kijáratnál - visszhang-válasz. Router(config)#ip access-list kibővített INT_IN Router(config-ext-nacl)#permit icmp 192.168.0.0 0.0.0.255 host 10.0.0.100 echo Hoppá, mi a baj az alhálózati maszkkal? Igen, ez egy trükk ACL. Úgynevezett WildCard-maszk. Kiszámítása a szokásos maszk fordítottja. Azok. 255.255.255.255
- Alhálózati maszk. Esetünkben az alhálózat 255.255.255.0
, kivonás után ami megmarad, az igazságos 0.0.0.255
.Szerintem ez a szabály nem szorul magyarázatra? Jegyzőkönyv icmp, forráscím – alhálózat 192.168.0.0/24
, cél címe – gazdagép 10.0.0.100, üzenet típusa – visszhang(kérés). Ezt egyébként könnyű észrevenni gazdagép 10.0.0.100 egyenértékű 10.0.0.100 0.0.0.0
.Ezt a szabályt alkalmazzuk az interfészre. Router(config)#int fa0/0
Router(config-if)#ip access-group INT_IN in Nos, valami ilyesmi. Most, ha ellenőrzi a pingeket, könnyen láthatja, hogy minden rendben működik. Itt azonban egy meglepetés vár ránk, ami kicsit később derül ki. Még nem árulom el. Ki sejtette – jól sikerült! - A szerverről – tiltunk minden visszhangkérést a belső hálózat felé (192.168.0.0/24). Meghatározunk egy új nevű listát, INT_OUT, és csatoljuk a szerverhez legközelebbi interfészhez.
Router(config)#ip hozzáférési lista kiterjesztve INT_OUT
Router(config-ext-nacl)#deny icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo
Router(config-ext-nacl)#exit
Router(config)#int fa0/1
Router(config-if)#ip access-group INT_OUT be
Hadd magyarázzam el, mit csináltunk. Létrehozott egy kiterjesztett hozzáférési listát INT_OUT néven, letiltva benne a protokollt icmp típussal visszhang házigazdától 10.0.0.100 alhálózatonként 192.168.0.0/24 és alkalmazzuk az interfész bemenetére fa0/1, azaz a szerverhez legközelebb. Próbálunk küldeni ping a szerverről.
SZERVER>ping 192.168.0.11
192.168.0.11 pingelése 32 bájt adattal:
Válasz a 10.0.0.1-től: A célállomás nem érhető el.
Válasz a 10.0.0.1-től: A célállomás nem érhető el.
Válasz a 10.0.0.1-től: A célállomás nem érhető el.
Ping-statisztikák a 192.168.0.11-hez:
Csomagok: Elküldött = 4, Fogadott = 0, Elveszett = 4 (100%-os veszteség)
Nos, úgy tűnt, működik, ahogy kell. Azok számára, akik nem tudják, hogyan kell pingeket küldeni, kattintson a minket érdeklő csomópontra, például egy szerverre. Menj az Asztal fülre, ott a Parancssorra. És most a beígért vicc. Próbáljon ping-et küldeni a gazdagéptől, mint az első pontban. PC>ping 10.0.0.100
10.0.0.100 pingelése 32 bájt adattal:
A kérés meghaladta a rendelkezésre álló időkeretet.
A kérés meghaladta a rendelkezésre álló időkeretet.
A kérés meghaladta a rendelkezésre álló időkeretet.
A kérés meghaladta a rendelkezésre álló időkeretet.Íme egy az Ön számára. Minden egyszerűen működött! Miért állt meg? Ez az ígért meglepetés. Elmagyarázom, mi a probléma. Igen, az első szabály nem szűnt meg. Lehetővé teszi visszhang kérés küldését a kiszolgáló csomópontnak. De hol van az engedély a visszhangválaszok átadására? Elment! Kérést küldünk, de választ nem áll módunkban elfogadni! Miért működött minden korábban? Akkor még nem volt ACL az interfészen. fa0/1. És mivel nincs ACL, akkor minden megengedett. Létre kell hoznia egy szabályt, amely lehetővé teszi az icmp válaszok fogadását.
Hozzáadás az INT_OUT listához
Adjuk hozzá ugyanezt az INT_IN listához.
Router(config-ext-nacl)#permit icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply
Most ne panaszkodj. Minden remekül megy!
- Engedélyezzük a WEB hozzáférést a szerverhez a *.11 csomópontról.Mi is így járunk! Itt azonban tudnod kell egy kicsit arról, hogy a 4. rétegbeli protokollokon (TCP, UDP) keresztül hogyan zajlanak a hívások. A kliensport tetszőlegesen > 1024, a kiszolgálóport pedig a szolgáltatásnak megfelelően van kiválasztva. WEB esetén ez a 80-as port (http protokoll) Mi a helyzet a WEB szerverrel? Alapértelmezés szerint a WEB szolgáltatás már telepítve van a szerveren, ezt a csomópont beállításainál láthatod. Győződjön meg róla, hogy van egy pipa. És csatlakozhat a kiszolgálóhoz, ha kiválasztja a „Webböngésző” parancsikont bármely csomópont „Asztalán”. Természetesen most nem lesz hozzáférés. Mert az útválasztó felületein ACL-ek vannak, és nincs hozzáférési engedélyük. Nos, hozzunk létre egy INT_IN hozzáférési listát (amely a felületen található fa0/0) adja hozzá a szabályt: Router(config-ext-nacl)#permit tcp host 192.168.0.11 gt 1024 host 10.0.0.100 eq 80 Vagyis engedélyezzük a TCP protokollt a gazdagépünkről (tetszőleges port, > 1024) a szerver címére , HTTP port.
És természetesen az ellenkező szabály az INT_OUT listában található (amely a felületen található fa0/1):
Router(config-ext-nacl)#permit tcp host 10.0.0.100 eq 80 host 192.168.0.11 létrehozva
Vagyis megengedjük TCP a kikötőből 80 szerverek állomásonként *.11 , és a kapcsolatnak már létre kell jönnie! Talán helyette alapított ugyanazt jelezze GT 1024, ugyanolyan jól fog működni. De a jelentés egy kicsit más.
Válaszolj kommentben, mi lenne a biztonságosabb?
- Engedélyezzük az FTP hozzáférést a *.13 csomóponttól a szerverig. Abszolút semmi bonyolult! Nézzük meg, hogyan történik az interakció FTP protokoll. A jövőben cikkek egész sorát tervezem szentelni a különböző protokollok munkájának, mivel ez nagyon hasznos a precíz (mesterlövész) ACL szabályok létrehozásában. Nos, egyelőre: Szerver és kliens műveletek:+ A kliens megpróbál kapcsolatot létesíteni, és egy csomagot küld (amely jelzi, hogy passzív módban fog működni) a szerver 21-es portjára az X portjáról (X > 1024, szabad port) + A szerver választ küld és jelenti a portszámát, hogy egy Y csatornaadatokat (Y > 1024) képezzen az X kliens portra, amelyet a TCP csomag fejlécéből nyerünk ki.+ A kliens kommunikációt kezdeményez az X+1 porton az adatok átvitelére a szerver Y portjára (a fejlécből vettük). az előző tranzakció). Valami ilyesmi. Kicsit bonyolultan hangzik, de csak rá kell jönnie! Adja hozzá a szabályokat az INT_IN listához:
tcp host engedélyezése 192.168.0.13 gt 1024 host 10.0.0.100 eq 21
tcp gazdagép engedélyezése 192.168.0.13 gt 1024 gazdagép 10.0.0.100 gt 1024És adjon hozzá szabályokat az INT_OUT listához:
tcp gazdagép engedélyezése 10.0.0.100 eq ftp gazdagép 192.168.0.13 gt 1024
tcp host engedélyezése 10.0.0.100 gt 1024 host 192.168.0.13 gt 1024Ellenőrzés innen parancs sor, csapat ftp 10.0.0.100, ahol a hitelesítő adatainkkal jelentkezünk be cisco:cisco(a szerver beállításaiból vettük), ott írja be a parancsot dirés látni fogjuk, hogy az adatok, valamint a parancsok továbbítása sikeresen megtörténik.
Nagyjából ennyi, ami a kiterjesztett hozzáférési listákkal kapcsolatos.
Tehát nézzük a szabályainkat:
Router#sh hozzáférés
Kiterjesztett IP hozzáférési lista INT_IN
icmp engedélyezése 192.168.0.0 0.0.0.255 host 10.0.0.100 echo (17 találat)
icmp host engedélyezése 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply
engedélyezése tcp host 192.168.0.11 gt 1024 host 10.0.0.100 eq www (36 találat)
tcp host 192.168.0.13 gt 1024 host 10.0.0.100 eq ftp engedélyezése (40 meccs)
tcp host engedélyezése 192.168.0.13 gt 1024 host 10.0.0.100 gt 1024 (4 találat)
Kibővített IP hozzáférési lista INT_OUT
icmp gazdagép megtagadása 10.0.0.100 192.168.0.0 0.0.0.255 echo (4 találat)
icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply engedélyezése (4 találat)
engedélyezése tcp host 10.0.0.100 eq www host 192.168.0.11 létrehozva (3 találat)
tcp host 10.0.0.100 eq ftp host 192.168.0.13 gt 1024 engedélyezése (16 találat)
tcp host 10.0.0.100 gt 1024 engedélyezése 192.168.0.13 gt 1024 (3 találat)
A felhasználókat gyakran bosszantja az internet lassúsága. Ez különösen igaz az amatőrök nagy seregére hálózati játékok. A ping funkció letiltásával csökkentheti a lehetséges késéseket.
Szükséged lesz
- - PC telepített Windows operációs rendszerrel;
- - Internet-hozzáférés.
Utasítás
Utasítás
A MikroTik konfigurálását a gyártó berendezéseiről szóló online tanfolyamon tanulhatja meg. A tanfolyam szerzője okleveles MikroTik tréner. Bővebben a cikk végén olvashat.
A cikk választ ad arra a kérdésre, hogy mennyire veszélyes az ICMP-forgalom blokkolása.
Az ICMP a vita csontja
Sok hálózati rendszergazda úgy véli, hogy az Internet Control Message Protocol (ICMP) biztonsági kockázatot jelent, ezért mindig le kell tiltani. Igaz, hogy a protokollnak vannak biztonsági problémái, és bizonyos kéréseket le kell tiltani. De ez nem ok hogy blokkolja az összes ICMP-forgalmat!
Az ICMP forgalomnak számos fontos funkciója van; ezek egy része a hibaelhárításhoz hasznos, míg mások a hibaelhárításhoz szükségesek megfelelő működés hálózatok. Az alábbiakban felsoroljuk az ICMP protokoll néhány fontos részét, amelyekről tudnia kell. Meg kell fontolnia, hogyan irányíthatja őket a legjobban a hálózaton keresztül.
Echo kérés és és Echo válasz
IPv4 – Echo-kérés (8. típus, 0. kód) és visszhangválasz (Type0, Code0)
IPv6 – Echo-kérés (Type128, Code0) és Echo-válasz (Type129, Code0)
Mindannyian jól tudjuk, hogy a ping az egyik első hibaelhárítási eszköz. Igen, ha engedélyezi az ICMP-csomagfeldolgozást a hardverén, ez azt jelenti, hogy a gazdagép most már felfedezhető, de a tiéd már nem figyel a 80-as porton, és nem küld válaszokat az ügyfelek kérésére? Természetesen ezeket a kéréseket is blokkolja, ha valóban a hálózat szélén szeretné a DMZ-t. De az ICMP forgalom blokkolásával a hálózaton belül nem erősíti meg a biztonságát, ellenkezőleg, egy szükségtelenül bonyolult hibaelhárítási folyamattal rendelkező rendszerhez jut ("Kérem, ellenőrizze, hogy az átjáró válaszol-e a hálózati kérésekre?", "Nem, de ez egyáltalán nem idegesít, mert nem érdekel.” nem mondok semmit!”).
Ne feledje, azt is engedélyezheti, hogy a kérések egy bizonyos irányba menjenek; Például állítsa be a berendezést úgy, hogy a hálózatról érkező visszhangkérések az Internetre, az internetről érkező Echo válaszok pedig a hálózatra menjenek, de fordítva ne.
Csomagdarabolás szükséges (IPv4) / Túl nagy csomag (IPv6)
IPv4 – (3. típus, 4. kód)
IPv6 – (2. típus, 0. kód)
Az ICMP protokoll ezen összetevői nagyon fontosak, mivel a Path MTU Discovery (PMTUD) fontos összetevői, amely szerves részét képezi TCP protokoll. Lehetővé teszi két gazdagép számára, hogy a TCP Maximális szegmensméret (MSS) értékét olyan értékre állítsa, amely megfelel a két cél közötti kommunikációs útvonal legkisebb MTU-jának. Ha a csomagok útvonalán van egy csomópont, amelynek maximális átviteli egysége kisebb, mint a feladó vagy a címzett, és nincs eszközük ennek az ütközésnek az észlelésére, akkor a forgalom csendben eldobódik. És nem fogja megérteni, mi történik a kommunikációs csatornával; más szóval: „vidám napok jönnek számodra”.
Ne töredezzen – az ICMP nem megy át!
A Don't Fragment bitkészlettel rendelkező IPv4-csomagok (a legtöbbjük!) vagy IPv6-csomagok (ne feledje, hogy az IPv6-ban nincs útválasztók általi töredezettség) továbbítása, amelyek túl nagyok ahhoz, hogy az interfészen keresztül továbbíthatók legyenek, az útválasztó eldobja a csomagot. és választ generál az átviteli forrásnak a következő ICMP hibákkal: Töredezettség szükséges ( Töredezettség szükséges), vagy a csomag túl nagy ( Csomag is nagy). Ha az ilyen hibás válaszokat nem lehet visszaküldeni a feladónak, akkor az ACK csomagok kézbesítésére vonatkozó megerősítő válaszok hiányát értelmezi ( Elismerés).
Egy ilyen probléma okát nehéz azonosítani és gyorsan megoldani; a TCP kézfogási folyamat jól működik, mivel kis csomagokat foglal magában, de amint tömeges adatátvitel történik, az átviteli munkamenet lefagy, mert az átvitel forrása nem hibaüzeneteket kapni.
A csomagküldési útvonal feltárása
Az RFC 4821-et arra tervezték, hogy a hálózati forgalom résztvevőinek csomagútvonal-vizsgálat segítségével megkerüljék ezt a problémát (Path MTU Discovery (PLPMTUD). A szabvány lehetővé teszi a maximális adatmennyiség észlelését (Maximális átviteli egység (MTU), amelyet a protokoll egy iterációban, a hasznos adatblokk maximális méretének fokozatos növelésével továbbíthat (Maximális szegmensméret (MSS), annak érdekében, hogy megtaláljuk egy csomag maximális lehetséges méretét anélkül, hogy széttöredeznénk az adótól a vevőig tartó úton. Ez a funkció csökkenti az Internet Control Message Protocol (ICMP) protokollon keresztüli hibaválaszok időbeni beérkezésétől való függőséget, és a legtöbb hálózati eszközveremben és kliens operációs rendszerben elérhető. Sajnos nem olyan hatékony, mint a lehető legnagyobb méretre vonatkozó közvetlen adatgyűjtés. Kérem, engedje meg, hogy ezek az ICMP üzenetek visszatérjenek az átvitel forrásához, rendben?
A csomag átviteli ideje túllépve
IPv4 – (11. típus, 0. kód)
IPv6 – (Type3, Code0)
A Traceroute egy nagyon hasznos hibaelhárítási eszköz hálózati kapcsolatok két gazdagép között, részletezve az útvonal minden lépését.
Csomagot küld az adatcsomag élettartamával az IP protokollhoz (Élni ideje (TTL) egyenlő 1 hogy az első útválasztó hibaüzenetet küldjön (a saját IP-címét is beleértve), hogy a csomag túllépte az élettartamát. Ezután küld egy csomagot TTL 2-vel és így tovább. Erre az eljárásra azért van szükség, hogy minden csomópontot észleljünk a csomagútvonal mentén.
NDP és SLAAC (IPv6)
Router Solicitation (RS) (Type133, Code0)
Router Advertisement (RA) (Type134, Code0)
Szomszéd megkeresése (NS) (135. típus, 0. kód)
Szomszédhirdetés (NA) (136. típus, 0. kód)
Átirányítás (137. típus, 0. kód)
Míg az IPv4 Address Resolution Protocolt (ARP) használt a 2. és 3. réteg leképezésére hálózati modell Az OSI, az IPv6 más megközelítést alkalmaz a Neighbor Discovery Protocol (NDP) formájában. Az NDP számos szolgáltatást kínál, beleértve az útválasztó felfedezését, az előtagok felderítését, a címfeloldást és még sok mást. Az NDP mellett a Stateless Address AutoConfiguration (SLAAC) lehetővé teszi egy gazdagép dinamikus konfigurálását a hálózaton, hasonlóan a Dynamic Host Configuration Protocol (DHCP) koncepciójához (bár a DHCPv6 a részletesebb vezérlésre szolgál).
Ezt az öt ICMP-üzenettípust nem szabad blokkolni a hálózaton belül (a külső kerület figyelmen kívül hagyásával), hogy az IP-adatátviteli protokoll megfelelően működjön.
ICMP típusszámozás
Az Internet Control Message Protocol (ICMP) számos olyan üzenetet tartalmaz, amelyeket a "type" mező azonosít.
| típus | Név | Leírás |
|---|---|---|
| 0 | Echo Válasz | |
| 1 | Nincs hozzárendelve | |
| 2 | Nincs hozzárendelve | |
| 3 | A cél nem elérhető | |
| 4 | Forrás Quench (elavult) | |
| 5 | Átirányítás | |
| 6 | Alternatív gazdagép címe (elavult) | |
| 7 | Nincs hozzárendelve | |
| 8 | Visszhang | |
| 9 | Router hirdetés | |
| 10 | Router Solicitation | |
| 11 | Időtúllépés | |
| 12 | Paraméter probléma | |
| 13 | Időbélyeg | |
| 14 | Időbélyegző Válasz | |
| 15 | Információkérés (elavult) | |
| 16 | Információs válasz (elavult) | |
| 17 | Címmaszk kérése (elavult) | |
| 18 | Címmaszk válasz (elavult) | |
| 19 | Fenntartva (biztonsági okokból) | Szóló |
| 20-29 | Fenntartva (a robusztussági kísérlethez) | ZSu |
| 30 | Traceroute (elavult) | |
| 31 | Datagram-konverziós hiba (elavult) | |
| 32 | Mobile Host Redirect (elavult) | David_Johnson |
| 33 | IPv6, hol vagy (elavult) | |
| 34 | IPv6 I-Am-Here (elavult) | |
| 35 | Mobil regisztrációs kérelem (elavult) | |
| 36 | Mobil regisztrációs válasz (elavult) | |
| 37 | Domainnév-kérés (elavult) | |
| 38 | Domainnév válasz (elavult) | |
| 39 | UGRÁS (elavult) | |
| 40 | Phototuris | |
| 41 | A kísérleti mobilitási protokollok, például a Seamoby által használt ICMP-üzenetek | |
| 42 | Kiterjesztett visszhangkérés | |
| 43 | Kiterjesztett visszhangválasz | |
| 44-252 | Nincs hozzárendelve | |
| 253 | RFC3692-stílusú 1. kísérlet | |
| 254 | RFC3692-stílusú 2. kísérlet | |
| 255 | Fenntartott |
Néhány szó a sebességkorlátozásról
Míg az ebben a cikkben leírtakhoz hasonló ICMP-üzenetek nagyon hasznosak lehetnek, ne feledje, hogy ezeknek az üzeneteknek a generálása processzoridőt vesz igénybe az útválasztókon, és forgalmat generál. Valóban arra számít, hogy normál helyzetben másodpercenként 1000 pinget fog kapni a tűzfalon keresztül? Ez normális forgalomnak számít? Valószínűleg nem. Határ áteresztőképesség hálózatok az ilyen típusú ICMP-forgalomhoz, ahogy jónak látja; ez a lépés segíthet a hálózat biztonságában.
Olvass, kutass és érts
Figyelembe véve, hogy az ICMP-csomagok „blokkolni vagy nem blokkolni” témájának megvitatása mindig zavarokhoz, vitákhoz és nézeteltérésekhez vezet, javaslom, hogy folytassa a téma önálló tanulmányozását. Számos linket adtam ezen az oldalon; úgy gondolom, hogy a problémák teljesebb megértéséhez szánjon időt az olvasásra. És tájékozott döntéseket hozzon arról, hogy mi a legjobb az Ön hálózatának.
MikroTik: hova kell kattintani, hogy működjön?
Minden előnye ellenére a MikroTik termékeknek van egy hátránya - sok szétszórt és nem mindig megbízható információ található a konfigurációjáról. Megbízható orosz nyelvű forrást ajánlunk, ahol minden össze van gyűjtve, logikusan és strukturáltan - videó tanfolyam " MikroTik berendezés beállítása" A tanfolyam 162 videóórát, 45 laboratóriumi munkát, önellenőrző kérdéseket és jegyzeteket tartalmaz. Minden anyag korlátlan ideig Önnél marad. A tanfolyam kezdetét ingyenesen megtekintheti, ha a kurzus oldalán kérést hagy. A tanfolyam szerzője okleveles MikroTik tréner.
A tűzfal az első védelmi vonal minden szerver számára, és ez ellen is helyes beállításokat attól függ, hogy a támadó tovább tud-e lépni a rendszerbe való behatolási kísérletében. A modern tűzprogramok számos biztonsági mechanizmust kínálnak, amelyek segítségével a támadók 99%-át távol tarthatja a huroktól. És mindez anélkül, hogy drága berendezéseket és kereskedelmi szoftvereket kellene vásárolnia.
Minden hacker fő célja, hogy hozzáférjen a kiszolgáló parancsértelmezőjéhez, hogy annak képességeit a saját előnyükre fordíthassa. Leggyakrabban a „szentek szentjébe” való behatolás a szolgáltatásokban lévő lyukak használatával vagy jelszókitalálással (nyers erő) történik az egyiknél (például ssh).
Port szkennelés
A sebezhető szolgáltatások számítógépen való azonosítása érdekében a támadó portszkenner és különféle sérülékenységészlelő rendszerek segítségével felderítést végez. Általában az nmap portszkennerként használatos, amely több tucat átvizsgálására képes különféle módokonés bizonyos esetekben képes észlelni az operációs rendszer verzióit és szolgáltatásokat. Itt található a támadók által gyakran használt, különösen népszerű nmap jelzők listája:
A vizsgálat során használt Nmap zászlók
- -sT - normál TCP-vizsgálat a megadott porthoz való kapcsolat megnyitásával és annak megszakításával;
- -sS - SYN/ACK vizsgálat, a kapcsolat azonnal megszakad a kapcsolat megnyitására irányuló kérelemre adott válasz után;
- -sU - UDP szkennelés;
- -sF - szkennelés csomagokban a FIN jelzővel;
- -sX - szkennelés csomagokkal a FIN, PSH és URG jelzőkkel;
- -sN - beállított zászlók nélküli csomagok vizsgálata.
A szkennelés elleni módszer egyszerű, és minden rendszergazda számára ismert. Ez abból áll, hogy egyszerűen bezárja az összes olyan szolgáltatást, amely nem lehet látható a külső hálózatról. Például, ha a gép ssh, samba és apache szolgáltatásokat futtat, és csak egy céges weblappal rendelkező webszerver legyen látható a külvilágból, akkor a tűzfalat a következőképpen lehet beállítani:
Az iptables kezdeti beállítása
outif="eth1"
iptables -F
iptables -i $outif -A BEMENET \
-m conntrack\
--ctstate LÉPTETT, KAPCSOLATOS \
-j ELFOGADJA
iptables -i $outif -A BEMENET -p tcp \
--dport 80 -j ELFOGADÁS
iptables -i $outif -P INPUT DROP
iptables -i $outif -P OUTPUT ACCEPT
Az ipfw kezdeti beállítása
outif="rl0"
ipfw hozzáadása engedélyezi az ip-t bármelyikről tetszőlegesre \
a lo0-n keresztül
ipfw add engedélyezése tőlem bármely \
$outif-on keresztül
ipfw add engedélyezd a tcp-t bármelyiktől nekem \
$outif-on keresztül jött létre
ipfw add engedélyezése tcp bármely 80-ból \
nekem $outif-on keresztül
ipfw add meg a deny ip-t bármelyikről bármelyikhez \
$outif-on keresztül
Kezdeti pf beállítás
outif="rl0"
állítsa be a kihagyást lo0-ra
blokkolja az összeset
elájul $outif -tól $outif \
bármely tartási állapotba
adja tovább a $outif protot bármely \
a $outif 80-as portra
Mindhárom szabálykészlet ugyanazt csinálja – lehetővé teszik, hogy bármilyen forgalom áthaladjon a visszacsatolási felületen, lehetővé tegyék a már létrehozott kapcsolatokból származó csomagok elfogadását (így például a böngésző választ kaphat egy kérésre távoli szerver), engedélyezi a 80-as portra irányuló hívásokat, blokkolva az összes többit, és engedélyezi a külső kapcsolatokat. Kérjük, vegye figyelembe, hogy ha az iptables és ipfw példákban kifejezetten olyan szabályokat adunk meg, amelyek lehetővé teszik a már felépített kapcsolatokból származó csomagok fogadását, akkor a pf esetében elegendő volt a „keep state” beállítást megadni a szabálykészletben, lehetővé téve az esetleges kimenő kapcsolatokat.
Általánosságban elmondható, hogy ez a hálózati szolgáltatások szkenneléstől és behatolástól való védelmét szolgáló séma nagyszerűen működik, de tovább mehetünk, és úgy konfigurálhatjuk a tűzfalat, hogy bizonyos típusú vizsgálatokat egyáltalán ne lehessen végrehajtani. Technikailag ezt nem tudjuk megtenni a szokásos vizsgálatoknál (nmap jelzők: "-sT", "-sS" és "-sU"), egyszerűen azért, mert nincs benne semmi bűn, hanem a nem szabványos vizsgálati típusok, például az "-sN" "-sF" " és "-sX" olyan csomagokat hoz létre, amelyeket valószínűleg nem hozhattak létre legitim alkalmazások.
Ezért minden kétség nélkül elutasítjuk az ilyen összefüggéseket.
Módszerek az egzotikus szkennelési típusok leküzdésére
# A FIN szkennelés letiltása
Linux> iptables -A BEMENET -p tcp\
-m tcp\
--tcp-flags FIN,ACK FIN -j DROP
FreeBSD>
nincs beállítva tcpflags fin
# Az X-scan letiltása
Linux>
--tcp-flags FIN,SYN,RST,PSH,ACK,URG
FIN,SYN,RST,PSH,ACK,URG\
–j CSEPP
FreeBSD> ipfw add reject tcp bármelyiktől tetszőlegeshez \
tcpflags fin, syn, rst, psh, ack, urg
# Az N-scan letiltása
Linux> iptables -A BEMENET -p tcp -m tcp\
--tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE –j DROP
FreeBSD> ipfw add reject tcp bármelyiktől tetszőlegeshez \
tcpflags !fin, !syn, !rst, !psh, !ack, !urg
Az OpenBSD-ben ezek a sorok lecserélhetők egy egyszerű bejegyzéssel az elején
/etc/pf.conf:
bozót mindenben
A scrub direktíva olyan csomagnormalizációs mechanizmust tesz lehetővé, amelyben a töredezett csomagok újraegyesítésre kerülnek, és az érvénytelen jelzőkombinációkkal rendelkező csomagokat eldobják. Az egzotikus szkennelési típusok mellett a scrub lehetővé teszi, hogy megvédje magát a behatolásérzékelő rendszerek megtévesztésével (nagyon töredezett csomagok küldésével) és bizonyos típusú DoS támadásokkal szemben.
Az nmap "-sS" jelzővel kezdeményezett SYN/ACK vizsgálatokkal szembeni védelem érdekében használhatjuk a pf és iptables/netfilter tűzfalakban elérhető passzív OS ujjlenyomat módszert (1.4.6 verzió óta). A szokásos vizsgálat (a "-sT" jelző) során az nmap a szabványos operációs rendszer socket interfészt használja, így az ilyen vizsgálat szinte semmiben sem különbözik a normál csomagok folyamától (a továbbiakban megnézzük néhány különbségét). , a SYN/ACK szkennelés során az nmap maga generálja a csomagokat, így van néhány funkciójuk, amely megadja a forrást. A passzív operációs rendszer észlelési módszere lehetővé teszi ezen csomagok azonosítását és eldobását a szabványos tűzfalszabályok segítségével:
Az OpenBSD> blokkolás gyorsan elérhető bármely operációs rendszer NMAP-járól
Linux> iptables -I INPUT -p tcp -m osf --genre NMAP \
-j DROP
Az iptables/netfilter tűzfal osf modulja az OpenBSD fejlesztői által összeállított és frissített ujjlenyomat-adatbázist használ (/etc/pf.os), így mindkét szabálynak ugyanazt az eredményt kell produkálnia. Az is érdekes, hogy hatékonyan ellensúlyozhatják az nmap segédprogram operációs rendszer észlelési funkcióját ("-O" jelző).
Most már szinte minden típusú szkenneléstől védettek vagyunk, kivéve a szabványos és hülye "-sT"-t. Mit kell vele csinálni? Valójában egyszerű. A portellenőrzés ténye könnyen észrevehető a tűzfalnaplók egyszerű elemzésével. Ha rövid időn belül sok kapcsolat jött létre a különböző portokkal, az azt jelenti, hogy ellenőriztük. Már csak át kell vinni ezt az ötletet a tűzfalszabályok közé. Van egy kiváló recept az iptables-hoz, amely blokkol mindenkit, aki túlságosan kitartóan kopogtat a nem működő portokon:
Harc a szkennelés ellen iptables segítségével
# Ellenőrizze, hogy nem kopog-e a nem működő portokon (10 óránként)
--másodperc 3600 --hitcount 10 --rttl -j RETURN
# Második ellenőrzés, hogy nem kopog-e a nem működő portokon (2 percenként)
iptables -A BEMENET -m legutóbb --rcheck \
--seconds 60 --hitcount 2 --rttl -j RETURN
# Feltesszük a listára a kopogtatók címét
iptables -A INPUT -m legutóbbi --set
# Dobd el a csomagokat mindazoktól, akik túllépik a limitet
kapcsolatok száma
iptables -P BEMENET -j DROP
A patch-omatic projekt fejlesztéseit tartalmazó xtables-addons csomag telepítésével hozzáférünk a PSD (Port Scan Detect) modulhoz, amely a scanlogd démon képében és hasonlatosságában van megvalósítva. Az összes korábbi sor könnyen helyettesíthető egy egyszerű szabállyal:
# iptables -A BEMENET -m psd -j DROP
Sajnos az ipfw és a pf csomagszűrőkben nincs ilyen, de ez nem probléma, mert a PortSentry démon és a scanlogd jól ellensúlyozza a portszkennelést.
Az Icmp üzenetek tiltása
Az is bevált gyakorlat, ha letiltja azokat az ICMP üzeneteket, amelyek okozhatnak További információ a gazdagépről, vagy különféle rosszindulatú műveletek végrehajtására használható (például az útválasztó tábla módosítása). Az alábbi táblázat a lehetséges ICMP üzenettípusokat sorolja fel:
Az ICMP üzenetek típusai
- 0 - visszhang válasz (visszhang válasz, ping)
- 3 - a cél elérhetetlen (a címzett nem elérhető)
- 4 - forrás kioltása (forrás elnyomása, kérjük, küldje el a csomagokat lassabban)
- 5 - átirányítás
- 8 - visszhang kérés (visszhang kérés, ping)
- 9 - router hirdetés
- 10 - router megkeresés
- 11 – az élettartam túllépése (a csomag élettartama lejárt)
- 12 - Az IP-fejléc rossz (helytelen IP-csomag fejléc)
- 13 - időbélyeg kérés (időszámláló értékének kérése)
- 14 - időbélyegző válasz (válasz az időszámláló értékének kérésére)
- 15 - információkérés
- 16 - tájékoztató válasz (válasz információkérésre)
- 17 - címmaszk kérése (hálózati maszk kérése)
- 18 - címmaszk válasz (válasz a hálózati maszk kérésére)
Amint láthatja, egyes ICMP-üzenetekre adott válasz bizonyos hosztinformációk felfedését eredményezheti, míg mások az útválasztási tábla módosítását eredményezhetik, ezért ezeket le kell tiltani.
Általában a 0, 3, 4, 11 és 12 ICMP-üzenetek kiléphetnek a külvilágba, míg bemenetként csak a 3-as, 8-as és 12-es üzenetek fogadhatók el. A különböző tűzfalakban a következőképpen valósítható meg:
A veszélyes ICMP üzenetek tilalma
Linux> iptables -A BEMENET -p icmp\
-icmp-type 3,8,12 -j ELFOGADÁS
Linux> iptables -A KIMENET -p icmp\
-icmp-type 0,3,4,11,12 -j ELFOGADÁS
FreeBSD> ipfw add enable icmp \
bármelyiktől $outif-ig \
$outif icmptype 3,8,12-en keresztül
FreeBSD> ipfw add enable icmp \
$outiftól bármely kimenőig \
$outif icmptype 0,3,4,11,12-en keresztül
OpenBSD> pass inet proto icmp \
bármelyikből $outif \
icmp-type ( 3, 8, 12 ) megőrzi állapotát
OpenBSD> kiadja az inet proto icmp \
$outiftól bármely \
icmp-type (0, 3, 4, 11, 12)\
állapot megtartása
Ha szeretné, letilthatja az összes ICMP forgalmat, beleértve a ping kéréseket is, de ez befolyásolhatja a hálózat megfelelő működését.
Nyers erő
Miután felkutatta az információkat nyitott portokés operációs rendszeren, a támadó megkísérli behatolni a rendszert, ami a szolgáltatásokban lévő lyukak kihasználásán vagy a jelszavak kitalálásán alapulhat. A tűzfal nem segít megakadályozni a szolgáltatások feltörésének lehetőségét, de könnyen lelassítható a jelszavak brutális kényszerítése. Ehhez olyan képességeket használnak, amelyek korlátozzák az egy IP-címről egy gépre érkező csomagok számát. Íme, hogyan kell ezt megtenni az iptables használatával:
Brute force védelem iptables segítségével
# Lánc a csatlakozások ellenőrzéséhez
iptables -N brute_check
# 60 feletti cím letiltása
másodpercben több mint 2 kapcsolatot kezdeményezett
--frissítés --másodperc 60\
--hitcount 3 -j DROP
# Ha nem, engedélyezze a csatlakozást és
adja hozzá a címet a listához
iptables -A brute_check -m legutóbbi\
--set -j ELFOGADÁS
# Törölje az INPUT láncot
iptables -F BEMENET
# Küldje el a brute_check-et a láncnak
mindenki, aki csatlakozni próbál
22. kikötő
--ctstate ÚJ -p tcp \
--dport 22 -j brute_check
iptables -P INPUT DROP
Ugyanez megtehető a pf használatával:
Brute force védelem pf használatával
# Hozzon létre egy táblázatot a brutális erők számára
asztal
# Blokkolás mindenkit, aki bekerül
blokkolja a gyors innen
# A bruteforcers táblázatba helyezzen mindenkit, aki percenként kettőnél több kapcsolatot kezdeményez a 22-es porton
$ext_if inet proto tcp átadása $outif \
A 22-es port jelzi az S/SA állapotát \
(max-src-conn-rate 60/2, \overload
Az ipfw tűzfal nem rendelkezik elegendő funkcionalitással a brutális erők elleni hatékony fellépéshez, ezért felhasználóinak fejlettebb eszközöket kell használniuk. magas szint, például speciális PAM modulok, behatolásérzékelő rendszerek és programok, mint például az sshguard.
Hamisítás
A hamisítás (a csomag forráscímének meghamisítása) DoS támadások végrehajtására vagy tűzfal megkerülésére használható. Az első esetben a hamisítás óriási előnyt jelent a támadónak, mivel jelentősen megnehezíti a támadásra adott választ (a teljesen eltérő feladói címmel érkező csomagokat nem olyan egyszerű osztályozni és blokkolni), és késlelteti az új kapcsolatok lezárásának folyamatát (általában a hamis cím nem érhető el, így a kapcsolat csak az időkorlát lejárta után záródik le). A biztonsági rendszerek megkerülésére végzett hamisítás kevésbé veszélyes, és a legtöbb esetben ellenőrizhető.
Elég gyakran, blokkolja a külső hálózati szolgáltatások hosta, rendszergazdák hagyja nyitva őket egy bizonyos címtartományhoz (például az otthoni gépről való csatlakozáshoz). Miután kitalálta az egyik címet, a támadó csomagot hozhat létre ezzel a címmel visszatérési címként, és így „átcsúszhat” a tűzfalon. Ezután kitalálhatja a TCP-csomagok sorszámát, és megbizonyosodhat arról, hogy a visszatérési címben megbízó szolgáltatás végrehajtja a kívánt műveletet. Ez egy nagyon nehezen kivitelezhető támadás, amit ennek ellenére egy hozzáértő szakember végrehajthat, és ha már az UDP protokollról beszélünk, akkor még egy hacker is meg tudja csinálni.
Szerencsére könnyű megvédeni magát ezektől a támadásoktól. Elég, ha nem nyitjuk meg a nem védett szolgáltatások portjait a külvilág felé, és sürgős szükség esetén maguk a szolgáltatások biztonsági rendszereit (például ssh-tanúsítványok) vagy a „port kopogtató” mechanizmust használjuk (ezről a végén lesz szó). a cikk).
A helyzet bonyolultabbá válik, ha arról van szó hálózati híd, elválasztva a belső és külső hálózatokat (vagy két helyi hálózatot). Megbízható kapcsolatok helyi hálózat- A szokásos dolog. A szolgáltatások mindenki számára elérhetőek, nincs hitelesítés, titkosítás stb. - csak egy finom falat egy betörőnek. Külső hálózaton lévén megtudhatja a belső hálózat hálózati maszkját, és a megfelelő visszatérési címmel csomagokat generálhat, ami az összes helyi erőforráshoz való hozzáféréshez vezet. Ez valóban veszélyes helyzet, de megfelelő tűzfal vagy operációs rendszer konfigurációval könnyen megelőzhető.
Ehhez elegendő, ha megtiltja a külső interfészről azoknak a csomagoknak az áthaladását, amelyeknek a visszatérési címe megegyezik a belső hálózatban használtakkal:
Linux> iptables -A BEMENET -i $outif \
-s 192.168.1.0/24 -j DENY
FreeBSD> ipfw add deny ip innen: \
192.168.1.0/24 bármely $outif-on keresztül
OpenBSD> blokkolása a $outif-on innen: \
192.168.1.0/24 bármelyikre
Alternatív vagy kiegészítő biztonsági intézkedésként használhat (sőt, szükség is van rá) speciális ipfw és pf direktívákat, valamint Linux kernelbeállításokat:
Linux> echo 1> /proc/sys/net/ipv4/conf/all/rp_filter
FreeBSD> ipfw add meg a deny ip-t bármelyiktől az any not antispoof in-hez
OpenBSD> antispoof gyors $ext_if esetén
Ez a három parancs ugyanazt az eredményt adja. Minden olyan csomag, amelynek visszatérési címe megegyezik egy másik interfész hálózati maszkjával, el lesz vetve.
Az IPTABLES előnyei
A cikk végén megvizsgáljuk az iptables/netfilter számos érdekes funkcióját, amelyek hasznosak lehetnek a szerver behatolásokkal szembeni védelmében. Kezdjük a mechanizmussal távirányító tűzfal, az úgynevezett „port kopogtatás”. Lényege, hogy a tűzfalat bizonyos műveletek végrehajtására kényszeríti az adott porthoz való csatlakozás után. Az alábbiakban egy példa azokra a szabályokra, amelyek a 27520-as port kopogtatása után 10 másodpercre megnyitják az SSH-portot:
iptables és port kopogtatás
# Lánc a védett porthoz való csatlakozások ellenőrzéséhez
iptables -N kopog
# Engedélyezze a csatlakozást, ha az elmúlt időszakban kopogás történt
10 másodperc
iptables -Knock -m legutóbbi --rcheck --seconds 10\
-j ELFOGADJA
# INPUT törlése
iptables -F BEMENET
# Engedjen meg mindent, ami már vonatkozik rá létrejött kapcsolatokat
iptables -A BEMENET -m conntrack\
--ctstate LÉPTETT, KAPCSOLATOS -j ELFOGADÁS
# A 22-es portra irányuló kapcsolat megnyitására irányuló összes kísérlet elküldésre kerül
hogy ellenőrizze a kopogásláncot
-p tcp --dport 22 -j kopog
# Adja hozzá a 27520-as porton kopogtató személy címét a listához
iptables -A BEMENET -m conntrack --ctstate ÚJ \
-p tcp --dport 27520 -m legutóbbi --set
# Ha a szomszédos portokon kopogtat, távolítsa el a címet a listából
iptables -A BEMENET -m conntrack --ctstate ÚJ -p tcp \
-m multiport --dport 27519,27521 -m legutóbbi --remove
# Mindent tiltani
iptables -P INPUT DROP
A végétől a harmadik szabály hozzáadja a listához a kopogtató címét. Ha ugyanaz a gép a kopogástól számított 10 másodpercen belül eléri a 22-es portot, a kapcsolat létrejön. Az utolsó előtti szabály a „brute force kopogás” elleni védelem. Ha egy támadó megpróbálja egymás után bekopogtatni az összes portot abban a reményben, hogy az egyik megnyitja a 22-es portot, ez a szabály működni fog, és a címe azonnal törlődik a listáról, miután eltalálta.
A második iptables segédprogram az xtables-addons (patch-o-matic) csomagban található, és a neve TARPIT. Ez egy olyan művelet (ugyanaz, mint az ACCEPT vagy DENY), amely "lefagy" a kapcsolatot, megakadályozva, hogy a támadó bezárja azt. Az a kapcsolat, amelynek a csomagjai a TARPIT-be esnek, sikeresen létrejön, de az ablak mérete nulla lesz, így a távoli gép nem tud adatot küldeni, ezzel pazarolja az erőforrásait, és a kapcsolat csak egy időkorlát után záródik le. A TARPIT vészhelyzetben használható a DoS elleni védelemre:
# iptables -A BEMENET -p tcp -m tcp -dport 80 -j TARPIT
Vagy félrevezetni a támadót és harcolni a szkennerek ellen
portok (csak normál TCP-keresés, "-sT"):
# iptables -A BEMENET -p tcp -m tcp --dport 80 -j ELFOGADÁS
# iptables -A BEMENET -p tcp -m tcp --dport 25 -j ELFOGADÁS
# iptables -A BEMENET -p tcp -m tcp -j TARPIT
Ezek a szabályok egy olyan rendszer látszatát keltik, amelyben minden port nyitva van, de ha megpróbál valamelyikhez csatlakozni (kivéve a 80-ast és a 25-öt), a kapcsolatok lefagynak. Ugyanezt az eredményt, de a kapcsolatok megszakadása nélkül érhetjük el a DELUDE művelettel, amely minden kapcsolatindítási kísérletre helyesen válaszol, de az összes többi csomagra válaszul RST-csomagot küld. A támadó további megzavarásához használhatja a KÁOSZ műveletet, amely véletlenszerűen aktiválja a fent leírt két művelet egyikét.
következtetéseket
Kellő ismeretekkel és a dokumentáció átgondolt olvasásával egy nagyon erős bástyát lehet kialakítani, amihez nem lesz olyan könnyű közel kerülni. A modern tűzfalak, és különösen a pf és az iptable, számos védelmet kínálnak a hívatlan vendégek ellen, amelyeket teljesen ingyen kaphat meg.
Linkek
- sf.net/projects/sentrytools - PortSentry
- www.openwall.com/scanlogd - scanlogd
Az erőforrás-szivárgás elleni küzdelem
A TARPIT művelet használatakor ügyeljen arra, hogy hozzáadja a következő szabályt a konfigurációhoz, különben a „megereszkedett” kapcsolatok felemésztik az erőforrásokat, amikor a conntrack alrendszer feldolgozza:
# iptables -t raw -I PREROUTING -p tcp --dport 25 -j NOTRACK