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:
ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled
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:
net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=5
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.
options IPFIREWALL
Ez a beállítás engedélyezi az IPFW használatát a rendszermag részeként.
options IPFIREWALL_VERBOSE
Ezzel és a log kulcsszóval tudjuk az IPFW szabályain keresztülhaladó csomagokat naplózni.
options IPFIREWALL_VERBOSE_LIMIT=5
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.
options IPFIREWALL_DEFAULT_TO_ACCEPT
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.
options IPDIVERT
Ezzel a beállítással engedélyezzük a címfordítás használatát.
Megjegyzés: 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:
firewall_enable="YES"
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:
firewall_type="open"
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
állománynév -- a tűzfal szabályait tartalmazó állomány abszolút elérési útvonala
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:
add deny in add deny out
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:
#!/bin/sh ipfw -q flush ipfw add deny in ipfw add deny out
Megjegyzés: 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ő:
firewall_logging="YES"
Figyelem: A
firewall_loggingváltozó egyedül csak annyit tesz, hogy beállítja anet.inet.ip.fw.verbosesysctl változónak az 1 értéket (lásd 30.6.1 Szakasz). 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:net.inet.ip.fw.verbose_limit=5
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 Szakaszban 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.
Megjegyzés: 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.
Figyelem: 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ályokhoz mindig tartozik egy sorszám is.
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.
Megjegyzés: 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é:
last message repeated 45 times
Ami magyarul így hangzik:
az utolsó üzenet 45 alkalommal ismétlődött meg
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:
####### itt kezdődik az ipfw szabályait tartalmazó szkript ###### # ipfw -q -f flush # töröljük az összes aktuális szabályt # Set defaults oif="tun0" # a kimenő interfész odns="192.0.2.11" # az internet szolgáltató névszerverének IP-címe cmd="ipfw -q add " # a szabályok hozzáadásához szükséges elemek ks="keep-state" # csupán a lustaság miatt $cmd 00500 check-state $cmd 00502 deny all from any to any frag $cmd 00501 deny tcp from any to any established $cmd 00600 allow tcp from any to any 80 out via $oif setup $ks $cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks $cmd 00611 allow udp from any to $odns 53 out via $oif $ks #### itt fejeződik be az ipfw szabályait tartalmazó szkript ######
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.
############## Itt kezdődnek az IPFW szabályai ##########################
# Kezdés előtt töröljük az összes aktív szabályt.
ipfw -q -f flush
# Állítsuk be a parancsok további szükséges opciót.
cmd="ipfw -q add"
pif="dc0" # az internethez csatlakozó
# interfész neve
#################################################################
# A belső hálózat számára ne korlátozzunk semmit se.
# Ha nincs helyi hálózatunk, akkor erre nincs szükségünk.
# Az 'xl0' nevét írjuk át a helyi hálózatra csatlakozó
# interfész nevére.
################################################################
#$cmd 00005 allow all from any to any via xl0
################################################################
# A rendszer belső interfészét se szűrjük.
################################################################
$cmd 00010 allow all from any to any via lo0
################################################################
# A csomagot engedjük át a tűzfalon, ha korábban már felvettünk
# hozzá egy dinamikus szabályt a keep-state opcióval.
################################################################
$cmd 00015 check-state
################################################################
# Az internet felé forgalmazó interfész (kimenő kapcsolatok)
# A saját hálózatunkról belülről vagy erről az átjáróról
# kezdeményezett kapcsolatokat vizsgáljuk az internet felé.
################################################################
# Kifelé engedélyezzük az internet-szolgáltatónk névszerverének
# elérését. Az x.x.x.x a szolgáltatónk névszerverének IP-címe
# legyen. Ha a szolgáltatónak több névszervere is van, akkor
# másoljuk le ezeket a sorokat és az /etc/resolv.conf
# állományban található IP-címeket helyettesítsük be.
$cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state
$cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state
# Kábel/DSL konfigurációk esetében kifelé engedélyezzük a
# szolgáltatónk DHCP szerverének elérését. Ha a "felhasználói
# PPP"-t használjuk, akkor erre nem lesz szükségünk, az egész
# csoportot törölhetjük. Az alábbi szabállyal csíphetjük el a
# beírandó IP-címet. Ha a naplóban megtaláltuk, akkor vegyük
# ki az első szabályt, a másodikba írjuk bele a címet és
# engedélyezzük.
$cmd 00120 allow log udp from any to any 67 out via $pif keep-state
#$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state
# Kifelé engedélyezzük a szabvány nem biztonságos WWW
# funkció elérését.
$cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state
# Kifelé engedélyezzük a biztonságos HTTPS funkció
# elérését TLS SSL használatával.
$cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state
# Kifelé engedélyezzük a e-mailek küldését és fogadását.
$cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state
$cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state
# Kifelé engedélyezzük a FreeBSD (a make install és a CVSUP)
# funkcióit. Ezzel lényegében a rendszeradminisztrátornak
# ,,ISTENI'' jogokat adunk.
$cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root
# Kifelé engedélyezzük a pinget.
$cmd 00250 allow icmp from any to any out via $pif keep-state
# Kifelé engedélyezzük az idő szolgáltatást.
$cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state
# Kifelé engedélyezzük az nntp news szolgáltatást
# (vagyis a hírcsoportokat)
$cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state
# Kifelé engedélyezzük a biztonságos FTP, telnet és SCP
# elérését az SSH (secure shell) használatával.
$cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state
# Kifelé engedélyezzük a whois szolgáltatást.
$cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state
# Dobjuk el és naplózzunk mindent, ami megpróbál kijutni.
# Ez a szabály gondoskodik róla, hogy alapértelmezés szerint
# mindent blokkoljunk.
$cmd 00299 deny log all from any to any out via $pif
################################################################
# Az internet felőli interfész (bejövő kapcsolatok)
# A saját hálózatunk felé vagy erre az átjáróra
# nyitott kapcsolatokat vizsgáljuk az internet felől.
################################################################
# Blokkoljunk minden olyan bejövő forgalmat, amely a fenntartott
# címtartományok felé tart.
$cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP
$cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP
$cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP
$cmd 00303 deny all from 127.0.0.0/8 to any in via $pif #helyi
$cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #helyi
$cmd 00305 deny all from 169.254.0.0/16 to any in via $pif #DHCP
$cmd 00306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott
$cmd 00307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszterek összekötésére használt
$cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast
# A nyilvános pingek tiltása.
$cmd 00310 deny icmp from any to any in via $pif
# Az ident szolgáltatás tiltása.
$cmd 00315 deny tcp from any to any 113 in via $pif
# Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram,
# 139=session. A Netbios az MS Windows megosztását implementálja.
# Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es
# porton.
$cmd 00320 deny tcp from any to any 137 in via $pif
$cmd 00321 deny tcp from any to any 138 in via $pif
$cmd 00322 deny tcp from any to any 139 in via $pif
$cmd 00323 deny tcp from any to any 81 in via $pif
# Eldobjuk az összes későn érkező csomagot.
$cmd 00330 deny all from any to any frag in via $pif
# Eldobjuk azokat az ACK csomagokat, amelyek egyik dinamikus
# szabálynak sem felelnek meg.
$cmd 00332 deny tcp from any to any established in via $pif
# Befelé engedélyezzük a szolgáltató DHCP szerverének válaszát. Ebben
# a szabályban csak a DHCP szerver IP-címe szerepelhet, mivel ez az
# egyetlen olyan hitelesített forrás, ami ilyen csomagokat küldhet.
# Ez csak a kábeles és DSL típusú kapcsolatok esetében szükséges.
# Amikor a "felhasználói PPP"-vel csatlakozunk az internethez, nem
# kell ez a szabály. Ugyanazt az IP-címet kell megadnunk, amelyet a
# kimenő kapcsolatoknál is.
#$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state
# Befelé engedélyezzük a szabvány WWW funkciót, mivel webszerverünk
# is van.
$cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2
# Befelé engedélyezzük a biztonságos FTP, telnet és SCP
# típusú kapcsolatokat az internetről.
$cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2
# Befelé engedélyezzük az internetről érkező nem biztonságos telnet
# kapcsolatokat. Azért tekintjük nem biztonságosnak, mert az
# azonosítók és a jelszavak az interneten titkosítatlanul vándorolnak.
# Töröljük ezt a csoportot, ha nincs telnet szolgáltatásunk.
$cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2
# Dobjuk el és naplózzuk az összes többi kintről érkező csomagot.
$cmd 00499 deny log all from any to any in via $pif
# Alapértelmezés szerint dobjuk el mindent. Az ide érkező
# csomagokat is naplózzuk, amiből többet is ki tudunk majd
# deríteni.
$cmd 00999 deny log all from any to any
############# Itt fejeződnek be az IPFW szabályai #####################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.
natd_enable="YES" # engedélyezzük a címfordításért felelős démont natd_interface="rl0" # az internet felé mutató hálózati kártya neve natd_flags="-dynamic -m" # -m = a portszámok megtartása, ha lehetséges
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:
#!/bin/sh cmd="ipfw -q add" skip="skipto 500" pif=rl0 ks="keep-state" good_tcpo="22,25,37,43,53,80,443,110,119" ipfw -q -f flush $cmd 002 allow all from any to any via xl0 # nem szűrjük a belső hálózatot $cmd 003 allow all from any to any via lo0 # nem szűrjük a helyi interfészt $cmd 100 divert natd ip from any to any in via $pif $cmd 101 check-state # A kimenő csomagok hitelesítése: $cmd 120 $skip udp from any to xx.168.240.2 53 out via $pif $ks $cmd 121 $skip udp from any to xx.168.240.5 53 out via $pif $ks $cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks $cmd 130 $skip icmp from any to any out via $pif $ks $cmd 135 $skip udp from any to any 123 out via $pif $ks # Az összes olyan csomagot eldobjuk, amely a fenntartott # címtartományokba tart: $cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszter $cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # Az érkező csomagok hitelesítése: $cmd 400 allow udp from xx.70.207.54 to any 68 in $ks $cmd 420 allow tcp from any to me 80 in via $pif setup limit src-addr 1 $cmd 450 deny log ip from any to any # Ide ugrunk a kimenő állapottartó szabályoknál: $cmd 500 divert natd ip from any to any out via $pif $cmd 510 allow ip from any to any ##################### a szabályok vége ##################
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:
#!/bin/sh
############# Az IPFW szabályai itt kezdődnek ###########################
# Kezdés előtt töröljük az összes jelenleg aktív szabályt:
ipfw -q -f flush
# Beállítjuk a parancsok megfelelő előtagjait:
cmd="ipfw -q add"
skip="skipto 800"
pif="rl0" # az internethez csatlakozó
# hálózati interfész neve
#################################################################
# A belső hálózat számára ne korlátozzunk semmit se.
# Ha nincs helyi hálózatunk, akkor erre nincs szükségünk.
# Az 'xl0' nevét írjuk át a helyi hálózatra csatlakozó
# interfész nevére.
#################################################################
$cmd 005 allow all from any to any via xl0
#################################################################
# A rendszer belső interfészét se szűrjük.
#################################################################
$cmd 010 allow all from any to any via lo0
#################################################################
# Ellenőrizzük, hogy ez egy beérkező csomag és ha igen, akkor
# fordítsuk a címét.
#################################################################
$cmd 014 divert natd ip from any to any in via $pif
#################################################################
# Ha ehhez a csomaghoz korábban már vettük fel dinamikus
# szabályt a keep-state opció révén, akkor engedjük tovább.
#################################################################
$cmd 015 check-state
#################################################################
# Az internet felé forgalmazó interfész (kimenő kapcsolatok)
# A saját hálózatunkról belülről vagy erről az átjáróról
# kezdeményezett kapcsolatokat vizsgáljuk az internet felé.
#################################################################
# Kifelé engedélyezzük az internet-szolgáltatónk névszerverének
# elérését. Az x.x.x.x a szolgáltató névszerverének IP-címe
# lesz. Ha a szolgáltatónknak több névszervere is van, akkor
# az /etc/resolv.conf állományból nézzük ki a címeiket és
# másoljuk le az alábbi sor mindegyikükhöz.
$cmd 020 $skip tcp from any to x.x.x.x 53 out via $pif setup keep-state
# A kábeles és DSL kapcsolatok esetén engedélyezzük a szolgáltató
# DHCP szerverének elérését.
$cmd 030 $skip udp from any to x.x.x.x 67 out via $pif keep-state
# Kifelé engedélyezzük a szabvány nem biztonságos WWW funkciót
$cmd 040 $skip tcp from any to any 80 out via $pif setup keep-state
# Kifelé engedélyezzük a biztonságos HTTPS funkciót a TLS SSL
# használatával.
$cmd 050 $skip tcp from any to any 443 out via $pif setup keep-state
# Kifelé engedélyezzük az e-mailek küldését és fogadását.
$cmd 060 $skip tcp from any to any 25 out via $pif setup keep-state
$cmd 061 $skip tcp from any to any 110 out via $pif setup keep-state
# Kifelé engedélyezzük a FreeBSD (make install és CVSUP) funkcióit.
# Ezzel a rendszeradminisztrátornak ,,ISTENI'' jogokat adunk.
$cmd 070 $skip tcp from me to any out via $pif setup keep-state uid root
# Kifelé engedélyezzük a pinget.
$cmd 080 $skip icmp from any to any out via $pif keep-state
# Kifelé engedélyezzük az idő szolgáltatást.
$cmd 090 $skip tcp from any to any 37 out via $pif setup keep-state
# Kifelé engedélyezzük az nntp news szolgáltatást (tehát a
# hírcsoportokat).
$cmd 100 $skip tcp from any to any 119 out via $pif setup keep-state
# Kifelé engedélyezzük a biztonságos FTP, telnet és SCP
# funkciókat az SSH (secure shell) használatával.
$cmd 110 $skip tcp from any to any 22 out via $pif setup keep-state
# Kifelé engedélyezzük ki a whois kéréseket.
$cmd 120 $skip tcp from any to any 43 out via $pif setup keep-state
# Kifelé engedélyezzük az NTP időszerver elérését.
$cmd 130 $skip udp from any to any 123 out via $pif keep-state
#################################################################
# Az internet felőli interfész (bejövő kapcsolatok)
# A saját hálózatunk felé vagy erre az átjáróra
# nyitott kapcsolatokat vizsgáljuk az internet felől.
#################################################################
# Tiltsuk a fenntartott címtartományok felé haladó összes beérkező
# forgalmat.
$cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP
$cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP
$cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP
$cmd 303 deny all from 127.0.0.0/8 to any in via $pif #helyi
$cmd 304 deny all from 0.0.0.0/8 to any in via $pif #helyi
$cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP
$cmd 306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott
$cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszter
$cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast
# Az ident tiltása.
$cmd 315 deny tcp from any to any 113 in via $pif
# Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram,
# 139=session. A Netbios az MS Windows megosztását implementálja.
# Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es
# porton.
$cmd 320 deny tcp from any to any 137 in via $pif
$cmd 321 deny tcp from any to any 138 in via $pif
$cmd 322 deny tcp from any to any 139 in via $pif
$cmd 323 deny tcp from any to any 81 in via $pif
# Dobjuk el a későn érkező csomagokat.
$cmd 330 deny all from any to any frag in via $pif
# Dobjuk el azokat az ACK csomagokat, amelyekre nincs
# dinamikus szabály.
$cmd 332 deny tcp from any to any established in via $pif
# Engedélyezzük a szolgáltató DHCP szerverétől érkező forgalmat. Ennek
# a szabálynak tartalmaznia kell a DHCP szerver címét, mert csak tőle
# fogadunk el ilyen típusú csomagokat. Egyedül csak kábeles vagy DSL
# konfigurációk esetén használatos, a "felhasználói PPP" esetében
# törölhetjük. Ez ugyanaz az IP-cím, amelyet a kimenő kapcsolatoknál
# megadtunk.
$cmd 360 allow udp from x.x.x.x to any 68 in via $pif keep-state
# Befelé engedélyezzük a szabvány WWW funkciót, mivel van
# webszerverünk.
$cmd 370 allow tcp from any to me 80 in via $pif setup limit src-addr 2
# Befelé engedélyezzük a biztonságos FTP, telnet és SCP
# használatát az internetről.
$cmd 380 allow tcp from any to me 22 in via $pif setup limit src-addr 2
# Befelé engedélyezzük a nem biztonságos telnet elérését az
# internetről. Azért nem tekintjük biztonságosnak, mert az
# azonosítókat és a jelszavakat az interneten titkosítatlanul
# közvetíti. Ha nincs telnet szolgáltatásunk, akkor törölhetjük is ezt
# a csoportot.
$cmd 390 allow tcp from any to me 23 in via $pif setup limit src-addr 2
# Dobjuk el és naplózzuk az összes internetről érkező hitelesítetlen kapcsolatot.
$cmd 400 deny log all from any to any in via $pif
# Dobjuk el és naplózzuk az összes internetre menő hitelesítetlen kapcsolatot.
$cmd 450 deny log all from any to any out via $pif
# Ez lesz a kimenő szabályokhoz tartozó "skipto" célja.
$cmd 800 divert natd ip from any to any out via $pif
$cmd 801 allow ip from any to any
# Minden mást alapértelmezés szerint tiltunk és naplózunk.
$cmd 999 deny log all from any to any
############# Az IPFW szabályai itt fejeződnek be #####################Ha kérdése van a FreeBSD-vel kapcsolatban, a következő
címre írhat (angolul): <freebsd-questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése,
kérjük erre a címre írjon: <gabor@FreeBSD.org>.