Eelmises artiklis rääkisime ühest Linuxi keskkonna paketifiltrist - ipchains. Kui kasutusel on juba 2.4 versiooni kernel, pole selle kasutamine aga enam mõttekas. Uuem paketifilter netfilter koos kasutajaliidesega iptables pakub palju suuremaid võimalusi. Kuigi enamustel puhkudel on ipchainsi funktsionaalsus piisav, on tal ka olulisi puudusi. Kaks kõige olulisemat on laiendusvõimaluste puudumine ning suutmatus eristada pakette, millega luuakse ühendusi, pakettidest, mis on seotud juba loodud ühendustega. Mõlemad probleemid on netfilter’is lahendatud. Ka on netfilter’i disain tunduvalt lihtsam ipchains’i omast. Samas on püütud vältida mõttetuid muutusi kasutajaliideses. Enamus ipcahins’i ja iptables’i käsurea võtmetest teeb täpselt sama asja. Seetõttu ei hakka ma siin kordama seda, mida käsitles eelmises numbris ilmunud artikkel “Linuxiga tulemüürimas 1”. Vaatame ainult olulisemaid muudatusi ipchains’iga võrreldes. Nimekiri neist muutustest, mida ühelt teisele üle minnes silmas pidada tuleb, on toodud ka “Linux 2.4 Packet Filtering HOWTO” dokumendi (vt. viidad) 10. peatükis.

Enne kui läheme konkreetsete käskude ja võimaluste juurde, tuleb selgeks teha üks asi - paketi teekond läbi netfilter’i ahelate (chains) erineb oluliselt paketi teekonnast läbi ipchains’i ahelate. Ipcains’is läbib masinasse sisenev pakett igal juhul INPUT ahela, olgu siis tegemist edastatava või masinale endale määratud paketiga. Sama moodi läbivad kõik paketid ka OUTPUT ahela. See ei ole aga hea kuna edastatavate pakettide filtreerimisel tuleb jälgida kõigi kolme ahela reegleid.

Paketi teekond netfilter’i ahelates on toodud joonisel 1. Nagu näha läbivad lokaalsele masinale määratud paketid sisenedes ainult INPUT ahela, lokaalsest masinast väljuvad paketid ainult OUTPUT ahela ning edastatavad paketid ainult FORWARD ahela. Selline struktuur teeb filtrite kirjutamise enamasti palju lihtsamaks. Samas on tegu ühe suurima segaduste allikaga ipcainsilt üle minemisel.

Joonis 1.

Ipchains’iga võrreldes on lisandunud kaks ahelat - PREROUTING ja POSTROUTING. Mõlemad on põhiliselt kasutusel NAT’i (Network Address Translation) tegemiseks ning filtreerimist nendes ei tehta. Iga ahel koosneb tabelitest. Selle artikli piires kasutame INPUT, OUTPUT ja FORWARD ahelate tabelit filter ning PREROUTING ja POSTROUTING ahelate tabelit nat. Võimalusi on loomulikult rohkem, kuid neid me siin käsitleda ei jõua. Vaikimisi tabeliks on filter, nii et seda igal filtreerimise real eraldi ütlema ei pea.

Tavakasutajate enamusele on tähtsaim uuendus ipchainsiga võrreldes muidugi võimalus jälgida pakettide olekut. Kas paketiga üritatakse luua uut ühendust või kuulub see juba loodud ühenduse koosseisu? Netfilter võimaldabki neil vahet teha lihtsustades nii filtrite kirjutamist. Pole enam mingit vajadust uurida järgi mis portidel teenused masinas jooksevad. Võimalikke olekuid on õigupoolest neli.

• NEW - Paketiga üritatakse luua uut ühendust.
• ESTABLISHED - Pakett kuulub juba loodud ühenduse koosseisu.
• RELATED - Pakett on seotud juba loodud ühendusega. Siia kuuluvad näiteks juba loodud ühendusega seotud ICMP veateated.
• INVALID - Pakett pole ühegi eelenvalt toodud olekuga. Ilmselt on tegemist vigase paketiga, mis on ohutum ära visata.

Näiteks toome ühe lihtsa reeglistiku dialup ühendusega masinale. Selline reeglistik peaks töötama iga 2.4 kerneli peal töötava Linuxiga ning on täiesti piisav kaitsmaks üksikut arvutit kuna blokeerib kõik väljastpoolt tulevad ühenduse loomise katsed. Reeglistik on toodud joonisel 2.

Joonis 2.

Kõigepealt lubatakse pakettide edastamine ning visatakse minema kõik vanad reeglid ning ahelad. Laaditakse ka ühenduse jälgimise moodulid. Kuna samad reeglid kehtestame nii INPUT kui ka FORWARD ahelale, teeme ise uue ahela - block (-N block).

Kolmes järgmises reas tehaksegi kogu filtreerimine. Pakette filtreeritakse oleku järgi (-m state) ning kõik paketid, mis kuuluvad juba loodud ühenduse juurde või on sellega seotud (–state ESTABLISHED,RELATED) lubatakse läbi (-j ACCEPT). Samuti lubatakse läbi kõik paketid, mis algatavad küll ühendust (–state NEW), aga ei tule võrguliideselt ppp0 (-i ! ppp0). Ülejäänud paketid visatakse minema (-j DROP). DROP on sama, mis ipchains’i puhul oli DENY. Viimasena seome omaloodud ahela nii INUPT kui ka FORWARD ahelaga.

NAT’i on võimalik netilter’is teha PREROUTING ja POSTROUTING ahelates. Kummas siis neist? PREROUTING ahelas tehakse sihtaadressi transleerimist (Destination NAT e. DNAT) ja POSTROUTING ahelas lähteaadressi transleerimist (Source NAT e. SNAT). SNAT on tuntud ka maskeraadina. Seega pole NAT ja maskeraad sünonüümid vaid maskeraad on ainult üks NAT’i alaliik. Vaatame mõningaid juhtusid, kus NAT’i kasutada.

Levinuim on kindlasti maskeraad. Oletame, et soovime privaatvõrgu aadressitega LAN’is asuvatele arvutitele ka ühendust pakkuda. Skriptile on sel juhul vaja lisada ainult üks rida:

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

POSTROUTING ahela tabelisse nat (-t nat -A POSTROUTING) lisatakse reegel, mis maskeerib ära (-j MASQUERADE) võrguliideselt ppp0 väljuvad paketid (-o ppp0). Viisakas oleks skripti algusesse ka lisada rida:

iptables --table nat --flush

nat tabeli puhastamiseks. Ning ongi kõik. Milleks kasutatakse aga sihtaadressi transleerimist? Oletame, et meil on interneti püsiühendus ühe avaliku IP aadressiga. Samas tahaks aga veebiserverit üles panna ning tulemüür pole just kõige õigem koht selle jaoks. Võimalus on server panna privaataadressiga sisevõrku ning suunata kogu 80 pordile tulev liiklus sellele aadressile. Vastav rida näeks välja umbes järgmine:

iptables -t nat -A PREROUTING -i eth0 -p tcp -dport www -j DNAT --to-dest 192.168.0.3

PREROUTING ahela nat tabelisse lisatakse reegel, mis suunab eth0 liideselt porti 80 siseneva tcp liikluse (-i eth0 -p tcp -dport www) sisevõrgu aadressile 192.168.0.3 (–to-dest 192.168.0.3). Välisvõrgus asuvad kliendid sisestavad brauserisse ikka selle ainsa avaliku aadressi, tegelikult serveerib aga veebi sisevõrgus asuv privaataadressiga server.

Sellist suunamist on võimalik teha ka ühe arvuti piires. Oletame, et oleme üles seadnud proxy serveri ning ei soovi, et sisevõrgu kasutajad saaksid sellest mööda minna. Üks võimalus on seadistada kõik arvutid proxy’t kasutama, kuid sama efekti annab ka üks iptables’i rida.

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport www -j REDIRECT --to-port 8080

Selle reaga suunatakse kõik liideselt eth1 porti 80 sisenev tcp liiklus ümber porti 8080, kus kuulab ühendusi nt. squid või mõni muu proxy server.

ICMP on protokoll, mille abil edastavad võrgus olevad seadmed üksteisele teateid. Mitte kõik neist pole aga vajalikud. Netfilter võimaldab ka ICMP teateid filtreerida nende tüübi järgi. Lisaks pakub netfilter võimalust limiteerida pakettide hulka ajaühikus. Näiteks flood pingi (hästi palju ICMP Echo Request pakette ajaühikus) vastu on see päris abiks.

iptables -A INPUT -p ICMP --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -A INPUT -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT

Esimese reaga lubatakse läbi Echo Request tüüpi ICMP paketid (-p ICMP –icmp-type echo-request), kuid ainult üks sekundis (-m limit –limit 1/s). Teise reaga lubatakse läbi ka ICMP paketid tüübiga 11. ICMP pakettide täieliku nimekirja leiab näiteks viitades toodud “Iptables tutorial” dokumendist.

Ka logimist on netfilter’is täiustatud. Kui ipchinsi puhul tehti logimist mitme reegliga, kippus logide analüüsimine mõnevõrra raske olema. Netfilteri puhul saab kontrollida ka seda, mida konkreetselt logisse kirjutatakse. Näiteks:

iptables -I INPUT -p tcp --destination-port 6667 -j LOG --log-prefix "IRC: "
iptables -I INPUT -p tcp --destination-port 6667 -j DROP

Esimese reaga kirjutatakse iga IRC serveri porti ühenduse loomise ürituse peale rida logisse, kuid iga rea ette kirjutatakse veel string “IRC: “. Selliselt saadud logi on tunduval lihtsam analüüsida.

Käesolevas artiklis vaadeldu on ainult murdosa netfilter’i võimalustest. Näiteks on võimalik masinast väljuvaid pakette filtreerida ka selle järgi mis kasutajale vastav protsess kuulub, ka on olemas võimalus terve paketi päise ümber kirjutamiseks jpm. Ja kui ka sellest väheseks jääb, võib igaüks luua suhteliselt lihtsa vaevaga uusi mooduleid. See eeldab muidugi juba programmeerimisoskust. Kasutajate enamus ilmselt kõike seda siiski ei vaja. Netfilter’i edasiseks uurimiseks soovitan kõigepealt vaadata viitades toodud dokumente. Need peaks andma piisavalt infot ka keeruliste tulemüüride ehitamiseks. Võrgus on liikvel ka päris palju vahendeid tulemüüri reeglite automaatseks genereerimiseks ning universaalseid reeglistikke. Ma ei soovita neid siiski kasutada. Kui kasutada, siis ainult õppimiseks. Esiteks lisavad sellised skriptid reeglitesse palju mõttetuid ridu kuna püüüavad universaalsed olla. Teiseks ei pääse te niikuinii iga rea endale selgeks tegemisest. Ilma arusaamiseta sellest, mida iga rida teie tulemüüri filtrites teeb, saavutate paremal juhul ainult võltsturvatunde. Rahulikult saate magada ainult siis kui teate täpselt, mida teie tulemüür teeb.

Netfilter’i kodulehekülg - http://www.netfilter.org
Linux 2.4 Packet filtering HOWTO - http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html
Iptables tutorial - http://www.boingworld.com/workshops/linux/iptables-tutorial/iptables-tutorial/iptables-tutorial.html