Csomagsz¶rés Linux-Net lter 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 Net lter 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 5.1 5.2 5.3 5.4
Forrás és célcím meghatározása a csomagok kiválasztásánál Protokoll meghatározása csomagillesztéshez . . . . . . . . . Interfész meghatározása csomagillesztéshez . . . . . . . . . Töredékek kezelése . . . . . . . . . . . . . . . . . . . . . . .
6 Kiterjesztések: Net lter modulok illetsztésre 6.1 6.2 6.3 6.4 6.5 6.6
TCP . . . . . . . . . . . . . . . UDP . . . . . . . . . . . . . . . A "mac" modul . . . . . . . . . A "limit" modul . . . . . . . . Az "owner" modul . . . . . . . A kapcsolatstátusz illeszkedések
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
7
8 8 8 9
9
9 10 10 10 11 11
7 További Net lter target lehet®ségek (-j opció)
12
8 Feladatok
14
9 Függelék
17
7.1 LOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2 REJECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
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 de niá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 de niá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 Net lter 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.
Rate limiting - A csomagok, kapcsolatok sebességének korlátozása, pl. Denial-of-Service (DoS) elleni védekezés céljából,
• Egyéb: Számos kiegészít® funkcionalitás van beépítve a rendszerbe, mint:
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, ellent-
mondá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 Net lter 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 Net lter 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 kon gurálható, így széles körben alkalmazható az egyszer¶ munkaállomás védelmét®l a komplex céges megoldásokig. A Net lter 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 de niá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 de niá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 de niá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-Net lter 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 speci ká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-Net lter 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 de niá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 de niá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 net lter modul kizárólag IP számokkal operál. Címtartományt is de niá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 de niá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 de niá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 ifcon g 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 de ní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 de niált szöveggel kezd®dik. Például ha az összes bejöv® ppp interfészre illeszked® sz¶rési feltételt szeretnénk de niá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 de niá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: Net lter 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 Net lter 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 de niált nevükkel is megadhatók. Ha tartományt szeretnénk de niá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 de niá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 de niá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, speci ká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 de niá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 de niá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 de niá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 hi-
baüzenet.
• INVALID Azonosítatlan csomag, mely nem rendelhet® egyetlen kapcsolathoz sem. Az ilyen cso-
magokat á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 Net lter 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 pre xeket de niá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-pre x 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 de niá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 Net lter 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 KNOPPIX) 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 kon gurá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 kon gurá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® kon gurá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 ifcon g és a route parancs segít-
ségével vizsgálja meg a hálózati kon gurá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 jogo-
sultsá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 ifcon g 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
[email protected]. (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 gra kus böngész®). Hint: wget -m -np http://10.21.1.4 (g) Hozzon létre egy új láncot tcp lter néven! (h) A tcp lter 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 tcp lter 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 tcp lter láncot kapcsolja a megfelel® el®rede niá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 tcp lter 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
