Eelmistes numbrites oleme vaadelnud mõningaid Linuxi distributsioone, mis on sobivad koduse ruuteri/tulemüüri ehitamiseks - Coyote, Smoothwall, E-Smith. Paraku ei saa kõik endale selleks otstarbeks eraldi arvutit lubada.

Selles ja järgnevas püüangi selgitada kuidas tavalises töölaua arvutina kasutatavas Linuxis tulemüüri teha. Võimalused selleks on kõigis Linuxi distributsioonides olemas. Kõigepealt peame rääkima natuke teooriast - kuidas toimivad ühendused arvutite vahel ning mis me selle teadmisega peale hakkame. Selles numbris vaatame veel kuidas kasutada vanemat tulemüüri tegemise võimalust - ipchains. Järgmises numbris tutvustame aga uuemat ning võimsamat netfilter’it koos selle kastajaliidese iptables’iga.

Kõigepealt sellest, mis asi on üldse tulemüür. Lühidalt on tulemüür lahenduste kompleks, mis kaitseb omaniku võrku kõrvaliste isikute sissetungide eest. Üks täisväärtuslik tulemüür oskab teha kõike sellega seonduvat - filtreerida pakette, luua turvalisi ühendusi üle avaliku võrgu, takistada ka sisevõrgus olijatel teha midagi lubamatut üksteise või teiste Internetis olevate arvutite vastu ja palju muud. Vahendid kõigeks selleks on Linuxis olemas, kuid olulisim on nendest üks - paketifilter ning seda me hakkamegi lähemalt vaatlema. Selleks, et aru saada kuidas paketifilter toimib, peame kõigepealt vaatama kuidas toimivad üldse IP ühendused. Kõige lihtsam on seda teha veebi näitel.

Internetis kasutatava protokollivirna võib jagada tinglikult neljaks kihiks nagu näha joonisel 1. Mis juhtub kui kasutaja sisestab brauserisse URL‘i ja vajutab enter klahvi? Vastaval aadressil olevale serverile esitatakse päring ja see saadab vastuse brauserile tagasi? Jah, seda küll, aga meid huvitab see protsess täpsemalt.

Joonis 1.

Rakenduse kihist (brauser) antakse pakett andmeid (päring veebiserverile) transpordikihile. Transpordikihis lisatakse paketile TCP päis, kus on kirjas lähteport ja sihtport ning veel hulk andmeid, mis on vajalikud andmete transportimiseks. Edasi läheb pakett IP kihi kätte, mis lisab sellele omakorda IP päise, kus olulisemate asjadena on kirjas lähteaadress ja sihtaadress. Seejärel lisab oma päise paketile veel füüsiline kiht (kus on kirjas just selle kihi toimimiseks vajalikud andmed - Etherneti puhul nt. MAC aadressid jms) ning alles peale seda väljuvad andmed kliendi masinast. Esimene ruuter, mis teel serverini paketi saab, eemaldab sellelt füüsilise kihi päise, vaatab IP päisest (sihtaadress) kuhu pakett minema peab, lisab uue füüsilise kihi päise ning saadab edasi. Füüsilise kihi andmed jõuavad nii ilmselt mitu korda muutuda enne kuni andmed serverini jõuavad. Serveris eemaldatakse kõigepealt füüsilise kihi päis ning antakse andmed ruutimise kihile. Kui sihtaadressiks on tõesti serveri aadress, eemaldatakse ruutimise kihi andmed ning antakse järg edasi transpordikihile. Transpordikiht eemaldab samuti enda kihi päise ning annab vastavalt sihtpordile andmed edasi rakendusele (veebiserver). Veebiserveri vastus läbib sama tee ainult vastupidises suunas.

See on küll mõnevõrra lihtsustatud selgitus, kuid piisav, et võrgus toimivast pilt saada. Võib tekkida aga küsimus, mis asi on port? Masin, mis on võrgus, tegeleb tõenäoliselt paljude ühendustega korraga. Et nende ühenduste andmed omavahel segi ei läheks, ongi olemas pordid. Ühendus kliendi ja serveri vahel luuakse alati mingist pordist mingisse porti. Just tänu sellele, et paketis on kirjas sihtport, teab serveri transpordikiht missugusele teenusele serveris andmed anda ning tänu lähtepordile teab ka kuhu vastus tagasi saata. TCP ja UDP puhul on porte 65535. Meie veebi näitel valitakse kliendi masinas suvaline port, mida hetkel muuks ei kasutata (mingiks muuks ühenduseks ja kus ei kuula mõni kliendi masinas olev teenust pakkuv rakendus) ja mille number on suurem kui 1024 (nt. 21912) ning saadetakse päring serverisse porti 80, mis on traditsiooniliselt port, kus “kuulab” veebiserver. Pordid 1 - 1024 on reserveeritud olulisematele serveritele ning neid väljuvate ühenduste puhul üldjuhul ei kasutata. Nimekiri olulisematele teenustele määratud portidest on unixilaadsetes süsteemides /etc/services failis.

Sugugi mitte kõik rakenduste protokollid ei ole aga nii lihtsad. Näiteks ftp puhul kasutatakse kahte ühendust. Ühte kliendi suvalisest pordist serveri porti 21 ühenduse juhtmiseks ning teist serveri pordist 20 kliendi suvalisse porti andmete reaalseks liigutamiseks. Seetõttu ongi vaja tulemüüri konfigureerijal vaja küllalt põhjalikke teadmisi, kuidas konkreetsed protokollid toimivad. Ineternetis toimuvast põhjalikuma ülevaate saamiseks soovitan lugeda dokumenti “Linux Networking-concepts HOWTO”, mis lahkab neid küsimusi märksa põhjalikumalt kui mina siin artikli raames suudaksin.

Kuid paketifiltri konfigureerimiseks olulisim peaks olema selge - liiklus võrgus toimib pakettidena ja igas paketis on kirjas lähteaadress, sihtaadress, lähteport ning sihtport. Põhiline osa tulemüüri konfimisest ongi vastamine sellistele küsimustele - kui tuleb sellisest võrgust pakett, millel on sellised lähteaadress, sihtport jne. ning mille protokoll on selline siis mis selle paketiga peale hakata? Lasta see läbi või visata ära? Nende baasteadmistega saame juba päris korraliku tulemüüri püsti panna.

Linuxis on aegade jooksul olnud kasutuses mitu paketifiltri mehanismi. Kerneli versioonis 2.0 oli selleks ipwf ning kasutajaliideseks ipwfadm. Kuna nii vana kernelit enam keegi loodetavasti ei kasuta, ei hakka siin selle kasutamist ka vaatama.

Ipfw’i vahetas 2.2 kernelis välja ipchains. Seda kasutatakse siiani laialdaselt. Ka Coyote, Smoothwall ning E-Smith kasutavad 2.2 kernelit ja ipchains’i. Ühilduvuse huvides on ka 2.4 kernelis selle tugi säilitatud ning seega on kõik järgnev kasutatav ka uusimate distributsioonidega.

Ipchains paketifilter on rida reegleid (rule), millega iga paketti võrreldakse. Kas pakett rahuldab reeglis toodud tingimusi? Kui jah siis mida sellega teha? Kui ei, vaadatakse järgmist reeglit ja nii kuni viimaseni välja. Kui pakett ei rahuldanud ühegi reegli tingimusi, rakendatakse sellele vaikereeglit.

Reeglid on omakorda jagatud ahelatesse (chain). Süsteemselt on olemas kolm ahelat - INPUT sisenevatele pakettidele, OUTPUT väljuvatele pakettidele ning FORWARD masinast läbi käivatele pakettidele. Ahelaid on võimalik ka ise juurde teha, kuid seda me käesolevas artiklis vaatama ei hakka.

Ipchains’i konfigureerimine käib käsuga ipchains. Enamasti on käsu süntaks lihtsustatult järgmine:

ipchains [käsk] [võtmed] [siht]

Olulisemad käsud, võtmed ja sihid (target või policy) on toodud joonisel 2.

Joonis 2.

Kuigi paketifiltrit on võimalik ehitada ja hallata ka käsurealt ükshaaval käske sisestades (reegleid lisades, kustutades, asendades jne.), on tulemüüri sel viisil kontrolli all hoidmine päris raske. Tunduvalt lihtsam on kirjutada üks skript, kus reeglid järjest olemas ja seda siis käivitada. Vajaduse korral on lihtne seda muuta ning uuesti käima lasta. Ka ülevaade tulemüüri reeglitest on sel juhul tunduvalt parem.

Peaaegu alati on kõige lihtsam viis midagi selgeks teha tuues mõni näide. Võtame ette konkreetse olukorra. Kodus on Linuxiga arvuti, millel on dialup interneti ühendus (liides ppp0). On olemas ka teine arvuti (või ka mitu), mis on ühendatud Linuxiga masinaga Ethernet võrgukaardi kaudu (liides eth0). Sisemises võrgus on kasutusel võrk 192.168.1.0 maskiga 255.255.255.0. Soovitud olukord oleks, et Linux jagaks teis(t)ele arvuti(te)le interneti ühendust ning kaitseks nii iseennast kui teisi väljast tulevate rünnakute eest. Et asja natuke keerulisemaks ajada, on tingimuseks veel see, et Internetis asuvast arvutist IP aadressiga 123.45.67.89 peab olema võimalik Linuxiga arvutisse ssh protokolli kasutades sisse logida.

Vastav skript on toodud joonisel 3. Reanumbrid on lisatud ainult selleks, et lihtsam seletada oleks. Skripti kasutades peate need muidugi eemaldama.

Joonis 3.

Esimene ja kolmas rida ei ole tegelikult ipchainsiga seotud. Esimene rida ütleb, et tegemist on shelli skriptiga, mille käivitamiseks kasutatakse shelli /bin/sh (kui skript on käivitatav saab teda sama moodi käivitada nagu iga teist käsku). Kolmas rida on IP pakettide edastamise sisse lülitamiseks. Vaikimisi on see keelatud ning ühe võrguliidesega arvutil polegi seda vaja sisse lülitada.

Read 5-6. Kustutatakse kõik reeglid kõikidest ahelatest ning eemaldatakse kõik kasutaja poolt loodud ahelad.

Read 8-10. Seatakse ahelatele vaikereeglid. Sisenevatele ja edastatavatele pakettidele REJECT ja väljuvatele pakettidele ACCEPT kuna väljuvaid ühendusi me piirata ei taha.

Read 12-13. Lisatakse (-A) sisenevate ühenduste ahelasse (input) reegel, mis laseb läbi (-j ACCEPT) kõik paketid, mis tulevad loopback liideselt (-i lo). See on vajalik nt. fontserveri ja logimise toimimiseks lokaalses masinas. Sama tehakse ka sisevõrgust tulevate pakettidega kuna nende piiramine pole samuti meie eesmärk.

Read 15-20. Siin pannakse paika tulemüüri põhiosa. Kuna me teame, et väljuvaid ühendusi ei tehta madalamatelt portidelt kui 1024, siis ei pea me nendega midagi ette võtma kuna vaikereegliks on REJECT. Et aga vastused seestpoolt algatatud ühendustele saaksid tagasi tulla, peame lubama interneti liideselt sisse tulevad paketid, mille sihtport on kõrgem kui 1024. Aga mis siis saab kui meie Linuxi masinas on mõni server kuulamas mõnel kõrgemal pordil? Tüüpilisteks näideteks on fontserver, mille port on tavaliselt 7100 ja X-Window süsteem, mis kasutab porte 6000-6009. Sel juhul tuleb nendele portidele sisenev liiklus keelata ENNE kui lubada kogu portide vahemikule 1024-65535 sisenev.

Vastupidiselt levinud arvamusele ei saa arvutisse tungida suvaliste portide kaudu vaid ainult nende kaudu, kus mõni teenus “kuulab”. Kui siseneb pakett, mille sihtpordil ühtegi teenust ei kuula, visatakse see niikuinii minema, sest transpordikihil pole seda kellelegi anda - pole rakendust, mis seda porti kuulaks. Kuidas aga teada saada, mis teenused kohalikus masinas töötavad ja mis porte nad kuulavad? Kõige lihtsam on seda teha käsuga netstat -tuan. Joonisel 4. on toodud näiteks selle käsu väljund.

Joonis 4.

Konkreetne arvuti kuulab (olek LISTEN) tcp ühendusi portidel 21, 22, 631, 25, 7100 ja 9812 ning udp ühendusi portidel 2049, 9813 ja 9814. Kõigepealt tuleks vaadata, kas need teenused on ikka vajalikud. Antud juhul tuli välja, et portidel 9812-9814 kuulav teenus pole seda ning see võeti üldse arvutist maha. Küll aga ei käinud käsu andmise hetkel X Window süsteem, mida aegajalt ikka käivitatakse. Kõrvalepõikena tuleb mainida küll seda, et lokaalses masinas X’i toimimiseks ei pea ta sugugi väljast tulevaid ühendusi kuulama.

Niisiis keelame reas 15 sisenevad udp (-p udp) ühendused porti (–destination-port) 2049, reas 16 tcp (-p tcp) ühendused portide vahemikule 6000-6009 ja reas 17 tcp ühendused pordile 7100. Alles seejärel lubame ühendused portide vahemikule 1024-65535 nii udp kui tcp protokollile.

Kui nüüd tuleb sisse pakett pordile 6000, jõutakse kontrollimisega reani 16 ning kuna pakett rahuldab reeglis toodud tingimusi, visatakse see minema ning edasised reegleid ei vaadatagi.

Rida 22. Selles reas lubatakse sisse kõik paketid, mille lähteaadressiks on 123.45.67.89 ning sihtpordiks 22. Seega saab sellelt aadressilt Linuxi masinasse ssh’ga sisse logida.

Rida 24. Lubatakse sisse kõik icmp protokolli paketid. Kiputakse arvama, et icmp on vajalik ainult pingimiseks ning püütakse see kinni keerata, kuid icmp on hoopis rohkemat. ICMP on Internet Control Message Protocol ning mõnede icmp pakettidega edastatakse väga olulist ühendusega seotud infot. Seega, kui te ei taha, et ühendus kannataks, on hea mõte icmp läbi lasta. Icmp pakette on võimalik filtreerida ka nende tüübi järgi, kuid sellest vast järgmine kord ning siis juba netfilter’iga seoses.

Rida 26. Kui sisse tulnud pakett ei ole seni rahuldanud üheski reeglis toodud tingimusi, kirjutatakse selle kohta rida logisse (-l), milleks on tavaliselt fail /var/log/messages ning rakendatakse vaikereeglit (mis on REJECT).

Read 28-29. Need read on pakettide edastamiseks sisevõrgust (so. ühenduse jagamiseks teistele arvutitele). Kõik paketid, mis tulevad võrgust 192.168.1.0/24 maskeeritakse liidesele ppp0 st. saadetakse internetti, kuid lähteaadressiks on siis juba ppp0 liidese aadress. Kui mingil põhjusel peaks kuskilt tulema pakett, mis peaks kah edastatama, kuid mille lähteaadress pole võrgust 192.168.1.0/24, kirjutatakse rida tema kohta logisse ning rakendatakse talle vaikereeglit - REJECT.

Sellega ongi meil olemas suhteliselt lihtne kuid tõhus tulemüür. Skripti edasisel täiendamisel on kindlasti parimaks abiliseks käsk man ipchains. Kuidas seda skripti nt. interneti ühenduse püsti tõstmisel automaatselt käivitada, jääb igaühe enda välja mõelda.

Ipchans’i momendil kehtivat reeglistikku on võimalik vaadata käsuga ipchains -L. Kuna selle väljund on liigagi lakooniline, võite lisada veel võtme -v.

Ipchains’i toimimiseks peab kernelis selle tugi sees olema. Kui see on kompileeritud moodulina, tuleb moodul enne skripti käivitamist laadida käsuga modprobe ipchains. Et sisevõrgust oleks võimalik kasutada ftp, icq ja irc teenuseid, peavad olema laetud ka vastavad maskeraadi moodulid - ip_masq_ftp, ip_masq_icq ja ip_masq_irc.

Mõni sõna veel logimisest. Logi uurides võite üsna varsti avastada, et üsna palju üritatakse luua ühendusi arvuti erinevatesse portidesse, kus tegelikult teenust polegi. Tavalise püsiühendusega arvuti logist leiab tavaliselt umbes paarkümmend rida üritusi ööpäevas. Põhilisteks sihtportideks on 80 (veebiserver), 21 (ftp) ja 111 (portmap). Esiteks, palju õnne, tulemüür toimib!

Enamasti ei tasu aga nendele olulist tähelepanu pöörata. Te võite selle küll teadmiseks võtta, kuid iga pordi proovimise peale ei tasu kindlasti lärmi tõsta. Enamuses polegi tegu sissetungi katsetega vaid hoopis millegi süütumaga. Näiteks porti 80 püüavad ühendusi luua enamasti Red Code’i ja Nimda taolised viirused. Kuna teil veebiserverit pole või kui on, siis ilmselt Apache, siis pole teil vaja muret tunda. Uskuge mind, kui te hakkaksite igale kutsumata külalisele reageerima, teenusepakkujale kirjutama jne, ei jääks teil varsti millekski muuks aega. Reageerida tasub alles siis kui kellegi huvi teie masina vastu muutub tõsisemaks või hakkab huviline teie ühendust ummmistama vms.

Ongi selleks korraks kõik. Järgmise korrani!

Linux Networking-concepts HOWTO - http://netfilter.samba.org/unreliable-guides/networking-concepts-HOWTO/index.html
Linux IPCHAINS HOWTO - http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html