Csomagsz rés Linux-Netlter környezetben

Csomagsz rés Linux-Netlter környezetben Kovács Balázs, Bigus Kornél, Trinh Anh Tuan (BME TMIT) korábbi útmutatóját felhasználva átdolgozta Bencsáth Boldizsár, Ta Vinh Thong CrySyS Lab. (BME HIT) March 18, 2012 A mérési útmutatót hozzátok el magatokkal a mérésre!!! 1

Contents 1 A T zfalakról 3 2 Az iptables, mint a Netlter szabályok kezel je 4 3 M veletek láncokkal 7 4 M veletek szabályokkal 7 5 Sz rési feltételek megadása 7 5.1 Forrás és célcím meghatározása a csomagok kiválasztásánál................. 8 5.2 Protokoll meghatározása csomagillesztéshez.......................... 8 5.3 Interfész meghatározása csomagillesztéshez.......................... 8 5.4 Töredékek kezelése........................................ 9 6 Kiterjesztések: Netlter modulok illetsztésre 9 6.1 TCP................................................ 9 6.2 UDP................................................ 10 6.3 A "mac" modul.......................................... 10 6.4 A "limit" modul......................................... 10 6.5 Az "owner" modul........................................ 11 6.6 A kapcsolatstátusz illeszkedések................................. 11 7 További Netlter target lehet ségek (-j opció) 12 7.1 LOG................................................ 12 7.2 REJECT............................................. 13 8 Feladatok 14 9 Függelék 17 2

1 A T zfalakról Saját Internetre kötött hálózatunk védelmének talán legegyszer bb és legáltalánosabb módja t zfalak (rewall) alkalmazása. Természetesen a különböz igényeknek megfelel en különböz típusú t zfalakról beszélhetünk. A csomagsz r t zfal (packet-lter rewall) a legalapvetöbb és legegyszer bb megoldás. Egy el re deniált statikus szabálygy jtemény alapján dönt a csomagokról: eldobja vagy továbbítja azokat. A csomagokat független objektumokként kezeli, a sz rési feltételek a protokoll fejlécekre korlátozódnak, nem vonatkoznak a csomag tartalmára (payload). Ezen t zfalak legnagyobb er ssége a könny implementáció, a gyorsaság, illetve hogy a végfelhasználók szempontjából gyakorlatilag transzparens módon viselkednek. Hátránya, hogy állapotmentes és nem jegyzi meg az egymáshoz tartozó folyamokat, továbbá a csomagok tartalmát is gyelmen kivül hagyja. A csomagsz r t zfalak továbbfejlesztése a állapotgép alapú (stateful packet inspection, stateful packet ltering) t zfal. Ezek az eszközök szintén elöre deniált szabályrendszer alapján m ködnek, viszont képesek a csomagok többszint vizsgálatára. A rendszer lényege, hogy nem független csomagokat kezel, hanem kapcsolatokat. Minden kapcsolatot egyedileg gyel, és az egyes csomagok átengedését nemcsak a csomag tartalma, hanem a kapcsolat állapotának gyelembevételével dönti el. Az állapotok követése természetesen több er forrást emészt fel, mint az állapotot nem vizsgáló t zfalazás, és implementációja is bonyolultabb, ugyanakkor ez e megoldás is relatíve gyors, kis er forrást igényel. A t zfalak harmadik típusa az alkalmazás szint t zfal (application gateway rewall). Az alkalmazásszint t zfal esetén az alkalmazás szintjén két különböz kapcsolat épül fel a résztvev k között. Az eredeti kapcsolatban résztvev két fél között egy-egy alkalmazás szint (pl. HTTP, SMTP stb.) kapcsolat jön létre, a t zfal feladata, hogy a két kapcsolat között az alkalmazás-szint információ (payload, pl. a levél tartalma) átkerüljön. A megoldás el nye, hogy minden szinten teljes vizsgálatot végez minden csomagra. Hátránya, hogy elég lassú, hiszen az ellen rzéshez teljesen fel kell dolgozni az összes protokollinformációt. A megoldás ráadásul egyedi minden egyes alkalmazás szint protokollra, így minden protokollra külön implementációt kell elkészíteni. A hibrid t zfal (hybrid rewall), több különböz megoldást kombinál össze és ötvözi azok elönyeit. Jelen mérés esetében a csomagsz rökkel fogunk részletesebben megismerkedni. A Netlter csomagsz r t zfal f bb funkciói: Sz rés: A hálózatok elválasztását állapottal rendelkez csomagvizsgálat segítségével valósítjuk meg. A két hálózat között csak a t zfalszabályok által engedélyezett adatcsomagok tudnak átmenni, így szabályozható a forgalom. A sz rés segítségével a nem biztonságos, vagy biztonsági kockázatot jelent, de nem használt protokollok, gépek adatcsomagjai kisz rhet ek, így potenciális támadási lehet ségek el zhet ek meg. NAT - Network Address Translation: Címfordítás végezhet két hálózat között. A bels hálózatban használt bels címeket a t zfal kicserélhet a kifelé men kapcsolatok esetében más IP címekre (SNAT - Source NAT, a forrás címének lecserélése), vagy egy kapcsolat célcíme módosítható és így a kapcsolat átirányíthat (DNAT - Destination NAT, a cél címének lecserélése). Csomagmódosítás, Mangling: Szükség esetén az IP csomagok módosítására is lehet ség van, pl. IP agek módosítása, TCP MSS érték kezelése. Egyéb: Számos kiegészít funkcionalitás van beépítve a rendszerbe, mint: Rate limiting - A csomagok, kapcsolatok sebességének korlátozása, pl. Denial-of-Service (DoS) elleni védekezés céljából, 3

accounting - átvitt adatmennyiségek nyilvántartása, routing támogatása - a csomagsz r pl. FWMARK segítségével segíthet a routing döntések meghozatalát, QoS megoldások - A sávszélesség felemésztésének védelmével, csomagmegjelöléssel stb. támogatja és interakcióban van a QoS alrendszerekkel, stb. A csomagsz r t zfalak f bb problémái: Policy-hez illeszkedés: Az implementált t zfalszabályok nem biztos, hogy valóban a magasabb absztrackiós szint policy-ben foglaltakat valósítják meg. Szabályok átláthatósága: Ha sok a szabály, átláthatatlanná és kezelheteténné válhat a t zfal kon- gurációja Ellentmondások és más szabályproblémák: A szabályhalmaz nem biztos hogy konzisztens, ellentmondás mentes, redundancia mentes, problémákat tartalmazhat Illeszkedés a bels hálózathoz, hálózati problémák: A rosszul beállított vagy implementált t zfal hálózati problémákat okozhat, vagy éppen biztonsági kockázatot jelenthet. A Linux Netlter csomagsz r je a kernel része - vagy teljesen bele van fordítva, vagy pedig modulként tölthet be. A Linux kernelek az 1.1 verzió óta tartalmaznak csomagsz r kódot. Az els generációt, mely a Berkeley Software Distribution (BSD) ipfw-jára épült, Alan Cox portolta 1994 végén. Ezt többekkel együtt Jos Vos fejlesztette tovább Linux 2.0-ra, melyben már az ipfwadm parancs kontrollálta a csomagsz rést. 1998 közepén, a Linux 2.2 alá nagymértékben újraírták a kódot, és kifejlesztették ennek kezel oldali alkalmazását, az ipchains-t. Végül a negyedik generációs eszköz, az iptables és a hozzá kapcsolódó kernelrészek újraírása történt meg 1999 közepén a Linux 2.4 alá. 2 Az iptables, mint a Netlter szabályok kezel je Az iptables képes a számítógépre beérkez, a kimen és az átmen csomagok vizsgálatára és sz résére. A rendszer meglehet sen rugalmasan kongurálható, így széles körben alkalmazható az egyszer munkaállomás védelmét l a komplex céges megoldásokig. A Netlter koncepciója több szint hierarchiára épül. Table (Tábla): A feldolgozás táblákra épül, az egyes táblák a csomagfeldolgozás más-más szakaszát érintik. Ezt a 2 ábra személteti. A négy el re deniált tábla: lter, nat, mangle és raw. Chain (Lánc): A táblákon belül feldolgozási láncokba, chain-ekbe szervez dnek a szabályok. Az alapértelmezett chaineken (táblafügg en PREROUTING, FORWARD, POSTROUTING, INPUT, OUTPUT) felhasználói chainek deniálhatóak. Rule (Szabály): A chain részeként a legkisebb egység a szabály. A szabály áll egy illeszkedési részb l, amely megadja, milyen forgalomra vonatkozik a szabály. Áll továbbá egy cél (target) részb l, amely deklarálja, hogy az illeszked forgalommal mi történjen, továbbá egyéb részeket is tartalmazhat. 4

A szabályok feldolgozási konceptiója: Egy láncon belül a beérkezett csomagra megvizsgáljuk, hogy az els szabályra illeszkedik-e. Ha igen, akkor végrehajtjuk a target m veletet. Target m velet függvényében a csomag feldolgozás befejez dhet (pl. DROP, ACCEPT, REJECT), vagy továbbmehet a következ szabályra (pl. LOG target), vagy másik láncon folytatódhat (ha pl. egy chain a target, vagy RETURN a target). Amennyiben a következ szabályra lép a feldolgozás, akkor ugyanez a folyamat játszódik le. Ha a csomag feldolgozása egyik szabálynál sem fejez dik be, akkor a chain-en deniált alapértelmezett policy szerint történik a csomag feldolgozása a normál chaineknél (pl. INPUT), vagy visszatér a feldolgozás a korábbi chainre, ahonnan az adott chainre ugrás történt. A csomag elfogadása (ACCEPT) nem azt jelenti, hogy más feldolgozásra nem kerül már sor, csak azt, hogy az adott tábla adott chainjén a csomag túljutott, és a feldolgozás folytatódik pl. egy másik chainen, ahogy azt az ábrákon láthatjuk. Figure 1: Csomagsz rés sematikus ábrája a Linux-Netlter környezetben Az iptables több beépített táblát tartalmaz. Az egyik a címfordítási feladatokat végzi (nat), a másik a csomagok sz réséért, szortírozásáért (lter) felel s, míg a harmadikat általános csomagmódosításokra használjuk (mangle). A lter táblába kell elhelyezni az alapvet sz r funkciókat, a mangle táblába a csomagmódosító szabályokat, a nat táblába a nat-tal kapcsolatos szabályok helyezhet k. Ha még a kapcsolatkövetés (connection tracking) el tt van szükség a csomag sz résére (pl. NAT-olt kapcsolatra visszajöv csomagokat még a címfordítás visszaállítása el tt), akkor a raw tábla használható. A táblákra a -t nat, -t lter, illetve -t mangle, -t raw specikációval tudunk hivatkozni az iptables parancs paraméterezése során. Alapesetben (-t opció hiányában) az iptables a lter táblához nyúl, így a -t lter kapcsolót nem szükséges beírni. Az iptables lter táblája három beépített láncot tartalmaz: az INPUT láncon a beérkez, a FORWARD láncon a továbbítandó, az OUTPUT láncon pedig a kimen csomagok haladnak. Ha egy beépített lánc végére érünk, akkor a lánc irányelve (default policy) fog érvényesülni. A beépített láncok irányelve (policy) ACCEPT, vagyis minden csomagot elfogadnak, ezt azonban megváltoztathatjuk (-P opció). A nat táblában szintén három beépített lánc van. A PREROUTING láncban szerepl szabályok még útválasztás el tt hajtódnak végre. Tipikusan DNAT célpont esetén (Destination Network Address Translation) használjuk. A POSTROUTING szabályok ennek megfelel en az útválasztás után hajtják végre a feladatukat; tipikusan SNAT célpontra (Source Network Address Translation) használjuk. A nat 5

6 Figure 2: Csomagsz rés részletesebb ábrája a Linux-Netlter környezetben

tábla OUTPUT lánca arra az esetre szolgál, ha a NAT szabályokat tartalmazó gépr l, mint forrásgépr l történik kapcsolat kezdeményezés, ekkor ugyanis a csomag nem halad végig a PREROUTING láncon, így a PREROUTING láncban lév szabályok nem hajtódnak végre. A megfelel szabályokat ilyenkor az OUTPUT láncban is alkalmazni kell. A mangle tábla csomagmódosítási feladatok elvégzésére használható. Tartalmaz PREROUTING, FORWARD, INPUT, OUTPUT és POSTROUTING láncokat egyaránt. Ilyen módosítási kérelem lehet lehet pl. a TOS mez átírása, ha pl. az ssh csomagok késleltetésének minimalizálására vagy a http átvitel maximalizálására törekszünk. A szabályokat tartalmazó gépr l, mint forrásról kimen csomagok számára a mangle táblában is van egy beépített OUTPUT lánc. Egyes mangle m veletek más táblában, pl. lter tábla is elvégezhet ek. 3 M veletek láncokkal Az el re deniált láncokat nem lehet törölni, alaphelyzetben üresek, nekünk kell feltölten ünk ket szabályokkal. Emellett mi is létrehozhatunk láncokat, melyeket a már meglév láncokhoz kell kapcsolnunk szabályok segítségével. A lánckezel parancsok a következ k: -N Új láncot hoz létre. -X Üres lánc törlésére szolgál. -P Megváltoztatja az irányelvet beépített láncon. -L Adott lánc szabályait listázza. -F Adott lánc összes szabályának törlése. -Z A csomag és byte számlálók nullázására szolgál egy adott lánc valamennyi szabályában. 4 M veletek szabályokkal A két alapm velet a szabályok létrehozása és törlése. A többi m velet e kett b l el állítható, kényelmi okokból azonban külön parancsként is deniálták ket: -A Új szabály hozzáf zése a lánchoz. -I Szabály beszúrása az adott pozícióra. -R Az adott pozíciójú szabály cseréje új szabályra. -D Az adott pozíción lév, vagy az els illeszked szabály törlése. 5 Sz rési feltételek megadása A t zfal egyik legfontosabb feladata a csomagok sz rése. Illesztési feltételek megadásával válaszhatjuk ki, hogy mely csomaggal mi történjen. Ezt számos különböz kapcsolókkal állíthatjunk be. Egy szabály több feltételt is tartalmazhat, és köztük logikai és kapcsolat van. Vannak olyan felételek is, melyek 7

együttes alkalmazása értelmetlen. Bizonyos sz rési feltételeknél inverzió is megadható. Ilyenkor a kifejezés azokra a csomagokra fog illeszkedni, melyek az adott tulajdonságnak nem felelnek meg. Az inverzió jelölésére a felkiáltójel szolgál (pld: -s! 127.0.0.1 ). 5.1 Forrás és célcím meghatározása a csomagok kiválasztásánál A forrás vagy a cél IP címét többféleképpen is megadhatjuk. Hivatkozhatunk rá a nevével (pld.: localhost,www.crysys.hu) vagy közvetlenül az IP címével (pld.: 127.0.0.1). A névvel megadott szabályokat az iptables feloldja, a netlter modul kizárólag IP számokkal operál. Címtartományt is deniálhatunk: megadhatjuk a hálózati maszkkal (10.0.0.0/ 255.0.0.0) vagy a maszk hosszával (10.0.0.0/8). -s, -source a forrás IP címének meghatározása. Például: iptables -A INPUT -s 10.0.0.0/8 -j DROP -d, -destination a cél IP címének meghatározása 5.2 Protokoll meghatározása csomagillesztéshez Az IP protokoll fölött több protokoll is található. Illesztést a különböz szállítási protokollok (TCP, UDP) szerint állithatjuk be. A -p, vagy hosszan kiírva -protocol illesztési paraméter a protokoll meghatározására szolgál. A protokollt megadhatjuk a nevével, mint például TCP vagy UDP, de a protokoll azonosítószámát is használhatjuk (ezt linux rendszereken az /etc/protocols fájl tartalmazza). 5.3 Interfész meghatározása csomagillesztéshez A hálózati interfész olyan zikai (pld.: hálózati kártya) vagy logikai (pld.: loopback) eszköz, mely lehet vé teszi a kommunikációt a hálózaton keresztül. Mivel egy számítógéphez több interfész is tartozhat, szükség lehet a csomagok megkülönböztetésére a forrás illetve a cél interfész alapján. -i, -in-interface a bejöv interfész deniálása. Egyes láncokon ez nem értelmezhet. Az OUTPUT láncon kimen csomagoknak nincs bemen interfésze, ezért ezen a láncon a szabályra egy csomag sem illeszkedik. Példa az alkalmazásra: iptables -A INPUT -i ppp0 -j DROP, -o, -out-interface a kimen interfész deniálása. Az INPUT láncon bejöv csomagoknak nincs kimen interfésze, ezért ezen a láncon a szabályra egy csomag sem illeszkedne, így az iptables nem engedi az illesztés alkalmazását. Ha olyan interfészt határozunk meg egy szabályban, mely pillanatnyilag nem m ködik, az nem min sül hibának, a az interfészt aktivizáljuk, a szabály m ködni fog. Az interfész beállítására az ifcong parancs szolgál. Az interfészek megadásánál is használható az inverzió, ekkor a szabály mindegyik interfészre vonatkozik kivéve a denícióban szerepl t. Egy másik speciális lehet ség, hogy interfész-típusokat is megadhatunk. Ez a név után írt + jellel történik. Ebben az esetben a szabály minden interfészre illeszkedik, melynek neve a + jel el tt deniált szöveggel kezd dik. Például ha az összes bejöv ppp interfészre illeszked sz rési feltételt szeretnénk deniálni, akkor azt a -i ppp+ megadásával tehetjük. Ennek az a jelent sége, hogy a fenti példában a ppp interfészek dinamikusan allokálódnak, és el fordulhat speciális esetben, hogy másik ppp interfészt használ a rendszer, mint a megszokott (ppp0 helyett ppp1-et egy átmeneti hiba miatt), ekkor biztonságosabb az összes ppp interfészre deniálni a sz réseket. 8

5.4 Töredékek kezelése Az IP hálózatok sokféleségéb l adódóan néha el fordul, hogy egy csomag túl nagy ahhoz, hogy egy adott hálózaton egyszerre továbbítsuk. Ebben az esetben a csomagot kisebb darabokra (töredék: fragment) vágjuk, és a darabokat külön továbbítjuk. A töredékeket tipikusan csak a célállomáson rakjuk újra össze. A töredékek (IP fragment) kezelése sajnos nem egyszer : mivel a darabolás az IP szintjén történik, ezért csak az els darab tartalmazza a teljes protokollstruktúra fejléceit, a többi csak az IP-jét hordozza. Minden szabály, mely egy nem létez tulajdonságot vizsgál, nem illeszked nek tekintend. Ezért a második vagy kés bbi töredékeket a csomagsz r nem tudja vizsgálni. Ebben az esetben ugyanis sem a szabály, sem a szabály inverze nem fog illeszkedni a csomagokra. Szerencsére az iptables lehet vé teszi a töredékek vizsgálatát: -f, -fragment a töredékekre vonatkozó szabályt jelent. Például: iptables -A OUTPUT -f -d 10.0.0.0/8 -j DROP Mivel az els töredék miden szempontból vizsgálható, gyakorlatilag már itt eld l az adott csomag sorsa. Ezért a többi töredék átengedése általában biztonságosnak min sül, de ezt a rendszergazdának mérlegelnie kell, a fragmentumok és azok kezelése már számos speciális támadási lehet ségben voltak érintettek az Internet történetében. 6 Kiterjesztések: Netlter modulok illetsztésre Az iptables kiterjeszthet, vagyis új illeszkedéseket vizsgáló eljárásokat, moduloket, továbbá pl. új célpontokat (target, -j opció) lehet implementálni és alkalmazni. A Netlter rutinkönyvtár maga is számos modult tartalmaz, de számos kiegészít modul is letölthet az internetr l. A b vítményeket kernelmodulok betöltésével, vagy a kernelbe való belefordításával kell betölteni, majd az iptables parancson keresztül vezérelhet k. 6.1 TCP A TCP-hez (Transmission Control Protocol) tartozó kiterjesztések automatikusan betölt dnek a -p tcp kapcsoló hatására. Ez a következ új opciókat teszi lehet vé: -tcp-ags a TCP kapcsolók (ag-ek) vizsgálatát (mintaillesztését) teszi lehet vé. Két kötelez paramétere van, az els egy maszk, mely megmondja mely kapcsolókat vizsgáljuk, a második paraméter pedig megmutatja, hogy mely kapcsolóknak kell aktívnak lenniük. A maszknál a vizsgált kapcsolókat kell felsorolnunk (SYN, ACK, FIN, RST, URG, PSH), de az ALL mindegyiket magába foglalja. A második paraméternél is van egy speciális beállítás, a NONE, mely azt jelenti, hogy egyik kapcsoló sincs beállítva. A "!"segítségével az egész kifejezés invertálható. -syn ugyanazt jelenti, mint a -tcp-ags SYN, RST, ACK SYN beállítás. A kifejezés invertálható. Mintául vegyük például azt az esetet, mikor a bejöv kapcsolatkéréseket (SYN) szeretnénk tiltani: iptables -A INPUT -p tcp --syn -j DROP --source-port, --sport: egy forrás portra vagy port-tartományra illeszkedik, használható a TCP és UDP beépített modulokkal egyaránt (megfelel -p tcp vagy -p udp paraméterrel közösen). A portok sorszámmal vagy a /etc/services fájlban deniált nevükkel is megadhatók. Ha tartományt szeretnénk deniálni, az alsó és a fels értéket kett sponttal válasszuk el. (Például --sport 22:80. Ha -sport 80:22-t íruni, azt egyszer en -sport 22:80-nak értelmezi.) Nyitott tartományokat is megadhatunk, ha a tartomány egyik végét elhagyjuk. 9

Például: --sport 23 csak a 23-as portra illeszkedik. --sport 2000:3000 a 2000 és a 3000 közötti portokra illeszkedik (zárt intervallum). --sport 2000: a 1999-nél nagyobb portokra illeszkedik. --sport :3000 a 3001-nél kisebb portokra illeszkedik. A szabály invertálható a "!" segítségével. --destination-port, --dport egy célportra vagy port-tartományra illeszkedik. A portok megadása ugyanúgy történik, mint a --source-port esetében. --tcp-option egy TCP opciót határoz meg, melyet a számával kell deniálnunk. A nem teljes TCP fejléccel rendelkez csomagok automatikusan eldobásra kerülnek, amint a TCP opciókat vizsgáljuk. A szabály a szokott módon invertálható. 6.2 UDP Az UDP-hez (User Datagram Protocol) tartozó kiterjesztések automatikusan betölt dnek a --p udp kapcsoló hatására. Ez a következ új opciókat teszi lehet vé: --source-port, --sport egy forrás portra vagy porttartományra illeszkedik, a TCP-hez hasonlóan. A portok és tartományok megadása ugyanúgy történik, mint a TCP-nél megismert --source-port esetében. A szabály invertálható a "!" segítségével. --destination-port, --dport egy célportra vagy porttartományra illeszkedik. A portok megadása ugyanaz mint a --source-port esetében. 6.3 A "mac" modul A mac modul demonstrációs célokat szolgál, a -m mac vagy a --match mac kapcsolókkal lehet betölteni. A betöltés nem helyes kifejezés, mert valójában nem betöltés történik, hanem az iptables szabály a modul által elérhet kiegészítésekkel együtt válik deniálhatóvá. Azaz nincs valódi betöltés vagy modul törlés, hanem minden olyan szabálynál, ahol egy adott modul speciális funkcionalitását használjuk fel, specikálni kell ezt a paramétert. A modul lehet vé teszi, hogy a bejöv csomagok címét ne IP cím, hanem a hardver cím (MAC cím) alapján is illesszük. Csak a PREROUTING és az INPUT láncokon m ködik. -mac-source paramétere egy MAC cím, a szabály a forrás MAC címével való egyezést vizsgálja. A szokott módon invertálható. Például: iptables -m mac -mac-source... 6.4 A "limit" modul A limit modult a -m limit vagy a --match limit kapcsolókkal lehet használni, hasonlóan az el z ekhez egy illesztési kiegészítésr l van szó, amit sebességlimitációval kapcsolatos célokra lehet felhasználni. Segítségével korlátozhatjuk az illeszkedések számát, így például a naplózás csökkentésére, vagy a DoS támadások elleni védekezésre használható, de újfent hangsúlyozzuk, maga a limit modul egy illesztést végez csak, nem számít targetnek (cél). --limit meghatározza az adott id intervallumon belüli maximális illeszkedések számát, természetesen a többi illeszkedési szabályt ÉS logikai függvénnyel gyelembe véve. A paraméter megadható a /second, /minute, /hour, /day kifejezésekkel, vagy ezek részeivel. Például a 2/second ekvivalens a 2/s kifejezéssel. Ebben a példa esetben leegyszer sítve az illeszkedés csak másodpercenként kétszer fog megtörténni, illeszkedés esetén pedig a szabályban deniált target m velet kerül elvégzésre. Ezt az alapelvet a következ k módosítják: 10

--limit-burst paramétere egy számérték, mely megadja a maximális csomagszámot miel tt a szabályt nem illeszked nek vennénk. A illeszkedések korlátozása tocken bucket elven m ködik. Ha van a vödörben token, akkor a bejöv csomagot elfogadjuk. Ha nincs, akkor nem illeszked nek min sítjük. Mikor egy csomagot elfogadunk, a vödörb l kiveszünk egy tokent. Így persze a vödör gyorsan kiürülne, ezért gondoskodnunk kell a periodikus újratöltésr l. A vödör mérete maximalizálva van. A --limit kapcsoló tulajdonképpen azt adja meg, hogy milyen gyorsan töltjük újra a vödröt tokenekkel, míg a --limit-burst a vödör méretét deniálja. (Figyelem: A limit-burst itteni leírása eltér az iptables man page-en, extra feladat kideríteni, hogy melyik leírás közelíti jobban a valóságot: A mérési segédlet, vagy a man page.) A korlátozás egyik legfontosabb szerepe a DoS támadások (szolgáltatásmegtagadásos támadás elárasztással) elleni védelem. A DoS támadások egyik lehetséges módja, hogy a támadó nagyszámú csomaggal, vagy pl. kapcsolódási kísérlettel árasztja el a megtámadott számítógépet, így az képtelen lesz válaszolni a bejöv kérésekre. Egy lehetséges ellenintézkedés, hogy gyors visszatöltést alkalmazva limitáljuk például a bejöv kapcsolatfelvételek számát. Syn-ood elleni védelem: iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j n ACCEPT Portscan elleni védelem: iptables -A FORWARD -p tcp --tcp-ags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT Ping ood elleni védelem: iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT Ezek a megoldások természetesen csak példák. A konkrét értékeket a rendszer igényeinek megfelel en kell beállítani. Nagyon fontos megérteni, hogy a fenti példákban bizonyos sebesség mellett elfogadtunk kéréseket, de arról nem szól a szabály, hogy a "többlet" kérésekkel, azaz azokkal, amik a forgalmi határon túl vannak, mi történjen. Ezeket egy további szabálynak kell feldolgoznia, pl. DROP m velet elvégzésével (vagy pl. default DROP a policy). Fontos megjegyzés továbbá, hogy ha egy támadó nagy mennyiség kapcsolódást próbál meg elküldeni, úgy a korlátozás sikeresen kisz rheti ezt, de legitim felhasználók kapcsolódási kérései ugyanúgy, nagy eséllyel kisz résre kerülnek, így noha pl. egy védett szerver m köd képességét meg rizzük ugyan, de az esetleg nem tud megfelel en felhasználókat kiszolgálni, így a támadás a célját így is elérheti. 6.5 Az "owner" modul A modul a kimen (az OUTPUT láncon végigmen ) csomagokra biztosít egy újabb sz rési feltételt. Segítségével beazonosítható és vizsgálható (illeszthet ) a csomag küld je, mint linux felhasználó. A tulajdonosazonosítás négy szinten történhet: -uid-owner paraméterként a felhasználó azonosítóját, az user id-t várja. Segítségével az adott felhasználó processzei által generált csomagok sz rhet k. Például: --uid-owner 105 a 105-ös user csomagjaira illeszkedik. -gid-owner paraméterként a csoport azonosítóját, a group id-t várja. M ködése a --uid-owner kapcsolóéval azonos. -pid-owner egy adott processz által generált hálózati kimen forgalmat sz ri. Jól használható például egy adott szolgáltatás forgalmának korlátozásához illetve logolásához. 6.6 A kapcsolatstátusz illeszkedések A state modul a kapcsolatstátusz illeszkedések vizsgálatával b víti az illesztési lehet ségeket. A Net- lter, mint csomagsz r állapotokat kezel sz r, nemcsak az egyedi csomag feldolgozását használhatja 11

fel a döntésekhez, illesztésekhez, hanem pl. a kapcsolat állapotokat is, ezért volt fontos a mérési útmutató elején deniálni mi a különbség a kétfajta csomagsz r között Az conntrack modul a kapcsolatkövet és analizáló részét implementálja. Segítségével a kapcsolat állapota alapján végezhetünk sz réseket, illesztéseket. A -m state paranccsal aktiválhatjuk. -state segítségével a kapcsolat állapotát vizsgálhatjuk. Paraméterként az állapotok vessz vel elválasztott listáját várja. Az állapotok lehetséges értékei: NEW Új kapcsolatot létesít csomag. ESTABLISHED Egy már létez kapcsolathoz tartozó csomag. (SYN-re küldött SYN ACK már létez nek kapcsolatnak számít) RELATED Egy kapcsolathoz tartozó, de annak részét nem képez csomag, például ICMP hibaüzenet. INVALID Azonosítatlan csomag, mely nem rendelhet egyetlen kapcsolathoz sem. Az ilyen csomagokat általában el kell dobni. Például: iptables -A INPUT -m state --state NEW,INVALID -j DROP Az állapotillesztés megkönnyíti, és pontosabbá is teszi speciális feladatok ellátását. Ha egy cég policy szerint minden kifele men kapcsolat engedélyezett a bels hálózatból, akkor elegend egy ACCEPT szabály a FORWARD listában egy interfész illetsztéssel, míg a küls címekr l visszajöv válaszcsomagokat illeszthetjük állapot szerint (ESTABLISHED, RELATED), és ezeket beengedjük a bels hálózatba. E kett szabály biztosan nem engedi meg azt, hogy kívülr l befele is kapcsolatkezdeményezés történjen. 7 További Netlter target lehet ségek (-j opció) 7.1 LOG A modul feladata az illeszked csomagok kernel szint naplózása. A logolás mechanizmusának és szintaktikájának megismeréséhez célszer áttanulmányozni a syslog.conf fájl leírását (man syslog.conf). A logolást érdemes a limit modullal együtt alkalmazni, mert így elkerülhet a naplófájlok teleszemetelése. A naplózásnál a könnyebb feldolgozhatóság érdekében különböz naplózási szinteket és prexeket deniálhatunk: -log-level paraméterként egy napalózási szintet vár, melyet megadhatunk a nevével, vagy a hozzá tartozó számértékkel: 7 debug: Debug üzenetek 6 info: Információs üzenetek 5 notice: Megjegyzések 4 warning: Figyelmeztetések 3 err: Egyéb hibák 2 crit: Kritikus hiba 1 alert: Azonnal javítandó hiba 12

0 emerg: Vészhelyzet esetén használatos -log-pre-x a jobb azonosíthatóság érdekében a paraméterként megadott maximum 29 karakteres szöveg az üzenet elejére f z dik. Például: iptables -A INPUT -p TCP --log-prex p2pforgalom -j LOG Fontos, hogy a LOG target nem fejezi be a csomag feldolgozását az adott láncban, nem jelent sem eldobást, sem engedélyezést, azt a további szabályoknak kell deniálni. 7.2 REJECT Az alapértelmezett ACCEPT és DROP targetek m ködési módja egyszer : ACCEPT esetén az adatcsomag továbbítása, feldolgozása engedélyezett, DROP esetén a csomag feldolgozása leáll és egyszer en eldobásra kerül. Nem történik naplóbejegyzés, és a másik fél fele sem történik semmilyen válasz, információ küldése az eldobásról. A REJECT target használatával a csomagot eldobjuk, de a küls félnek a rendszer egy port unreachable ICMP üzenetet küld vissza. Ez megkülönböztethet attól az esett l, mintha a cél gépen nem futna egy szolgáltatás, mert pl. TCP esetben ekkor egy RST aggel megjelöl TCP packet jön vissza, nem egy ICMP hibaüzenet. TCP esetére a Netlter támogatja a TCP RST-s REJECT targetet is: -j REJECT --reject-with-tcp-reset 13

8 Feladatok A feladatok elvégzéséhez mér állomásonként egy darab számítógépet állítottunk be. Mindegyik számítógép két hálózati interfésszel (eth0, eth1) rendelkezik. A hálózaton 6 mér hely helyezkedik el, ezeknek a 10.105.1.4X és 10.21.1.4X IP címeket rendeltük DHCP-n keresztül, ahol X a mér hely sorszáma, (1-t l 6-ig). Az eth1 interfész esetén az IP szám hozzárendeléséhez szükség lehet a pump -i eth1 (vagy ifup eth1) parancs lefuttatására. Megjegyzés: root-ként kell ezeket futtatni. A mérések során a 10.105.1.4X (mér gépek) számú gépen egy linux munkaállomást (LIVE CD KNOP- PIX) telepítettük, ezek a gépek játsszák a t zfalak szerepét. A 10.105.1.241-246 számmal rendelkez, szintén linuxot futattó, próbakliens gépek a mérési feladatoknál a küls, távoli kliens (esetleg támadó) szerepét töltik be. A 3-as ábrán láthatjuk a mérési kongurációt. A próbakliens gépeken meresx, (X {1,..., 6}), felhasználói névvel hoztunk létre unix felhasználókat, SSH belépési lehet sségel. A meres1-meres6 felhasználók használhatják a wget, ping, links, lynx parancsokat a teszteléshez. A jelszót a mérésvezet fogja megadni. Figure 3: Mérési konguráció A hálózaton a védett gépet (próbaszerver) a 10.21.1.X-es gépek, (X {1,..., 6}), jelenti, ami az eth1 interfészen át érhet el. Tehát pl. a 3-as sorszámmal ellátott gép a 10.105.1.243-as próbakliens gépr l meres3 felhasználóval kapcsolódást kezdeményezhet a 10.21.1.3 próbaszerver gépre, ami a 10.105.1.43-as mér gépen keresztül fog lezajlani (a t zfalbeállításnak függvényében). Jegyz könyv: FONTOS!!! A feladatok során 1) kiadott parancsokat rögzítse és 2) röviden irja le az elvégzett lépéseket! A jegyz könyv beadásának határideje: egy héttel a mérés után. 14

Általános teend k: a csomagsz r kongurációja el tt vizsgálja meg a rendszert! - Ellen rizze a zikai hálózati kapcsolatok meglétét. Vizsgálja meg, és rajzolja le a hálózat topológiáját! Lépjen be a számítógépre, ellen rizze a hálózat m ködését! Az ifcong és a route parancs segítségével vizsgálja meg a hálózati kongurációt, jegyezze le a beállításokat! Az iptables parancs segítségével vizsgálja meg az aktuális beállításokat. Amennyiben szükséges, törölje a láncokat és a szabályokat! Vigyázat! Az iptables használatához rendszergazdai jogosultság szükséges (sudo vagy su parancs)! Csak óvatosan... 1. Egyszer t zfalazási védelmek: A feladat egy t zfal alapvet védelmének kialakítása. (a) A gép bekapcsolása után gy z djön meg az ifcong paranccsal mindkét hálózati interfész m ködésér l. Lépjen be a próbakliensre és tesztelje a próbaszerver elérhet ségét ping parancs segítségével! FONTOS: Amennyiben szükséges, állítsa át a gép ip_forward változóját a Függelék szerint és tesztelje újra, amig a kommunikáció nem sikeres! Szükséges parancsok: 1) cat /proc/sys/net/ipv4/ip_forward; 2) echo 1 > /proc/sys/net/ipv4/ip_forward. (sudo szükséges) (b) A lter táblában található láncok policy-ját (alapértelmezett sz rés) állítsa eldobásra. Az FORWARD láncon rakjon be egy olyan tiltószabályt is, amely TCP kapcsolatok visszautasításról visszajelzést is küld az egyszer bb követhet ség érdekében. (c) A policy átállítás után gy z djön meg arról, hogy a gépr l indított csomagok már nem érik el az internetet-intranetet! (Példa: ping m velet használatával pingeljük meg a szervert a munkaállomásról, routing táblák megvizsgálása, hálózati forgalom megvizsgálása tcpdump vagy tshark paranccsal) (d) Engedélyezze a munkaállomásra érkez és kimen ICMP üzeneteket a lter táblában! Ellen rizze, hogy a módosítás után ICMP csomagok sikeresen küldhet ek ki! Ellen rizze mind a próbakliens, mind a próbaszerver irányú kapcsolatokat ping parancs segítségével. (e) Engedélyezze az INPUT és OUTPUT láncokon a 22-es (SSH) protokoll futtatását, kizárólag a mér állomás és a próbakliens között. Most beléphet a próbakliensre a további tesztelés érdekében SSH klienssel. Hint: ssh meres4@10.105.1.244. (f) Engedélyezze a mér gépr l a TCP kapcsolatokat a próbaszerver irányába, minden portra. Tesztelje a t zfalról (mér gép) a próbaszerver TCP elérhet ségét azzal, hogy a rajta található weblapot letölti (links, wget, lynx, vagy grakus böngész ). Hint: wget -m -np http://10.21.1.4 (g) Hozzon létre egy új láncot tcplter néven! (h) A tcplter láncban fogadja el a bels hálózatból (próbaszerver) érkez, már létez TCP kapcsolatokhoz tartozó csomagokat! (state modul) (i) A tcplter láncban engedélyezze a küls hálózat fel l bejöv, már létrejött TCP kapcsolatok fogadását. Engedélyezze új kapcsolatok létrehozását is, de kizárólag csak a 80-as portra, a próbaszerver irányában! (j) A tcplter láncot kapcsolja a megfelel el redeniált lánchoz! (A t zfalon átmen kapcsolatokkal foglalkozó láncról van szó...) Listázza ki az iptables beállításait! Ellen rizze és tesztelje, hogy sikeres volt-e a beállítás! A feladat megoldásához fontos, hogy megfejtsük a TCPFILTER láncot melyik lánchoz adjuk hozzá, ha az átmen forgalmat akarunk átengedni. (Hint: utána tesztelni lehet: wget -m -np http://server ) 15

(k) Az nmap parancs segítségével végezzen portscannelést a próba szerver irányába, ellen rizze, hogy TCP szinten csak a 80-as port elérhet (l) Engedélyezze a 22-es SSH port elérését is a tcplter lánc módosításával és ellen rizze az eredményt újabb portscanneléssel! (m) Engedélyezze kizárólag a próbakliens IP-je felöl a próbaszerverre men, 1:1000 közötti TCP portok (szervernél) elérését a megfelel módon. Nmap portscannerrel (tetsz legesen paraméterezve, elegend sima portscan) ellen rizze az eredményt, a nyitott portokat. A tesztelési tapasztalatokat a jegyz könyvbe rögzítse! Screenshotokkal, vagy más módon dokumentálja a létrejött beállításokat, jegyz könyvezze a végrehajtott parancsokat. 2. Csak a lter táblákban használjon elutasító default policyt, a mostani feladatban használt táblákban hagyja meg az alapértelmezett elfogadást. Ne felejtse el rögzíteni a kiadott parancsokat! (a) Hozzon létre DNAT szabályt, mely segítségével eléri, hogy a próbakliensr l a próbaszerver 8022-es portjára men adatok a 22-es portra érkezzenek meg a próbaszerverre, azaz az SSH szolgáltatást a t zfal a 8022-es porton mutassa. Módosítsa a raw tábla láncait úgy, hogy magán a 22-es porton viszont ne lehessen elérni a próbaszervert, viszont a 8022-es (új) porton az ssh látszódjék! (ellen rizheti telnet paranccsal, vagy a netcat "`nc"' parancsával. nmap portscanneléssel is ellen rizze az eredményeket. Gondolja át, hogy miért a raw táblát kell módosítani?! Megvalósítható lenne a lter táblák módosításával? (A nat táblákban nem támogatott a DROP target, ezért nem lehet ott kezelni a dolgot.). Ezenkivül ne felejse el visszaállitani azok a korlátozó szabályokat amiket ezel tt állitott be!!! (b) Engedélyezze a próbaszerver 80-as portjának elérését oly módon, hogy csak másodpercenként 2 kapcsolatot fogadjon. Írjon egy kis scriptet ami párhuzamosan több wget kéréssel próbálja elérni a szervert, ennek futtatásával és lehallgatással (tcpdump) ellen rizze a sikeres beállítást! Hints: 1) használja a limit modult. 2) párhuzamos letöltéseket elinditó script a teszteléshez: for i in 'seq 1 10'; do wget -m -np http://server (c) Készítsen loggoló szabályt a FORWARD láncban eldobott csomagokra. Korlátozza a loggolást a limit modullal! Tesztelje alaposan a beállításokat! A tapasztalatokat rögzítse a jegyz könyvben! Hint: A log kimenetét dmesg paranccsal nézzék meg. (d) Hallgasson le egy próba TCP kapcsolatot a próbakliens és próbaszerver között (Wireshark vagy tshark programokkal). Ellen rizze az ECN ag meglétét! A mangle táblákba helyezzen el szabályt amit nullára módosítja az ECN ag értékét, majd lehallgatással ellen rizze, hogy tényleg módosul-e a csomag. A szükséges iptables kapcsolót keresse ki a "`man iptables"' dokumentációból. (e) Mangle szabállyal módosítsa az MSS értéket 1200-ra TCP kapcsolatokban. Használja a TCPMSS targetet. Figyeljen oda, hogy az MSS mez t csak a TCP protokoll kapcsolatfelvételi csomagjai tartalmazzák így csak azokat kell módosítani! Ellen rizze a beállítást teszteléssel (mindkét hálózati oldal lehallgatásával)! (f) A dokumentáció alapján találjon ki egy érdekes, szabadon választható t zfallal megvalósítható feladatot és oldja is meg! 16

9 Függelék #!/bin/bash echo 1 >/proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o eth0 -j SNAT\ --to-source 152.66.249.88 iptables -t nat -A PREROUTING -d 152.66.249.88 -p tcp --dport 80\ -j DNAT --to-destination 10.1.1.3:80 iptables -t nat -A PREROUTING -d 152.66.249.88 -p tcp --dport 22\ -j DNAT --to-destination 10.1.1.3:22 17