A tűzfalak szolgálnak arra a célra, hogy felfogják a kívülről érkező támadásokat, amelyek száma napjainkra folyton-folyvást nő: egyre több irányból kell védekezni. A védelem megtervezésével az előző rész foglalkozott, ezen a fázison túlesve megkezdhetjük a kivitelezést.

A legtöbbünk otthonában már rendelkezésre áll számítógép, amely rá van kötve a világhálóra. Nagyon sokan nem is sejtik, miféle és mennyiféle veszélynek vannak kitéve az idilli levelezgetés és szörfözgetés közben. Sajnos sokan a megkárosított rendszerük romjai felett keseregve határozzák el, hogy megkísérelnek elkészíteni valamiféle tűzfalat a védelem céljából.
Egy Linux rendszer, akár már egy egyszerű felhasználói telepítés után futtat néhány hálózati szerveralkalmazást, amelyek alapesetben csak a helyi gép esetleg a helyi hálózat felől elérhetőek, de amint az adott gép felkapcsolódik a világhálóra, azonnal elérhetővé válnak szinte bárki számára. Ez a legtöbb esetben komoly biztonsági lyukat jelent, hiszen bárki használhatja a nyilvános hálózati erőforrásainkat, leggyakrabban az FTP és a HTTP protokollok szoktak alapvetően nyitottak lenni, ami nem olyan nagy baj, de bosszantó, amikor elfogy a helyünk, mert a gépünket használja valaki átmeneti tároló hely céljából, mivel rendszeresen feltöltöget a gépünkre az FTP szerverünket használva. Ez utóbbi, gyakori probléma a kábel-netes világháló elérést használók körében, hiszen a gép jó esetben állandó összeköttetéssel és fix IP címmel rendelkezik.
Egy tűzfal kiépítéséhez és helyes beállításához tulajdonképpen elegendően mély hálózati ismeretekre és tapasztalatokra lenne szükség, amely legtöbbünk esetében nem áll rendelkezésre. Másik irányból nézve ugyancsak nem áll rendelkezésre egy külön hardver, amellyel majd megvédjük a megfelelő gépeket. Otthoni környezetet feltételezve nem várható el, hogy a biztonságosságnak megfelelően a tűzfal egy elkülönített (szakmai nyelven fogalmazva dedikált) gép legyen, amelynek csak és kizárólag a védelem a feladata: a probléma megoldását egy gép felhasználásával kell megoldani, amely maga a védendő terület: a rendszermag szolgáltatásait fogjuk használni, hogy megfelelően megvédhessük a tulajdonunkat.
A rendszermag verziójának megfelelően több program közül kell választanunk, mivel a szolgáltatás a verziószámnak megfelelően folyamatosan fejlődött. Egyszerű irányszám szerint:
  2.0.x     ipfwadm
  2.2.x     ipchains
  2.4.x     iptables
A 2.2.x rendszermag van jelenleg leginkább elterjedve, mivel a 2.0.x verziójú magok már túlságosan réginek számítanak, elvétve találhatók meg néhány kevésbé karbantartott gépen, illetve a 2.4.x magok túl újnak számítanak, most kezdik kinőni a gyermekbetegségeiket, ahogy az x helyén álló verziószám közelíti a kétjegyű számot. Ennek megfelelően az ipchains (http://www.rustcorp.com/linux/ipchains/, http://www.osb.hu/tech/forditasok/ipchains-hogyan/) program beállításaival készítjük el a házi tűzfalunkat.
Az ipchains program a rendszermag ipv4 moduljának a kezelőfelülete, egyben a régebbi ipfwadm program újabb kiadása is. Ezzel a programmal tudjuk a gépünk által kezelt IP csomagokat különféle feltételeknek megfelelően szűrni. A legtöbb használt hálózaton (mondhatni minden hálózaton) a küldött adatok kisebb csomagok formájában utaznak a feladótól a címzettig. A világháló felépítése és működése csomagokon alapul, amelyeket IP csomagoknak nevezünk, amely tartalmazza a forrás és a cél címeket és a csomag hosszát és típusát (ezeken kívül tartalmaz még sok egyéb adminisztratív adatot is). Az IP csomagnak ezt a részét fejlécnek nevezzük, a tulajdonképpeni adatot tartalmazó rész pedig a csomag teste. A csomagszűrő az a program (jelen esetben az ipchains), amely megvizsgálja a csomagok fejlécét a megadott szabályok szerint eldönti, hogy mit tegyen vele. Több lehetőséget adhatunk meg, például a csomagot egyszerűen figyelmen kívül hagyjuk, mintha meg sem kaptuk volna (deny). A csomagot elutasíthatjuk (reject), amely hasonló az eldobáshoz, de ez esetben egy figyelmeztetést (ICMP protokollal) küldünk a feladó felé, hogy a csomagot megtagadtuk. A harmadik megoldás szerint a csomagot elfogadja a rendszermag (accept), ekkora az továbbhaladhat a láncon.
Mint már említettem, az ipchains nem önmagában szűri a csomagokat, hanem a rendszermag megfelelő szolgáltatásait használja, mintegy könnyen kezelhetővé teszi azokat.
Alapesetben a rendszermag három szabályláncot használ, amelyek rendre a beérkező (input), a továbbítandó (forward) és a kilépő (output) irányokat jelentik. Minden egyes láncban szabályok sorakoznak, amelyek bizonyos fejlécváltozókat jelentenek, és megmondják, hogy a rendszermag mit tegyen, ha a szabály által meghatározott változók azonosak a csomag változóival. Ha a szabály nem egyezik a csomag fejlécével, akkor a rendszermag a következő szabályt veszi elő és e szerint is megvizsgálja a csomagot. Két eset lehetséges:

1. A lánc egyik szabálya alapján sikerül megfogni egy csomagot, ekkor a szabályban meghatározott tevékenységet végzi el a rendszermag (accpet, deny, reject).
2. A lánc egyik szabálya sem illik a csomagra, ekkor az adott lánc irányelve határozza meg a csomag további élettörténetét.
 

Az ábrán látható a szűrés menete, amely folyamatában mondhatni összetett, de könnyen megérthető. A bejövő csomagoknak először az ellenőrző összegét képezi a rendszermag, amelynek egyeznie kell a küldő fél által a csomagba tett ellenőrző összeggel. Ha ez az egyezőség nem áll fenn, akkor joggal gyaníthatjuk, hogy a csomag megsérült, tehát akár el is dobhatjuk.
Ezt követi a józanság ellenőrzése, amely leginkább a bemeneti láncon a legfontosabb, mivel egy értelmetlen tartalmú csomag kellően összezavarhatja az ellenőrzést, vagyis esetleg átmehet a láncokon, pedig a tartalma értelmetlen: a küldő állomás nincs a helyzet magaslatán, így nyugodt szívvel eldobhatjuk a csomagot.
A bemeneti (input) lánc szabályai jönnek most, amely egyezőség esetén végrehajtja a szabály utasítását, egyéb esetben a lány irányelvét veszi alapul.
Ha a csomag érintetlenül átjutott a bemeneti láncon, akkor következik a MASQ ellenőrzése, vagyis a csomag újra-fejlécezésének ellenőrzése. Ha a csomagot a tűzfalunk újrafejlécezte valamikor, akkor most ennek az ellentéte következik, a le-fejlécezés.
Az útvonalválasztás egy fontos lépése a csomag továbbhaladásának, mivel most dől el, hogy a helyi gépnek címezték-e a csomagot, vagy tovább kell-e küldeni egy másik gép (vagy hálózat) felé.
A továbbítási (forward) lánc esetén szintén megvizsgálásra kerül a csomag fejléce, és a szabályoknak megfelelően él a továbbiakban.
A kimeneti (output) láncba kerülnek bele azok a csomagok, amelyek el fogják hagyni a gépünket.

Ezek után kezdhetjük is az ismerkedést a programmal

linux:~ # ipchains --version
ipchains 1.3.9, 17-Mar-1999
linux:~ # _

A program dokumentációja az 1.3.4 verziót, vagy az 1.3.8 verziót követő programokat javasolja, mivel a kettő közötti verziók biztonságilag hibásak. Nézzük a program paramétereit, mégpedig a láncok kezelését illetően:

    -N új lánc létrehozása
    -D üres lánc törlése
    -P irányelv megadása
    -L a lánc szabályai
    -F az összes szabály törlése a láncból
    -Z csomag és adatszámlálók nullázása
és a láncokon belül:
    -A új szabály hozzáadása a lánc végére
    -I új szabály beszúrása a lánc elejére
    -R szabály cseréje egy új szabállyal
    -D szabály törlése
Nézzünk egy rövid példát a program működésére, amelyet mindenki el tud végezni a saját gépén, még akkor is, ha nincs hálózati adapter a gépében. A Linux ugyanis létrehoz egy úgynevezett visszahurkolást, amelynek az IP címe 127.0.0.1 szokott lenni. Próbáljuk ki rajta a ping parancsot, amely a célcím felé ICMP Echo-Request üzeneteket fog küldözgetni, és várja onnan az ICMP Echo-Reply üzeneteket:

linux:~ # ping -c 4 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=255 time=0.268 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.244 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.185 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.185 ms
--- 127.0.0.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.185/0.220/0.268 ms
linux:~ # _

Láthatjuk, hogy minden csomagra kapott választ a parancs, de tegyük fel, hogy ez nekünk nem tetszik és nem szeretnénk, ha a gépünk válaszolna az ICMP Echo-Request üzenetekre. A megoldás egyszerűnek látszik (az is :), vagyis el kell dobni a beérkező ICMP Echo-Request üzeneteket, amikor a címzett IP címe a 127.0.0.1 cím. Ehhez tegyük a következőt:

linux:~ # ipchains -A input -s 0/0 8 -d localhost -p icmp -j DENY
linux:~ # _

vagyis megmondtuk a rendszermagnak az ipchains programot paraméterezve, hogy tetszőleges címről érkező (-A input) ICMP Echo-Request (-s 0/0 8 -p icmp) üzeneteket, amelyeknek a címzettje 127.0.0.1 (-d 127.0.0.1), azokat egyszerűen dobja el (-j DENY).

Ezek után már hiába is próbáljuk az előző ping parancsot:

linux:~ # ping -c 4 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
--- 127.0.0.1 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
linux:~ # _

a csomagjaink egyszerűen elvesznek. Megnézhetjük, hogy a szabályunk miképpen jelenik meg, ha listát kérünk a láncokról és a szabályokról:

linux:~ # ipchains -L
Chain input (policy ACCEPT):
target prot opt source destination ports
DENY icmp ------ anywhere localhost echo-request
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):
linux:~ # _

De ez a szabály nem kell nekünk, ezért ki is töröljük hamar:

linux:~ # ipchains -D input 1
linux:~ # _

Ezek után meg is nézhetjük a jelenlegi beállításokat, amely listáknak üresnek kell lenniük:

linux:~ # ipchains -L
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):
linux:~ # _

Próbaképpen kitörölhetjük még egyszer a bemeneti láncból az első szabályt:

linux:~ # ipchains -D input 1
ipchains: No chain by that name
linux:~ # _

és láthatjuk, hogy nincs gond, mert nincs törölhető szabály.

Alapvetően a fentiekhez hasonlóan kell az ipchains programot használni, de ehhez természetesen ismerni kell néhány parancsot is, amelyeket most nem részletezek, mivel magyar dokumentációban elolvashatók és megérthetők. Ezek helyett inkább nézzünk egy átlagosnak mondható gép védelmét a világháló felől.

Ehhez első körben fel kell deríteni a nyitott portokat a külvilág felé:

linux:~ # nmap localhost
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on localhost (127.0.0.1):
(The 1502 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp
37/tcp open time
53/tcp open domain
79/tcp open finger
80/tcp open http
110/tcp open pop-3
111/tcp open sunrpc
119/tcp open nntp
443/tcp open https
512/tcp open exec
513/tcp open login
514/tcp open shell
515/tcp open printer
627/tcp open unknown
901/tcp open samba-swat
2049/tcp open nfs
3128/tcp open squid-http
6000/tcp open X11

Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds
linux:~ # _

hát ez bizony nagyon sok nyitott port, amelyeknek a nagy részét nem kellene a nagy nyilvánosság elé tárni, kezdjünk is neki a bezárásnak, amely a ppp0 eszközön át érkező csomagokra érvényes csak:

linux:~ # ipchains -A input -s 0/0 -d 0/0 21 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 23 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 37 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 53 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 79 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 80 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 110 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 111 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 119 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 443 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 512 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 513 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 514 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 515 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 627 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 901 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 2049 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 3128 -p tcp -i ppp0 -j REJECT
linux:~ # ipchains -A input -s 0/0 -d 0/0 6000 -p tcp -i ppp0 -j REJECT
linux:~ # _

Ezek után ismét megnézhetjük a nyitott portokat, de meglepetésünkre azok nyitva maradtak. Hol lehet a hiba? Természetesen ott, hogy a helyi gépen néztük meg a listát, pedig azt egy távoli gépről kellene, ahogyan mások is látják a gépünket a világhálóról. Nézzük meg egy ilyen listát a nyitott portokról:

remote:~ # nmap ip.cime.a.gepunknek
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on localhost (ip.cime.a.gepunknek):
(The 1502 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp

Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds
remote:~ # _

Azonnal látszik a különbség, már csak kettő portunk van nyitva, akár nyugodtan hátra is dőlhetnénk a fotelban, de jobban tesszük, ha a TCP portok után megnézzük a nyitott UDP portokat is:

linux:~ # nmap -sU localhost
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on localhost (127.0.0.1):
(The 1435 ports scanned but not shown below are in state: closed)
Port State Service
37/udp open time
53/udp open domain
111/udp open sunrpc
161/udp open snmp
514/udp open syslog
517/udp open talk
518/udp open ntalk
520/udp open route
624/udp open unknown
723/udp open unknown
870/udp open unknown
2049/udp open nfs
3130/udp open squid-ipc
Nmap run completed -- 1 IP address (1 host up) scanned in 7 seconds
linux:~ #

A fentiekhez hasonlóan itt is bezárjuk a feleslegesen nyitott portjainkat, de a "-p tcp" paraméter helyett minden sorba "-p udp" paramétert kell írnunk.
Amint megvagyunk ezekkel a védelmünket sikeresen kiépítettük, de ez még nem egy komolyan szakértelemmel kidolgozott tűzfal, hanem egy gyenge lábakon álló csomagszűrő tűzfal, tehát ne bízzuk el magunkat túlságosan. Vigyázni kell arra, hogy a rendszer újraindulásakor az ipchains beállítások elvesznek, ezért szokás azokat elmenteni:

linux:~ # ipchains-save >/etc/ipchains.rules

illetve azt visszatölteni:

linux:~ # ipchains-restore </etc/ipchains.rules

A következő részben egy belső privát hálózatot rakunk tűzfal mögé, a rövid elméletet és a megvalósítás lépéseit írom majd le, amely egy kicsit mélyebbre vezet minket a tűzfalak birodalmában.