Linux iptables csomagszűrési gyorstalpaló, kezdőknek...

Átírás

1 1 / :57 Linux iptables csomagszűrési gyorstalpaló, kezdőknek... v0.01, , husky(bigyó)mad.hu Áttekintés a 2.4-es linux kernelben található iptables csomagszűrőről és képességeiről. 1. Bevezetés 2. TCP/IP alapok, röviden 3. És hogy jön ehhez a kernel? 3.1 A 'vanilla' kernel beállítása 3.2 Egyéb extrák 4. Az iptables Biztonsági lozóák, tűzfalak 4.2 A csomagok útja 5. Csapjunk a közepébe 5.1 Az iptables használata 5.2 Gyakorlati példák 5.3 Egy kis bash script Bevezetés Nos, üdvözöllek, kedves látogató... Jelen dokumentum - melyet épp olvasol - azon szándékkal jött létre, hogy - a témához mérten - rövid és - lehetőség szerint - szinte bárki számára érthető áttekintést nyújtson a 2.4-es linux kernelben található csomagszintű tűzfalról és annak használatáról. Technikailag valahol félúton kíván elhelyezkedni Rusty Russell "Linux 2.4 Csomagszűrő HOWTO"-ja < és Oskar Andreasson - jelen dokumentum írásakor még csak angolul olvasható - "iptables Tutorial 1.1.6"-ja között. < /ip-ipt/> Elolvasása után sajnos nem leszel biztonságtechnikai guru, viszont - reményeim szerint - átfogó képet kapsz majd az iptables szerkezetéről, használatáról és lehetőségeiről, valamint képes leszel saját géped védelmi tűzfalának megtervezésére és karbantartására... A dokumentum első fele afféle "hálózati alapismeretek-howto"... Akik már tisztában vannak az IP/TCP/UDP/ICMP protokoll feladataival és működésével, nyugodtan ugorják át a második fejezetet. Akik pedig már használható kernelt is fordítottak, rátérhetnek a lényegre: az utolsó két fejezetre. 2. TCP/IP alapok, röviden Nem, itt most sem történelemről, sem mély technikai részletekről nem lesz szó. Egyszerűen csak átfutjuk az IP (Internet Protokoll) számunkra lényeges részeit... Tegyük fel, van néhány számítógépünk szétszórva az interneten, és ezek kommunikálni szeretnének egymással. Mivel zikailag nincsenek összekötve, egymást csak akkor tudják korlátlanul elérni, ha mindegyiküknek van egy egyedi azonosítója, azaz IP címe. Ilyenkor egyszerűen fogják a mondanivalójukat, belerakják egy csomagba, - ami a számítógépes világban bitsorozatot jelent, - ráírják a célgép IP címét, majd "Add tovább!" felkiáltással átadják az "átjárójuknak", azaz a gateway-nek. A gateway-nek is van "átjárója", sőt, több hálózati kártyája, és a kapott csomag cél-ip címe alapján általában eldönti, hogy a csomagot melyik hálózati kapcsolatán, melyik közvetlen szomszédjának fogja átpasszolni. Ezt a döntést hivják "útvonalválasztásnak", azaz route-olásnak. Ez mindaddig folytatódik, gépről gépre, amíg a csomag el nem éri célját. Természetesen a kézbesíthetetlen csomagok nem pattognak az idők végezetéig az interneten, erről egy, a csomagba épített számláló gondoskodik, melynek kezdőértékét a küldő gép adja meg (ez a ttl - Time To Live), és minden egyes megállónál eggyel csökken az értéke. Ha ez eléri a nullát, az éppen aktuális gép nem küldi tovább a csomagot, hanem eldobja azt. Amennyiben a küldött adatok nem férnek el egyetlen csomagban, a küldő gép értelemszerűen feldarabolja őket, majd sorban, egymás után küldi el a részcsomagokat a címzettnek. Eddigi ismereteink alapján tehát az IP csomagok fejlécében (a csomag elején) fel van tüntetve a csomag forráscíme (source address), célcíme (destination address), és egy ttl számláló. Van még bennük pár apróság (verziószám, fejléc-hossz számláló, csomagazonosító, hibaellenőrző-összeg (checksum), stb), ezek viszont kívül esnek jelen leírás kereteiből, így a továbbiakban csak egyet részletezünk közülük, az átviteli protokollt deniáló mezőt. Az IP csomagról a fejlécet (az elejét) "levágva" megkapjuk a csomagban vitt hasznos adatot. Mivel az IP-t rendkívül általános körű felhasználásra tervezték, a hasznos adat elején többnyire megint csak egy újabb fejlécet találunk... Arról, hogy hogyan kell kibontanunk ezt az újabb csomagot, a levágott fejléc igazít el bennünket; pontosabban annak az átviteli protokollt deniáló mezője, melynek értéke 1 és 255 közé esik. A "hétköznapi számítástechnikában" ez általában 6 (TCP - Transmission Control Protocol), 17 (UDP - User Datagram Protocol), vagy 1 (ICMP - Internet Control Message Protocol). TCP-t használunk minden olyan átvitelnél, amelynél fontos, hogy minden egyes részcsomag sorrendben és hibátlanul, hiánytalanul érkezzen a címzetthez. Itt a címzett adott számú fogadott csomag után értesítést küld a küldő gépnek, hogy minden csomagot megkapott/nem kapott meg, és jöhet a folytatás/javítás. TCP-n keresztül küld adatokat például a http (WWW) vagy az ftp. UDP-t olyan adatok átvitelére használunk, ahol sem a beérkezési sorrend, sem a megérkezés nem életbevágóan fontos. Ilyen például az on-line kép/hang közvetítés, a Network Time Protocol vagy a talk. ICMP-t általában kisegítő üzenetek továbbítására használnak. ("Nincs nálam ilyen szerver", "A csomagot nem tudtam továbbadni, a célgép nem reagál", "A csomagot nem tudtam továbbadni, a célgép hálózata nem reagál", "Hé, ott vagy?", stb), viszont a tűzfalak létrehozásánál nem szabad lebecsülnünk, hiszen ugyanúgy tudunk vele adatot továbbítani mint előző két társával, azaz egy, a gépünkre került trójai program ugyanúgy vezérelhető általa, mint a hagyományos protokollok által. Nos, el is érkeztünk a fejezet végére... Az iptables megértéséhez már csak azt kell átnéznünk, hogy az egyik gépen futó program hogyan éri el, hogy a másik gépre úgy jusson el az üzenete egy adott programhoz, hogy a célgépen futó többi programot ez ne zavarja... A megoldás egyszerű: a csomagokon nemcsak a címzett lakcíme (IP címe) szerepel, hanem az is, hogy az adott lakcímen található ház melyik ajtajának megy az adat. Ezt a mezőt portszámnak hívjuk, értéke 1 és közé eshet... Igen, ebből az is következik, hogy egy gépen egyszerre "csak" kb féle szerver futhat anélkül, hogy különösebb trükkökhöz kellene folyamodnunk... Pusztán a példa kedvért: a WWW a 80-as TCP porton, az FTP a 21-es TCP porton, a RealPlayer a 6970-es UDP porton, az NTP pedig a 123-as UDP porton kommunikál... Tegyük fel, megnéznénk egy weboldalt. Mi sem egyszerűbb: begépeljük a címet a böngészőbe. A böngésző (kliens) első dolga, hogy a DNS (Domain Name Service) szervertől megkérdezze a beírt géphez tartozó IP címet. Mikor megkapja a választ, megkezdi a kapcsolatfelvételt a kapott IP cím 80-as TCP portjával,

2 2 / :57 hiszen alapértelmezett beállításokkal a webszerver az mögött van (ha van). Ehhez először nyitnia kell egy TCP portot a gépünkön, amelyről a kérést elküldi és amelyre a választ fogadja. Ez ugyanolyan jogokkal bíró port mint amely mögött pl. a webszerver várakozik, csak éppen a száma változó, hiszen ideiglenes használatra kell csak. A kapcsolat felépítése a következőképpen történik: Mivel a TCP protokollnak garantálnia kell a csomagok sorrendjét és megérkezését, a kapcsolat felépítésének elején a gépek (Nem a felhasználói programok!) megbeszélik egymás között a csomagok kezdő sorszámait. Ez három lépésből áll: a kliens küld egy ún. SYN (SYNchronize - szinkronizálj) csomagot a szervernek, benne az általa használt kezdő sorszámmal. Válaszul erre a szerver küld egy kettős célú, ACK/SYN csomagot (ACKnowledge - elismerve), melyben tájékoztatja a klienst, hogy tudomásul vette annak kezdő sorszámát, és egyúttal mellékeli azt a kezdő sorszámot, amelyet majd ő fog kiindulószámként használni a csomagok számozására. A kliens ezt a csomagot egy ACK válasszal elismeri, és innentől a kapcsolat felépültnek tekinthető, indulhatnak a tényleges adatok - a sorszámok és checksumok ellenőrzésével a gépek anélkül intézhetik el a hibajavítást (újraküldést), hogy arról a felhasználói programok tudomást szereznének. UDP/ICMP esetén ez a szinkronizáció elmarad, a gépek számozás nélkül megcímzik a csomagot, majd elküldése után nem foglalkoznak többé vele. (De mivel a magasabb szinten lévő felhasználói programok azt raknak a csomag adatrészébe amit akarnak, utólag természetesen akár számláló is építhető az átvitelbe...) 3. És hogy jön ehhez a kernel? A 2.4-es linux kernelben kétféle tűzfal is lakik. Kompatibilitási okokból a jó öreg ipchains (előreláthatóan 2004-ig), és az iptables. Az iptables állapottartó (stateful) tűzfal, ami annyiban különbözik az egyszerű csomagszűrőktől, hogy a szabványos fejléc-mezőkön felül gyeli a kezdeményezett kapcsolatokat, és azok állapotát is. A különbség megértéséhez folytassuk az előző példát a böngészővel: A gépek felépítik a böngésző kérésére a TCP kapcsolatot a kliens - tegyük fel es portja és a szerver 80-as portja között. A kliens elküldi a kérését a szervernek (kliens: > szerver:80), amire a szerver válaszol (szerver:80 ---> kliens:1234). Ha a kapcsolat tűzfalon is átmegy, a tűzfal kimenetén (OUTPUT) engedélyezni kell, hogy a kliensek csatlakozhassanak külső gépek 80-as portjára; és mivel általában választ is várnak, a tűzfal bemenetén (INPUT) engedélyezni kell a külső gépek számára, hogy választ küldjenek a 80-as portjukról a belső gépeknek. Itt álljunk meg egy kis fogalomtisztázásra... Belső gépek alatt itt azokat a gépeket értjük, amelyek a belső hálózatról az Internetre a tűzfalon keresztül küldenek adatokat. Többnyire őket védi a tűzfal. (Természetesen lehetnek esetek amikor az Internetet akarjuk megvédeni a belső gépektől... :) ) Külső gépnek számít tehát minden olyan gép, amelyeket a belső gépek a tüzfalon keresztül érnek el. A nem állapottartó tűzfalakon az "engedélyezd a külső gép 80-as portjának válaszát a belső gépnek" utasítás okozhat problémát. Ugyanis egy külső - hozzáértő - támadó könnyedén hamisíthat olyan TCP csomagokat, amelyek a tűzfalak számára teljesen hétköznapi válasznak tűnnek egy külső gép 80-as portjáról és éppen ezért átengedik őket. A probléma ott van, hogy a megcélzott belső gép nem is kért adatokat a külső géptől... Ez még nem túl nagy baj, de vannak esetek amikor az ilyen tűzfalon keresztül a külső gép feltérképezheti a belső gépeket és az azokon futó szolgáltatásokat (portscan) és esetleg csatlakozhat is azokhoz. Az állapottartó tűzfalak ezen a problémán segítenek, mivel emlékeznek a rajtuk keresztül nyitott kapcsolatokra és azok állapotára. Tehát csak akkor engedélyezik a külső gépek számára hogy adatokat küldjenek a belső gépeknek, ha a belső gépek valóban kérték azt. A belső hálózaton használt IP címek két kategóriába tartozhatnak: "külső" IP címek, és "belső" IP címek. A különbség közöttük pusztán annyi, hogy a "belső" IP címeket kívülről nem lehet közvetlenül elérni. (Tehát az előbb vázolt probléma a nem állapottartó tűzfalakkal ezen IP-ket nem érinti.) A külső IP címmel rendelkezők a tűzfalat pusztán a védelem miatt használják. Ilyenkor a tűzfal szűri, amit szűrnie kell, az engedélyezett csomagokat pedig egyszerűen továbbengedi (forward), a belső IP címek viszont csak akkor tudnak adatot küldeni az Internetre, ha egy külső IP címmel rendelkező gép vállalja azok továbbítását. A célgép az így kapott csomagokról úgy látja, a külső IP-jű gépről származnak, így a válaszát is annak küldi. A külső IP-s gép pedig továbbítja a választ a belső IP-jű gép számára. Ezt a folyamatot hívjuk... hm... álcázásnak... de mint oly sok számítógépes fogalomnál, az angol eredeti - NAT (Network Address Translation, masquerading) - itt is sokkal jobban passzol A 'vanilla' kernel beállítása A linux kernel forráskódját az ftp://ftp.kernel.org címről szerezhetjük meg. A nyílt forráskód szépsége, hogy az ember (na jó: a programozó) tetszőleges tudással ruházhatja fel a kernelt (vagy bármely programot), amennyiben megírja hozzá a szükséges programkódot. Az esetek nagyobbik részében azonban már valaki megírta helyettünk a kódot és nekünk csak annyi dolgunk marad vele, hogy a patch nevű varázslattal hozzáadjuk az eredeti forráskódhoz. Mindaddig amíg nem rondítunk bele az eredeti kódba, annak a neve vanilla kód. A kernel.org-ról letöltött vanilla kernel is tökéletesen használható, azonban ha különleges igényünk támad (van nálunk néhány, helyenként hibás RAM modul amit a hibák ellenére szeretnénk használni, vagy extra biztonsági beállításokkal akarjuk ellátni a gépet, esetleg olyan tűzfalat szeretnénk amely csak szerda délutánonként hajlandó átengedni a forgalmat, stbstb), szükségessé válhat a patchelés... A kernel beállításáról és lefordításáról nem ezen dokumentum ír, ezért itt csak az iptables-szel kapcsolatos pontokról lesz szó: Network packet ltering (replaces ipchains) (CONFIG_NETFILTER) - Az egész tűzfal alapja. Ha itt nemmel válaszolunk, a többi, iptables-szel kepcsolatos kérdésre már nem kerül sor. Connection tracking (required for masq/nat) (CONFIG_IP_NF_CONNTRACK) - A tűzfalon átmenő kapcsolatok követése. Amennyiben nem csak saját tűzfalat építünk, hanem a tűzfalon keresztül más gépek is elérnék az Internetet, szükségünk van rá. FTP protocol support (CONFIG_IP_NF_FTP) - Az FTP nem csak egy TCP kapcsolatot használ az átvitelhez. PASV átvitelnél pedig a DATA kapcsolat nem is kizárólag a 20-as portról megy. Ez az opció ennek a szűrését/engedélyezését könnyíti. IRC protocol support (CONFIG_IP_NF_IRC) - Az IRC-n használt DCC kapcsolatok kezdeményezését teszi lehetővé a NAT-olt gépek számára. IP tables support (required for ltering/masq/nat) (CONFIG_IP_NF_IPTABLES) - Az iptables felület engedélyezése. limit match support (CONFIG_IP_NF_MATCH_LIMIT) - Segítségével megadhatjuk, milyen mennyiségben engedünk át (vagy korlátozunk) csomagokat. Megadása csomag/perc,másodperc,stb mennyiségben történik. Használható pl. ping flood elhárítására, vagy a logle méretének csökkentésére. MAC address match support (CONFIG_IP_NF_MATCH_MAC) - A hálókártya hardvercímének alapján szűr. Belső hálózaton használhatjuk teljes gépek tiltására (engedélyezésére), IP címüktől függerlenül. Packet type match support (CONFIG_IP_NF_MATCH_PKTTYPE) - Segítségével leegszerűsített formában adhatunk utasítást pl. broadcast csomagok szűrésére. netlter MARK match support (CONFIG_IP_NF_MATCH_MARK) - Segítségével megjelölhetjük a csomagokat. A megjelölt csomagokkal később esetleg egyszerűbb lehet további műveleteket végezni. Multiple port match support (CONFIG_IP_NF_MATCH_MULTIPORT) - Alapesetben a tűzfalban egy szabályhoz egy portot (vagy porttartományt) rendelhetünk. Ennek segítségével egyszerre több port(! de nem tartomány) is megadható. TOS match support (CONFIG_IP_NF_MATCH_TOS) - Az IP csomagok Type Of Service (minimális késleltetés, max. sebesség, max. megbízhatóság) bitjei alapján szűr. Egy hétköznapi tűzfalnál nem túl használható. ECN match support (CONFIG_IP_NF_MATCH_ECN) - Mint a TOS, csak itt a TCP csomag ECN (Explicit Congestion Notication) bitjei alapján szűrhetünk. Számunkra ez sem túl fontos. DSCP match support (CONFIG_IP_NF_MATCH_DSCP) - A DSCP mező alapján szűr. Reflektált DoS támadásoknál esetleg segíthet kivédeni a forgalmat, de annak leírása megint nem egy "alapfokú gyorstalpaló" feladata. AH/ESP match support (CONFIG_IP_NF_MATCH_AH_ESP) - Az IPSec csomagokban található AH/ESP mezőket szűri. Jelen dokumentumban ezt is hanyagoljuk... :) LENGTH match support (CONFIG_IP_NF_MATCH_LENGTH) - Ez viszont egy hasznos opció. Méretük alapján korlátozhatjuk a csomagokat, ami segíthet kivédeni egy DoS támadást. TTL match support (CONFIG_IP_NF_MATCH_TTL) - Az IP csomag TTL mezőjét gyeli. Segítségével pl. elbújtathatjuk linuxos gépünket a hálózaton fellelhető Windows-ok elől. De természetesen komolyabb céloknál is megállja helyét... tcpmss match support (CONFIG_IP_NF_MATCH_TCPMSS) - A TCP csomagok MSS (Maximum Segment Size) mezőjét gyeli. Szintén DoS támadások esetén segíthet rajtunk. Helper match support (CONFIG_IP_NF_MATCH_HELPER) - A lista elején található FTP és IRC szűrők által módosított csomagokat azonosítja. Connection state match support (CONFIG_IP_NF_MATCH_STATE) - Az iptables egyik hasznos opciója, közeli kapcsolatban van az említett álapottartással. Connection tracking match support (CONFIG_IP_NF_MATCH_CONNTRACK) - Az előző opció erősen továbbfejlesztett változata. NAT-olt kapcsolatokban képes szűrni a külső, belső cél-, és forráscímek alapján is. Packet ltering (CONFIG_IP_NF_FILTER) - Erre szükségünk lesz, ha tűzfalat építünk. Amennyiben külön-külön gépet használunk NAT-ra és tűzfalnak, a csak NAT-ot végző gépen elhagyhatjuk. REJECT target support (CONFIG_IP_NF_TARGET_REJECT) - Az iptables alapból csak kétféle lehetőséget ismer: átengedi a csomagot (ACCEPT) vagy

3 3 / :57 eldobja a csomagot (DROP). Itt kiegészíthetjük egy REJECT (elutasít) opcióval is, hogy a csomag eldobásáról küldjön értesítést a küldő gépnek is. így a küldő esetleg hajlamos azt elhinni, hogy az adott porton nincs is szerver. Full NAT (CONFIG_IP_NF_NAT) - Amennyiben NAT-olni is fog a gép, erre szükségünk lesz. MASQUERADE target support (CONFIG_IP_NF_TARGET_MASQUERADE) -...és erre is, mivel enélkül nincs csomagtovábbítás a belső gépek számára. REDIRECT target support (CONFIG_IP_NF_TARGET_REDIRECT) - Ez egy ranált kis opció. A belső gépek által kifelé küldött csomagokat átirányíthatjuk a NAT-oló gépen futó szervernek. Akkor használhatjuk, ha például rá akarjuk kényszeríteni a belső gépeket a NAT gépen futó proxy szerver használatára. NAT of local connections (READ HELP) (CONFIG_IP_NF_NAT_LOCAL) - A NAT-oló gép csomagjai alapesetben módosítás nélkül mennek ki a gépből. Ha a NAT gépről WWW-böngészünk, ezzel az opcióval például megoldhatjuk, hogy a kedvenc reklámbanner-szervereink reklámai helyett a saját gépünkön futó webszerver szolgáltasson egy transzparens GIF-et... Packet mangling (CONFIG_IP_NF_MANGLE) - Apró kiegészítő, amellyel beállíthatjuk a csomagok fejléceinek különböző mezőit. TOS target support (CONFIG_IP_NF_TARGET_TOS) - A TOS mezőt állítja be. ECN target support (CONFIG_IP_NF_TARGET_ECN) - Az ECN mezőt állítja tetszőleges értékre. DSCP target support (CONFIG_IP_NF_TARGET_DSCP) - A TCP Control mezőjének 6 bitjét állíthatjuk tetszőleges értékűre. MARK target support (CONFIG_IP_NF_TARGET_MARK) - Csomagok megjelölése. Amennyiben több hálózati kapcsolatunk is van, segítségével eldönthetjük, melyiket használjuk WWW-re, melyiket FTP-re, és így tovább... LOG target support (CONFIG_IP_NF_TARGET_LOG) - Amennyiben kíváncsiak vagyunk, mi is történik a gépünkkel, ezzel átküldhetünk néhány hasznos információt a syslog-nak... ULOG target support (CONFIG_IP_NF_TARGET_ULOG) - Ha nem szeretjük a syslog-ot, a csomaginformációkat egy daemonnak is átküldhetjük... TCPMSS target support (CONFIG_IP_NF_TARGET_TCPMSS) - Az MSS mezőt állíthatjuk át. 3.2 Egyéb extrák A címről leszedhetjük a teljes netlter kódot, melyben sok olyan kiegészítő funkció található, amelyek helytakarékosságból nem kerültek bele a vanilla kernelbe. A netlter és patch-o-matic csomagokat a kernel kongurálása előtt kell kicsomagolni és lefordítani/elindítani, mivel mindkét csomag a kernel forráskódját patch-eli. A kiegészítő funkciók között számos - számunkra esetleg használhatatlan - apróság van, viszont találhatunk közöttük olyanokat is, amelyek egyetlen tűzfal-szabállyal detektálnak portscant, két tűzfal-szabállyal megoldják hogy gépünk egy megadott időtartamra teljesen láthatatlanná váljon a támadó gép számára annak első próbálkozása után, de olyasmit is engedélyezhetünk, hogy az előbb említett CONFIG_IP_NF_MATCH_MULTIPORT ne csak port-felsorolást (21,80,110...), de port-tartományokat (21,80,137:139,110...) támogasson Az iptables... A hosszas bevezető-ismétlés után végre rátérhetünk az iptables bemutatására. Amennyiben nem vagy kíváncsi az elméleti alapokra és tudod (vagy nem akarod tudni), miben különbözik a nat-, a lter- és a mangle-tábla, lapozhatsz az ötödik fejezethez Biztonsági lozóák, tűzfalak Két megközelítése van a tűzfalak felépítésének: a megengedő- és a tiltó hozzáállás. Előbbinél mindent szabad, ami nincs kifejezetten tiltva. Utóbbinál pedig alapból tiltunk mindent, és utána egyenként engedélyezünk, teszünk kivételeket. Értelemszerűen ez utóbbi a szigorúbb hozzáállás, és az elmúlt években - ahogy folyamatosan nőtt a számítógépes sebezhetőségek hírértéke - egyre inkább ez került előtérbe. (A szerző magánvéleménye, hogy a csomagszintű tűzfalaknál a szigorúbb megközelítés nem feltétlenül eredményez nagyobb biztonságot mint az engedékeny hozzáállás, hiszen a csomagszintű tűzfalakkal csak szervereket és klienseket zárhatunk el egymástól, miközben a tényleges fenyegetést inkább az elszaporodó féreg/vírus/trójai kombinációk okozzák, amelyek gyakran a tűzfaltól függetlenül is képesek eljutni bármely gépre. Külső gépek hozzáférését a belső, bizalmas adatokat tároló szerverekhez pedig bármilyen tűzfal-lozóával egyszerűen megoldhatjuk). Viszont kétségkívül a bimbózó paranoia korszakát éljük, így ez a dokumentum is a tiltó-alapú tűzfalakra koncentrál. 4.2 A csomagok útja Miután a hálózati kártya (modem, ISDN kártya, stb) vette a csomagot, átadja azt a kernelnek. A kernelen belül a fogadott csomagok átfutnak a netlter kódon, majd a jellemzőiktől függően kerülnek át a gépen futó szerverekhez/programokhoz, vagy - amennyiben forwardolni/nat-olni való csomagról van szó - futnak a bemenetről egyenesen át a route-táblákon és a nat táblán, hogy újra elhagyják a gépet. Nézzük meg - ijesztőként :) - a teljes netlter folyamatábrát: mangle nat mangle lter mangle nat Hálózat Hálózat > PREROUTING ---> PREROUTING ---> R ---> FORWARD ---> FORWARD ---> R ---> POSTROUTING ---> POSTROUTING > ^^ ^ Nekünk jött >> Csak továbbítani kell v OUTPUT lter mangle INPUT +---^ OUTPUT nat v ^----+ lter INPUT OUTPUT mangle KERNEL v ^ PROGRAMOK bejövő adatok kimenő adatok Kisbetűkkel írjuk a táblák nevét, három van belőlük: mangle, nat és lter táblák. Nagybetűkkel írjuk a láncokat, amelyekhez hozzáfűzhetjük saját szabályainkat: INPUT, OUTPUT, PREROUTING, POSTROUTING és FORWARD, de tetszőlegesen hozhatunk létre saját láncokat is. Az "R" betűs kockák jelzik azt a két helyet, ahol route-olás történik. A bemenetnél az dől el, hogy ki a csomag tényleges címzettje: a mi gépünk, vagy csak azért került hozzánk, hogy mi továbbítsuk. A kimenetnél pedig az dől el, hogy melyik hálózati csatolónkon fog távozni a csomag... A mangle tábla a legegyszerűbb, itt a csomagok fejlécének mezőit módosíthatjuk, esetleg megjelölhetjük a csomagokat a későbbi route-oláshoz. A továbbiakban nem foglalkozunk vele... A nat tábla szolgál a csomagok forrás- és célcímeinek módosítására. Az ehhez a táblához tartozó láncokon belül irányíthatjuk át a kapcsolatokat más gépekre (hogy például a gépünk 80-as portja egy másik gépen lévő webszerverhez vezessen, vagy akár azt, hogy a gépünk összes portja mögött ugyanaz a szerver legyen... és igen, itt akár olyan csomagokat is létrehozhatunk, amelyek első ránézésre nem is a mi gépünkről származnak...) A lter tábla pedig az, amellyel ezen dokumentum foglalkozni kíván. Itt korlátozhatjuk a gépünkhöz való hozzáférést. (Azaz elvileg korlátozhatjuk a másik két tábla bármelyikében is, de egyrészt azt a fejlesztők nem ajánlják - mivel lehetnek mellékhatásai, másrészt pedig azért lter a lter tábla neve, hogy a lterezést ott végezzük... :) ) Miután kellőképp áttanulmányoztuk a fenti ábrát, egyszerűsítsük le, hogy csak a számunkra jelenleg fontos lter/input, lter/forward, és lter/output maradjanak benne: lter Hálózat Hálózat > R ---> FORWARD ---> R > ^^ ^ Nekünk >> v Nem nekünk

4 4 / :57 INPUT lter OUTPUT lter v ^ bejövő adatok kimenő adatok Nos, ez valamivel szelídebb ábra. Mint láthatjuk, ha a gépünkre bejövő kapcsolatokat akarjuk korlátozni, a lter/input láncban kell tevékenykednünk. Ha a saját gépünket akarjuk korlátozni, a lter/output való nekünk. Ha pedig azt kívánjuk szigorítani, hogy a bennünket gateway-nek használó gépek mit csinálhatnak, a lter/forward láncot kell majd bővítenünk. 5. Csapjunk a közepébe A sok elmélet után jöjjön a - meglepően kevés - gyakorlat, lévén az iptables kezelése roppant egyszerű, bár igaz, kissé "fapados"... Mint említettük, táblákon dolgozunk. A tábláknak gyakorlatilag csak az a szerepe, hogy segítsen nekünk eligazodni, hogy melyik láncokat szerkesztjük éppen, és hogy azokon a láncokon belül milyen szabályokat alkothatunk. A láncok pedig nem véletlenül kapták a lánc nevet: a csomag a létrehozott, felfűzött szabályokon szépen sorban végighalad, mindaddig, amíg valamely szabály nem lesz érvényes arra a csomagra. Ha egy láncon belül két szabály is illeszkedik a csomagra és az első engedélyező, a második pedig tiltó, akkor a csomag áthaladása engedélyezve lesz, hiszen a tiltó szabályig már nem jut el a csomag, az első szabály illeszkedése után azonnal kikerül a láncból és folytatja útját. Fordított sorrend esetén pedig hiába engedélyezzük egy tiltó szabály után a csomagot, a tiltó szabály illeszkedése esetén a csomag megsemmisül. Amennyiben egy szabály sem illeszkedik a csomagra, a láncra meghatározott szabály érvényesül (tiltó vagy engedélyező). 5.1 Az iptables használata Az iptables-t - meglepő módon - az iptables paranccsal kezelhetjük. Fontosabb paraméterei a következők: -t - A tábla megadása, amelyen dolgozunk: "iptables -t lter..." -A - Új szabály hozzáadása a megadott tábla/lánc végéhez: "iptables -t lter -A INPUT..." -D - Meglévő szabály törlése a megadot tábla/láncból: "iptables -t lter -D INPUT 2" (a második szabályt törli), vagy "...-D INPUT -d localhost --dport 80..." (a megadott szűrőt próbálja megkeresni és kitörölni) -I - Új szabály hozzáadása a megadott tábla/lánc elejéhez: "iptables -t lter -I INPUT..." -R - Meglévő szabály lecserélése: "iptables -t lter -R INPUT 2 -d localhost --dport 80..." (a második szabály lecserélése "-d localhost --dport 80..."-ra) -L - A megadott tábla láncainak kilistázása: "iptables -t lter -L", vagy "iptables -t lter -L OUTPUT" (csak a kimeneti szűrők listázása) -F - A megadott tábla/lánc elemeinek teljes törlése: "iptables -t lter -F" vagy "iptables -t lter -F FORWARD" (csak a FORWARD láncot törli) -N - Új lánc létrehozása a megadott táblán: "iptables -t lter -N NYAKLANC" (ingyen nyaklánc). Az így létrehozott láncok a -j paraméterrel már meglévő láncokba illeszthetőek bele. -X - Az általunk létrehozott lánc törlése: "iptables -t lter -X NYAKLANC" -P - A lánc alapértelmezett szabályának megadása: "iptables -t lter -P INPUT DROP" (amit nem engedélyezünk külön a bemeneten, azt eldobjuk) -s - Forrás-IP cím megadása: "iptables -t lter -A INPUT -s /24..." ("ami a közötti gépekről jön, azt...") -d - Cél-IP cím megadása: "iptables -t lter -I FORWARD -d /24..." ("ami a közötti gépeknek megy, azt...") -p - Protokoll megadása: "iptables -t lter -I OUTPUT -p tcp..." ("ami TCP protokollú csomag, azt...") -j - A szabály eredményének megadása. Itt dől el a csomag sorsa: "iptables -t lter -A INPUT -p icmp -j DROP..." (nem kérünk ICMP csomagot) -i - A bejövő hálózati kapcsolat megadása: "iptables -t lter -I INPUT -i eth0 -j ACCEPT..." (az eth0 hálókártyáról mindent elfogadunk) -o - A kimenő hálózati kapcsolat alapján szűr. Csak ott van értelme, ahol már tudni, melyik kártyán fog kimenni a csomag: "iptables -t lter -A OUTPUT -o eth1 -j DROP..." (az eth1-re nem küldhetünk adatokat) -m - A szűrő kiterjesztése. Egy példa: "iptables -t lter -A INPUT -p icmp -m limit --limit 5/sec -j ACCEPT..." (másodpercenként 5 ping) --sport - A forrásport megadása: "iptables -t lter -I INPUT -s p tcp --sport j REJECT..." (A es gép 1234-es portját nem szeretjük) --dport - A cél-port megadása: "iptables -t lter -I INPUT -s p tcp --dport www -j REJECT..." (...és ez a gép a webszerverünket sem használhatja...) A "-t lter" elhagyható, mivel az az alapértelmezett. Csak a nat/mangle esetén kell kiírni. 5.2 Gyakorlati példák - Nem akarok befelé engedélyezni semmit, csak azokat a kapcsolatokat amiket én kezdeményeztem. - iptables -P INPUT DROP; iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT - Nem akarom szűrni a belső hálót. - iptables -I INPUT -s belso_halo/maszk -j ACCEPT - Nem akarok Half-Life/Counter-Strike csomagokat látni a gépemen. - iptables -A INPUT -p udp --dport 27015: j DROP - Tudni akarom, ki csatlakozik az FTP szerveremhez. - iptables -A INPUT -p tcp -m state --state NEW --dport 21 -j LOG --log-prex "[FTP_KAPCSOLAT] " - Engedélyezni akarom a bejövő FTP,WWW,SSH,SMTP és TELNET kapcsolatokat. - iptables -A INPUT -p tcp -m multiport --dports ftp,www,ssh,smtp,telnet -j ACCEPT - A portscan-gyanús csomagokat el akarom dobni. - iptables -I INPUT -m psd --psd-weight-threshold 60 --psd-delay-threshold psd-lo-ports-weight 10 --psd-hi-ports-weight 5 -j REJECT (csak ha bele van patch-elve a kernelbe) - A támadók számára váljak láthatatlanná. - A lánc végére: -A INPUT -p tcp -m recent --set -j DROP, a lánc elejére -I INPUT -m recent --update --seconds 600 -j DROP (csak ha bele van patch-elve a kernelbe) - Boldog broadband user vagyok, és másokat is boldoggá szeretnék tenni. (Ez esetleg ütközhet a szolgáltató szabályzatával) - iptables -t nat -A POSTROUTING -s /24 -i eth1 -j MASQUERADE és echo 1 > /proc/sys/net/ipv4/ip_forward - Tűzfal vagyok, és az általam védett, kívülről egyébként elérhető belső gépek inkább ne legyenek elérhetőek. - iptables -A FORWARD -m state --state NEW -j DROP 5.3 Egy kis bash script... Végül a türelmetleneknek álljon itt egy egy egyszerű shell script, amely elintézi a munka apraját... :)

5 5 / :57 Szűri a bejövő kapcsolatokat, NAT-ot hajt végre tetszőleges belső címtartományok számára, valamit egyszerű tűzfalként szűri a gép mögötti, "normális" IP-kre menő kapcsolatokat. Mivel csak abban a védelemben bízhatunk, amit ismerünk is, azok feltétlenül rágják át, akik biztonságban akarják tudni a gépüket... #!/bin/bash echo -n "Setting rewall rules... " # [INIT] iptbl_path="/usr/local/sbin/iptables" if! [ -x $iptbl_path ] ; then echo "!!" $iptbl_path "- is not executable.!!"; exit 1; ; # Ha bootoláskor megadjuk a no-rewall paramétert, nincs tűzfal (kivéve, ha ezt a scriptet "force" paraméterrel indítjuk): if [ "$1"!= "force" ]; then if [ "`/bin/grep no-rewall /proc/cmdline`" ]; then echo "Disabled."; exit 0; ; ; # Saját IP-címünk megállapítása: default_interface=`route grep default awk '{print $8}'` my_ip=`ifcong $default_interface grep inet awk '{print $2}' cut -d: -f2` # [CONFIG] # A tűzfal hozzáállása a dolgokhoz: megpróbálunk elbújni (DROP), vagy álljuk a sarat (REJECT) drop_or_reject="drop" # Válaszolunk-e a pingre? ping_reply=0 max_ping_speed=5/s # Ha az előző válasz nem, van-e mégis olyan ping, amire válaszolunk? (ping <host> -s 1234) magic_ping=1234 # 0 és 84 byte között válaszolunk. (56 byte default ping data + 28 byte header) max_ping_packet_size=84 # Velük egyáltalán nem állunk szóba: ignore_hosts=" # Port(tartomány)ok, amelyekkel egyáltalán nem törődünk: ignore_ports_tcp="" ignore_ports_udp="27015:27050" # Ha valaki megkísérel egy tiltott portra csatlakozni, elbújunk-e előle (a drop_or_reject gyelembevételével!): # Nincs benne a default kernelben, a netlter.org-ról letölthető patch viszont tartalmazza (sok más extrával együtt) hide_from_vicious_hosts=0 hide_interval=600 # A sikertelen csatlakozási kísérletek loggolása a megadott tartomány(ok)ban: log_illegal_connections=1 log_illegal_tcp_range="0:1024" log_illegal_udp_range="0:1024" # Haszál-e bennünket valaki gateway-nek: forward_connections=1 # "Rendes" IP címmel rendelkező hálózat(ok), amelyek rajtunk keresztül csatlakoznak: forward_for_networks="" #`echo $my_ip cut -d. -f1,2,3`.0/24 # Ami ezeken a gépeken "kívülről" elérhető: forward_ports_tcp="ssh,www" forward_ports_udp="" # "Privát" IP címmel rendelkező hálózat(ok), amelyek rajtunk keresztül csatlakoznak: NAT_for_networks=" /24" # Az új bejövő kapcsolatok loggolása: log_legal_connections=1 # És végül: az engedélyezett portok: accept_ports_tcp="ssh,ftp,smtp,www,https" accept_ports_udp="talk,ntalk,ntp" # Amennyiben a kernel nem támogatja, átjavítandó "--dport"-ra, a portlistákban meg a vesszőket szóközre kell cserélni: use_multiport="-m multiport --dports" # [MAIN] # Nagytakarítás: $iptbl_path -F INPUT $iptbl_path -F FORWARD $iptbl_path -F OUTPUT # Alapértelmeződjünk: befelé semmi, kifelé bármi. $iptbl_path -P INPUT $drop_or_reject $iptbl_path -P FORWARD $drop_or_reject $iptbl_path -P OUTPUT ACCEPT # Az elején mindjárt eldobjuk azt, amire nincs szükségünk: for bad_hosts in $ignore_hosts; do $iptbl_path -A INPUT -s $bad_hosts -j DROP; done for port_number in $ignore_ports_tcp; do $iptbl_path -A INPUT -p tcp --dport $port_number -j DROP; done for port_number in $ignore_ports_udp; do $iptbl_path -A INPUT -p udp --dport $port_number -j DROP; done # Beállítjuk, pingelhetőek vagyunk-e: if (( ping_reply == 1 )); then $iptbl_path -A INPUT -p icmp --icmp-type echo-request -m length --length `echo $max_ping_packet_size awk '{print $0+1}'`: j DROP $iptbl_path -A INPUT -p icmp --icmp-type echo-request -m limit --limit $max_ping_speed -j ACCEPT else if (( $magic_ping > 0 )); then $iptbl_path -A INPUT -p icmp --icmp-type echo-request -m length --length `echo $magic_ping awk '{print $0+28}'` -j ACCEPT; ; $iptbl_path -A INPUT -p icmp --icmp-type echo-request -j DROP ; # Bármilyen egyéb ICMP csomagot elfogadunk: $iptbl_path -A INPUT -p icmp --icmp-type! echo-request -j ACCEPT # Loggoljuk azokat a kapcsolatokat, amelyek átjutnak a tűzfalon... if (( log_legal_connections == 1 )); then for port_number in $accept_ports_tcp; do $iptbl_path -A INPUT -d $my_ip -p tcp -m state --state NEW $use_multiport $port_number -j LOG --log-prex "[FW_NEW_TCP] "; done for port_number in $accept_ports_udp; do $iptbl_path -A INPUT -d $my_ip -p udp -m state --state NEW $use_multiport $port_number -j LOG --log-prex "[FW_NEW_UDP] "; done #... és engedélyezzük is azokat: for port_number in $accept_ports_tcp; do $iptbl_path -A INPUT -d $my_ip -p tcp -m state --state NEW $use_multiport $port_number -j ACCEPT; done for port_number in $accept_ports_udp; do $iptbl_path -A INPUT -d $my_ip -p udp -m state --state NEW $use_multiport $port_number -j ACCEPT; done # Meglévő kapcsolatokkal összefüggő csomagok: $iptbl_path -A INPUT -d $my_ip -m state --state RELATED,ESTABLISHED -j ACCEPT # Csomagok, amelyeket nem engedélyeztünk... if (( log_illegal_connections == 1 )); then for port_number in $log_illegal_tcp_range; do $iptbl_path -A INPUT -p tcp -m state --state NEW --dport $port_number -j LOG --log-prex "[FW_ALERT_UNK_TCP] "; done for port_number in $log_illegal_udp_range; do $iptbl_path -A INPUT -p udp -m state --state NEW --dport $port_number -j LOG --log-prex "[FW_ALERT_UNK_UDP] "; done

6 6 / :57 #...és így, a chain végén akár arra is felhasználhatunk, hogy a küldő gép egyébként elfogadott csomagjai se érjék el a gépünket: if (( hide_from_vicious_hosts == 1 )); then $iptbl_path -A INPUT -m state --state NEW -m recent --set -j $drop_or_reject $iptbl_path -I INPUT -m recent --update --seconds $hide_interval -j $drop_or_reject # IP forward és NAT konguráció: if (( $forward_connections == 1 )); then for dest_net in $forward_for_networks; do for port_number in $forward_ports_tcp; do $iptbl_path -A FORWARD -o! $default_interface -d $dest_net -p tcp -m state --state NEW $use_multiport $port_number -j ACCEPT; done for port_number in $forward_ports_udp; do $iptbl_path -A FORWARD -o! $default_interface -d $dest_net -p udp -m state --state NEW $use_multiport $port_number -j ACCEPT; done $iptbl_path -A FORWARD -i! $default_interface -s $dest_net -m state --state NEW -j ACCEPT done $iptbl_path -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT for nat_net in $NAT_for_networks; do $iptbl_path -t nat -A POSTROUTING -o $default_interface -s $nat_net -j MASQUERADE; $iptbl_path -A FORWARD -i! $default_interface -s $nat_net -m state --state NEW -j ACCEPT done echo 1 > /proc/sys/net/ipv4/ip_forward else echo 0 > /proc/sys/net/ipv4/ip_forward echo "done."