Az IPFIREWALL (IPFW) a FreeBSD által támogatott tűzfalazó alkalmazás, melyet a FreeBSD Projektben résztvevő önkéntesek fejlesztettek ki és tartanak karban. Régi típusú, állapottartás nélküli szabályokat használ, és az itt használatos szabályírási technikát „egyszerű állapottartó megoldásnak” nevezzük.
Az IPFW szabvány FreeBSD-ben levő, mintaként
szolgáló szabályrendszere (ez az
/etc/rc.firewall
és
/etc/rc.firewall6
állományokban
található meg) annyira egyszerű, hogy komolyabb
módosítások nélkül nem
ajánlatos használni. Ez a példa nem
tartalmaz állapottartó szűrést, ami
viszont a legtöbb esetben kívánatos lenne,
ezért ezt a szakaszt nem erre alapozzuk.
Az IPFW állapottartás nélküli szabályainak felépítésében olyan technikailag kifinomult leválogatási képességek bújnak meg, amelyek jócskán meghaladják az átlagos tűzfalépítők tudását. Az IPFW elsősorban olyan szakemberek vagy szakmailag előrehaladott felhasználók számára készült, akiknek speciális csomagszűrési igényeik vannak. A különböző protokollok használatának és a hozzájuk tartozó fejlécinformációk mindenre kiterjedő ismerete szinte nélkülözhetetlen az IPFW valódi erejének kihasználásához. Ez a szint azonban túlmutat a kézikönyv ezen szakaszának keretein.
Az IPFW hét komponensből épül fel,
melyek közül az elsődleges a rendszermag
tűzfalazásért felelős
szabályfeldolgozó és a
hozzá tartozó csomagnyilvántartás, majd
ezt követi a naplózás, a hálózati
címfordítást aktiváló
divert
szabály, valamint a komolyabb
célok megvalósítására alkalmas
lehetőségek: a forgalom
korlátozásáért felelős dummynet,
a továbbküldésre alkalmas fwd
rule
szabály, a hálózati hidak
támogatása, illetve az ipstealth. Az IPFW
egyaránt használható IPv4 és IPv6
esetén.
Az IPFW az alap FreeBSD telepítésben
külön, futás időben betölthető
modulként érhető el. Ha az
rc.conf
állományban megadjuk
a firewall_enable="YES"
beállítást, akkor a rendszer
indulásakor ezt a modult dinamikusan betölti. Az
IPFW-t csak akkor kell a FreeBSD rendszermagjába
beépítenünk, ha szükségünk
van a címfordítási
funkciójára is.
Ha tehát az rc.conf
állományban megadtuk a
firewall_enable="YES"
sort és
újraindítottuk a
számítógépünket, akkor a
következő fehérrel kiemelt üzenet fog
megjelenni a rendszerindítás során:
A „logging disabled” üzenetből
kiderül, hogy a modul nem végez
naplózást. A naplózást és a
hozzá tartozó részletesség
szintjét úgy tudjuk beállítani, ha
az /etc/sysctl.conf
állományba felvesszük a következő
sorokat, amivel a következő indításkor
már működni fog:
Ha nem akarjuk kihasználni az IPFW által felkínált címfordítási lehetőségeket, akkor egyáltalán nem szükséges a FreeBSD rendszermagjába belefordítani a támogatását. Ezért az alábbiakat csak kiegészítő információként tüntettük fel.
Ez a beállítás engedélyezi az IPFW használatát a rendszermag részeként.
Ezzel és a log
kulcsszóval
tudjuk az IPFW szabályain keresztülhaladó
csomagokat naplózni.
Ez az érték korlátozza a syslogd(8) segítségével naplózott azonos bejegyzések maximális számát. Ezt a beállítást olyan veszélyes környezetekben érdemes használnunk, ahol naplózni akarunk. Segítségével meg tudjuk akadályozni, hogy a rendszernapló elárasztásával megakasszák a rendszerünket.
Ezen beállítás hatására a tűzfal alapértelmezés szerint mindent átenged, ami általában akkor jöhet jól, amikor először beállítjuk a tűzfalat.
Ezzel a beállítással engedélyezzük a címfordítás használatát.
Ha nem adjuk meg az IPFIREWALL_DEFAULT_TO_ACCEPT beállítást, vagy ha nem engedélyezzük a bejövő csomagokat, akkor a gépünkre semmilyen csomag nem lesz képes bejutni, illetve onnan kijutni.
Így tudjuk engedélyezni a tűzfalat:
A FreeBSD-hez mellékelt alapértelmezett
tűzfaltípusok közül az
/etc/rc.firewall
állomány
átolvasásával tudunk választani,
és megadni az alábbi helyett:
A következő értékek állnak rendelkezésünkre:
open
— átengedi az
összes forgalmat
client
— csak ezt a
gépet védi
simple
— az egész
hálózatot védi
closed
— a helyi
interfész kivételével minden IP
alapú forgalmat tilt
UNKNOWN
— tiltja a tűzfal
szabályainak betöltését
— a tűzfal szabályait tartalmazó
állomány abszolút elérési
útvonalaállománynév
Két különböző módon lehet
betölteni a saját ipfw
szabályainkat. Az egyik közülük, ha a
firewall_type
változóban
megadjuk a tűzfal szabályait
tartalmazó állomány abszolút
elérési útvonalát, az ipfw(8)
parancssori beállításai nélkül.
Az alábbi példában egy olyan egyszerű
szabályrendszert láthatunk, amely blokkolja az
összes bejövő és kimenő
forgalmat:
Másrészről az
firewall_script
változóban is
megadhatjuk azt a szkriptet, amelyben a
rendszerindítás során meghívjuk
ipfw
parancsot. Az iménti
szabályrendszert az alábbi szkripttel tudjuk
kiváltani:
Ha a firewall_type
változó client
vagy
simple
értékét
használjuk, akkor az
/etc/rc.firewall
állományban található
alapértelmezett szabályokat érdemes
átvizsgálnunk, hogy kellően illeszkednek-e
az adott géphez. Hozzátennénk, hogy a
fejezetben szereplő példák azt
feltételezik, hogy a firewall_script
értéke az /etc/ipfw.rules
állomány.
A naplózás így engedélyezhető:
A firewall_logging
változó egyedül csak annyit tesz, hogy
beállítja a
net.inet.ip.fw.verbose
sysctl
változónak az 1
értéket (lásd 30.6.1. szakasz - Az IPFW engedélyezése). A napló
korlátozására nincs külön
változó az rc.conf
állományon belül, de az
/etc/sysctl.conf
állomány
segítségével és manuálisan
be tudjuk állítani a hozzá tartozó
változót:
Amennyiben a gépünk
átjáróként viselkedik, tehát
a natd(8) segítségével
címfordítást végez, a 31.9. szakasz - Hálózati
címfordításban olvashatunk utána, hogy ehhez
az /etc/rc.conf
állományban
milyen beállításokat kell megadnunk.
Normál esetben az ipfw
parancs
használatos arra, hogy a tűzfal
működése közben az aktív belső
szabályai közé vegyünk fel vagy
töröljünk közülük
manuálisan bejegyzéseket. Ennek a
módszernek az egyedüli hátránya, hogy
az így végrehajtott
módosítások el fognak veszni a rendszer
leállításával. Itt inkább
azt a megoldást javasoljuk, hogy az összes
szabályt tegyük bele egy állományba
és a rendszerindítás során ezt
töltsük be, majd ha változtatni akarunk a
tűzfalon, akkor ezt az állományt
módosítsuk és a régiek
törlésével töltsük be újra
az egész szabályrendszert.
Az ipfw
parancs mellesleg remekül
használható a jelenleg futó
tűzfalszabályok megjelenítésére
a konzolon. Az IPFW nyilvántartásában az
egyes szabályokhoz dinamikusan jönnek létre
számlálók, amelyek a rá
illeszkedő csomagokat számolják. A
tűzfal tesztelése folyamán a szabályok
és hozzá tartozó
számlálók lekérdezése a
megfelelő működés
ellenőrzésének egyik lehetséges
módja.
A szabályokat így tudjuk egymás után felsoroltatni:
#
ipfw list
A szabályokat így tudjuk az utolsó illeszkedésük idejével együtt megjeleníteni:
#
ipfw -t list
A következő példában a nyilvántartási információkat kérdezzük le, ekkor a szabályok mellett az illeszkedő csomagok száma is láthatóvá válik. Az első sorban a szabály száma szerepel, majd ezt követi rendre az illeszkedő kimenő és bejövő csomagok mennyisége, valamint végül maga a szabály.
#
ipfw -a list
A statikus szabályok mellett a dinamikusakat így lehet kilistázni:
#
ipfw -d list
A lejárt dinamikus szabályokat is meg tudjuk nézni:
#
ipfw -d -e list
A számlálók nullázása:
#
ipfw zero
Csak a SZÁM
sorszámú szabályhoz tartozó
számlálók nullázása:
#
ipfw zero SZÁM
Az IPFW esetében a szabályrendszer olyan szabályokból áll, amelyek a csomagokról tartalmuk alapján eldöntik, hogy át kell engedni vagy vissza kell tartani. A gépek közt két irányban áramló csomagok egy munkamenet alapú társalgást képeznek. A tűzfalhoz tartozó szabályrendszer egyaránt feldolgozza a internetről a hálózatunk felé igyekvő csomagokat, illetve a hálózatunk ezekre adott válaszait. Az egyes TCP/IP szolgáltatásokat (mint például telnet, www, levelezés stb.) a hozzájuk tartozó protokol és szabványos (fogadó) portszám írja le. Ezekre a forrásról általában valamilyen nem szabványos (magasabb értékű) portról érkeznek csomagok. Ekkor a kommunikáció összes paramétere (vagyis a portok és címek) bármelyike alapján definiálhatunk blokkolást vagy továbbengedést leíró szabályokat.
Amikor egy csomag eléri a tűzfalat, a szabályrendszer első szabályával kerül összehasonlításra és amíg nem illeszkedik valamelyikre, addig lefut rá a többi szabály is fentről lefelé egyesével, a sorszámuknak megfelelő növekvő sorrendben. Ha a csomag megfelel valamelyik szabály leválogatási paramétereinek, akkor a benne megnevezett cselekvés zajlik le, és számára a feldolgozás befejeződik. Ezt a viselkedést neveztük „az első illeszkedés nyer” típusú keresésnek. Amennyiben a csomag egyetlen szabályra sem illeszkedik, akkor az IPFW 65535-ös sorszámú állandó szabálya fogja elcsípni, amely feladata szerint eldobja az összes hozzá beérkező csomagot anélkül, hogy bármit is válaszolna a csomag feladójának.
A keresés a count
,
skipto
és tee
szabályok után még
folytatódik.
Az itt szereplő utasítások
különböző állapottartásra
vonatkozó opciókat, például a
keep state
, limit
,
in
, out
és
via
kulcsszavakat tartalmazó
szabályokon alapulnak. Lényegében ezt
tekinthetjük az inkluzív típusú
tűzfalak kiindulási alapjaként.
A tűzfal szabályainak beállítása során nem árt óvatosnak lennünk, mert figyelmetlenségünk révén könnyen kizárathatjuk magunkat a gépünkről.
Az itt bemutatásra kerülő szabályok felépítését csak olyan mértékig részletezzük, ami elengedő a szabványos inkluzív típusú tűzfalak kialakításához. A szabályok felépítésének pontos leírását az ipfw(8) man oldalán találhatjuk meg.
A szabályok kulcsszavakat tartalmaznak. Ezeket a kulcsszavakat soronként egy előre rögzített sorrendben kell szerepeltetni. A kulcsszavakat a szövegben kiemeltük. Bizonyos kulcsszavakhoz további opciókhoz is tartozhatnak, amelyek gyakran maguk is kulcsszavak és szintén további opciókat tartalmazhatnak.
A #
egy megjegyzés
kezdetét jelzi, mely egyaránt megjelenhet egy
külön sorban, vagy egy szabályt
tartalmazó sor végén. Az üres sorok
nem vesznek részt a feldolgozásban.
PARANCS SZABÁLY_SZÁM
CSELEKVÉS NAPLÓZÁS SZűRÉS
ÁLLAPOTTARTÁS
Minden új szabály előttt az
add
(mint hozzáadás)
parancsnak kell szerepelni, amellyel a belső
táblázatba tudjuk felvenni.
A szabályhoz az alábbi cselekvések valamelyike kapcsolható, amely akkor hajtódik végre, amikor a csomag megfelel a hozzá tartozó szűrési feltételeknek.
allow | accept | pass |
permit
A fentiek közül mindegyik ugyanazt jelenti, vagyis hatásukra az illeszkedő csomag kilép a tűzfalból. Ez a szabály megállítja a keresést.
check-state
A csomagot a dinamikus szabályokat
tároló táblázattal veti
össze. Ha itt egyezést talál, akkor
végrehajtja az egyező dinamikus
szabályhoz tartozó cselekvést, minden
más esetben továbblép a
következő szabályra. Ennek a
szabálynak nincs illeszthető paramétere.
Ha a szabályrendszerben nem szerepel ilyen, akkor a
dinamikus szabályok vizsgálatát az
első keep-state
vagy
limit
használatánál
vonja be a rendszer.
deny | drop
Mind a két szó ugyanarra utal, vagyis a szabályra illeszkedő csomagokat el kell dobni. Ebben az esetben a keresés befejeződik.
log
vagy
logamount
Amikor egy csomag egy log
kulcsszót tartalmazó szabályra
illeszkedik, akkor a rendszernaplóban egy üzenet
keletkezik a security
(biztonság)
funkción keresztül. A naplóba
ténylegesen csak akkor kerül bele az
üzenet, ha az adott szabály még nem
haladta meg a hozzá tartozó
logamount
paraméter
értékét. Ha ezt nem adtuk meg, akkor
az itt érvényes korlát a
net.inet.ip.fw.verbose_limit
sysctl
változóból fog származni. A
nulla érték mind a két esetben
megszünteti ezt a korlátozást. Ha
elértük a korlátot, akkor a
naplózást úgy tudjuk újra
engedélyezni, ha töröljük a
naplózáshoz tartozó
számláló értékét,
lásd az ipfw reset log
parancsot.
A naplózás mindig az összes paraméter illeszkedésének ellenőrzése után történik, de még a cselekvés (accept, deny) elvégzése előtt. Teljesen rajtunk múlik, hogyan milyen szabályokat naplózunk.
Ebben a szakaszban azok a kulcsszavak találhatóak, amelyek segítségével a csomagok különböző tulajdonságait tudjuk megvizsgálni és eldönteni, hogy illeszkedik-e a szabályra vagy sem. A következő általános tulajdonságokat tudjuk megvizsgálni, ebben a kötött sorrendben:
udp | tcp | icmp
Bármilyen más olyan protokoll is
megadható, amely megtalálható az
/etc/protocols
állományban. Ezzel adjuk a csomaghoz
tartozó protokollt. Használata
kötelező.
from
forrás
to cél
Mind a from
és
to
kulcsszavak IP-címek
illesztésére alkalmasak. A
szabályoknak tartalmazniuk kell a
forrás
ÉS a
cél
paramétereket
is. Az any
egy olyan kulcsszó,
amely tetszőleges IP-címre illeszkedik. A
me
pedig egy olyan speciális
kulcsszó, amely a tűzfalat
működtető FreeBSD-s gép (tehát ez
a gép) adott interfészhez tartozó
IP-címét jelöli, mint ahogy a
from me to any
, from any to
me
, from 0.0.0.0/0 to any
,
from any to 0.0.0.0/0
, from
0.0.0.0 to any
, from any to
0.0.0.0
vagy from me to 0.0.0.0
paraméterekben. Az IP-címek numerikus
pontozott formában a hálózati maszk
hosszával együtt (CIDR-jelöléssel),
vagy egyszerűen csak pontozott formában
adhatóak meg. A hálózati maszkok
megállapításában a net-mgmt/ipcalc
port lehet
segítségünkre. Erről bővebb
információkat a segédprogram
honlapján, a http://jodies.de/ipcalc címen
találhatunk (angolul).
port
szám
A portszámokat is ismerő protokollok
esetében (mint például a
TCP vagy UDP) adhatjuk
meg. Fontos, hogy itt annak a szolgáltatásnak
a portszámát adjuk meg, amelyre a
szabály vonatkozik. A szolgáltatás (az
/etc/services
állományból származó)
nevét is megadhatjuk a port száma
helyett.
in | out
A beérkező valamint a kimenő csomagokat
adhatjuk meg ezen a módon. Itt az
in
és out
kulcsszavak, melyeket kötelező megadni a
szabály részeként.
via
interfész
Név szerint az adott interfészen
keresztül haladó csomagokat tudjuk szűrni.
A via
kulcsszó
hatására a használt interfész is
számítani fog a csomag feldolgozása
során.
setup
Ez a kulcsszó a TCP csomagok esetében a kapcsolatok felépítésére vonatkozó kéréseket segít beazonosítani.
keep-state
Ez egy kötelező kulcsszó. Feldolgozásakor a tűzfal létrehoz dinamikus szabályt, amely alapértelmezés szerint az egyazon protokollt használó forrás és cél IP/port párosok közti kétirányú forgalomra fog automatikusan illeszkedni.
limit
{
forráscím
|
forrásport
|
célcím
|
célport
}
A tűzfal csak N
darab, a
szabálynak megfelelő azonos
paraméterű kapcsolatot fog átengedi. Itt
egy vagy több forrás- és
célcím valamint forrás- és
célport adható meg. A
limit
és a
keep-state
egy szabályon
belül nem használható. A
limit
ugyanazokat az
állapottartó funkciókat
képviseli, mint a keep-state
, csak
a saját kiegészítéseivel
megtoldva.
Az állapottartó szűrés a kétirányú csomagváltásokat egy létrejött kapcsolatba sorolja. Olyan vizsgálatokat végez, amivel képes megállapítani, hogy a csomag küldője és címzettje között kialakult kommunikáció követ-e valamilyen kétirányú csomagküldésre érvényes folyamatot. Az így felállított sablontól eltérő összes csomag hamisnak minősül és automatikusan eldobásra kerül.
A check-state
segítségével ellenőrizhetjük,
hogy az adott csomag a IPFW szerint megfelel-e valamelyik
dinamikusan leképzett szabálynak. Ha egyezik
valamelyikőjükkel, akkor a csomag a
tűzfalból kilépve folytatja
útját és a kommunikációban
soron következő csomag számára
létrejön egy másik dinamikus
szabály. Ha nincs egyezés, akkor csomag
feldolgozása a szabályrendszer
következő szabályánál
folytatódik.
A dinamikus szabályokat kezelő rutin
sebezhető, mivel ha egyszerre nagy mennyiségű
SYN csomagot küldünk, akkor olyan sok dinamikus
bejegyzés keletkezik, hogy egyszerűen kifogyunk a
rendelkezésre álló
erőforrásokból. A FreeBSD fejlesztői
azonban az ilyen természetű
támadások kivédésére is
felkészítették, és
kialakították belőle a
limit
opciót.
Alkalmazásával le tudjuk korlátozni az
egyszerre folyó párhuzamos kapcsolatok
számát a forrás vagy a cél a
limit
paraméternél megadott
mezőinek és a csomag IP-címe
alapján. Így az adott szabályhoz
és IP-címhez csak előre
rögzített mennyiségű nyitott
állapotú dinamikus szabály
létezhet egy időben. Ha ezt a korlátot
átlépjük, a csomag eldobódik.
A naplózás előnyei nyilvánvalóak. Ha engedélyezzük, aktiválása után képesek leszünk olyan információknak utánanézni, mint például milyen csomagokat dobtunk el, honnan érkeztek, hova tartottak. Ez egy komoly fegyverünk lehet a potenciális támadókkal szemben.
Azonban hiába engedélyezzünk
önmagában a naplózást, attól
az IPFW még saját magától nem fog
naplózást előíró
szabályokat gyártani. A tűzfal
karbantartóinak maguknak kell eldöntenie, hogy a
szabályrendszerben mely szabályokhoz tartozzon
naplózás, nekik kell felvenni ezekhez a
log
kulcsszót.
Általában csak az eldobással
járó deny
típusú szabályokat vagy a
bejövő ICMP pingeket
szokták naplózni. Gyakran úgy
oldják meg ezt, hogy a szabályrendszer
utolsó szabályaként
lemásolják az ipfw
alapértelmezett „mindent eldobunk”
szabályát és a naplózást
adják meg benne. Ezen a módon fény
derül azokra a csomagokra, amelyek a
szabályrendszerben semmire sem illeszkedtek.
A naplózás azonban egy kétélű fegyver, mivel ha nem vagyunk elég körültekintőek, akkor a sok naplóinformáció között könnyen el tudunk veszni és a lemezünk is gyorsan betelhet a mindent elfoglaló naplóktól. Mellesleg a naplók megdagasztását célzó DoS típusú támadás a rendszerek lebénítására alkalmazott egyik legősibb technika. Ezek az üzenetek nem csak a rendszernaplóba kerülnek bele, hanem az elsődleges konzol képernyőjére is kiíródnak, ami egy idő után idegesítő tud lenni.
A rendszermag
IPFIREWALL_VERBOSE_LIMIT=5
beállításával azonban
képesek vagyunk korlátozni azokat a
rendszernapló felé küldött
egymás után következő üzeneteket,
amelyek ugyanarra a szabályra vonatkoznak. Amikor ezt
a beállítást megadjuk a rendszermag
fordításánál, akkor az egyes
szabályokhoz az általa meghatározott
értéken felül nem jön létre
több hasonló üzenet. Hiszen semmi sem
derül ki 200 teljesen azonos
naplóüzenetből. Például, ha az
egyes szabályokhoz legfeljebb öt egymást
követő üzenetet engedélyezünk,
akkor a többi fennmaradó azonos üzenetet
összeszámolja a rendszer és a
következő módon közvetíti a
rendszernaplózó szolgáltatás
felé:
Ami magyarul így hangzik:
Az összes csomagokkal kapcsolatos
naplózás alapértelmezés szerint a
/var/log/security
állományba kerül, amelyet az
/etc/syslog.conf
állomány
definiál.
A rutinosabb IPFW felhasználók a szabályokat egy állományban programozzák le olyan stílusban, hogy szkriptként is futtatható legyen. Ennek az egyik legnagyobb előnye, hogy a tűzfal szabályai így egyszerre cserélhetőek a rendszer újraindítása nélkül. Ez a módszer nagyon kényelmes az új szabályok kipróbálásánál, mivel tetszőleges alkalommal végrehajthatjuk. Mivel ez egy szkript, ki tudjuk használni az itt megszokott szimbolikus helyettesítés által felkínált lehetőségeket, és ezzel a gyakran használt értékeket is egyszerre több szabályban tudjuk helyettesíteni. Erre a következőkben fogunk egy konkrét példát látni.
A szkript felépítése kompatibilis a sh(1), csh(1) és tcsh(1) parancsértelmezőkkel. A szimbolikus mezők helyettesítését a $ vagyis dollárjel vezeti be. Maguk a szimbolikus mezők nem tartalmazzák a $ előtagot. A szimbolikus mezők értékeit "kettős idézőjelek" között kell megadni.
A szabályok összeírását kezdjük el így:
Ezzel készen is vagyunk. Most ne törődjünk a példában szereplő szabályokkal, itt most a szimbolikus helyettesítés használatát igyekeztük bemutatni.
Ha az iménti példát az
/etc/ipfw.rules
állományba
mentettük el, akkor az alábbi parancs
kiadásával tudjuk újratölteni a
benne szereplő szabályokat:
#
sh /etc/ipfw.rules
Az /etc/ipfw.rules
állományt egyébként
tetszőleges néven hívhatjuk és
bárhová rakhatjuk.
Ugyanez természetesen elérhető a következő parancsok egymás utáni begépelésével is:
#
ipfw -q -f flush
#
ipfw -q add check-state
#
ipfw -q add deny all from any to any frag
#
ipfw -q add deny tcp from any to any established
#
ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state
#
ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state
#
ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state
A most következő címfordítás nélküli szabályrendszer arra mutat példát, hogyan valósítsunk meg egy biztonságos „inkluzív” tűzfalat. Az inkluzív tűzfalak csak a szabályainak megfelelő szolgáltatásokat engedik át, minden mást alapértelmezés szerint tiltanak. A komplett hálózati szegmensek védelmére összeállított tűzfalaknak legalább két interfészük van, amelyek mindegyikéhez tartoznia kell szabályoknak a megfelelő működéshez.
Az UNIX® mintájú operációs
rendszer, köztül a FreeBSD is olyan, hogy a rendszerben
belüli kommunikációt a
lo0
nevű interfészen
és a 127.0.0.1
IP-címen bonyolítja le. A tűzfalban
mindenképpen szerepelniük kell olyan
szabályoknak, amelyek gondoskodnak ezen
speciális belső csomagok zavartalan
közlekedéséről.
Az internet felé csatlakozó interfész
lesz az, amelyen keresztül a kifelé menő
kéréseket hitelesítjük és
vezéreljük az internet
elérését, valamint ahol szűrjük
az internet felől érkező
kéréseket. Ez lehet a PPP
esetében a tun0
eszköz,
vagy a DSL-, illetve kábelmodemhez csatlakozó
hálózati kártya.
Abban az esetben, amikor egy vagy több hálózati kártyával csatlakozunk a tűzfal mögött található belső helyi hálózatra, szintén gondoskodnunk kell a helyi hálózaton belül mozgó csomagok akadálymentes továbbításáról.
A szabályokat először három nagyobb osztályba kell sorolnunk: az összes szabadon forgalmazó interfész, a publikus kimenő és a publikus bejövő interfész csoportjába.
A publikus interfészekhez tartozó csoportokban úgy kell rendeznünk a szabályokat, hogy előre kerüljenek a gyakrabban használtak és hátra a kevésbé használtak, valamint a csoportok utolsó szabálya blokkoljon és naplózzon minden csomagot az adott interfészen és irányban.
A következő szabályrendszerben
szereplő, a kimenő kapcsolatokat tartalmazó
csoport csak olyan allow
típusú szabályokat tartalmaz, amelyek
szűrési feltételei egyértelműen
azonosítják az interneten elérhető
szolgáltatásokat. Az összes
szabályban megjelennek a proto
,
port
,
in
/out
,
via
és keep
state
opciók. A proto
tcp
szabályokban emellett szerepel még
egy setup
opció is, amellyel a
kapcsolatokat kezdeményező csomagokat tudjuk
azonosítani és felvenni az
állapottartásért felelős dinamikus
szabályok közé.
A bejövő forgalmat vezérlő szabályrendszerben először az eldobni kívánt csomagokat kell megadni, aminek két eltérő oka van. Először is előfordulhat, hogy a veszélyes csomagok részleges illeszkedés miatt szabályosnak tűnnek. Az ilyen csomagokat értelemszerűen nem lenne szabad beengedni a szabályok részleges megfelelése alapján. A másodszor az eleve ismerten problémás és értelmetlen csomagokat csendben el kellene vetni, mielőtt a szakaszhoz tartozó utolsó szabály fogná meg és naplózná. Ez az utolsó szabály egyébként szükség esetén felhasználható a támadók elleni bizonyítékok begyűjtésére.
A másik, amire még oda kell figyelnünk,
hogy a blokkolt csomagok esetében semmilyen
válasz nem keletkezzen, egyszerűen csak
tűnjenek el. Így a támadó nem fogja
tudni, hogy a csomagjai vajon elérték-e a
rendszerünket. Minél kevesebb
információt tudnak összegyűjteni a
rendszerünkről a támadók, annál
biztonságosabbnak tekinthető.
Amikor ismeretlen portokra érkező csomagokat
naplózunk, érdemes az
/etc/services/
állományban
vagy http://www.securitystats.com/tools/portsearch.php
címen (angolul) utánanézni a porthoz
tartozó szolgáltatásnak. A
különböző trójai programok
által portok számai ezen a linken
érhetőek el (angolul): http://www.simovits.com/trojans/trojans.html.
A most következő,
címfordítást nem tartalmazó
szabályrendszer teljesen inkluzív
típusú. Éles rendszereken is nyugodtan
alkalmazhatjuk. Egyszerűen csak annyit kell
tennünk, hogy megjegyzésbe tesszük az olyan
szolgáltatásokra vonatkozó
szabályokat, amelyeket nem akarunk engedélyezni.
Amikor pedig olyan üzenetek jelennek meg a
naplóban, amelyeket nem akarunk tovább
látni, a bejövő kapcsolatokhoz vegyünk
fel egy deny
típusú
szabályt hozzájuk. Minden szabályban
cseréljük ki a dc0
interfészt arra a hálózati
kártyára, amely közvetlenül
csatlakoztatja rendszerünket az internethez. A
felhasználói PPP
esetében ez a tun0
.
A szabályok használatában felfedezhetünk egyfajta rendszerszerűséget:
Mindegyik sorban, ahol az internet felé nyitunk
meg egy kapcsolatot, a keep-state
opciót használjuk.
Az internetről az összes hitelesített
szolgáltatás elérése
tartalmazza a limit
opciót az
elárasztások kivédése
miatt.
Az összes szabályban az
in
vagy az out
paraméterrel megadjuk szűrni
kívánt forgalom
irányát.
Az összes szabályban szerepel a
via
paraméterrel a csomagokat
továbbító interfész
neve.
Az alábbi szabályokat tegyük az
/etc/ipfw.rules
állományba.
Az IPFW címfordító
funkciójának
kihasználásához további
konfigurációs beállítások
alkalmazására is szükségünk
lesz. A rendszermagban opció között meg kell
adnunk az option IPDIVERT
sort a többi
IPFIREWALL
sor mellett, és
fordítanunk egy saját verziót.
Emellett még az /etc/rc.conf
állományban is engedélyezni kell az IPFW
alapvető funkcióit.
Az állapottartó szabályok
használata a divert natd
címfordítási opcióval együtt
nagyban növeli a szabályrendszer
leprogramozásának bonyolultságát.
A check-state
és divert
natd
szabályok helye kritikus a
megfelelő működés tekintetében.
Az eddig megszokott egyszerű viselkedés itt
már nem érvényesül. Bevezetünk
egy új cselekvést is, amelynek a neve
skipto
. A skipto
parancs használatához elengedhetetlen a
szabályok sorszámozása, mivel pontosan
tudnunk kell, hogy a skipto
hatására hova kell ugrania a
vezérlésnek.
A következő példában nem fogunk sok megjegyzést látni, mivel benne az egyik lehetséges programozási stílust próbáljuk érzékeltetni és a csomagok szabályrendszerek közti áramlását magyarázzuk.
A feldolgozás a szabályokat tartalmazó állomány tetején található első szabállyal kezdődik, és innen egyesével pereg végig lefelé a feldolgozás egészen addig, amíg a csomag a szűrési feltételek valamelyikének eleget nem tesz és távozik a tűzfalból. Leginkább a 100-as, 101-es, 450-es, 500-as és 510-es sorszámú szabályokat emelnénk ki. Ezek vezérlik kimenő és bejövő csomagok fordítását, ezért a hozzájuk tartozó dinamikus állapottartó bejegyzések mindig a helyi hálózat IP-címeire hivatkoznak. Amit még érdemes megfigyelnünk, hogy az összes áteresztő és eldobó szabályban szerepel a csomag haladási iránya (tehát kimenő vagy éppen bejövő) és az érintett interfészt megnevezése. Emellett azt is vegyük észre, hogy az összes kifelé irányuló kapcsolatlétrehozási kérés az 500-as sorszámú szabályhoz fog ugrani a címfordítás elvégzéséhez.
Tegyük fel, hogy a helyi hálózatunkon
levő felhasználók szeretnek honlapokat
nézgetni az interneten. A honlapok a 80-as porton
keresztül kommunikálnak. Tehát amikor egy
ilyen csomag eléri a tűzfalat, nem fog illeszkedni
a 100-as szabályra, mert a fejléce szerint
kifelé halad és nem befelé. A 101-es
szabályon is átlép, mivel ez az első
csomag, így a dinamikus állapottartó
táblázatban sem szerepel még. A csomag
végül a 125-ös szabályra fog
illeszkedni: kifelé halad az internetre
csatlakozó hálózati
kártyán. A csomagban azonban még mindig
az eredeti forrás IP-címe
található, amely a helyi hálózat
egyik gépére hivatkozik. A szabály
illeszkedésekor két cselekvés is
végbemegy. A keep-state
opció
hatására ez a szabály felveszi ezt a
kapcsolatot az állapottartó dinamikus
szabályok közé és végrehajtja
a másik megadott feladatot. Ez a feladat része
a dinamikus táblázatba rögzített
bejegyzésnek, ami ebben az esetben a skipto
500
(„ugorjunk az 500-as
szabályra”) lesz. Az 500-as szabály a
továbbküldés előtt lefordítja a
csomag forrás IP-címét. Ezt ne
felejtsük el, nagyon fontos! A csomag ezután
eljut a céljához, és visszatérve
ismét belép a szabályrendszer
tetején. Ezúttal illeszkedni fog a 100-as
szabályra és a cél IP-címét
visszafordítjuk a helyi hálózatunk
megfelelő gépének címére.
Ezután a check-state
szabályhoz kerül, amely megtalálja a
dinamikus szabályok között és
továbbengedi a belső hálózatra.
Ezzel visszakerül a küldő géphez, amely
egy újabb csomagot küld egy újabb
adatszeletet kérve a távoli szervertől.
Ekkor már a check-state
szabály megtalálja a hozzá tartozó
bejegyzést a dinamikus szabályok
között és végrehajtódik a
korábban letárolt skipto 500
művelet. A csomag erre az 500-as szabályra ugrik,
ahol lefordítjuk a címét és
továbbküldjük.
Az bejövő oldalon minden, ami egy
korábban kialakult kapcsolat részeként
érkezik, automatikusan a check-state
és a megfelelő helyre rakott divert
natd
szabályok által dolgozódik
fel. Itt mindössze a rossz csomagok
eldobásával és a hitelesített
szolgáltatások elérésének
biztosításával kell foglalkoznunk.
Például a tűzfalon egy webszerver fut,
és azt szeretnénk, hogy az internetről
képesek legyenek elérni a rajta levő
oldalakat. Az újonnan beérkező
kapcsolatépítési kérelem a 100-as
szabályra fog illeszkedni, amelynek a cél
IP-címét a tűzfal helyi
hálózaton található
címére fogjuk leképezni. A csomagot
ezután még megvizsgáljuk, nem tartalmaz-e
valamilyen huncutságot, majd végül a
425-ös szabálynál fog kikötni. Az
egyezéskor két dolog történhet: a
csomaghoz felveszünk egy dinamikus szabályt, de
ezúttal az adott forrás IP-címről
érkező kapcsolatkérések
számát 2-re lekorlátozzuk. Ezzel az
adott szolgáltatás portján meg tudjuk
óvni a tűzfalat üzemeltető gépet
a DoS típusú támadásoktól.
A csomagot ezután hozzá tartozó
cselekvés szerint továbbengedjük a
belső hálózat felé.
Visszatéréskor a tűzfal felismeri, hogy a
csomag egy már meglevő kapcsolathoz tartozik,
ezért közvetlenül az 500-as szabályhoz
kerül címfordításra, majd a
kimenő interfészen keresztül
továbbküldjük.
Íme az első példa egy ilyen szabályrendszerre:
A következő példa teljesen megegyezik az előzővel, azonban itt már dokumentációs szándékkal szerepelnek megjegyzések is, melyek a tapasztalatlan IPFW szabályíróknak segítik jobban megérteni a szabályok pontos működését.
A második példa:
Ha kérdése van a FreeBSD-vel kapcsolatban, a
következő címre írhat (angolul):
<questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon:
<gabor@FreeBSD.org>.