Ez a fejezet bemutatja, mire van ténylegesen szükséged a csomagszűrés igényeid szerinti felépítéséhez.
4.1 Hogyan keresztezik a csomagok a szűrőket
A kernel a szabályok három listájával kezd, ezeket a listákat hívjuk tűzfal láncoknak, vagy csak szimplán láncoknak. A három láncot inputnak, outputnak, valamint forwardnak hívják. Amikor egy csomag érkezik, mondjuk az Ethernet kártyán keresztül, a kernel az input láncot használja arra, hogy eldöntse a csomag sorsát. Ha a csomag túléli ezt a lépést, akkor a kernel eldönti, hogy a csomaggal mit csináljon (hova küldje, ezt szokás routing-nak hívni). Ha a cél egy másik gép, a kernel a forward lánccal konzultál. Végül, mielőtt még a csomag lelépne, a kernel megbeszéli a dolgot az output lánccal. Egy lánc tulajdonképpen szabályok listája. Minden szabály megmondja: "ha a csomag fejléc ez és ez, akkor itt van mit kell csinálni a csomaggal.". Ha a szabály nem egyezik a csomag fejlécével, a lánc következő szabálya vizsgálja meg a csomagot. Végül, ha nincs több szabály, a kernel megvizsgálja az adott lánc irányelvét (policy), hogy eldöntse mit is tegyen. Egy tudatosan biztonságra törekvő rendszerben ez az irányelv általában megmondja a kernelnek, hogy tagadja meg vagy utasítsa vissza a csomagot.
Az ASCII művészeknek, itt egy kis ábra, hogyan is működik a dolog:
----------------------------------------------------------------
| ACCEPT/ lo interface |
v REDIRECT _______ |
--> C --> S --> ______ --> D --> ~~~~~~~~ -->|forward|----> _______ -->
h a |input | e {Routing } |Chain | |output |ACCEPT
e n |Chain | m {Decision} |_______| --->|Chain |
c i |______| a ~~~~~~~~ | | ->|_______|
k t | s | | | | |
s y | q | v | | |
u | v e v DENY/ | | v
m | DENY/ r Local Process REJECT | | DENY/
| v REJECT a | | | REJECT
| DENY d --------------------- |
v e -----------------------------
DENY
Itt van a leírás lépésről-lépésre:
Ellenőrző összeg (Checksum):
Ez egy teszt arra, hogy a csomag meghibásodott-e valamilyen módon az átvitel során. Ha igen, akkor a csomag megtagadva.
Józanság (Sanity):
Minden lánc előtt van egy ún. 'józansági' teszt, de az input láncé a legfontosabb. Néhány hibás csomag összezavarhatja a szabály ellenőrző kódot, és ezek a csomagok itt vannak kitiltva (ha ez történik, a syslog egy üzenetet generál a log file-ba).
Input lánc (input chasin):
Ez az első tűzfal lánc, ahol a csomagokat teszteli a kernel. Ha a lánc döntése végül nem DENY vagy REJECT, a csomag továbbhalad.
Lefejlécezés (Demasquerade):
Ha a csomag egy válaszüzenet egy előzőleg masquerade-olt csomagra, akkor a csomagot újrafejlécezi a kernel, és átugrik egyenesen az output lánchoz. Ha nem használsz IP Masquerading-ot, képzeletben kitörölheted ezt a részt az ábráról.
Útválasztás (Routing decision):
A csomag célcím mezejét megvizsgálja a kernel útválasztó algoritmusa, hogy eldöntse, a csomag egy helyi processznek (lásd a helyi processzeket lentebb) mehet-e, vagy el kell inkább küldeni (lásd a forwardot lentebb) egy távoli gépnek.
Helyi processzek (local processes):
Egy gépen futó folyamat (processz) az útválasztás után kaphat csomagokat, és küldhet is (amely csomagok szintén átmennek az útválasztáson, azután rátérnek az output láncra).
lo interfész (lo interface):
Ha a csomagok egy helyi folyamattól egy szintén helyi folyamatig kell elmenjenek, átmennek az output láncra a 'lo' nevű interfész segítségével, majd vissza is térnek az input láncon szintén a 'lo' interfésszel. Ezt az interfészt loopback-nek, magyarul visszahurkolási interfésznek hívják.
Helyi (local):
Ha a csomagok nem helyi folyamatok által lettek generálva, akkor a forward lánc lesz megvizsgálva, egyébként a csomagok az output láncra kerülnek.
Forward lánc (forward chain):
Minden csomag áthalad ezen a láncon, amelyek erről a gépről egy másikra kívánkoznak utazni.
Output lánc (output chain):
Minden csomag áthalad itt, amelyek elhagyják ezt a gépet.
Először is, nézd meg, rendelkezel-e azzal a verzióval, amiről ez a dokumentáció beszél.
$ ipchains --version
ipchains 1.3.9, 17-Mar-1999
Mindezek ellenére mi az 1.3.4-et javasoljuk a használatra (aminek nincsenek hosszú opciói, mint pl. '--sport'), vagy pedig az 1.3.8 és felettieket, ezek nagyon biztosak.
Az ipchains-nak eléggé részletes az online dokumentációja (man ipchains), de ha még több információra van szükséged az apró részletekről, megnézheted a programozási interfészt is (man 4 ipfw), vagy pedig a kernel forrásokban lévő /net/ipv4/ip_fw.c nevű állományt (2.1.x kernelek), ami nyilván mértékadó lehet.
Van egy kiváló gyors referenciakártya Scott Bronsontól a forráscsomagban, A4 és US Letter Postscript formátumban.
Van jónéhány dolog, amit az ipchains-al kezdeni tudsz. Először is, egész láncokra vonatkozó műveletek. Alapvetően három beépített lánc van, az input, output és forward, amelyeket nem tudsz kitörölni.
1. Új lánc létrehozása (-N)
2. Üres lánc törlése (-D)
3. Irányelv változtatás a beépített láncokra (-P)
4. A láncban lévő szabályok listázása (-L)
5. A szabályok kitörlése a láncból (-F)
6. Csomag és byte számlálók nullázása az összes szabályra egy adott láncban (-Z)
Szabályok manipulálása egy láncon belül:
1. Új szabály hozzáfűzése a lánchoz (-A)
2. Új szabály beszúrása valahol a láncban (-I)
3. Meglévő szabály cseréje egy új szabállyal valahol a láncban (-R)
4. Szabály törlése a lánc adott pozíciójáról (-D)
5. Az első szabály kitörlése a láncból, ami megegyezik a megadottal (-D)
Néhány művelet a masqueradinghoz:
1. Az éppen aktuális masquerade-olt kapcsolatok listázása (-M -L)
2. A masquerading időtúllépési határának beállítása (-M -S) (de nézd meg: 'Nem tudom beállítani a Masquerading időtúllépéseket!')
Az utolsó (és talán egyben a leghasznosabb) funkció megengedi számodra, hogy megvizsgáld, mi történne egy adott csomaggal ha átmenne egy adott láncon.
Ez az ipchains színe-java, a szabályok manipulálása. Általában a hozzáfűzés (-A) és a törlés (-D) parancsokat fogod használni. A többi (-I, -R) az előző kettő kiterjesztései.
Minden szabály feltételek halmazát határozza meg a csomagok fejléceivel kapcsolatosan, így egy szabály el tudja dönteni (amit ugye mi határozunk meg), hogy mit tegyen, ha a csomag fejléce megegyezik a szabályban specifikált feltételekkel, mi legyen a cél. Például, le szeretnél tiltani minden ICMP típusú csomagot, ami a 127.0.0.1-ről jön. Ebben az esetben szabályunk feltétele az kell legyen, hogy a csomag típusa ICMP legyen, valamint a forráscíme 127.0.0.1. A célunk (target) DENY.
A 127.0.0.1 a visszahurkolási interfész, ami akkor is létezik, ha tényleges hálózati kapcsolat nincsen (pont azért lett kitalálva, hogy akkor is lehessen hálózati szoftvereket írni és tesztelni, ha nincs hálózat). Kipróbálhatod rajta a ping nevű programot, ami csomagokat fog generálni (egyszerűen ICMP 8-as típusú csomagokat (echo-request) fog küldeni, amelyre minden kooperatív hoszt ICMP 0-s típusú csomagokkal fog válaszolni (echo-reply)). Ezzel jól lehet tesztelni:
Látható, hogy az első ping sikeres volt (a -c 1 azt jelenti, hogy csak egy csomagot küldjön a ping, különben nélküle nyomja a világ végéig, vagy amíg leállítod Ctrl+C-vel, esetleg megszakítod Ctrl+Z-vel)# ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.2/0.2 ms # ipchains -A input -s 127.0.0.1 -p icmp -j DENY # ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes
--- 127.0.0.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss
Ezek után befűztünk az input láncba egy új szabályt (-A), amivel meghatároztuk, hogy azt a csomagot, aminek a forráscíme 127.0.0.1 (-s 127.0.01), valamint típusa ICMP (-p icmp), ugrassa a DENY targetre (-j DENY).
A második ping eredménye jól látható, a csomagot megtagadta kernelünk.
Ha szabályt szeretnénk törölni, két módón tehetjük meg. Először is, tudjuk hogy ez az egyetlen szabály az input láncban, így a sorszáma is egyértelmű (1), ezért törölhetjük így:
# ipchains -D input 1 #
A másik módszer a hozzáfűzés tükörképe, csak egyszerűen lecseréljük az A-t D-re:
# ipchains -D input -s 127.0.0.1 -p icmp -j DENY #
A szintaxisnak ugyannak kell lennie, mint a hozzáfűzésnél (vagy -I, -R-nél). Ha több ugyanilyen szintaxisú szabály van, csak az első törlődik a láncból.
Láttuk, hogy a '-p'-vel a csomag protokolltípusát, a '-s'-el pedig a csomag forráscímét határoztuk meg. Van ezen kívül jónéhány opció, amit bevethetünk csomag-meghatározásra a szabályok megadásánál. Következzék a kimerítő részletezés.
A forrás (-s) és cél (-d) IP címeket négy módon határozhatjuk meg. A legegyszerűbb mód, ha a hoszt teljes nevét adjuk meg, mint pl. 'localhost', vagy 'www.linuxhq.com'. A második mód, ha megadjuk a gazdagép IP számát, pl. 127.0.0.1.
A harmadik és negyedik módszerrel IP címcsoportokat határozhatsz meg, mint pl. 199.95.207.0/24', vagy `199.95.207.0/255.255.255.0'. Mindkettő bármilyen IP számot meghatároz 199.95.207.0-tól 199.95.207.255-ig. A '/' utáni számok megmondják, az IP cím mely részei számítanak (/24=24 byte, az ipv4 címek 32 byte-osak). A '/32', vagy a '/255.255.255.255' az alapértelmezés, minden IP számot magukba foglalnak. Ahhoz, minden létező IP-t meghatározzunk, én a következő módszert kedvelem:
# ipchains -A input -s 0/0 -j DENY #
Ez mondjuk így ritkán használatos, mert a fenti szabály hatása ugyanaz, mintha nem adnánk meg a '-s' opciót.
Sok jelzőt, belefoglalva a '-s'-t és a '-d'-t is, megelőzheti egy argumentum, a '!' (jelentése nem, mint a c-ben), és így jelentése megváltozik: azokra az IP-kre érvényes a szabály, amik NEM egyenlők a felkiáltójel után megadottakkal. Például, a '-s ! localhost' minden csomagra vonatkozik, ami nem a lokálhosztról való.
A csomag protokolltípusa a '-p' opcióval határozható meg. Értéke lehet szám (ha tudod fejből az értékeket), vagy sztringek olyan speciális fajtáknál, mint pl 'TCP', 'UDP' vagy 'ICMP'. Kis és nagybetű jelen esetben lényegtelen, szóval 'tcp' ugyanúgy jó, mint 'TCP'. Itt is lehet invertálni, pl: '-p ! tcp'.
Abban az esetben, ha protokollként a tcp-t vagy az udp-t adjuk meg, kitehető némi extra argumentum jelezvén a tcp vagy udp portokat, vagy pedig portok tartományát határozunk meg (de lásd a 'Töredékek kezelését' lentebb). Tartományt a ':' segítségével adhatunk meg, mint pl.: '6000:6010', ami 11 portszámot ad meg, 6000-tól 6010-et is magába foglalva. Ha az alsó határt elhagyjuk, alapértelmezés szerint így az 0 lesz. Ha a felső határt hagyjuk el, az alapból 65535 lesz. Például, ahhoz hogy meghatározzunk tcp kapcsolatokat 1024-es alatti portokon, a szintaxis: '-p tcp -s 0.0.0.0/0 :1023'. Az általános portszámok helyettesíthetőek sztringekkel, például a 80-as az 'www'.
Invertálni tudunk itt is, például ahhoz, hogy meghatározzunk minden tcp csomagot, kivéve ami www: '-p tcp -d 0.0.0.0/0 ! www'.
Fontos, hogy érezzük a különbségeket:
-p tcp -d ! 192.168.1.100 wwwÉs ez:
-p tcp -d 192.168.1.100 ! wwwEz a két utóbbi meghatározás nagyon hasonlít egymásra, pedig teljesen mást jelentenek. Az első meghatároz minden www portra igyekvő csomagot, aminek nem a 192.168.1.100 a célja, míg a második meghatároz minden csomagot, aminek célja a 192.168.1.100, kivéve a www portra igyekvő csomagokat.
Végül, ez meg azt jelenti, hogy se nem www portra, se nem a 192.168.1.100-ra : '-p tcp ! 192.168.1.100 ! www'.
Az icmp protokoll meghatározása szintén lehetővé tesz egy opcionális argumentumot, de vegyük figyelembe, hogy az ICMP-nek nincsen portja, hanem típusa és kódja van. Mást jelentenek.
Sztringekként is megadhatod az icmp típusokat (ipchains -h kilistázza a neveket) a '-s' után, vagy pedig számként a típust és a kódot, ahol a típus követ a '-s'-t, és a kód követi a '-d'-t.
Itt egy kis táblázat az alapvető ICMP csomagokról:
Szám Név Mihez kell 0 echo-reply ping 3 destination-unreachable Bármilyen TCP/UDP forgalomhoz 5 redirect útválasztás, ha nem fut útválasztó démon 8 echo-request ping 11 time-exceeded tracerouteMegjegyezzük, jelen pillanatban ezeket nem lehet invertálni a '!'-al.
NE BLOKKOLJ KI EGYETLENEGY 3-as SZÁMÚ ICMP CSOMAGOT SE! (Lásd az 'ICMP csomagokat' lentebb).
A '-i' opcióval megadhatunk egy interfészt nevét. Egy interfész a fizikai eszköz, amin a csomag be tud jönni, vagy ki tud menni. Az ifconfig paranccsal kilistázhatod az aktív interfészeidet.
A bejövő csomagok interfésze (azaz, a csomagok az input láncon) kerül szóba, amikor bejönnek az interfészen. Logikusan, az output láncra kerülő csomagoknál az az interfész jön szóba, amelyiken a csomagok kimennek. A forward láncon szintén a kimenő csomagok interfésze a mérvadó, kicsit bonyolultra sikerült ez a mondat.
Meg lehet adni olyan interfészt is, ami jelenleg nem 'up', azaz nem él, a szabály nem egyezik addig semmivel, amíg az interfész fel nem jön. Ez rendkívül hasznos pl. betárcsázós interfésznél (ppp0), és hasonlóknál.
Egy speciális jellel, a '+'-al megadhatjuk azt, hogy bármilyen megadott interfészre jó legyen a meghatározás, például a ppp+ az jelent ppp0-t, ppp1-et, ppp2-t stb.
Lehet invertálni is, pl. !ppp+ a meghatározása bármilyen interfésznek, kivéve a ppp interfészeknek.
Néha hasznos lehet a tcp kapcsolatok engedélyezése az egyik irányba, de visszafele nem. Például engedhetsz kapcsolatokat egy külső www szerver felé, attól a szervertől befele pedig nem.
A naív megoldás az lenne, hogy blokkoljuk a felénk érkező tcp csomagokat attól a szervertől, sajnos azonban a tcp kapcsolatok működéséhez mindkét irányban mennie kell a csomagforgalomnak.
A megoldás az, hogy csak azokat a csomagokat blokkoljuk, amelyek a kapcsolat felépítését kérik tőlünk. Ezeket a csomagokat SYN csomagoknak hívják (jó, igazából ezek olyan csomagok, amelyeknek a SYN jelző (flag) be van állítva, a FIN meg az ACK flag-ek pedig nincsenek). Ha csak ezeket a csomagokat blokkoljuk, megállíthatjuk a felénk irányuló kapcsolatok felépítését kérelmező csomagokat.
Ehhez a '-y' opciót kell használni, és csak akkor érvényes, ha tcp protokollt adunk meg mellé. Például ahhoz hogy meghatározzunk kapcsolódási kísérleteket a 192.168.1.1-ről: -p tcp -s 192.168.1.1 -y.
Invertálhatunk itt is, ha pl. fenti meghatározást invertáljuk, az minden kapcsolódási kísérletet meghatároz a 192.168.1.1-en kívül.
Néha egy csomag túl nagy ahhoz, hogy egyszerre beférjen a villamos vezetékbe (a fizikai átviteli vonalra, koax-kábelre, optikai vezetékre, fénykábelre, rádióhullámra, mikrohullámra stb). Ilyen esetekben a csomag több töredékre bontódik, és több, kisebb csomagként küldődik el. A másik végpont összeállítja a csomagokat, hogy megkapja eredményül az eredeti nagy csomagot.
Ezzel az a probléma, hogy a fentebb tárgyalt meghatározásokhoz szükséges az (részletesebben, forrásport, célport, icmp típus, icmp kód vagy tcp syn jelző), hogy a kernel belekukkantson a csomag elejébe, ami viszont csak az első töredékben van meg.
Ha a géped az egyetlenegy kapcsolat a külső hálózat felé, megmondhatod a Linux kernelnek, hogy állítsa össze újra a rajta keresztül haladó csomagokat, ha a kernelbe belefordítod az IP: always defragment: y -t.
Ellenkező esetben fontos megérteni, hogyan bánnak a szűrési szabályok a töredékekkel. Ha egy szabály olyan meghatározási információt tartalmaz, amit a csomag nem, akkor a szabály nem fog ráilleni a csomagra. Ez azt jelenti, hogy az első csomaggal a megfelelő módón bánnak el a szabályok, de azt követő töredékekkel már nem. Ilyenformán egy ilyen meghatározás: -p tcp -s 192.168.1.1 www nem fog ráilleni, csak az első töredékre, de még az inverze sem (-p tcp -s 192.168.1.1 ! www).
Mégis, megadhatsz specifikus szabályokat, direkt a második és a többi töredék kezelésére, a '-f' opcióval. Töredék szabályba azonban nem lehet megadni TCP, UDP portot, ICMP típust, ICMP kódot vagy TCP SYN jelzőt.
Lehet invertálni is.
Általában biztonságosnak tekinthetjük átengedni a második és a további töredékeket, mivel a szűrés hatása az első töredéket érinti, és ilyen módón megakadályozható a töredékek célhoszton való összerakása. Vannak jól ismert hibák, amivel szét lehet ütni egy gépet töredékek küldésével.
Megjegyzés a hálófejűeknek: a hibás csomagok (tcp, udp és icmp csomagok túl rövidek, hogy a tűzfal kód beolvassa a portokat vagy az icmp típust és kódot) szintén töredékként vannak kezelve. Csak a 8-as pozíción kezdődő tcp töredékek lesznek határozottan kidobva a tűzfal kód szerint (ha ilyesmi történik, a syslog üzenetet generál).
Példaként, a következő szabály megtagad bármilyen töredéket, a 192.168.1.1-re:
# ipchains -A output -f -d 192.168.1.1 -j DENY #
Jól van, tudjuk immár a szabályok meghatározási módszereit, hogy illeszkedjenek adott csomagokra, lássuk illeszkedésnél mi történik:
1. Az illeszkedő szabály byte számlálója növekedik a csomag méretével (fejléc + test)
2. A szabály csomagszámlálója növekszik
3. Ha a szabály kéri, a csomag loggolódik.
4. Ha a szabály kéri, a csomag 'szolgáltatás típusa' mezője cserélődik (Type of Service)
5. Ha a szabály kéri, a csomag megjelölődik (a 2.0-s kernelekben nem)
6. A szabály célja (targetje) szerint a tűzfal kód eldönti, mi legyen a csomaggal.
Lássuk fontossági sorrendben.
A cél elmondja a kernelnek, mit csináljon, ha a szabály ráillik a csomagra. Az ipchains erre a '-j' opciót használja (gondolj az ugrásra, jump-to). A cél nevének 8 karakternél kisebbnek kell lennie, és a kis-nagybetű különbség számít (RETURN nem egyenlő return-al).
Legegyszerűbb esetben nincs is cél, ilyenkor a szabályt 'számláló' szabálynak hívjuk, mert nem csinál semmit, csak számlálja az illeszkedő csomagokat. Akár egyezett a szabály, akár nem, a kernel megvizsgálja a következő szabályt a láncban. Például, ha számolni akarjuk a beérkező csomagokat a 192.168.1.1-en, akkor:
# ipchains -A input -s 192.168.1.1 #
Az 'ipchains -L -v' megmutatja a csomag és byte számlálókat mindegyik szabályban az adott láncon.
Hat különböző speciális cél van. Az első három az ACCEPT, REJECT, DENY már egyértelműek (remélem). Az ACCEPT átengedi a csomagot, a DENY megtagadja (a kernel eldobja a csomagot, mintha sosem érkezett volna meg), a REJECT pedig visszautasítja, de (ha nem egy ICMP csomag) generál egy ICMP választ, hogy elmondja a forrásnak: a cél nem elérhető (destination unreachable).
A következő, a MASQ azt mondja a kernelnek, hogy fejlécezze újra a csomagot. Hogy ez működjön, a kernelben benn kell lennie az IP Masquerading kódrészletnek. A részletekért nézd meg az IP-MASQUERADING-HOWTO-t, és a függelékben található 'Különbségek az ipchains és az ipfwadm között' című részt. Ez a cél (MASQ) csak a forward láncon áthaladó csomagokra érvényes.
Egy másik különleges cél az átirányítás (REDIRECT), ami elmondja a kernelnek, hogy a csomagot egy helyi portra küldje ahelyett ahova eredetileg tartott. Ez csak tcp és udp protokoll-meghatározásoknál érvényes. Opcionálisan megadható egy port (név vagy szám) a '-j REDIRECT' után, ami a csomagot erre a portra irányítja, még akkor is, ha másik volt a fejlécben. Ez a cél csak az input láncon áthaladó csomagokra érvényes.
Az utolsó speciális cél a visszatérés (RETURN), ami a lánc végére eséssel azonos (Lásd lentebb az 'Irányelvek beállítását').
Minden más cél egy felhasználó által definiált láncot jelez (ahogy tárgyaljuk a 'Műveletek a teljes láncon' résznél lentebb). A csomag átugrik a másik láncra, és megkezdődik az itt definiált szabályok tesztelése. Ha a lánc nem dönti el a csomag sorsát, akkor egyszer áthalad ezen a láncon a végére, majd visszatér a következő szabályra az előző láncban.
Itt az idő még több ASCII mágiára. Képzeljünk el két (buta) láncot: az input-ot (beépített), és a test-et (felhasználó által definiált).
Képzeljünk el egy tcp csomagot, ami a 192.168.1.1-ról jön és célja az 1.2.3.4. Belép az input láncra, és megkezdődik a tesztelés. Az első szabály: nincs illeszkedés (mert az icmp-re illeszkedik). A második szabály már illeszkedik, és annak célja a Test, ami viszont egy új lánc (mi definiáltuk), így a következő szabály a Test láncban tesztelődik. Itt az első szabály illeszkedik, de nem határoz meg célt, így a következő szabály tesztelődik. Ez viszont nem illeszkedik (mert a cél 1.2.3.4 és nem 192.168.1.1), és elértük a Test lánc végét. Visszatérünk az input láncra, ahol az előbb teszteltük a kettes szabályt, szóval most jöhet a hármas számú, ami szintén nem illeszkedik (mert az meg UDP csomagokra illeszkedne).
A csomag útvonala így:
input lánc --> input lánc.szabály1 --> input lánc.szabály2 --> Test láncra ugrás --> Test lánc.szabály1 --> Test lánc.szabály2 --> Ugrás vissza az input láncra --> input lánc.szabály3 -->
Nézd meg a 'Hogyan rendszerezd a tűzfal szabályaidat' fejezetet ötletekért a jó felhasználáshoz.
Ez egy mellékhatás, amit egy illeszkedő szabály megtehet. Loggolhatod a szabályra illeszkedő csomagot a '-l' opcióval. Valószínűleg a szimpla rutin forgalmat nem akarod loggolni, de hasznos lehet a dolog kivételes esetekben.
A kernel ilyesmit loggol:
'input' 'Test'
------------------------------ -----------------------------
| Szabály1: -p ICMP -j REJECT| | Szabály1: -s 192.168.1.1 |
------------------------------ -----------------------------
| Szabály2: -p TCP -j Test | | Szabály2: -d 192.168.1.1 |
------------------------------ -----------------------------
| Szabály3: -p UDP -j DENY |
------------------------------
Csomagok loggolása
Packet log: input DENY eth0 PROTO=17 192.168.2.1:53 192.168.1.1:1025 L=34 S=0x00 I=18 F=0x0000 T=254
A loggolási információ úgy lett tervezve, hogy tömör, lényegretörő legyen, olyan infókat tartalmaz, ami hasznos lehet a hálózati guruknak, de miért ne lehetne hasznos számunkra is? Lássuk:
1. 'input' a lánc neve, amelyik a loggolást kiváltó szabályt tartalmazza.
2. DENY a célja a szabálynak. Ha ez '-', akkor a szabály nem csinált a csomaggal semmit (számláló szabály).
3. eth0 az interfész neve. Mivel a csomag az input láncról való, ez azt jelenti, hogy a csomag az eth0-ra érkezett.
4. PROTO=17: a csomag protokoll típusa a 17-es számú protokoll. Van egy lista az /etc/protocols file-ban, de a leggyakoribbak az 1 (icmp), 6 (tcp) és 17 (udp).
5. 192.168.2.1:53: A csomag forráscíme a 192.168.2.1, és a forrásport az 53-as. Ha megnézed az /etc/services file-t, láthatod, hogy ez a port a 'domain' port (azaz, a csomag valószínűleg egy DNS válasz). A tcp és udp portokhoz ez a szám a forrásportot jelöli, icmp-hez ez a szám az icmp típusa. Máshoz a szám 65535 lesz.
6. 192.168.1.1:1025: A csomag célcíme a 192.168.1.1, a célport pedig 1025. Az udp és tcp csomagokhoz ez a szám a célportot jelöli, icmp-hez az icmp kódot. Máshoz a szám 65535 lesz.
7. L=34: A csomag 34 byte hosszú.
8. S=0x00: A szolgáltatás típusa mező (Type Of Service), oszd el 4-el, hogy megkapd az ipchains által használt szolgáltatás típusát.
9. I=18: Az IP ID (identification).
10. F=0x0000: a 16 bites töredék offszet plusz jelzők. 0x4-el, vagy 0x5-el kezdődő értékek azt jelentik, ne állítson töredék bitet be. 0x2, vagy 0x3 jelentése: további töredékek jelző beállítva, ezekután több töredék fog következni. A szám nagy része a töredék offszetje, nyolccal osztva.
11. T=254: Életidő a csomagnak (Time to live). Minden ugrópontnál (hop, útválasztó gép) 1 kivonódik ebből a számból, és általában 15-el, vagy 255-el indul.
12. Lehet még egy szám a végén (pl. #5), ez a láncban lévő szabály sorszámát jelzi, ami a loggolást kiváltotta (2.2.9 után).
Linux rendszereken általában ezt a kernel kimenetet általában a klogd nevű démon (kernel logger) kapja el, ami átadja a syslognak (system logging daemon). Az /etc/syslog.cong file-ban kontrollálhatod a syslogd működését azzal, hogy meghatározol célállományokat a szolgáltatásoknak (faclity) (jelenleg a facilty-nk a kernel), és egy szintet (level), az ipchainshoz egy info nevű szintet használunk.
Például, az én (Debian) /etc/syslog.conf file-om két sort tartalmaz, ami illeszkedik a 'kern.info'-ra:
kern.* -/var/log/kern.log
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages
Ez azt jelenti, hogy az üzenetek mind a /var/log/kern.log-ba, mind pedig a /var/log/messages-be bemennek. További infóért olvasd el: man syslog.conf.
Van négy ritkán használt bit az IP fejlécben, amit szolgáltatás típusának hívnak (Type Of Service, TOS). A csomagok lekezelésében fejtik ki hatásukat, a négy bit a 'minimális várakozás' (Minimum Delay), 'maximális teljesítmény' (Maximum Throughput), 'maximális megbízhatóság' (Maximum Reliabilty) és 'minimális költség' (Minimum Cost). Csak ezeket a bitekkel lehet szórakozni. Rob van Nieuwkerk, a TOS kezelő kód szerzője így kommentálja:
Különösen a minimális várakozás fontos számomra. Bekapcsoltam az interaktív csomagjaim számára a Linux routeremen. Egy 33.6k-s modem kapcsolat mögött vagyok. A Linux a csomagokat három sorba rendezi prioritás szerint. Ezzel a módszerrel elfogadható interaktív eredmény kaptam egyidőben történő nagy letöltések esetén is (még jobb lenne az eredmény, ha nem lenne olyan nagy sor a soros driverben).
Nyilvánvalóan nem tudod kontrollálni a bejövő csomagokat (MÁRMINT A TOS-ait), csak a kimenő csomagok kijutási prioritását tudod szabályozni. Hogy megtárgyald a prioritást a másik véggel, használni kell az RSVP nevű protokollt (amiről nem tudok semmit, szóval ne is kérdezd).
A leggyakrabban használatos módszer a telnet és ftp kapcsolatok 'Minimum Delay' és az FTP adat 'Maximum Throughput' szabályozása. Például így:
A '-t' opció két extra paramétert fogad, mindkettőt hexadecimálisan. Így bonyolult megoldásokat is elérhetünk a TOS bitekkel: az első maszk logika ÉS műveletet hajt végre a csomag jelenlegi TOS-án, majd a második maszk logika kizáró vagy (XOR) műveletet hajt végre a módosított TOS-on. Mindez persze túlságosan is bonyolult, csak használd az alábbi táblázatot:
Andi Kleen rámutatott a következőkre:
Szóval, ha modemezel, nézd meg a legnagyobb hasznos értéket a modemes ppp linkre, a dialup szkriptedbe írd be: 'ifconfig $1 txqueuelen', a szám a modem sebességétől és a pufferelésének mennyiségétől függ.
Ez megenged komplex és erőteljes interakciót Alexey Kuznetsov's új Quality of Service implementációjával, valamint a jelölés-alapú továbbítással a 2.1-es kernelek után. Ez az opció a 2.0-ásokban nem szerepel.
Az ipchains egyik nagyon hasznos tulajdonsága, hogy láncokba csoportosíthatjuk az összetartozó szabályokat. Úgy hívhatod a saját láncaidat, ahogyan csak akarod, de nem használhatod új lánc létrehozására a három beépített láncnevet (input, output, forward) és a célneveket (ACCEPT, REJECT, DENY, REDIRECT, MASQ, RETURN). Javallom, a láncnevekhez kisbetűket használj, mint a három beépítetté is ilyen, csak szépségi okokból. A név maximum nyolc karakter hosszú lehet.
Csináljunk egy új láncot. Hívjuk testnek.
Ilyen egyszerű. Most már tudsz szabályokat is belerakni, ahogy fentebb elmagyaráztam.
Szintén egyszerű.
Miért '-X'? Nos, minden jó betű már használva van másra.
Van néhány megszorítás lánc törlésekor: üresnek kell lennie (lásd a 'Lánc kiürítése' részt), és nem szabad egyetlen szabály céljának sem lennie. A három beépített láncot nem tudod kitörölni.
Ezzel a paranccsal kitörölhetjük egy adott láncban az összes létező szabályt.
Ha nem határozol meg láncot, mindegyiket üríti.
Kilistázhatod egy láncban lévő szabályok összességét a '-L opcióval'.
ipchains -A output -p tcp -d 0.0.0.0/0 ftp -t 0x01 0x10
ipchains -A output -p tcp -s 0.0.0.0/0 ftp-data -t 0x01 0x08
TOS Név Érték Tpikus használat
Minimum Delay 0x01 0x10 ftp, telnet
Maximum Throughput 0x01 0x08 ftp-adat
Maximum Reliability 0x01 0x04 snmp
Minimum Cost 0x01 0x02 nntp
Talán hasznos lehet egy referenciát adni az ifconfig txquelen paraméterének, hogy a TOS bitek kitárgyalásra kerüljenek. Az alapértelmezett eszköz sorhossza az ethernet kártyákhoz lett beállítva, a modemeken ez túl hosszú, és a három szalagos időzítő nem fog optimálisan működni. Jó ötlet ezt az értéket 4-10-re állítani a modemeken, vagy a szimpla b csatornás isdn-en, összekapcsolt eszközökön nagyobb érték kell. Ez a 2.0-áknál, és a 2.1-eknél probléma, de a 2.1-ben van egy ifconfig jelző, míg a 2.0-ban forrás patch szükséges az eszközkezelő változtatásához.
Csomag megjelölése
Új lánc létrehozása
# ipchains -N test
#
Lánc törlése
# ipchains -X test
#
Lánc kiürítése
# ipchains -F forward
#
Lánc listázása
# ipchains -L input
Chain input (refcnt = 1): (policy ACCEPT)
target prot opt source destination ports
ACCEPT icmp ----- anywhere anywhere any
# ipchains -L test
Chain test (refcnt = 0):
target prot opt source destination ports
DENY icmp ----- localnet/24 anywhere any
#
A refcnt=0 a test láncban jelzi, hogy nincs egyetlenegy szabály sem sehol, amelynek a célja a test lánc lenne. Ennek nullánnak kell lennie, ha törölni akarsz egy láncot.
Ha elhagyjuk a listázni kívánt lánc nevét, kilistázza az összes lánc szabályait, még az üreseket is.
Van néhány hasznos opció, amit listázásnál alkalmazhatunk. A '-L -n' (numeric) például megóvja az ipchainst attól, hogy lookupoljon az IP címekért, ami így hosszú várakozástól kímél meg bennünket listázás közben. (akkor tart sokáig, ha nincsen rendesen beállítva a DNS, vagy blokkolod a DNS kéréseket). A portokat is számmal írja ki a nevek helyett.
A '-v' opció listázásnál minden részletet kiír a képernyőre (vagy ahova irányítod az outputot), mint például a csomag és byte-számlálókat és a csomag jelzőket. Egyébként ezek elmaradnak. Például:
# ipchains -v -L input Chain input (refcnt = 1): (policy ACCEPT) pkts bytes target prot opt tosa tosx ifname mark source destination ports 10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any
A csomag és byte számlálók elé kerülhet esetleg 'K', 'M', 'G', ekkor az érték 1.000x, 1.000.000x, valamint 1.000.000.000x nagyobb értelemszerűen. A '-x'-el kiírja a számokat, nem számít, milyen nagyok.
Hasznos lehet néha kinullázni a számlálókat. Ezt a '-Z' kapcsolóval tehetjük meg. Például:
# ipchains -v -L input Chain input (refcnt = 1): (policy ACCEPT) pkts bytes target prot opt tosa tosx ifname mark source destination ports 10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any # ipchains -Z input # ipchains -v -L input Chain input (refcnt = 1): (policy ACCEPT) pkts bytes target prot opt tosa tosx ifname mark source destination ports 0 0 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any #Néha lehet, hogy tudni akarod a számláló értékeket azonnal, nullázás előtt. A fenti példában, könnyen meglehet, hogy mialatt listázol, azalatt is generálódik némi forgalom, így hamis értékeket kapsz legközelebb. Hogy ezt elkerüld, használd a listázásást és a törlést egyszerre ('-L -Z'). Sajnos ilyenkor az összes láncon egyszerre történik meg a művelet, egyesével ez nem működik.
# ipchains -L -v -Z Chain input (policy ACCEPT): pkts bytes target prot opt tosa tosx ifname mark source destination ports 10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any Chain forward (refcnt = 1): (policy ACCEPT) Chain output (refcnt = 1): (policy ACCEPT) Chain test (refcnt = 0): 0 0 DENY icmp ----- 0xFF 0x00 ppp0 localnet/24 anywhere any # ipchains -L -v Chain input (policy ACCEPT): pkts bytes target prot opt tosa tosx ifname mark source destination ports 10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any Chain forward (refcnt = 1): (policy ACCEPT) Chain output (refcnt = 1): (policy ACCEPT) Chain test (refcnt = 0): 0 0 DENY icmp ----- 0xFF 0x00 ppp0 localnet/24 anywhere any #
Elmondtuk fentebb, mi történik, ha a csomag elér egy adott lánc végére és még mindig nem volt illeszkedés valami szabályra, tehát a csomagnak még nincs targetje (Ha nem emlékszel, nézd meg még egyszer a 'Cél meghatározása részt'). Ebben az esetben az adott lánc irányelve a mértékadó. Csak és kizárólag a beépített láncok rendelkezhetnek irányelvekkel, mivel ha egy felhasználó által definiált lánc végére ér a csomag, akkor visszaugrik az előző lánc következő szabályára.
Az irányelv az első négy speciális célok valamelyike lehetnek: ACCEPT, DENY, REJECT, MASQ. A MASQ csak a forward láncban érvényes. Fontos még tudni, hogy a RETURN céllal a beépített láncok szabályai valamelyikében explicit módon megcélozhatjuk az adott lánc irányelvét.
Van néhány opció az újra fejlécezéssel kapcsolatban. Ezek az opciók az ipchains programba vannak beépítve, mivel nem akartak külön eszközt írni hozzá (valószínűleg ez meg fog változni).
A fejlécező opció a '-M', és kombinálható a listázással ('-L'), aminek következtében a program kilistázza a jelenlegi fejlécezés alatt álló kapcsolatokat. Van még itt az '-S' is, amivel, amivel a fejlécező paramétereit állíthatjuk.
A '-L' az '-n'-el kitűnően használható, így nem kell sokat várni, míg a program feloldja nekünk az IP címeket nevekké, hanem egyből a címeket listázza.
A '-S'-t három időtúllépési érték követheti, mindegyik másodpercben megadva: tcp kapcsolatokhoz, tcp kapcsolatokhoz a FIN csomag után, valamint az UDP csomagokhoz.
Az alapértelmezett értékek az /usr/linux/include/net/ip_masq.h file-ban találhatóak meg, jelenleg ezek: 15 másodperc, 2 másodperc és 5 másodperc.
Leggyakrabban az elsőt szokták megváltoztatni az FTP miatt (lásd lentebb: 'FTP Rémálmok'). Ha problémáid vannak az időtúllépések állításával, lásd a 'Nem tudom állítani a Masquerading időtúllépéseket!' részt.
Néha jó lenne tesztelni a tűzfaladat, vajon mi történne, ha egy "ilyen és ilyen csomag" érkezne. Ehhez a '-C' opciót használhatod. Az opció után megadhatod, melyik láncot akarod tesztelni. A kernel mindig a beépített láncok egyikén küldi át a csomagot (attól függően, a csomag jön vagy megy), de te kezdheted bármelyik általad definiált lánccal is a tesztelést. A csomag fejléc-illeszkedési részleteit ugyanúgy adhatod meg, ahogy a szabályokat is készíted (forrás ip, cél ip, interfész, protokoll). Ha a protokoll tcp vagy udp, egy darab forrásport vagy célport is megadandó, ha pedig icmp, akkor az icmp típus és kód is (ha csak nem töredéket tesztelsz a '-f'-el, ekkor az előbbiek nem érvényesek).
Ha a protokoll tcp (és a '-f' nincs megadva), akkor a '-y' megadható, jelezve, hogy a tesztcsomag SYN bitje be van kapcsolva.
Itt egy példa egy tcp SYN csomag tesztelésére, ami 192.168.1.1-ről jön a 60000-es portról a 192.168.1.2 www portjára az ethernet interfészre (a 192.168.1.2 ethernetére), amint belép az input láncra (ez egy klasszikus bejövő www request felépítésére vonatkozó kérelem):
# ipchains -C input -p tcp -y -i eth0 -s 192.168.1.1 60000 -d 192.168.1.2 www packet accepted #
Néha egyetlenegy parancssor okozhatja több szabály behatását is. Két módon mehet végbe: Először is, ha megadsz egy hosztnevet, ami több IP címet old fel (DNS-t használva), az ipchains úgy fog viselkedni, mintha több parancsot adtál volna ki a címek minden kombinációjával.
A másik mód az, hogy megkéred az ipchainst, teljesítsen egyszerre több dolgot, használva a kétirányú opciót, a '-b'-t. Ennek hatására az ipchains úgy veszi, mintha kétszer ütötted volna be a parancsot, a második parancsban pedig felcserélted volna a forrás és célmezőket.
# ipchains -b -A forward -j REJECT-s 192.168.1.1 #
Személy szerint én nem szeretem a '-b' kapcsolót, ha kényelemre van szükséged, lásd lentebb az 'Ipchains-save használata'-t.
A '-b' használható a beszúrással ('-I'), törléssel ('-D') (de nem azzal a változattal, amikor sorszámot adsz meg a törlésnél), hozzáfűzéssel ('-A'), és a teszteléssel ('-C').
Egy másik hasznos opció a '-v', ami mindent kiír, amit az ipchains a parancsaid következtében tesz. Például itt, megvizsgáljuk a töredékek viselkedését:
# ipchains -v -b -C input -p tcp -f -s 192.168.1.1 -d 192.168.1.2 -i lo tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.1 -> 192.168.1.2 * -> * packet accepted tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.2 -> 192.168.1.1 * -> * packet accepted #
Van egy betárcsázós PPP kapcsolatom (-i ppp0). Szeretem a news hírcsoportokat (-p tcp -s news.virtual.net.au nntp), és levelezek is (-p tcp -s mail.virtual.net.au pop-3). A Debian FTP szerverét használom arra, hogy rendszeresen frissítsem a gépemet (-p tcp -y -s ftp.debian.org.au ftp-data). Az interneten is szörfözök az Internet szolgáltatóm proxyján keresztül (-p tcp -s proxy.virtual.net.au 8080), viszont utálom azokat a reklámokat a doubleclick.net-ről a Dilbert archívumoknál (-p tcp -y -d 199.95.207.0/24 és -p tcp -y -d 199.95.208.0/24).
Nem bánom, ha be-ftp-znek hozzám amíg online vagyok (-p tcp -d $IPCIMEM), de nem akarom, hogy valaki kívülről olyan IP-vel próbáljon csomagot küldeni, amilyen a lokális hálózatom kiosztása (-s 192.168.1.0/24). Ezt úgy hívják, hogy IP spoofing (nem tudom lefordítani, sajnálom), van viszont sokkal jobb módszer ennek kivédésére, lásd a 'Hogyan állítsak be IP spoofing ellen védelmet?' részt.
Ez a felállás elég egyszerű, mert most nincs több gépem a belső hálómon, csak ez az egy.
Nem akarom, hogy akármilyen helyi folyamat (Netscape, lynx stb) kapcsolatot létesítsen a doubleclick.net-tel:
# ipchains -A output -d 199.95.207.0/24 -j REJECT # ipchains -A output -d 199.95.208.0/24 -j REJECT #
Most, némi elsőbbségeket akarok kialakítani a különböző kifele haladó csomagok között (a bejövőkkel nem tudok mit csinálni ilyen téren). Mivel van jónéhány ilyen szabályom, jó ötlet külön láncba tenni őket, hívjuk a láncot mondjuk 'ppp-out'-nak.
# ipchains -N ppp-out # ipchains -A output -i ppp0 -j ppp-out #
Minimális várakozás a web forgalomnak és a telnetnek:
# ipchains -A ppp-out -p TCP -d proxy.virtual.net.au 8080 -t 0x01 0x10 # ipchains -A ppp-out -p TCP -d 0.0.0.0 telnet -t 0x01 0x10 #
Alacsony költség az ftp adatnak, nntp-nek (news) és a pop-3-nak:
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 ftp-data -t 0x01 0x02 # ipchains -A ppp-out -p TCP -d 0.0.0.0/0 nntp -t 0x01 0x02 # ipchains -A ppp-out -p TCP -d 0.0.0.0/0 pop-3 -t 0x01 0x02 #
Van egy kevés megszorítás a ppp0-ra érkező csomagoknak: csináljunk egy láncot, amit hívjunk 'ppp-in'-nek:
# ipchains -N ppp-in # ipchains -A input -i ppp0 -j ppp-in #
Most, nem jöhet csomag a ppp0-ra olyan forrással, hogy 192.168.1.*, szóval ezeket kitiltom és loggolom:
# ipchains -A ppp-in -s 192.168.1.0/24 -l -j DENY #
Az udp csomagokat megengedem a DNS lekérdezésekhez (egy cache-elő névszervert futtatok, ami minden kérést a 203.29.16.1-re továbbít, szóval onnan csak DNS válaszokat várok), a bejövő ftp kapcsolatokat és csak a kimenő ftp-adatot (ami csak az 1023 feletti portokat használja, és nem pedig a 6000 körül X11 portokat).
# ipchains -A ppp-in -p UDP -s 203.29.16.1 -d $LOCALIP dns -j ACCEPT # ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 1024:5999 -j ACCEPT # ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 6010: -j ACCEPT # ipchains -A ppp-in -p TCP -d $LOCALIP ftp -j ACCEPT #
Végül, a helyi forgalmat engedélyezem:
# ipchains -A input -i lo -j ACCEPT #
Most az alapértelmezett irányelvem az input láncon DENY, szóval minden más mehet a levesbe:
# ipchains -P input DENY #
Megjegyzés: Nem ebben a sorrendben állítanám be a láncaimat, mivel csomagok átjuthatnak akkor is, miközben konfigurálok. A legbiztosabb mód, ha először az alapértelmezett irányelvet DENY-re rakom, majd beillesztem a szabályokat. Persze, ha a szabályoknak DNS lookupokat kell kérniük a hosztnevek feloldásához, bajban lehetsz.
Felállítani a lánc-szabályokat, majd legközelebb is emlékezni rájuk igen fájdalmas dolog.
Az ipchains-save nevű szkripttel beolvashatod a lánc-beállításokat, és kimentheted őket egy file-ba. Most még bizonytalanságban hagylak, és nem árulom el, vajon mire is jó az ipchains-restore nevű szkript…
Az ipchains-save kimenthet egy láncot, de akár az összest is egyszerre (ha nem adtál meg láncnevet paraméterként). Az egyetlen jelenleg működő opció a '-v', ami a szabályokat kinyomtatja az stderr-re, miközben ment. A három beépített lánc irányelve szintén mentődik.
# ipchains-save > my_firewall Saving `input'. Saving `output'. Saving `forward'. Saving `ppp-in'. Saving `ppp-out'. #
Az ipchains-restore használata
Az ipchains-restore visszaállítja a láncokat, amit az ipchains-save-el előzőleg elmentettél. Két opciót adhatsz neki: A '-v', ami kiír minden szabályt, amit a program beállít, valamint a '-f', ami kiüríti a már benn levő felhasználó által definiált láncokat, ha léteznek (lentebb az info).
Ha egy felhasználó által definiált lánc a bemenet, az ipchains-restore megnézi, hogy a kernelben van-e már ilyen nevű lánc. Ha igen, akkor a program jelzi számodra, hogy a bennt levő láncban ki fogja törölni az összes szabályt, vagy esetleg hagyja-e a fenébe a visszaállítást.
Például:
# ipchains-restore < my_firewall Restoring `input'. Restoring `output'. Restoring `forward'. Restoring `ppp-in'. Chain `ppp-in' already exists. Skip or flush? [S/f]? s Skipping `ppp-in'. Restoring `ppp-out'. Chain `ppp-out' already exists. Skip or flush? [S/f]? f Flushing `ppp-out'. #