doc/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.xml
Gabor Kovesdan a6684b4306 - Reduce the misuse of role attribute; role="directory" should actually be
class="directory"
- Add constraint to enforce this
2013-04-04 11:40:58 +00:00

4555 lines
150 KiB
XML

<?xml version="1.0" encoding="iso-8859-2"?>
<!--
The FreeBSD Documentation Project
$FreeBSD$
-->
<!-- The FreeBSD Hungarian Documentation Project
Translated by: PALI, Gabor <pgj@FreeBSD.org>
%SOURCE% en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
%SRCID% 1.94
-->
<chapter id="firewalls" lang="hu">
<chapterinfo>
<authorgroup>
<author>
<firstname>Joseph J.</firstname>
<surname>Barbish</surname>
<contrib>Írta: </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Brad</firstname>
<surname>Davis</surname>
<contrib>SGML formátumúra alakította
és aktualizálta: </contrib>
</author>
</authorgroup>
</chapterinfo>
<title>Tűzfalak</title>
<indexterm><primary>tűzfalak</primary></indexterm>
<indexterm>
<primary>biztonság</primary>
<secondary>tűzfalak</secondary>
</indexterm>
<sect1 id="firewalls-intro">
<title>Bevezetés</title>
<para>A tűzfalakkal a rendszerünkön
keresztülfolyó bejövő és kimenő
forgalmat tudjuk szűrni. A tűzfalak egy vagy több
<quote>szabályrendszer</quote> alapján
vizsgálják az éppen érkező vagy
távozó hálózati csomagokat, és
vagy továbbengedik ezeket vagy
megállítják. A tűzfalak
szabályai a csomagok egy vagy több
jellemzőjét veszik szemügyre, amelyek lehetnek
például a protokoll típusa, a forrás
vagy cél hálózati címe, esetleg a
forrás- vagy a célport.</para>
<para>A tűzfalak jelentős mértékben
képesek gyarapítani egy gép vagy egy
hálózat védelmét. Leginkább a
következőkre tudjuk felhasználni:</para>
<itemizedlist>
<listitem>
<para>A belső hálózatunkban futó
alkalmazások, szolgáltatások,
gépek megvédésére és
elszigetelésére az internetről
érkező nem kívánt forgalom
ellen</para>
</listitem>
<listitem>
<para>A belső hálózatban levő
gépek elérését tudjuk
korlátozni vagy letiltani az interneten
elérhető szolgáltatások
felé</para>
</listitem>
<listitem>
<para>A hálózati címfordítás
(Network Address Translation, <acronym>NAT</acronym>)
beállításához, ahol a belső
hálózatunk privát
<acronym>IP</acronym>-címeket használnak
és egy közös kapcsolaton keresztül
érik el az internetet (egyetlen
<acronym>IP</acronym>-címmel, vagy pedig automatikusan
kiosztott publikus címekkel).</para>
</listitem>
</itemizedlist>
<para>A fejezet elolvasása során
megismerjük:</para>
<itemizedlist>
<listitem>
<para>hogyan adjuk meg helyesen a csomagok
szűrését leíró
szabályokat;</para>
</listitem>
<listitem>
<para>a &os;-be épített tűzfalak közti
különbségeket;</para>
</listitem>
<listitem>
<para>hogyan állítsuk be és
használjuk az OpenBSD <application>PF</application>
tűzfalát;</para>
</listitem>
<listitem>
<para>hogyan állítsuk be és
használjuk az <application>IPFILTER</application>
tűzfalat;</para>
</listitem>
<listitem>
<para>hogyan állítsuk be és
használjuk az <application>IPFW</application>
tűzfalat.</para>
</listitem>
</itemizedlist>
<para>A fejezet elolvasása előtt ajánlott:</para>
<itemizedlist>
<listitem>
<para>a &os;-hez és az internethez kötődő
alapvető fogalmak ismerete.</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="firewalls-concepts">
<title>Röviden a tűzfalakról</title>
<indexterm>
<primary>tűzfalak</primary>
<secondary>szabályrendszerei</secondary>
</indexterm>
<para>A tűzfalak szabályrendszereit alapvetően
kétféleképpen tudjuk
összeállítani: <quote>inkluzív</quote>,
vagyis megengedő, illetve <quote>exkluzív</quote>
vagyis kizáró módon. Az exkluzív
tűzfalak minden forgalmat átengednek, amiről nem
rendelkeznek a tűzfal szabályai. Az inkluzív
tűzfalak ennek pontosan az ellenkezőjét teszik.
Csak azt a forgalmat engedik át, amiről van
szabály és minden mást blokkolnak.</para>
<para>Az inkluzív tűzfalak alkalmazásával
sokkal jobban kezünkbentudjuk tartani a
hálózatunk kimenő forgalmát,
ezért leginkább az internetes
szolgáltatásokat futtató rendszerek
esetében bizonyulhat jobb választásnak.
Emellett az internetről a hálózatunk
felé irányuló forgalmat is képes
szabályozni. Ekkor az egyetlen szabályra sem
illeszkedő csomagokat egyszerűen eldobjuk és
naplózzuk. Az inkluzív tűzfalak
általában biztonságosabbak az exkluzív
típusú társaiknál, mivel
esetükben jelentős mértékben visszaszorul
a nem kívánatos átfolyó
forgalom.</para>
<note>
<para>Hacsak nem emeljük ki külön, a fejezet
további részében minden
példaként megadott szabályrendszer
inkluzív tűzfalat hoz létre.</para>
</note>
<para>Ez a típusú védelem még
tovább fokozható az
<quote>állapottartó tűzfalak</quote> (stateful
firewall) használatával. Az ilyen
típusú tűzfalak szemmel tartják a rajtuk
keresztül megnyitott kapcsolatokat, és vagy csak a
már meglevő kapcsolathoz tartozó forgalmat
engedik át vagy nyitnak egy újat. Az
állapottartó tűzfalak hátránya,
hogy a <quote>Denial of Service</quote> (<acronym>DoS</acronym>)
típusú támadásokkal szemben sokkal
sérülékenyebbek olyan helyzetekben, amikor az
új kapcsolatok nagyon gyorsan jönnek létre. A
legtöbb tűzfal esetében azonban tudjuk
vegyíteni az állapottartó és nem
állapottartó viselkedést, és ezzel egy
ideális beállítást
kialakítani.</para>
</sect1>
<sect1 id="firewalls-apps">
<title>Tűzfalak</title>
<para>A &os; alaprendszerébe három
különböző tűzfalat
építettek be, melyek a következők: az
<emphasis>IPFILTER</emphasis> (másik nevén
<acronym>IPF</acronym>), az <emphasis>IPFIREWALL</emphasis>
(más néven <acronym>IPFW</acronym>) és az
<emphasis>OpenBSD csomagszűrője</emphasis> (Packet
Filter, azaz <acronym>PF</acronym>). A forgalom
szabályozására (vagyis alapvetően a
sávszélesség
kihasználtságának
vezérlésére) a &os; két
beépített csomagot tartalmaz: ez az &man.altq.4;
és a &man.dummynet.4;. Általában a Dummynet
az <acronym>IPFW</acronym>, míg az <acronym>ALTQ</acronym>
a <acronym>PF</acronym> partnere. Az IPFILTER esetében
maga az IPFILTER végzi a címfordítást
és a szűrést, a
sávszélességet pedig az
<acronym>IPFW</acronym> a &man.dummynet.4;
<emphasis>vagy</emphasis> a <acronym>PF</acronym> az
<acronym>ALTQ</acronym> segítségével. Az
<acronym>IPFW</acronym> és a <acronym>PF</acronym>
szabályokkal rendelkezik a rendszerünkbe
érkező vagy onnan távozó
csomagokról, habár megoldásaik teljesen
máshogy működnek és a szabályok
megadási módja is eltér.</para>
<para>A &os; azért tartalmaz egyszerre ennyiféle
tűzfalat, mert az emberek elvárásai és
igényei eltérnek. Egyikük sem tekinthető
a legjobbnak.</para>
<para>A szerző egyébként az IPFILTER
megoldását részesíti előnyben,
mivel egy hálózati címfordítást
alkalmazó környezetben sokkal könnyebb vele
megfogalmazni az állapottartó szabályokat,
valamint tartalmaz egy beépített FTP proxyt is,
amivel így a kimenő FTP kapcsolatok
beállítása még tovább
egyszerűsödik.</para>
<para>Mivel az összes tűzfal a csomagok
fejlécének bizonyos mezőinek alapján
dolgozik, ezért a tűzfal
szabályrendszerét megalkotó egyénnek
teljesen tisztában kell lennie a <acronym>TCP/IP</acronym>
működésével, továbbá azzal,
hogy ezekben a mezőkben milyen értékek
szerepelhetnek és ezeket hogyan használják
egy átlagos kapcsolat alatt. Ebben a témában
a <ulink url="http://www.ipprimer.com/overview.cfm"></ulink>
címen találhatunk egy remek ismertetőt
(angolul).</para>
</sect1>
<sect1 id="firewalls-pf">
<sect1info>
<authorgroup>
<author>
<firstname>John</firstname>
<surname>Ferrell</surname>
<contrib>Átnézte és
aktualizálta:</contrib>
</author>
</authorgroup>
</sect1info>
<title>Az OpenBSD csomagszűrője (PF) és az
<acronym>ALTQ</acronym></title>
<indexterm>
<primary>tűzfalak</primary>
<secondary>PF</secondary>
</indexterm>
<para>2003 júliusában az OpenBSD <acronym>PF</acronym>
néven ismert csomagszűrőjét
átírták &os;-re és
elérhetővé tették a &os;
Portgyűjteményének részeként. A
<acronym>PF</acronym> programot beépítetten
tartalmazó első kiadás pedig 2004
novemberében a &os;&nbsp;5.3 volt. A <acronym>PF</acronym>
egy teljes, mindentudó tűzfal, amely támogatja
az ún. <acronym>ALTQ</acronym> (Alternate Queuing, vagyis
a <quote>váltóbesorolás</quote>)
megoldást. Az <acronym>ALTQ</acronym> lehetővé
teszi a sávszélesség
korlátozását a szolgáltatás
minősége (Quality of Service, <acronym>QoS</acronym>)
alapján.</para>
<para>Az OpenBSD Projekt kiváló munkát
végez a PF <ulink
url="http://www.openbsd.org/faq/pf/">felhasználói
útmutatójának</ulink>
karbantartásával. A kézikönyv ezen
szakasza ezért elsősorban azzal foglalkozik, hogyan
kell a <acronym>PF</acronym>-et &os; alatt használni,
miközben igyekszik egy általános
összefoglalást adni a témáról. A
részletesebb információkkal kapcsolatban
azonban feltétlenül nézzük meg a
felhasználói útmutatót.</para>
<para>A <ulink url="http://pf4freebsd.love2party.net/"></ulink>
címen olvashatunk többet arról (angolul), hogy
a <acronym>PF</acronym>-et hogyan használjunk
&os;-n.</para>
<sect2>
<title>A PF rendszermagmodulok használata</title>
<para>A <acronym>PF</acronym> modul
betöltéséhez a következő sort kell
felvennünk az <filename>/etc/rc.conf</filename>
állományba:</para>
<programlisting>pf_enable="YES"</programlisting>
<para>Ezt követően futtassuk le a
hozzá tartozó rendszerindító
szkriptet:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/pf start</userinput></screen>
<para>A <acronym>PF</acronym> modul abban az esetben nem fog
betöltődni, ha nem találja a szabályokat
tartalmazó konfigurációs
állományt. Ez alapértelmezés
szerint az <filename>/etc/pf.conf</filename>
állomány. Ha a szabályok
leírása rendszerünkön máshol
található, akkor az
<filename>/etc/rc.conf</filename> állományban a
következő módon adhatjuk meg annak pontos
helyét:</para>
<programlisting>pf_rules="<replaceable>/elérési/út/pf.conf</replaceable>"</programlisting>
<note>
<para>A &os;&nbsp;7.0 kiadással a minta
<filename>pf.conf</filename> állomány az
<filename class="directory">/etc</filename>
könyvtárból átkerült a
<filename class="directory">/usr/share/examples/pf</filename>
könyvtárba. A &os;&nbsp;7.0 előtti
kiadásokban alapértelmezés szerint
található egy <filename>pf.conf</filename>
állomány az <filename
class="directory">/etc</filename>
könyvtárban.</para>
</note>
<para>A <acronym>PF</acronym> modul parancssorból
akár kézzel is betölthető:</para>
<screen>&prompt.root; <userinput>kldload pf.ko</userinput></screen>
<para>A <acronym>PF</acronym> működésének
naplózását a <literal>pflog.ko</literal>
teszi lehetővé, amelyet az alábbi sor
hozzáadásával engedélyezhetünk
az <filename>/etc/rc.conf</filename>
állományban:</para>
<programlisting>pflog_enable="YES"</programlisting>
<para>A modul betöltését a
hozzá tartozó rendszerindító szkript
segítségével kérhetjük:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/pflog start</userinput></screen>
<para>Ha a <acronym>PF</acronym> többi
funkcióját is használni szeretnénk,
akkor ehhez egy új rendszermagot kell fordítanunk
<acronym>PF</acronym> támogatással.</para>
</sect2>
<sect2>
<title>A PF rendszermagbeli
beállításai</title>
<indexterm>
<primary>a rendszermag
beállításai</primary>
<secondary>device pf</secondary>
</indexterm>
<indexterm>
<primary>a rendszermag
beállításai</primary>
<secondary>device pflog</secondary>
</indexterm>
<indexterm>
<primary>a rendszermag
beállításai</primary>
<secondary>device pfsync</secondary>
</indexterm>
<para>Noha egyáltalán nem szükséges
beépítenünk a <acronym>PF</acronym>
támogatását a rendszermagba, abban az
esetben mégis szükségünk lehet
rá, amikor a <acronym>PF</acronym> olyan komolyabb
lehetőségeit szeretnénk kiaknázni,
amelyek már nem részei a modulnak. Ilyen
például a &man.pfsync.4;, amely a
<acronym>PF</acronym> által használt
állapottáblázatok bizonyos
változásainak megjelenítésére
alkalmas pszeudoeszköz. A &man.carp.4;
megoldásával párosítva így
akár hibatűrő tűzfalak is
kialakíthatóak a <acronym>PF</acronym>-fel. A
<acronym>CARP</acronym> megoldásáról a
kézikönyvben bővebb ismertetést a <xref
linkend="carp"/> ad.</para>
<para>A <acronym>PF</acronym> rendszermag
konfigurációs beállításai a
<filename>/usr/src/sys/conf/NOTES</filename>
állományban találhatóak:</para>
<programlisting>device pf
device pflog
device pfsync</programlisting>
<para>A <literal>device pf</literal>
beállítás engedélyezi a
csomagszűrő tűzfalat (&man.pf.4;).</para>
<para>A <literal>device pflog</literal> megadásával
keletkezik egy &man.pflog.4; pszeudo hálózati
eszköz, amellyel egy &man.bpf.4; eszközre
érkező forgalmat tudunk naplózni.
Ezután a &man.pflogd.8; démon
használható tőle származó
naplózott adatok
rögzítésére.</para>
<para>A <literal>device pfsync</literal> engedélyezi a
&man.pfsync.4; pszeudo hálózati eszköz
létrejöttét, amely az ún.
<quote>állapotváltások</quote>
megfigyelésére alkalmas.</para>
</sect2>
<sect2>
<title>Az <filename>rc.conf</filename> állományban
elérhető beállítások</title>
<para>A következő &man.rc.conf.5;
beállítások aktiválják a
rendszerindítás során a
<acronym>PF</acronym> és a &man.pflog.4;
használatát:</para>
<programlisting>pf_enable="YES" # a PF engedélyezése (a modul betöltése, ha kell)
pf_rules="/etc/pf.conf" # a pf szabályait tartalmazó állomány
pf_flags="" # a pfctl indításához szükséges további paraméterek
pflog_enable="YES" # a pflogd(8) elindítása
pflog_logfile="/var/log/pflog" # hol tartsa a pflogd az naplóit
pflog_flags="" # a pflogd indításához szükséges paraméterek</programlisting>
<para>Ha a tűzfalunk mögött egy helyi
hálózat is meghúzódik, akkor az ott
levő gépek számára valamilyen
módon tudnunk kell továbbítani a csomagokat
vagy címfordítást kell végezni,
így ez is mindenképpen kelleni fog:</para>
<programlisting>gateway_enable="YES" # az átjáró funkciók engedélyezése</programlisting>
</sect2>
<sect2>
<title>A szűrési szabályok
megfogalmazása</title>
<para>A <acronym>PF</acronym> a beállításait
a &man.pf.conf.5; állomány tárolja (amely
alapértelmezés szerint az
<filename>/etc/pf.conf</filename> helyen
található), és az ebben
található szabályok alapján
módosítja, dobja el vagy éppen engedi
át a csomagokat. A &os; rendszerünkben ehhez
találhatunk néhány példát a
<filename>/usr/share/examples/pf/</filename>
könyvtárban. A <acronym>PF</acronym> által
használt szabályokról minden
részletre kiterjedően a PF <ulink
url="http://www.openbsd.org/faq/pf/">felhasználói
útmutatójában</ulink> olvashatunk.</para>
<warning>
<para>A PF <ulink
url="http://www.openbsd.org/faq/pf/">felhasználói
útmutatójának</ulink>
olvasásakor ne feledkezzünk meg róla, hogy
a különböző &os; verziók
különböző <acronym>PF</acronym>
verziókat tartalmaznak. A
&os;&nbsp;7.<replaceable>X</replaceable> és
későbbi változatok az OpenBSD&nbsp;4.1
kiadásában szereplő <acronym>PF</acronym>
változatot tartalmazzák.</para></warning>
<para>A &a.pf; remek hely a <acronym>PF</acronym> tűzfal
beállításával és
futtatásával kapcsolatos kérdésekre.
A kérdezés előtt azonban ne felejtsük el
alaposan átnézni az archívumot!</para>
</sect2>
<sect2>
<title>A PF használata</title>
<para>A <acronym>PF</acronym> a &man.pfctl.8;
segítségével vezérelhető. Az
alábbiakban ezzel kapcsolatban most összefoglalunk
néhány hasznos parancsot (de ne felejtsük el
megnézni a &man.pfctl.8; man oldalon
található többi lehetőséget
sem):</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<thead>
<row>
<entry>Parancs</entry>
<entry>Leírás</entry>
</row>
</thead>
<tbody>
<row>
<entry><command>pfctl <option>-e</option></command></entry>
<entry>A PF engedélyezése</entry>
</row>
<row>
<entry><command>pfctl <option>-d</option></command></entry>
<entry>A PF tiltása</entry>
</row>
<row>
<entry><command>pfctl <option>-F</option> all <option>-f</option> /etc/pf.conf</command></entry>
<entry>Az összes (címfordítási,
szűrési, állapottartási stb.)
szabály törlése, és az
<filename>/etc/pf.conf</filename> állomány
újratöltése</entry>
</row>
<row>
<entry><command>pfctl <option>-s</option> [ rules | nat | state ]</command></entry>
<entry>A szűrési (<literal>rules</literal>),
címfordítási
(<literal>nat</literal>) és
állapottartási (<literal>state</literal>)
információk
lekérdezése</entry>
</row>
<row>
<entry><command>pfctl <option>-vnf</option> /etc/pf.conf</command></entry>
<entry>Az <filename>/etc/pf.conf</filename>
állomány ellenőrzése a benne
levő szabályok betöltése
nélkül</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>
<sect2>
<title>Az <acronym>ALTQ</acronym>
engedélyezése</title>
<para>Az <acronym>ALTQ</acronym> kizárólag csak
úgy használható, ha a
konfigurációs beállításokon
keresztül beépítjük a &os;
rendszermagjába. Az <acronym>ALTQ</acronym>
alkalmazását nem minden hálózati
kártya meghajtója támogatja, ezért
ezt a &man.altq.4; man oldalon ellenőrizzük.</para>
<para>A következő rendszermag
konfigurációs beállításokkal
engedélyezhetjük az <acronym>ALTQ</acronym>
használatát és bővíthetjük
azt további lehetőségekkel:</para>
<programlisting>options ALTQ
options ALTQ_CBQ # osztályozás alapú besorolás (Class Bases Queuing, CBQ)
options ALTQ_RED # véletlen korai észlelés (Random Early Detection, RED)
options ALTQ_RIO # RED befele/kifele
options ALTQ_HFSC # hiearchikus csomagütemező (Hierarchical Packet Scheduler, HFSC)
options ALTQ_PRIQ # prioritásos besorolás (Priority Queuing, PRIQ)
options ALTQ_NOPCC # az SMP esetén kell</programlisting>
<para>Az <literal>options ALTQ</literal> az
<acronym>ALTQ</acronym> rendszert engedélyezi.</para>
<para>Az <literal>options ALTQ_CBQ</literal> engedélyezi a
osztályozás alapú besorolást
(<emphasis>Class Based Queuing</emphasis>,
<acronym>CBQ</acronym>). A <acronym>CBQ</acronym>
használatával a kapcsolatunkhoz tartozó
sávszélességet
különböző osztályokra vagy sorokra
tudjuk bontani és a szűrési
szabályoknak megfelelően osztályozni
segítségükkel a forgalmat.</para>
<para>Az <literal>options ALTQ_RED</literal> a véletlen
korai észlelés (<emphasis>Random Early
Detection</emphasis>, <acronym>RED</acronym>)
használatát engedélyezi. A
<acronym>RED</acronym> a hálózati forgalomban
keletkező torlódások
elkerülésére alkalmas. A
<acronym>RED</acronym> ezt a problémát úgy
oldja meg, hogy méri a sorok hosszát és
összeveti a hozzá tartozó minimális
és maximális
küszöbértékekkel. Ha a sor hossza
meghaladja a számára előírt
maximális értéket, akkor az új
csomagokat eldobja. Nevéhez hűen a
<acronym>RED</acronym> az eldobásra ítélt
csomagokat véletlenszerűen választja
ki.</para>
<para>Az <literal>options ALTQ_RIO</literal> engedélyezi a
<acronym>RED</acronym> használatát mind a
két irányba, tehát be- és
kifelé.</para>
<para>Az <literal>options ALTQ_HFSC</literal> a pártatlan
hierachikus szolgáltatási görbe alapú
csomagütemezőt (<emphasis>Hierarchical Fair Service
Curve Packet Scheduler</emphasis>, <acronym>HFSC</acronym>)
engedélyezi. Vele kapcsolatban a <ulink
url="http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html"></ulink>
címen találhatunk bővebben
olvasnivalót (angolul).</para>
<para>Az <literal>options ALTQ_PRIQ</literal> a prioritásos
besorolást (<emphasis>Priority Queuing</emphasis>,
<acronym>PRIQ</acronym>) teszi elérhetővé. A
<acronym>PRIQ</acronym> mindig elsőként a nagyobb
értékű sorban levő forgalmat
továbbítja.</para>
<para>Az <literal>options ALTQ_NOPCC</literal> az
<acronym>ALTQ</acronym> <acronym>SMP</acronym>, vagyis
többprocesszoros támogatását adja meg.
Ilyen típusú rendszerekben ez
kötelező.</para>
</sect2>
</sect1>
<sect1 id="firewalls-ipf">
<title>Az IPFILTER (IPF) tűzfal</title>
<indexterm>
<primary>tűzfalak</primary>
<secondary>IPFILTER</secondary>
</indexterm>
<para>Az IPFILTER szerzője Darren Reed. Az IPFILTER nem
kötődik egyik rendszerhez sem: ez egy olyan nyílt
forráskódú alkalmazás, amelyet
átírtak &os;, NetBSD, OpenBSD, &sunos;, HP/UX
és &solaris; operációs rendszerekre. Az
IPFILTER karbantartása és támogatása
pillanatnyilag is aktív, folyamatosan jelennek meg
újabb változatai.</para>
<para>Az IPFILTER egy rendszermag oldalán
működő tűzfalazási és egy
címfordítási mechanizmusra alapszik, amelyet
felhasználói programokkal tudunk felügyelni
és vezérelni. A tűzfal szabályai az
&man.ipf.8; segédprogrammal
állíthatóak be vagy
törölhetőek. A hálózati
címfordításra vonatkozó
szabályokat az &man.ipnat.1; segédprogrammal
állíthatjuk be vagy törölhetjük. Az
&man.ipfstat.8; segédprogram képes futás
közben statisztikákat készíteni az
IPFILTER rendszermagban elhelyezkedő részeinek
viselkedéséről. Az &man.ipmon.8; program pedig
az IPFILTER cselekvéseit képes a
rendszernaplókba feljegyezni.</para>
<para>Az IPF eredetileg olyan szabályfeldolgozási
módszer szerint készült, amelyben <quote>az
utolsó egyező szabály nyer</quote> és
csak állapotnélküli szabályokat ismert.
Az idő múlásával az IPF
részévé vált a <quote>quick</quote>
opció és a <quote>keep state</quote> opción
keresztül az állapottartás is, melyek
drámai mértékben
korszerűsítették a szabályok
feldolgozásának elvét. Az IPF hivatalos
dokumentációja csak a régi szabályok
létrehozását és azok
feldolgozásának leírását
tartalmazza. A korszerűsített funkciók csak
kiegészítésképpen jelennek meg,
és az általuk felkínált
előnyök megértése egy sokkal magasabb
szintű és biztonságosabb tűzfal
megépítését teszik
lehetővé.</para>
<para>A szakaszban szereplő utasításokban olyan
szabályok szerepelnek, amelyek kihasználják a
<quote>quick</quote> és <quote>keep state</quote>
opciókat. Ezek az inkluzív
tűzfalszabályok létrehozásának
alapjai.</para>
<para>A régi típusú szabályokról
a <ulink
url="http://www.obfuscation.org/ipf/ipf-howto.html#TOC_1"></ulink>
és <ulink
url="http://coombs.anu.edu.au/~avalon/ip-filter.html"></ulink>
címeken olvashatunk (angolul).</para>
<para>Az IPF gyakran ismételt kérdései a <ulink
url="http://www.phildev.net/ipf/index.html"></ulink> címen
érhetőek el (angolul).</para>
<para>A nyílt forrású IPFILTER
levelezési lista kereshető archívumait a <ulink
url="http://marc.theaimsgroup.com/?l=ipfilter"></ulink>
címen találjuk (angolul).</para>
<sect2>
<title>Az IPF engedélyezése</title>
<indexterm>
<primary>IPFILTER</primary>
<secondary>engedélyezés</secondary>
</indexterm>
<para>Az IPF megtalálható a &os;
alaptelepítésében mint menet közben
külön betölthető modul. Ha az
<filename>rc.conf</filename> állományba
beírjuk a <literal>ipfilter_enable="YES"</literal> sort,
akkor ez a modul dinamikusan betöltődik. A
betölthető modul alapból naplóz
és a <literal>default pass all</literal>
beállítást tartalmazza. Ha helyette a
<literal>block all</literal> szabályt akarjuk
használni, akkor emiatt még nem kell
feltétlenül újrafordítanunk a &os;
rendszermagját, elég ha egyszerűen csak a
szabályrendszerünk végére
beszúrjuk.</para>
</sect2>
<sect2>
<title>A rendszermag beállításai</title>
<indexterm>
<primary>a rendszermag
beállításai</primary>
<secondary>IPFILTER</secondary>
</indexterm>
<indexterm>
<primary>a rendszermag
beállításai</primary>
<secondary>IPFILTER_LOG</secondary>
</indexterm>
<indexterm>
<primary>a rendszermag
beállításai</primary>
<secondary>IPFILTER_DEFAULT_BLOCK</secondary>
</indexterm>
<indexterm>
<primary>IPFILTER</primary>
<secondary>a rendszermag
beállításai</secondary>
</indexterm>
<para>Az IPF használatához nem kötelező a
következő beállításokkal
újrafordítani a &os; rendszermagját, itt
csupán
háttérinformációként
szerepel. Amikor az IPF a rendszermagba kerül, a
betölhető modulra nem lesz szükség.</para>
<para>Az IPF a rendszermag forrásai között
található
<filename>/usr/src/sys/conf/NOTES</filename>
állományban megadott
beállításai a következő
módon foglalhatóak össze:</para>
<programlisting>options IPFILTER
options IPFILTER_LOG
options IPFILTER_DEFAULT_BLOCK</programlisting>
<para>Az <literal>options IPFILTER</literal> engedélyezi az
<quote>IPFILTER</quote> tűzfal
támogatását.</para>
<para>Az <literal>options IPFILTER_LOG</literal>
hatására az IPF az <devicename>ipl</devicename>
csomagnaplózó pszeudo eszközre jegyzi fel a
forgalmat &mdash; minden olyan szabály esetén,
ahol megjelenik a <literal>log</literal> kulcsszó.</para>
<para>Az <literal>options IPFILTER_DEFAULT_BLOCK</literal>
megváltoztatja az alapértelmezett
viselkedést, tehát minden olyan csomag, amely nem
illeszkedik a tűzfal valamelyik <literal>pass</literal>
típusú (átengedő)
szabályára, blokkolásra kerül.</para>
<para>Ezek a beállítások csak azt
követően érvényesülnek, ha
fordítottunk és telepítettünk
velük egy új rendszermagot.</para>
</sect2>
<sect2>
<title>Az <filename>rc.conf</filename> állomány
beállításai</title>
<para>Az <filename>/etc/rc.conf</filename>
állományban a következő
utasításokra lesz szükségünk az
IPF működésbe hozására a rendszer
indítása során:</para>
<programlisting>ipfilter_enable="YES" # az ipf tűzfal indítása
ipfilter_rules="/etc/ipf.rules" # betölti a szabályokat tartalmazó szöveges állományt
ipmon_enable="YES" # elindítja az IP monitor naplózását
ipmon_flags="-Ds" # D = indítás démonként
# s = naplózás a syslog használatával
# v = a tcp ablak, ack, seq csomagok naplózása
# n = az IP-címek és portok feloldása</programlisting>
<para>Ha olyan helyi hálózat áll meg a
tűzfal mögött, amely egy fenntartott
privát IP-címtartományt használ,
akkor még a következő
utasításokra is szükségünk lesz a
címfordítás
bekapcsolásához:</para>
<programlisting>gateway_enable="YES" # a helyi hálózat átjárója
ipnat_enable="YES" # az ipnat funkció elindítása
ipnat_rules="/etc/ipnat.rules" # az ipnat működéséhez szükséges definíciók</programlisting>
</sect2>
<sect2>
<title>IPF</title>
<indexterm><primary><command>ipf</command></primary></indexterm>
<para>Az &man.ipf.8; parancs használható a
szabályokat tartalmazó állomány
betöltésére. Általában egy
állományba írjuk össze a tűzfal
szabályait és ezzel a paranccsal
cseréljük le egyszerre a tűzfalban levő
jelenlegi szabályokat:</para>
<screen>&prompt.root; <userinput>ipf -Fa -f /etc/ipf.rules</userinput></screen>
<para>Az <option>-Fa</option> az összes belső
szabály törlését jelenti.</para>
<para>Az <option>-f</option> jelzi, hogy egy
állományból kell beolvasni a
betöltendő szabályokat.</para>
<para>Ezzel mintegy lehetőségünk van
változtatni a korábban
összeállított szabályainkon, futtatni
a fenti IPF parancsot és ezen keresztül úgy
frissíteni a szabályok friss
másolatával a már működő
tűzfalat, hogy nem is kell újraindítanunk a
rendszert. Ez a módszer igen kényelmes az
új szabályok
kipróbálásához, mivel
bármikor tetszőlegesen
végrehajtható.</para>
<para>Az &man.ipf.8; man oldala tartalmazza a parancsnak
megadható további
beállításokat.</para>
<para>Az &man.ipf.8; parancs a szabályokat
tároló állományt egy
szabványos szöveges állománynak
tekinti, semmilyen szimbolikus helyettesítést
alkalmazó szkriptet nem fogad el.</para>
<para>Lehetőségünk van azonban olyan IPF
szabályokat készíteni, amelyek
kiaknázzák a szkriptek szimbolikus
helyettesítésének lehetőségeit.
Erről bővebben lásd <xref
linkend="firewalls-ipf-rules-script"/>.</para>
</sect2>
<sect2>
<title>Az IPFSTAT</title>
<indexterm><primary><command>ipfstat</command></primary></indexterm>
<indexterm>
<primary>IPFILTER</primary>
<secondary>statisztika</secondary>
</indexterm>
<para>Az &man.ipfstat.8; alapértelmezés szerint a
arra használatos, hogy le tudjuk kérdezni
és megjeleníteni a tűzfalhoz tartozó
számlálók értékeit, amelyek a
legutóbbi indítás vagy az <command>ipf
-Z</command> parancs által kiadott
lenullázásuk óta a bejövő vagy
kimenő forgalomból a megadott szabályoknak
megfelelő csomagok alapján gyűjtenek össze
statisztikákat.</para>
<para>A parancs működésének
részleteit az &man.ipfstat.8; man oldalon
olvashatjuk.</para>
<para>Az &man.ipfstat.8; meghívása alapból
így néz ki:</para>
<screen>input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0
output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0
input packets logged: blocked 99286 passed 0
output packets logged: blocked 0 passed 0
packets logged: input 0 output 0
log failures: input 3898 output 0
fragment state(in): kept 0 lost 0
fragment state(out): kept 0 lost 0
packet state(in): kept 169364 lost 0
packet state(out): kept 431395 lost 0
ICMP replies: 0 <acronym>TCP</acronym> RSTs sent: 0
Result cache hits(in): 1215208 (out): 1098963
IN Pullups succeeded: 2 failed: 0
OUT Pullups succeeded: 0 failed: 0
Fastroute successes: 0 failures: 0
<acronym>TCP</acronym> cksum fails(in): 0 (out): 0
Packet log flags set: (0)</screen>
<para>Az <option>-i</option> mint bejövő (inbound), vagy
az <option>-o</option> mint kimenő (outbound) forgalomra
vonatkozó paraméterek megadásával a
rendszermagban az adott oldalon jelenleg telepített
és alkalmazott szabályokat kérhetjük
le és jeleníthetjük meg.</para>
<para>Az <command>ipfstat -in</command> parancs így a
bejövő forgalomra vonatkozó belső
szabályokat mutatja a szabályok
számával.</para>
<para>Az <command>ipfstat -on</command> parancs a kimenő
forgalmat érintő belső szabályokat
mutatja a szabályok számával.</para>
<para>Az eredmény körülbelül ilyen
lesz:</para>
<screen>@1 pass out on xl0 from any to any
@2 block out on dc0 from any to any
@3 pass out quick on dc0 proto tcp/udp from any to any keep state</screen>
<para>Az <command>ipfstat -ih</command> a bejövő
forgalomhoz tartozó belső szabályokat mutatja
és mindegyik elé odaírja, hogy eddig mennyi
csomag illeszkedett rájuk.</para>
<para>Az <command>ipfstat -oh</command> ugyanígy a
kimentő forgalom esetén mutatja a belső
szabályokat és mindegyik előtt
feltünteti, hogy az adott pillanatig mennyi csomag
illeszkedett rájuk.</para>
<para>A kimenete nagyjából ilyen lesz:</para>
<screen>2451423 pass out on xl0 from any to any
354727 block out on dc0 from any to any
430918 pass out quick on dc0 proto tcp/udp from any to any keep state</screen>
<para>Az <command>ipfstat</command> parancs talán egyik
legfontosabb funkciója a <option>-t</option>
kapcsolóval csalható elő, melynek
hatására a rendszerben aktív
állapotok táblázatát mutatja meg
ugyanúgy, ahogy a &man.top.1; a &os; rendszerben
futó programokat. Amikor a tűzfalunk
támadás alatt áll, ezzel a
funkcióval tudjuk a problémát
beazonosítani, leásni a mélyébe
és látni a támadótól
érkező csomagokat. A
kiegészítésképpen megadható
alkapcsolók megadásával
kiválaszthatjuk azt a cél vagy forrás
IP-címet, portot vagy protokollt, amelyet valós
időben meg akarunk figyelni. Ennek részleteit az
&man.ipfstat.8; man oldalán láthatjuk.</para>
</sect2>
<sect2>
<title>Az IPMON</title>
<indexterm><primary><command>ipmon</command></primary></indexterm>
<indexterm>
<primary>IPFILTER</primary>
<secondary>naplózás</secondary>
</indexterm>
<para>Az <command>ipmon</command> megfelelő
működéséhez be kell kapcsolnunk a
rendszermag <literal>IPFILTER_LOG</literal>
beállítását. Ez a parancs
két különböző módban
használható. Ha parancsot a <option>-D</option>
opció nélkül gépeljük be, akkor
ezek közül alapból a natív módot
kapjuk meg.</para>
<para>A démon mód abban az esetben hasznos, ha
folyamatosan naplózni akarjuk a rendszerben zajló
eseményeket, majd később ezeket
átnézni. Így képes egymással
együttműködni a &os; és az IPFILTER. A
&os; beépítve tartalmaz olyan
lehetőséget, aminek révén
magától cseréli a rendszernaplókat.
Ezért ha átküldjük a &man.syslogd.8;
démonnak a naplózandó üzeneteket,
akkor sokkal jobban járunk, mintha egyszerűen csak
mezei állományba naplóznánk. Az
<filename>rc.conf</filename> alapértelmezései
között az <literal>ipmon_flags</literal>
beállítás a <option>-Ds</option>
kapcsolókat rögzíti:</para>
<programlisting>ipmon_flags="-Ds" # D = indítás démonként
# s = naplózás a syslog használatával
# v = a tcp ablak, ack, seq csomagok naplózása
# n = az IP-címek és portok nevének feloldása</programlisting>
<para>Ennek a viselkedésnek az előnyei minden
bizonnyal egyértelműek.
Segítségével képesek vagyunk az
esetek megtörténte után
átnézni, hogyan milyen csomagokat dobott el a
rendszer, azok milyen címekről érkeztek
és hova szánták. Ez egy komoly fegyver a
támadók lenyomozásában.</para>
<para>Hiába engedélyezzük a
naplózást, az IPF
önszántából semmilyen
naplózási szabályt nem fog gyártani.
A tűzfal gazdájának kell eldöntenie,
hogy a szabályokat közül melyiket akarja
naplózni, és így neki kell megadnia a
<literal>log</literal> kulcsszót ezekben az esetekben.
Normális esetben csak a <literal>deny</literal>
szabályokat naplózzák.</para>
<para>Egyáltalán nem ritka, hogy a
szabályrendszer végén egy
alapértelmezés szerint mindent eldobó
szabály áll, amely naplóz. Ezzel
lehetőségünk nyílik
rögzíteni azokat a csomagokat, amelyek egyetlen
szabályra sem illeszkedtek.</para>
</sect2>
<sect2>
<title>Naplózás az IPMON
használatával</title>
<para>A <application>syslogd</application> egy saját
módszert alkalmaz a naplózott adatok
elkülönítésére. Egy
<quote>funkciók</quote> (facility) és
<quote>szintek</quote> (level) segítségével
kialakított speciális csoportosítást
alkalmaz. Az IPMON <option>-Ds</option> módja
alapértelmezés szerint a <literal>local0</literal>
<quote>funkciót</quote> használja. Ezen
túl a következő szinteken
különíthetjük el igényeinknek
megfelelően a naplózott adatokat:</para>
<screen>LOG_INFO - az átengedés vagy blokkolás helyett a "log" kulcsszóval ellátott csomagok
LOG_NOTICE - az át is engedett csomagok
LOG_WARNING - a blokkolt csomagok
LOG_ERR - a naplózott csomagok közül azok, amelyek túlságosan kicsik (hibás a fejlécük)</screen>
<para>Az IPFILTER csak akkor tud naplózni a
<filename>/var/log/ipfilter.log</filename>
állományba, ha előtte létrehozzuk. Az
alábbi parancs erre tökéletesen
megfelelő:</para>
<screen>&prompt.root; <userinput>touch /var/log/ipfilter.log</userinput></screen>
<para>A &man.syslogd.8; működését az
<filename>/etc/syslog.conf</filename> állományban
szereplő definíciók vezérlik. A
<filename>syslog.conf</filename> állomány
számottevő mértékben képes
meghatározni azt, ahogy a
<application>syslog</application> az IPF és a
hozzá hasonló alkalmazásoktól kapott
rendszerszintű üzeneteket kezeli.</para>
<para>Az <filename>/etc/syslog.conf</filename>
állományba az alábbi sor kell
felvennünk:</para>
<programlisting>local0.* /var/log/ipfilter.log</programlisting>
<para>A <literal>local0.*</literal> megadásával az
összes ilyen típusú üzenet egy
előre rögzített helyre kerül.</para>
<para>Az <filename>/etc/syslog.conf</filename>
állományban elvégzett
módosításokat úgy
léptethetjük érvénybe, ha
újraindítjuk a
számítógépet vagy az
<command>/etc/rc.d/syslogd reload</command> paranccsal
megkérjük a &man.syslogd.8; démont, hogy
olvassa újra az <filename>/etc/syslog.conf</filename>
állományt.</para>
<para>Az imént létrehozott naplót ne
felejtsük el megadni az
<filename>/etc/newsyslog.conf</filename>
állományban sem, és akkor ezzel a
cseréjét is megoldjuk.</para>
</sect2>
<sect2>
<title>A naplózott üzenetek formátuma</title>
<para>Az <command>ipmon</command> által létrehozott
üzenetek whitespace karakterekkel elválasztott
adatmezőkből állnak. A következő
mezők az összes üzenet esetében
megjelennek:</para>
<orderedlist>
<listitem>
<para>A csomag megérkezésének
dátuma</para>
</listitem>
<listitem>
<para>A csomag megérkezésének
időpontja. ÓÓ:PP:MM.E alakban jelennek
meg az órák, percek, másodpercek
és ezredmásodpercek (ez több
számjegy hosszú is lehet) szerint</para>
</listitem>
<listitem>
<para>Azon interfész a neve, ahol a csomag
feldolgozásra került, például
<devicename>dc0</devicename></para>
</listitem>
<listitem>
<para>A szabályhoz tartozó csoport és
sorszám, például
<literal>@0:17</literal></para>
</listitem>
</orderedlist>
<para>Ezek az <command>ipfstat -in</command> paranccsal
nézhetőek meg.</para>
<orderedlist>
<listitem>
<para>Cselekvés: a p mint átment (passed), b
mint blokkolt (blocked), S mint rövid csomag (short
packet), n mint egyik szabályra sem illeszkedett (not
match), L mint naplózás (log). A
módosítók
megjelenítésének sorrendje: S, p, b, n,
L. A nagybetűs P és B azt jelzi, hogy a
csomagot egy felsőbb szintű
beállítás miatt
naplózták, nem egy szabály
hatására.</para>
</listitem>
<listitem>
<para>Címek: ez tulajdonképpen három
mezőt takar: a forrás címet és
portot (melyet egy vessző választ el), a -&gt;
jelet és cél címet és portot.
Például: <literal>209.53.17.22,80 -&gt;
198.73.220.17,1722</literal>.</para>
</listitem>
<listitem>
<para>A <literal>PR</literal> után a protokoll neve
vagy száma olvasható, például
<literal>PR tcp</literal>.</para>
</listitem>
<listitem>
<para>A <literal>len</literal> csomaghoz tartozó
fejléc és törzsének teljes
hosszát jelöli, például
<literal>len 20 40</literal>.</para>
</listitem>
</orderedlist>
<para>Amennyiben a csomag <acronym>TCP</acronym>, egy
kötőjellel kezdődően további
mezők is megjelenhetnek a beállított
opcióknak megfelelő betűk
képében. A betűket és
beállításaikat az &man.ipf.5; man
oldalán olvashatjuk.</para>
<para>Amennyiben a csomag ICMP, a sort két mező
zárja, melyek közül az első tartalma
mindig <quote>ICMP</quote>, és ezt egy perjellel
elválasztva az ICMP üzenet típusa és
altípusa követi. Tehát például
az ICMP 3/3 a <quote>nem elérhető port</quote>
üzenetet hordozza.</para>
</sect2>
<sect2 id="firewalls-ipf-rules-script">
<title>A szabályok felírása szimbolikus
helyettesítéssel</title>
<para>Az IPF használatában gyakorlott
felhasználók közül
néhányan képesek olyan
stílusú szabályrendszert
készíteni, ahol szimbolikus
helyettesítést használnak. Ennek az egyik
legnagyobb előnye az, hogy ilyenkor elég csak a
szimbolikus névhez tartozó értéket
megváltoztatni és amikor a szkript lefut, akkor az
összes rá hivatkozó szabályba ez
kerül be. Szkript lévén a szimbolikus
helyettesítéssel ki tudjuk emelni a gyakran
használt értékeket és
behelyettesíteni ezeket több helyre. Ezt a most
következő példában
láthatjuk.</para>
<para>Az itt alkalmazott felírás kompatibilis az
&man.sh.1;, &man.csh.1; és &man.tcsh.1;
parancsértelmezőkkel.</para>
<para>A szimbolikus helyettesítést egy
dollárjellel fejezzük ki:
<literal>&dollar;</literal>.</para>
<para>A szimbolikus mezőkben nem szerepel a &dollar;
jelölés.</para>
<para>A szimbolikus mező tartalmát kettős
idézőjelbe (<literal>"</literal>)
tesszük.</para>
<para>Kezdjük így el a szabályok
írását:</para>
<programlisting>######### Az IPF szabályait tartalmazó szkript eleje ###########
oif="dc0" # a kimenő interfész neve
odns="192.0.2.11" # az internet szolgáltató névszerverének IP-címe
myip="192.0.2.7" # a szolgáltatótól kapott statikus IP-címünk
ks="keep state"
fks="flags S keep state"
# Választhatunk, hogy az /etc/ipf.rules állományt ebből a szkriptből
# hozzuk létre vagy futtathatjuk "magát" a szkriptet.
#
# Egyszerre csak az egyik sort használjuk.
#
# 1) Ezzel gyárhatjuk le az /etc/ipf.rules állományt:
#cat &gt; /etc/ipf.rules &lt;&lt; EOF
#
# 2) Ezzel futtathajuk "magát" a szkriptet:
/sbin/ipf -Fa -f - &lt;&lt; EOF
# Engedélyezzük a szolgáltató névszerverének elérését.
pass out quick on &dollar;oif proto tcp from any to &dollar;odns port = 53 &dollar;fks
pass out quick on &dollar;oif proto udp from any to &dollar;odns port = 53 &dollar;ks
# Engedélyezzük kifelé a titkosítatlan www funkciót.
pass out quick on &dollar;oif proto tcp from &dollar;myip to any port = 80 &dollar;fks
# Engedélyezzük kifelé a TLS SSL felett üzemelő titkosított www funkciót.
pass out quick on &dollar;oif proto tcp from &dollar;myip to any port = 443 &dollar;fks
EOF
################## Itt az IPF szkript vége ########################</programlisting>
<para>Ennyi lenne. A példában szereplő
szabályok most nem annyira lényegesek, a
hangsúly most igazából a szimbolikus
helyettesítésen és annak
használatán van. Ha a fenti példát
az <filename>/etc/ipf.rules.script</filename>
állományba mentjük, akkor ezeket a
szabályokat a következő paranccsal újra
tudjuk tölteni:</para>
<screen>&prompt.root; <userinput>sh /etc/ipf.rules.script</userinput></screen>
<para>Egyetlen aprócska gond van a beágyazott
szimbólumokat tartalmazó
állományokkal: az IPF maga nem képes
megérteni a helyettesítéseket, azért
közvetlenül nem olvassa a szkriptet.</para>
<para>Ez a szkript két módon
hasznosítható:</para>
<itemizedlist>
<listitem>
<para>Vegyük ki megjegyzésből a
<literal>cat</literal> paranccsal kezdődő sort,
és tegyük megjegyzésbe az
<literal>/sbin/ipf</literal> kezdetűt. A megszokottak
szerint tegyük az
<literal>ipfilter_enable="YES"</literal> sort az
<filename>/etc/rc.conf</filename> állományba,
majd minden egyes módosítása
után futtassuk le a szkriptet az
<filename>/etc/ipf.rules</filename> állomány
létrehozásához vagy
frissítéséhez.</para>
</listitem>
<listitem>
<para>Tiltsuk le az IPFILTER aktiválását
a rendszerindításkor, tehát
írjuk bele az <literal>ipfilter_enable="NO"</literal>
sort (ami mellesleg az alapértelmezett
értéke) az <filename>/etc/rc.conf</filename>
állományba.</para>
<para>Tegyünk egy, az alábbi szkripthez
hasonlót az <filename
class="directory">/usr/local/etc/rc.d/</filename>
könyvtárba. A szkriptnek adjuk valamilyen
értelmes nevet, például
<filename>ipf.loadrules.sh</filename>. Az
<filename>.sh</filename> kiterjesztés
használata kötelező.</para>
<programlisting>#!/bin/sh
sh /etc/ipf.rules.script</programlisting>
<para>A szkript engedélyeit állítsuk be
úgy, hogy a <username>root</username>
tulajdonában legyen és képes legyen
olvasni, írni valamint végrehajtani.</para>
<screen>&prompt.root; <userinput>chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh</userinput></screen>
</listitem>
</itemizedlist>
<para>Most miután a rendszer elindult, az IPF
szabályai be fognak töltődni.</para>
</sect2>
<sect2>
<title>Szabályrendszerek az IPF-ben</title>
<para>Az IPF 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
<acronym>TCP/IP</acronym> 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.</para>
<indexterm>
<primary>IPFILTER</primary>
<secondary>a szabályok feldolgozásának
sorrendje</secondary>
</indexterm>
<para>Az IPF eredetileg úgy íródott, hogy a
szabályokat <quote>az utolsó illeszkedő
szabály nyer</quote> stílusban dolgozza fel
és csak állapot nélküli
szabályokat ismert. Az idők folyamán az IPF
szabályai kiegészültek a <quote>quick</quote>
és az állapottartásra vonatkozó
<quote>keep state</quote> opciókkal, amelynek
köszönhetően óriási
mértékben korszerűsödött a
szabályok feldolgozása.</para>
<para>A szakaszban szereplő utasítások olyan
szabályokat alkalmaznak, amelyekben egyaránt
szerepel a <quote>quick</quote> és az
állapottartásért felelős <quote>keep
state</quote> beállítás. Ez az
inkluzív tűzfalak
létrehozásának egyik
alapeszköze.</para>
<warning>
<para>A tűzfal szabályainak
összeállítása során
<emphasis>nagyon óvatosnak</emphasis> kell
lennünk! Bizonyos beállítások
hatására akár <emphasis>ki is
zárhatjuk magunkat</emphasis> a
szerverünkről. Az ebből fakadó
esetleges kellemetlenségek elkerülése
érdekében javasoljuk, hogy a tűzfal
alapjait először helyi konzolról
építsük fel, ne pedig
távolról, például
<application>ssh</application>
segítségével.</para>
</warning>
</sect2>
<sect2>
<title>A szabályok felépítése</title>
<indexterm>
<primary>IPFILTER</primary>
<secondary>a szabályok
felépítése</secondary>
</indexterm>
<para>A szabályok felépítésének
bemutatását itt most leszűkítjük
a modern állapottartó szabályokra és
az <quote>első illeszkedő szabály nyer</quote>
típusú feldolgozásra. A szabályok
felírásának régebbi módjai az
&man.ipf.8; man oldalon találhatóak.</para>
<para>A <literal>#</literal> karakterrel egy megjegyzés
kezdetét jelezzük, és általában
a sor végén vagy egy külön sorban bukkan
fel. Az üres sorokat a rendszer nem veszi
figyelembe.</para>
<para>A szabályok kulcsszavakat tartalmaznak. Ezeknek a
kulcsszavaknak balról jobbra haladva adott sorrendben
kell szerepelniük. A kulcsszavakat kiemeltük. Egyes
kulcsszavakhoz további beállítások
is tartozhatnak, amelyek maguk is kulcsszavak lehetnek,
és még további opciókkal
rendelkezhetnek. Az alábbi nyelvtan mindegyik
elemét kiemeltük és az alábbiakban
egyenként kifejtjük a részleteiket.</para>
<para><replaceable>CSELEKVÉS BE-KI OPCIÓK
SZűRÉS ÁLLAPOTTARTÓ PROTOKOLL
FORRÁS_CÍM,CÉL_CÍM OBJEKTUM
PORTSZÁM TCP_BEÁLLÍTÁS
ÁLLAPOTTARTÓ</replaceable></para>
<para><replaceable>CSELEKVÉS</replaceable> = block |
pass</para>
<para><replaceable>BE-KI</replaceable> = in | out</para>
<para><replaceable>OPCIÓK</replaceable> = log | quick | on
<replaceable>interfész</replaceable></para>
<para><replaceable>SZűRÉS</replaceable> = proto
<replaceable>érték</replaceable> |
<replaceable>forrás/cél IP</replaceable> | port =
<replaceable>szám</replaceable> | flags
<replaceable>beállítás</replaceable></para>
<para><replaceable>PROTOKOLL</replaceable> = tcp/udp | udp | tcp |
icmp</para>
<para><replaceable>FORRÁS_CÍM,CÉL_CÍM</replaceable>
= all | from <replaceable>objektum</replaceable> to
<replaceable>objektum</replaceable></para>
<para><replaceable>OBJEKTUM</replaceable> =
<replaceable>IP-cím</replaceable> | any</para>
<para><replaceable>PORTSZÁM</replaceable> =
<replaceable>portszám</replaceable></para>
<para><replaceable>TCP_BEÁLLÍTÁS</replaceable>
= S</para>
<para><replaceable>ÁLLAPOTTARTÓ</replaceable> = keep
state</para>
<sect3>
<title>CSELEKVÉS</title>
<para>A cselekvés határozza meg, hogy mit kell
tenni azokkal a csomagokkal, amelyek illeszkednek a
szabály többi részére. Minden
szabályhoz tartoznia <emphasis>kell</emphasis> egy
cselekvésnek. A következő cselekvések
közül választhatunk:</para>
<para>A <literal>block</literal> megadásával a
szabályban szereplő szűrési
feltételre illeszkedő csomagot eldobjuk.</para>
<para>A <literal>pass</literal> megadásával a
szabályban szereplő szűrési
feltételre illeszkedő csomagot
átengedjük a tűzfalon.</para>
</sect3>
<sect3>
<title>BE-KI</title>
<para>Az összes szűrési szabály
esetében kötelező egyértelműen
nyilatkozunk arról, hogy a bemenő vagy a
kimenő forgalomra vonatkozik. Ezért a
következő kulcsszó vagy az
<literal>in</literal> vagy pedig az <literal>out</literal>, de
közülük egyszerre csak az egyiket szabad
használni, máskülönben a
szabály hibásnak minősül.</para>
<para>Az <literal>in</literal> jelenti, hogy a szabályt
az internet felől az adott interfészen
beérkező csomagokra kell alkalmazni.</para>
<para>Az <literal>out</literal> jelenti, hogy a szabályt
az internet felé az adott interfészen
kiküldött csomagokra kell alkalmazni.</para>
</sect3>
<sect3>
<title>OPCIÓK</title>
<note>
<para>Ezek az opciók csak a lentebb bemutatott
sorrendben használhatók.</para>
</note>
<para>A <literal>log</literal> jelzi, hogy illeszkedés
esetén a csomag fejlécét az
<devicename>ipl</devicename> eszközön keresztül
naplózni kell (lásd a
naplózásról szóló
szakaszt).</para>
<para>A <literal>quick</literal>jelzi, hogy illeszkedés
esetén ez lesz a legutolsónak
ellenőrzött szabály és így egy
olyan <quote>rövidzárat</quote> tudunk
képezni a feldolgozásban, amellyel
elkerüljük a csomagra egyébként
vonatkozó többi szabály
illesztését. Ez az opció a
korszerűsített szabályfeldolgozás
kihasználásához elengedhetetlen.</para>
<para>Az <literal>on</literal> használatával a
szűrés feltételei közé
bevonhatjuk a csomaghoz tartozó hálózati
interfészt. Itt az interfészek az
&man.ifconfig.8; által megjelenített
formában adhatóak meg. Az opció
megadásával csak az adott interfészen az
adott irányba (befelé/kifelé)
közlekedő csomagokra fog illeszkedni a
szabály. Ez az opció a
korszerűsített szabályfeldolgozás
kihasználásához
nélkülözhetetlen.</para>
<para>Amikor naplózunk egy csomagot, akkor a
hozzá tartozó fejléc az
<acronym>IPL</acronym> csomagnaplózó pszeudo
eszközhöz kerül. A <literal>log</literal>
kulcsszó után közvetlenül a
következő minősítők szerepelhetnek
(a következő sorrendben):</para>
<para>A <literal>body</literal> jelzi, hogy a csomag
tartalmának első 128 byte-ját még
jegyezzük fel a fejléc mellé.</para>
<para>A <literal>first</literal> minősítőt
akkor érdemes használnunk, amikor a
<literal>log</literal> kulcsszót a <literal>keep
state</literal> opcióval együtt alkalmazzuk, mivel
ilyenkor csak a szabályt kialakító csomag
kerül naplózásra és nem minden
olyan, ami illeszkedik az állapottartási
feltételekre.</para>
</sect3>
<sect3>
<title>SZűRÉS</title>
<para>Ebben a szakaszban olyan kulcsszavak jelenhetnek meg,
amelyekkel a csomagok különféle
tulajdonságai alapján
ítélkezhetünk azok
illeszkedéséről. Itt adott egy
kiinduló kulcsszó, amelyhez további
kulcsszavak is tartoznak, és amelyek közül
csak egyet választhatunk. Az alábbi
általános tulajdonságok alapján
tudjuk szűrni a csomagokat, ebben a sorrendben:</para>
</sect3>
<sect3>
<title>PROTOKOLL</title>
<para>A <literal>proto</literal> egy olyan kulcsszó,
amelyhez hozzá kell rendelnünk még
valamelyik opcióját is. Ez az opció
segít az adott protokolloknak megfelelően
válogatni a csomagok között. A
korszerűsített szabályfeldolgozás
lehetőségeinek
kihasználásához
nélkülözhetetlen.</para>
<para>Opcióként a <literal>tcp/udp | udp | tcp |
icmp</literal>, vagy bármelyik, az
<filename>/etc/protocols</filename> állományban
megtalálható kulcsszó
felhasználható. A <literal>tcp/udp</literal>
ebből a szempontból speciálisnak
tekinthető, mivel hatására egyszerre
illeszthetőek a szabályra a <acronym>TCP</acronym>
és <acronym>UDP</acronym> csomagok, és
így a protokolltól eltekintve azonos
szabályok felesleges
többszörözését
kerülhetjük el.</para>
</sect3>
<sect3>
<title>FORRÁS_CÍM/CÉL_CÍM</title>
<para>Az <literal>all</literal> kulcsszó gyakorlatilag a
<quote>from any to any</quote> (<quote>bárhonnan
bárhova</quote>) szinonímája és
nem tartozik hozzá paraméter.</para>
<para>A <literal>from <replaceable>forrás</replaceable>
to <replaceable>cél</replaceable></literal>
felépítése: a <literal>from</literal>
és <literal>to</literal> kulcsszavak az IP-címek
illesztésére használhatóak.
Ilyenkor a szabályokban a forrás
<emphasis>és</emphasis> a cél
paramétereknek is szerepelniük kell. Az
<literal>any</literal> egy olyan speciális
kulcsszó, amely tetszőleges IP-címre
illeszkedik. Néhány példa az
alkalmazására: <literal>from any to
any</literal> vagy <literal>from 0.0.0.0/0 to any</literal>,
<literal>from any to 0.0.0.0/0</literal>, <literal>from
0.0.0.0/0 to any</literal> vagy <literal>from any to
0.0.0.0</literal>.</para>
<para>Az IP-címek megadhatóak pontozott numerikus
formában a hálózati maszk bitekben
mért hosszával együtt, vagy akár
egyetlen pontozott numerikus IP-címként.</para>
<para>Nincs lehetőség olyan
IP-címtartományok illesztésére,
amelyek nem adhatóak meg kényelmesen ponttal
elválasztott számok és maszk
hosszával. A <filename
role="package">net-mgmt/ipcalc</filename> port az ilyen
számításokat könnyíti meg. A
hálózati maszkok hosszának
megállapításban segíthet az
említett segédprogram (angol nyelvű)
honlapja: <ulink
url="http://jodies.de/ipcalc"></ulink>.</para>
</sect3>
<sect3>
<title>PORT</title>
<para>Amikor portra vonatkozó illeszkedést
írunk elő, megadhatjuk a forrásra és
célra, amit aztán vagy csak
<acronym>TCP</acronym> vagy pedig csak <acronym>UDP</acronym>
csomagokra alkalmazunk. A portok feltételeinek
megfogalmazásánál használhatjuk a
portok számát vagy az
<filename>/etc/services</filename> állományban
szereplő nevüket. Amikor a port egy
<literal>from</literal> típusú objektum
leírásában jelenik meg, akkor
automatikusan a forrásportot jelenti, míg a
<literal>to</literal> objektum leírásában
pedig a célportot. A <literal>to</literal>
objektumoknál a port megadása elengedhetetlen a
korszerűsített szabályfeldolgozás
előnyeinek kihasználásához.
Példa: <literal>from any to any port =
80</literal>.</para>
<para>Az egyes portokat különböző
műveletek segítségével, numerikusan
hasonlíthatjuk össze, ahol akár
porttartományt is megadhatunk.</para>
<para>port "=" | "!=" | "&lt;" | "&gt;" | "&lt;=" | "&gt;=" |
"eq" | "ne" | "lt" | "gt" | "le" | "ge".</para>
<para>A porttartományok megadásához
használjuk a <literal>port</literal> "&lt;&gt;" |
"&gt;&lt;" felírási módot.</para>
<warning>
<para>A forrásra és célra
vonatkozó paraméterek után
szereplő másik két paraméter
nélkülözhetetlen a
korszerűsített szabályfeldolgozás
működéséhez.</para>
</warning>
</sect3>
<sect3>
<title><acronym>TCP</acronym>_BEÁLLÍTÁS</title>
<para>A beállítások csak a
<acronym>TCP</acronym> forgalom
szűrésénél
érvényesülnek. A betűk jelölik
azokat a lehetséges beállításokat,
amelyek a <acronym>TCP</acronym> csomagok
fejlécében
megvizsgálhatóak.</para>
<para>A korszerűsített
szabályfeldolgozás a <literal>flags S</literal>
paraméter segítségével ismeri fel
a <acronym>TCP</acronym> munkameneteket
kezdeményező kéréseket.</para>
</sect3>
<sect3>
<title>ÁLLAPOTTARTÓ</title>
<para>A <literal>keep state</literal> jelzi, hogy a
szabály paramétereinek megfelelő
bármely csomag aktiválja az
állapottartó szűrés
használatát.</para>
<note>
<para>Ez a beállítás
feltétlenül szükséges a
korszerűsített szabályfeldolgozás
megfelelő kihasználásához.</para>
</note>
</sect3>
</sect2>
<sect2>
<title>Állapottartó csomagszűrés</title>
<indexterm>
<primary>IPFILTER</primary>
<secondary>állapottartó
szűrés</secondary>
</indexterm>
<para>Az állapottartó szűrés a csomagok
kétirányú áramlását
egy létrejött kapcsolatba sorolja be. Amikor
aktiválódik, az állapottartó
szabály előre dinamikusan létrehozza a
kétirányú kommunikációban
megforduló csomagokhoz a megfelelő belső
szabályokat. Olyan vizsgálatokat végez,
amelyek segítségével ki tudja
deríteni, hogy a csomag küldője és
címzettje között fennálló
kétirányú kapcsolat érvényes
szabályok szerint zajlik-e. Minden olyan csomagot, amely
nem illeszkedik megfelelően a kapcsolatra vonatkozó
sémára, csalásnak tekintjük és
automatikusan eldobjuk.</para>
<para>Az állapottartás révén
lehetőségünk van a <acronym>TCP</acronym> vagy
<acronym>UDP</acronym> kapcsolatokhoz tartozó
<acronym>ICMP</acronym> csomagokat is átengedni a
tűzfalon. Tehát ha kapunk egy 3-as
típusú, 4-es kódú
<acronym>ICMP</acronym> választ valamilyen
böngészésre használt
állapottartó szabályon keresztül
kiküldött kérésre, akkor az
automatikusan bejöhet. Amelyik csomagot az IPF
egyértelműen képes besorolni az aktív
kapcsolatba, még ha az eltérő protokollt is
használ, beengedi.</para>
<para>Ami ilyenkor történik:</para>
<para>Az internethez csatlakozó interfészen
keresztül kifelé haladó csomagokat
először egy dinamikus állapottábla
alapján illesztjük, és ha a csomag
illeszkedik az aktív kapcsolatban
következőként várt csomagra, akkor
átmegy a tűzfalon és a dinamikus
állapottáblában frissül a kapcsolat
állapota. Az aktív munkameneten kívül
csomagok pedig egyszerűen a kimenő
szabályrendszer szerint kerülnek
ellenőrzésre.</para>
<para>Hasonlóan az előzőhöz, az internethez
csatlakozó interfészen keresztül
befelé haladó csomagokat először egy
dinamikus állapottábla alapján
illesztjük, és ha a csomag illeszkedik az
aktív kapcsolatban következőként
várt csomagra, akkor átmegy a tűzfalon
és a dinamikus állapottáblában
frissül a kapcsolat állapota. Az aktív
munkamenethez nem tartozó csomagok pedig egyszerűen
a bejövő szabályrendszer szerint kerülnek
ellenőrzésre.</para>
<para>Amikor egy kapcsolat befejeződik, automatikusan
törlődik a dinamikus
állapottáblából.</para>
<para>Az állapottartó csomagszűrés
használatával az újonnan keletkező
kapcsolatok elutasítására vagy
engedélyezésére tudunk koncentrálni.
Ha engedélyeztük egy új kapcsolat
létrejöttét, akkor a
rákövetkező összes többi csomag
automatikusan átmegy a tűzfalon és minden
más hamis csomag eldobódik. Ha tiltjuk az
új kapcsolatot, akkor egyetlen
rákövetkező csomag sem juthat át. Az
állapottartó szűrés által
felkínált fejlett elemzési
lehetőségek képesek védelmet
nyújtani a behatolók részéről
alkalmazott megannyi különböző
támadási módszer ellen.</para>
</sect2>
<sect2>
<title>Példa inkluzív
szabályrendszerre</title>
<para>A most következő szabályrendszer arra mutat
példát, hogyan programozzunk le egy nagyon
biztonságos inkluzív tűzfalat. Az
inkluzív tűzfalak csak a szabályainak
megfelelő szolgáltatásokat engedik
keresztül, és alapértelmezés szerint
minden mást blokkolnak. Egy hálózat
gépeit védő tűzfalnak, amelyet gyakran
<quote>hálózati tűzfalnak</quote> (network
firewall) is neveznek, legalább két
hálózati interfésszel kell rendelkeznie.
Ezeket az interfészeket általában
úgy állítják be, hogy
tökéletesen megbíznak az egyik oldalban (a
helyi hálózatban), a másikban (az
internetben) pedig egyáltalán nem. A
tűzfalat egyébként úgy is
beállíthatjuk, hogy csak a tűzfalat
működtető gépet védje &mdash; ezt
<quote>egyrendszeres tűzfalnak</quote> (host based
firewall) nevezik. Az ilyen típusú
megoldásokat nem biztonságos
hálózaton keresztül kommunikáló
szervereknél alkalmaznak.</para>
<para>Mindegyik &unix;-típusú rendszert,
köztük a &os;-t is úgy
alakították ki, hogy az operációs
rendszeren belüli kommunikáció az
<devicename>lo0</devicename> interfészen és a
<hostid role="ipaddr">127.0.0.1</hostid> IP-címen
keresztül történik. A tűzfal
szabályai között feltétlenül
szerepelniük kell olyanoknak, amelyek lehetővé
teszik ezen a speciális intefészen a csomagok
zavartalan mozgását.</para>
<para>Az internetre csatlakozó interfészhez kell
rendelni a kifelé és befelé haladó
forgalom hitelesítését é a
hozzáférésének
vezérlését. Ez lehet a
felhasználói PPP által létrehozott
<devicename>tun0</devicename> interfész vagy a DSL-,
illetve kábelmodemhez csatlakozó
hálózati kártya.</para>
<para>Ahol egy vagy több hálózati kártya
is csatlakozik több különböző helyi
hálózathoz, úgy kell
beállítani a hozzájuk tartozó
interfészeket, hogy egymás felé és
az internet felé képesek legyenek küldeni
és fogadni.</para>
<para>A szabályokat először három nagy
csoportba kell szerveznünk: először jönnek a
megbízható interfészek, ezeket követik
az internet felé mutató interfészek,
végül internet felől jövő, nem
megbízható interfészeke.</para>
<para>Az egyes csoportokban szereplő szabályokat
úgy kell megadni, hogy közülük előre
kerüljenek a leggyakrabban alkalmazottak, és a
csoport utolsó szabálya blokkoljon és
naplózzon minden csomagot az adott interfészen
és irányban.</para>
<para>A kimenő forgalomat vezérlő
szabályrendszer csak <literal>pass</literal>
(tehát átengedő) szabályokat
tartalmazhat, amelyek bentről az interneten
elérhető szolgáltatásokat
azonosítják egyértelműen. Az
összes ilyen szabályban meg kell jelenni a
<literal>quick</literal>, <literal>on</literal>,
<literal>proto</literal>, <literal>port</literal> és
<literal>keep state</literal>
beállításoknak. A <literal>proto
tcp</literal> szabályok esetében meg kell adni a
<literal>flag</literal> opciót is, amivel fel tudjuk
ismertetni a kapcsolatok keletkezését és
ezen keresztül aktiválni az
állapottartást.</para>
<para>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.</para>
<para>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 több időt kell
szánniuk csínytevéseik
kieszelésére. A <literal>log first</literal>
opciót tartalmazó szabályok csak az
illeszkedésnél fogják naplózni a
hozzájuk tartozó eseményt. Erre
láthatunk példát az <literal>nmap OS
fingerprint</literal> szabálynál. Az <filename
role="package">security/nmap</filename> segédprogramot
a támadók gyakran alkalmazzák a
megtámadni kívánt szerver
operációs rendszerének
felderítésére.</para>
<para>Minden <literal>log first</literal> opcióval megadott
szabály illeszkedésénél a
<command>ipfstat -hio</command> parancs
meghatározódik az eddigi illeszkedések
aktuális száma. Nagyobb értékek
esetében következtethetünk arra, hogy a
rendszerünket megtámadták (vagyis csomagokkal
árasztják éppen el).</para>
<para>Az ismeretlen portszámok
felderítésére az
<filename>/etc/services</filename> állomány,
esetleg a <ulink
url="http://www.securitystats.com/tools/portsearch.php"></ulink>
(angol nyelvű) honlap használható.</para>
<para>Érdemes továbbá megnézni a
trójai programok által használt portokat a
<ulink
url="http://www.simovits.com/trojans/trojans.html"></ulink>
címen (angolul).</para>
<para>A következő szabályrendszer egy olyan
biztonságos <quote>inkluzív</quote>
típusú tűzfal, amelyet éles rendszeren
is használnak. Ezt a rendszerünkön nem
használt szolgáltatásokra vonatkozó
<literal>pass</literal> szabályok
törlésével könnyedén a
saját igényeink szerint
alakíthatjuk.</para>
<para>Ha nem akarunk látni bizonyos üzeneteket, akkor
vegyünk fel hozzájuk egy <literal>block</literal>
típusú szabályt a befelé
irányuló forgalomhoz tartozó
szabályok közé.</para>
<para>A szabályokban írjuk át a
<devicename>dc0</devicename> interfész nevét annak
a hálózati kártyának az
interfészére, amelyen keresztül csatlakozunk
az internethez. A felhasználói PPP
esetében ez a <devicename>tun0</devicename> lesz.</para>
<para>Tehát a következőket kell beírni az
<filename>/etc/ipf.rules</filename>
állományba:</para>
<programlisting>#################################################################
# A helyi hálózatunkon zajló forgalmat ne korlátozzuk.
# Csak akkor kell, ha helyi hálózathoz is csatlakozunk.
#################################################################
#pass out quick on xl0 all
#pass in quick on xl0 all
#################################################################
# A belső interfészen szintén ne korlátozzunk semmit.
#################################################################
pass in quick on lo0 all
pass out quick on lo0 all
#################################################################
# 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é.
#################################################################
# Engedélyezzük az internet szolgáltatók névszerverének elérését,
# az "xxx" helyett a névszervet IP-címét kell megadni.
# Másoljuk le ezeket a sorokat, ha a szolgáltatónknak több
# névszerverét is beakarjuk állítani. A címeiket az /etc/resolv.conf
# állományban találjuk.
pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state
pass out quick on dc0 proto udp from any to xxx port = 53 keep state
# DSL vagy kábeles hálózatoknál engedélyezzük a
# szolgáltatónk DHCP szerverének elérését.
# Ez a szabály nem kell, ha "felhasználói PPP"-vel
# kapcsolódunk az internethez, ilyenkor tehát az egész
# csoport törölhető.
# Használjuk az alábbi szabályt és keressük meg a naplóban az
# IP-címet. Ha megtaláltuk, akkor tegyük bele a megjegyzésben
# szereplő szabályba és töröljük az első szabályt.
pass out log quick on dc0 proto udp from any to any port = 67 keep state
#pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state
# Kifelé engedélyezzük a szabványos nem biztonságos WWW funkciókat.
pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state
# Kifelé engedélyezzük a biztonságos WWW funkciókat TLS SSL
# protokollal.
pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state
# Kifelé engedélyezzük az e-mailek küldését és fogadását.
pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state
pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state
# Kifelé engedélyezzük az idő szolgáltatást.
pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state
# Kifelé engedélyezzük az nntp híreket.
pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state
# Kifelé engedélyezzük az átjáróról és a helyi hálózatról a nem
# biztonságos FTP használatát (passzív és akív módokban is). Ez a
# funkció a működéséhez a nat szabályokat tartalmazó állományban
# hivatkozott FTP proxyt használja. Amennyiben a pkg_add paranccsal
# csomagokat akarunk telepíteni az átjáróra, erre a szabályra
# mindenképpen szükségünk lesz.
pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state
# Kifelé engedélyezzük az ssh/sftp/scp # (biztonságos telnet/rlogin/FTP)
# szolgáltatások # elérését az SSH (secure shell) használatával.
pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state
# Kifelé engedélyezzük a nem biztonságos telnet elérését.
pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state
# Kifelé engedélyezzük FreeBSD CVSUp funkcióját.
pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state
# Kifelé engedélyezzük a pinget.
pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state
# Kifelé engedélyezzük a helyi hálózatról érkező whois kéréseket.
pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state
# Minden mást eldobunk és naplózzuk az első előfordulásukat.
# Ez a szabály blokkol alapértelmezés szerint mindent.
block out log first quick on dc0 all
#################################################################
# 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.
#################################################################
# Eldobjuk az összes olyan bejövő forgalmat, amit hivatalosan nem
# lehetne továbbítani vagy fenntartott címterülethez tartozik.
block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918: privát IP
block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918: privát IP
block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918: privát IP
block in quick on dc0 from 127.0.0.0/8 to any #helyi
block in quick on dc0 from 0.0.0.0/8 to any #helyi
block in quick on dc0 from 169.254.0.0/16 to any #DHCP
block in quick on dc0 from 192.0.2.0/24 to any #dokumentációs célokra fenntartva
block in quick on dc0 from 204.152.64.0/23 to any #Sun klaszterek összekötésére használt
block in quick on dc0 from 224.0.0.0/3 to any #D és E osztályú multicast
##### Itt eldobunk egy rakás csúf dolgot ############
# Ezeket nem akarjuk a naplóban látni:
# Eldobjuk a töredékcsomagokat.
block in quick on dc0 all with frags
# Eldobjuk a túlságosan rövid TCP csomagokat.
block in quick on dc0 proto tcp all with short
# Eldobjuk a forrás által közvetített (source routed) csomagokat.
block in quick on dc0 all with opt lsrr
block in quick on dc0 all with opt ssrr
# Elutasítjuk az "OS fingerprint" kéréseket.
# Naplózzuk az első előfordulást, így nálunk lesz a kíváncsiskodó
# egyén IP-címe.
block in log first quick on dc0 proto tcp from any to any flags FUP
# Eldobunk mindent, aminek speciális beállításai vannak.
block in quick on dc0 all with ipopts
# Elutasítjuk a publikus pinget.
block in quick on dc0 proto icmp all icmp-type 8
# Elutasítjuk az ident kéréseket.
block in quick on dc0 proto tcp from any to any port = 113
# 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.
block in log first quick on dc0 proto tcp/udp from any to any port = 137
block in log first quick on dc0 proto tcp/udp from any to any port = 138
block in log first quick on dc0 proto tcp/udp from any to any port = 139
block in log first quick on dc0 proto tcp/udp from any to any port = 81
# Engedélyezzük a szolgáltatónk DHCP szerverétől érkező forgalmat.
# Ebben a szabályban meg kell adnunk a szolgáltató DHCP szerverének
# IP-címét, mivel itt csak a hiteles forrásból fogadunk el csomagokat.
# Erre csak DSL- és kábelmodemes kapcsolat esetében van szükség, a
# "felhasználói PPP" alkalmazása során szükségtelen. Ez az IP-cím
# megegyezik a kimenő kapcsolatoknál megadott címmel.
pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state
# Befelé engedélyezzük a szabványos WWW funkciót, mivel webszerverünk
# van.
pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state
# Befelé engedélyezzük az internetről érkező nem biztonságos telnet
# kapcsolatokat. Azért nem biztonságos, mert az azonosítókat és
# jelszavakat titkosítatlan formában közli az interneten keresztül.
# Töröljük ezt a szabályt, ha nem használunk telnet szervert.
#pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state
# Befelé engedélyezzük az internetről # érkező ssh/sftp/scp (biztonságos
# telnet/rlogin/FTP) # kapcsolatokat az SSH (secure shell) használatával.
pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state
# Minden mást dobjuk el és naplózzuk az első előfordulásukat.
# Az első alkalom naplózásával elejét tudjuk venni a "Denial of
# Service" típusú támadásoknak, amivel egyébként lehetséges lenne a
# napló elárasztása.
# Ez a szabály blokkol alapértelmezés szerint mindent.
block in log first quick on dc0 all
################### Itt van a szabályok vége ##############################</programlisting>
</sect2>
<sect2>
<title><acronym>NAT</acronym></title>
<indexterm><primary>NAT</primary></indexterm>
<indexterm>
<primary>IP maszkolás</primary>
<see>NAT</see>
</indexterm>
<indexterm>
<primary>hálózati
címfordítás</primary>
<see>NAT</see>
</indexterm>
<para>A <acronym>NAT</acronym> jelentése <emphasis>Network
Address Translation</emphasis>, vagyis hálózati
címfordítás. A &linux; esetében ezt
<quote>IP masqueradingnak</quote>, vagyis IP maszkolásnak
hívják. A hálózati
címfordítás és az IP
maszkolás lényegben ugyanazt takarja. Az IPF
címfordításért felelős
funkciójának köszönhetően
képesek vagyunk a tűzfal mögött
elhelyezkedő helyi hálózat
számára megosztani az
internet-szolgáltatól kapott publikus
IP-címet.</para>
<para>Sokakban felmerülhet a kérdés, hogy erre
vajon mi szükségünk lehet. Az
internet-szolgáltatók a
magánszemélyeknek általában
dinamikus IP-címeket osztanak ki. A dinamikus itt arra
utal, hogy a címünk minden alkalommal
változik, amikor betárcsázunk a
szolgáltatóhoz vagy amikor ki- és
bekapcsoljuk a modemünket. Ez a dinamikus IP-cím
fog azonosítani minket az interneten.</para>
<para>Most tegyük fel, hogy öt gépünk van
otthon, viszont csak egyetlen előfizetéssel
rendelkezünk. Ebben az esetben öt telefonvonalat
kellene használnunk és mindegyik géphez
előfizetni az internetre.</para>
<para>A hálózati címfordítás
alkalmazásával azonban mindössze egyetlen
előfizetés kell. A gépek közül
négyet hozzákötünk egy switch-hez
és a switch-et pedig a fennmaradó géphez,
amelyen &os; fut. Ez utóbbi lesz az így
kialakított helyi hálózatunk
átjárója. A tűzfalban
működő címfordítás
segítségével a helyi
hálózaton található gépek
IP-címeit észrevétlenül át
tudjuk fordítani a hálózatunk publikus
IP-címére, ahogy a csomagok elhagyják az
átjárót. A beérkező csomagok
esetében mindez visszafelé történik
meg.</para>
<para>Az IP-címek közül adott egy
tartomány, amit a címfordítást
használó helyi hálózatok
részére tartanak fenn. Az RFC&nbsp;1918 szerint
az alábbi IP-címtartományok
használhatók a helyi hálózatban,
mivel ezeken keresztül közvetlenül sosem lehet
kijutni az internetre:</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<colspec colwidth="1*"/>
<colspec colwidth="1*"/>
<colspec colwidth="1*"/>
<tbody>
<row>
<entry>Kezdő IP: <hostid
role="ipaddr">10.0.0.0</hostid></entry>
<entry>-</entry>
<entry>Záró IP: <hostid
role="ipaddr">10.255.255.255</hostid></entry>
</row>
<row>
<entry>Kezdő IP: <hostid
role="ipaddr">172.16.0.0</hostid></entry>
<entry>-</entry>
<entry>Záró IP: <hostid
role="ipaddr">172.31.255.255</hostid></entry>
</row>
<row>
<entry>Kezdő IP: <hostid
role="ipaddr">192.168.0.0</hostid></entry>
<entry>-</entry>
<entry>Záró IP: <hostid
role="ipaddr">192.168.255.255</hostid></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>
<sect2>
<title>IP<acronym>NAT</acronym></title>
<indexterm>
<primary>NAT</primary>
<secondary>IPFILTER</secondary>
</indexterm>
<indexterm><primary><command>ipnat</command></primary></indexterm>
<para>A címfordításra vonatkozó
szabályokat az <command>ipnat</command> paranccsal tudjuk
betölteni. Az ilyen típusú
szabályokat általában az
<filename>/etc/ipnat.rules</filename> állományban
találjuk. A részleteket lásd az
&man.ipnat.1; man oldalán.</para>
<para>Amikor a címfordítás üzembe
helyezése után meg akarjuk változtatni a
címfordítás szabályait,
először a címfordítás
szabályait tartalmazó állományt
módosítsuk, majd a belső
címfordítási szabályok és a
címfordítási táblázatban
szereplő aktív bejegyzések
törléséhez futassuk le az
<command>ipnat</command> parancsot a <option>-CF</option>
beállítással.</para>
<para>A címfordítási szabályok
újratöltését egy ehhez hasonló
paranccsal tudjuk elvégezni:</para>
<screen>&prompt.root; <userinput>ipnat -CF -f <replaceable>/etc/ipnat.szabályok</replaceable></userinput></screen>
<para>A címfordításhoz tartozó
statisztikákat ezzel a paranccsal tudjuk
lekérdezni:</para>
<screen>&prompt.root; <userinput>ipnat -s</userinput></screen>
<para>A címfordítási
táblázatban pillanatnyilag szereplő
összerendeléseket a következő paranccsal
tudjuk listázni:</para>
<screen>&prompt.root; <userinput>ipnat -l</userinput></screen>
<para>A szabályok feldolgozásával és
az aktív szabályokkal/bejegyzésekkel
kapcsolatos információk
részletezését így
engedélyezhetjük:</para>
<screen>&prompt.root; <userinput>ipnat -v</userinput></screen>
</sect2>
<sect2>
<title>A címfordítási
szabályok</title>
<para>A címfordítási szabályok nagyon
rugalmasak és rengeteg olyan funkciót meg tudunk
velük valósítani, ami az üzleti
és otthoni felhasználók
számára egyaránt hasznos.</para>
<para>Itt most a szabályok
felépítését csak
egyszerűsítve mutatjuk be, leginkább a nem
üzleti környezetek tekintetében. A
szabályok komplett formai leírását
az &man.ipnat.5; man oldalán találjuk.</para>
<para>Egy címfordítási szabály
tehát valahogy így néz ki:</para>
<programlisting>map <replaceable>INTERFÉSZ</replaceable> <replaceable>HELYI_IP_TARTOMÁNY</replaceable> -&gt; <replaceable>PUBLIKUS_CÍM</replaceable></programlisting>
<para>A szabályt a <literal>map</literal> kulcsszó
kezdi.</para>
<para>A <replaceable>INTERFÉSZ</replaceable> helyére
az internet felé mutató külső
interfész nevét írjuk be.</para>
<para>A <replaceable>HELYI_IP_TARTOMÁNY</replaceable> lesz
az, amelyben a kliensek címeznek. Ez
például a <hostid
role="ipaddr">192.168.1.0/24</hostid>.</para>
<para>A <replaceable>PUBLIKUS_CÍM</replaceable> lehet egy
külső IP-cím vagy a <literal>0/32</literal>
speciális kulcsszó, amellyel a
<replaceable>FELÜLET</replaceable>-hez rendelt
IP-címre hivatkozunk.</para>
</sect2>
<sect2>
<title>Hogyan működik a hálózati
címfordítás</title>
<para>A publikus cél felé haladó csomag
megérkezik a helyi hálózatról.
Miután a kimenő kapcsolatokra vonatkozó
szabályok átengedik, a
címfordítás kapja meg a szerepet és
fentről lefelé haladva nekilát alkalmazni a
saját szabályait, ahol az első egyező
szerint cselekszik. A címfordítás a
szabályokat a csomaghoz tartozó interfészre
és a forrás IP-címére illeszti.
Amikor a csomag interfészének neve illeszkedik egy
címfordítási szabályra, akkor
ezután a csomag forrás (vagyis a helyi
hálózaton belüli)
IP-címéről igyekszik eldönteni, hogy a
szabály nyilának bal oldalán szereplő
tartományba esik-e. Ha erre is illeszkedik, akkor a
forrás IP-címét átírjuk a
<literal>0/32</literal> kulcsszó alapján
felderített publikus IP-címre. A
címfordító rutin ezt feljegyzi a
saját belső táblázatába,
így amikor a csomag visszatér az internetről,
akkor képes lesz visszafordítani az eredeti
belső IP-címére és
feldolgozásra átadni a tűzfal
szabályainak.</para>
</sect2>
<sect2>
<title>A címfordítás
engedélyezése</title>
<para>A címfordítás életre
keltéséhez a következőket kell
beállítanunk az <filename>/etc/rc.conf</filename>
állományban.</para>
<para>Először engedélyezzük a
gépünknek, hogy közvetítsen forgalmat az
interfészek között:</para>
<programlisting>gateway_enable="YES"</programlisting>
<para>Minden alkalommal indítsuk el a
címfordításért felelős IPNAT
programot:</para>
<programlisting>ipnat_enable="YES"</programlisting>
<para>Adjuk meg az IPNAT számára a
betöltendő szabályokat:</para>
<programlisting>ipnat_rules="/etc/ipnat.rules"</programlisting>
</sect2>
<sect2>
<title>Hálózati címfordítás
nagyon nagy helyi hálózatok
esetében</title>
<para>Az olyan helyi hálózatokban, ahol rengeteg PC
található vagy több alhálózatot
is tartalmaz, az összes privát IP-cím
egyetlen publikus IP-címbe
tömörítése igen komoly
problémává tud dagadni és az azonos
portok gyakori használata a helyi hálózatra
kötött számítógépek
között ütközéseket okoz. Két
módon tudunk megoldást nyújtani erre a
problémára.</para>
<sect3>
<title>A használható portok
kiosztása</title>
<para>Egy normális címfordítási
szabály valahogy így nézne ki:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 0/32</programlisting>
<para>A fenti szabályban a csomag
forrásportját az IP<acronym>NAT</acronym>
változatlanul a feldolgozás után hagyja.
Ha ehhez még hozzátesszük a
<literal>portmap</literal> kulcsszót, akkor ezzel
utasítani tudjuk az IP<acronym>NAT</acronym>-ot, hogy
csak az adott tartományban képezze le a
forrásportokat. Például a
következő szabály hatására az
IP<acronym>NAT</acronym> a forrásportokat egy adott
tartományon belül fogja
módosítani:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 0/32 portmap tcp/udp 20000:60000</programlisting>
<para>Ha viszont még inkább meg akarjuk
könnyíteni a dolgunkat, akkor itt egyszerűen
csak adjuk meg az <literal>auto</literal> kulcsszót,
amellyel az IP<acronym>NAT</acronym>
önmagától megállapítja, hogy
milyen portokat tud használni:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 0/32 portmap tcp/udp auto</programlisting>
</sect3>
<sect3>
<title>Több publikus cím használata</title>
<para>Minden nagyobb helyi hálózat esetében
elérkezünk ahhoz a ponthoz, ahol már
egyetlen publikus cím nem elég. Ha több
publikus IP-címmel is rendelkezünk, akkor
ezekből a címekből egy <quote>közös
készletet</quote> hozhatunk létre, amiből
majd az IPNAT válogathat miközben a csomagok
címeit átírja kifelé
menetben.</para>
<para>Például ahelyett, hogy a csomagokat egyetlen
publikus IP-címre képeznénk le, ahogy itt
tesszük:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 204.134.75.1</programlisting>
<para>A hálózati maszk
segítségével meg tudjuk adni
IP-címek egy tartományát is:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 204.134.75.0/255.255.255.0</programlisting>
<para>CIDR-jelöléssel:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 204.134.75.0/24</programlisting>
</sect3>
</sect2>
<sect2>
<title>A portok átirányítása</title>
<para>Gyakran előfordul, hogy van webszerverünk,
levelező szerverünk, adatbázis szerverünk
és névszerverünk, melyek a helyi
hálózat különböző
gépein futnak. Ebben az esetben a szerverekhez
tartozó forgalmat is fordítanunk kell, illetve
valamilyen módon a bejövő forgalmat is
át kell irányítanunk a helyi
hálózat megfelelő gépeihez. Az
IP<acronym>NAT</acronym> ezt a gondot a hálózati
címfordítás
átirányítást támogató
funkcióival szünteti meg. Tegyük fel, hogy a
<hostid role="ipaddr">10.0.10.25</hostid> belső
címen van egy webszerverünk, amelyhez a <hostid
role="ipaddr">20.20.20.5</hostid> publikus IP tartozik.
Ilyenkor a következő szabályt adjuk meg:</para>
<programlisting>rdr dc0 20.20.20.5/32 port 80 -&gt; 10.0.10.25 port 80</programlisting>
<para>vagy:</para>
<programlisting>rdr dc0 0.0.0.0/0 port 80 -&gt; 10.0.10.25 port 80</programlisting>
<para>Így tudjuk beállítani a <hostid
role="ipaddr">10.0.10.33</hostid> címmel
rendelkező névszervert a kintről
érkező névfeloldási
kérések fogadására:</para>
<programlisting>rdr dc0 20.20.20.5/32 port 53 -&gt; 10.0.10.33 port 53 udp</programlisting>
</sect2>
<sect2>
<title>Az FTP és a címfordítás</title>
<para>Az FTP egy olyan őskövület, amely még
az internet egy régi korszakából maradt fenn,
amikor az egyetemek között még bérelt
vonal létezett és az FTP szolgált a
kutatók közt az állományok
megosztására. Ez még abban az időben
történt, amikor a biztonság
egyáltalán nem volt lényeges szempont. Az
évek előrehaladtával az FTP protokoll
beleivódott a feltörekvő internet
gerincébe és a titkosítatlanul
küldött azonosítóival és
jelszavaival továbbra is ugyanolyan védtelen
maradt. Az FTP két változatban, aktív
és passzív módban képes
működni. Az eltérés kettejük
között az adatcsatorna
megállapításában van. A
passzív mód sokkal biztonságosabb, mivel
ilyenkor az adatcsatornát az FTP kapcsolatot
kezdeményező állítja be. Az FTP
különböző módjainak
magyarázatát és a köztük
levő különbséget a <ulink
url="http://www.slacksite.com/other/ftp.html"></ulink>
címen ismerhetjük meg részleteiben
(angolul).</para>
<sect3>
<title>Az IPNAT szabályai</title>
<para>Az IPNAT egy speciális beépített FTP
proxyval rendelkezik, amelyre a hálózati
címfordítás leképezései
között hivatkozhatunk. Képes figyelni az
összes aktív vagy passzív FTP kapcsolathoz
tartozó kimenő kérést és
ezekhez dinamikusan létrehozni olyan ideiglenes
szűrési szabályokat, amelyek valóban
csak az adatcsatornához felhasznált portokat
tartalmazzák. Ezzel ki tudjuk
küszöbölni az FTP azon káros
hatását a tűzfalra nézve, hogy
egyszerre túlságosan sok magasabb
tartománybeli port legyen nyitva.</para>
<para>Ez a szabály a belső hálózat
összes FTP forgalmát lekezeli:</para>
<programlisting>map dc0 10.0.10.0/29 -&gt; 0/32 proxy port 21 ftp/tcp</programlisting>
<para>Ez a szabály pedig az
átjáróról érkező FTP
forgalommal bírkózik meg:</para>
<programlisting>map dc0 0.0.0.0/0 -&gt; 0/32 proxy port 21 ftp/tcp</programlisting>
<para>Ez a szabály kezeli a belső
hálózatról érkező összes
nem FTP típusú forgalmat:</para>
<programlisting>map dc0 10.0.10.0/29 -&gt; 0/32</programlisting>
<para>Az FTP leképzésére vonatkozó
szabály a szokásos leképzési
szabály elé kerül. Az összes csomag
fentről haladva az első illeszkedő
szabály alapján kerül feldolgozásra.
Először az interfész nevét
vizsgáljuk, majd a belső hálózatbeli
forrás IP-t, végül azt, hogy a csomag egy
FTP kapcsolat része. Ha minden
paraméterében megfelel, akkor az FTP proxy
készít egy ideiglenes szűrési
szabályt hozzá, amellyel az FTP kapcsolathoz
tartozó csomagok mind a két irányba
képesek lesznek vándorolni, természetesen
a címfordítással együtt. Az
összes többi bentről érkező csomag
átlép ezen a szabályon és
megáll a harmadiknál, ahol az
interfésznek és forrás IP-nek
megfelelően átfordítjuk a
címét.</para>
</sect3>
<sect3>
<title>Az IPNAT szűrési szabályai
FTP-re</title>
<para>Az FTP esetében csak egyetlen szűrési
szabályra van szükségünk a
hálózati címfordításba
épített FTP proxy
használatához.</para>
<para>FTP proxy nélkül az alábbi három
szabály kellene:</para>
<programlisting># Kifelé engedélyezzük a belső gépek FTP elérést az internet irányába,
# aktív és passzív módokban.
pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state
# Kifelé engedélyezzük a passzív módhoz tartozó magasabb tartománybeli
# adatcsatornákat.
pass out quick on rl0 proto tcp from any to any port &gt; 1024 flags S keep state
# Aktív módban beengedjük az FTP szervertől érkező adatcsatornát.
pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state</programlisting>
</sect3>
</sect2>
</sect1>
<sect1 id="firewalls-ipfw">
<title>IPFW</title>
<indexterm>
<primary>tűzfalak</primary>
<secondary>IPFW</secondary>
</indexterm>
<para>Az IPFIREWALL (<acronym>IPFW</acronym>) a &os; által
támogatott tűzfalazó alkalmazás, melyet a
&os; 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 <quote>egyszerű állapottartó
megoldásnak</quote> nevezzük.</para>
<para>Az IPFW szabvány &os;-ben levő, mintaként
szolgáló szabályrendszere (ez az
<filename>/etc/rc.firewall</filename> és
<filename>/etc/rc.firewall6</filename> á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.</para>
<para>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.</para>
<para>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ó
<literal>divert</literal> 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 <literal>fwd
rule</literal> szabály, a hálózati hidak
támogatása, illetve az ipstealth. Az IPFW
egyaránt használható IPv4 és IPv6
esetén.</para>
<sect2 id="firewalls-ipfw-enable">
<title>Az IPFW engedélyezése</title>
<indexterm>
<primary>IPFW</primary>
<secondary>engedélyezése</secondary>
</indexterm>
<para>Az IPFW az alap &os; telepítésben
külön, futás időben betölthető
modulként érhető el. Ha az
<filename>rc.conf</filename> állományban megadjuk
a <literal>firewall_enable="YES"</literal>
beállítást, akkor a rendszer
indulásakor ezt a modult dinamikusan betölti. Az
IPFW-t csak akkor kell a &os; rendszermagjába
beépítenünk, ha szükségünk
van a címfordítási
funkciójára is.</para>
<para>Ha tehát az <filename>rc.conf</filename>
állományban megadtuk a
<literal>firewall_enable="YES"</literal> 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:</para>
<screen>ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled</screen>
<para>A <quote>logging disabled</quote> ü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 <filename>/etc/sysctl.conf</filename>
állományba felvesszük a következő
sorokat, amivel a következő indításkor
már működni fog:</para>
<programlisting>net.inet.ip.fw.verbose=1
net.inet.ip.fw.verbose_limit=5</programlisting>
</sect2>
<sect2 id="firewalls-ipfw-kernel">
<title>A rendszermag beállításai</title>
<indexterm>
<primary>a rendszermag
beállításai</primary>
<secondary>IPFIREWALL</secondary>
</indexterm>
<indexterm>
<primary>a rendszermag
beállításai</primary>
<secondary>IPFIREWALL_VERBOSE</secondary>
</indexterm>
<indexterm>
<primary>a rendszermag
beállításai</primary>
<secondary>IPFIREWALL_VERBOSE_LIMIT</secondary>
</indexterm>
<indexterm>
<primary>IPFW</primary>
<secondary>a rendszermag
beállításai</secondary>
</indexterm>
<para>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 &os; 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.</para>
<programlisting>options IPFIREWALL</programlisting>
<para>Ez a beállítás engedélyezi az
IPFW használatát a rendszermag
részeként.</para>
<programlisting>options IPFIREWALL_VERBOSE</programlisting>
<para>Ezzel és a <literal>log</literal> kulcsszóval
tudjuk az IPFW szabályain keresztülhaladó
csomagokat naplózni.</para>
<programlisting>options IPFIREWALL_VERBOSE_LIMIT=5</programlisting>
<para>Ez az érték korlátozza a
&man.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.</para>
<indexterm>
<primary>a rendszermag
beállításai</primary>
<secondary>IPFIREWALL_DEFAULT_TO_ACCEPT</secondary>
</indexterm>
<programlisting>options IPFIREWALL_DEFAULT_TO_ACCEPT</programlisting>
<para>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.</para>
<indexterm>
<primary>a rendszermag
beállításai</primary>
<secondary>IPDIVERT</secondary>
</indexterm>
<programlisting>options IPDIVERT</programlisting>
<para>Ezzel a beállítással
engedélyezzük a címfordítás
használatát.</para>
<note>
<para>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.</para>
</note>
</sect2>
<sect2 id="firewalls-ipfw-rc">
<title>Az <filename>/etc/rc.conf</filename>
beállításai</title>
<para>Így tudjuk engedélyezni a
tűzfalat:</para>
<programlisting>firewall_enable="YES"</programlisting>
<para>A &os;-hez mellékelt alapértelmezett
tűzfaltípusok közül az
<filename>/etc/rc.firewall</filename> állomány
átolvasásával tudunk választani,
és megadni az alábbi helyett:</para>
<programlisting>firewall_type="open"</programlisting>
<para>A következő értékek állnak
rendelkezésünkre:</para>
<itemizedlist>
<listitem>
<para><literal>open</literal> &mdash; átengedi az
összes forgalmat</para>
</listitem>
<listitem>
<para><literal>client</literal> &mdash; csak ezt a
gépet védi</para>
</listitem>
<listitem>
<para><literal>simple</literal> &mdash; az egész
hálózatot védi</para>
</listitem>
<listitem>
<para><literal>closed</literal> &mdash; a helyi
interfész kivételével minden IP
alapú forgalmat tilt</para>
</listitem>
<listitem>
<para><literal>UNKNOWN</literal> &mdash; tiltja a tűzfal
szabályainak betöltését</para>
</listitem>
<listitem>
<para><filename><replaceable>állománynév</replaceable></filename>
&mdash; a tűzfal szabályait tartalmazó
állomány abszolút elérési
útvonala</para>
</listitem>
</itemizedlist>
<para>Két különböző módon lehet
betölteni a saját <application>ipfw</application>
szabályainkat. Az egyik közülük, ha a
<literal>firewall_type</literal> változóban
megadjuk a <emphasis>tűzfal szabályait</emphasis>
tartalmazó állomány abszolút
elérési útvonalát, az &man.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:</para>
<programlisting>add deny in
add deny out</programlisting>
<para>Másrészről az
<literal>firewall_script</literal> változóban is
megadhatjuk azt a szkriptet, amelyben a
rendszerindítás során meghívjuk
<command>ipfw</command> parancsot. Az iménti
szabályrendszert az alábbi szkripttel tudjuk
kiváltani:</para>
<programlisting>#!/bin/sh
ipfw -q flush
ipfw add deny in
ipfw add deny out</programlisting>
<note>
<para>Ha a <literal>firewall_type</literal>
változó <literal>client</literal> vagy
<literal>simple</literal> értékét
használjuk, akkor az
<filename>/etc/rc.firewall</filename>
á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 <literal>firewall_script</literal>
értéke az <filename>/etc/ipfw.rules</filename>
állomány.</para>
</note>
<para>A naplózás így
engedélyezhető:</para>
<programlisting>firewall_logging="YES"</programlisting>
<warning>
<para>A <varname>firewall_logging</varname>
változó egyedül csak annyit tesz, hogy
beállítja a
<varname>net.inet.ip.fw.verbose</varname> sysctl
változónak az <literal>1</literal>
értéket (lásd <xref
linkend="firewalls-ipfw-enable"/>). A napló
korlátozására nincs külön
változó az <filename>rc.conf</filename>
állományon belül, de az
<filename>/etc/sysctl.conf</filename> állomány
segítségével és manuálisan
be tudjuk állítani a hozzá tartozó
változót:</para>
<programlisting>net.inet.ip.fw.verbose_limit=5</programlisting>
</warning>
<para>Amennyiben a gépünk
átjáróként viselkedik, tehát
a &man.natd.8; segítségével
címfordítást végez, a <xref
linkend="network-natd"/>ban olvashatunk utána, hogy ehhez
az <filename>/etc/rc.conf</filename> állományban
milyen beállításokat kell megadnunk.</para>
</sect2>
<sect2 id="firewalls-ipfw-cmd">
<title>Az IPFW parancs</title>
<indexterm><primary><command>ipfw</command></primary></indexterm>
<para>Normál esetben az <command>ipfw</command> 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.</para>
<para>Az <command>ipfw</command> 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.</para>
<para>A szabályokat így tudjuk egymás
után felsoroltatni:</para>
<screen>&prompt.root; <userinput>ipfw list</userinput></screen>
<para>A szabályokat így tudjuk az utolsó
illeszkedésük idejével együtt
megjeleníteni:</para>
<screen>&prompt.root; <userinput>ipfw -t list</userinput></screen>
<para>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.</para>
<screen>&prompt.root; <userinput>ipfw -a list</userinput></screen>
<para>A statikus szabályok mellett a dinamikusakat
így lehet kilistázni:</para>
<screen>&prompt.root; <userinput>ipfw -d list</userinput></screen>
<para>A lejárt dinamikus szabályokat is meg tudjuk
nézni:</para>
<screen>&prompt.root; <userinput>ipfw -d -e list</userinput></screen>
<para>A számlálók
nullázása:</para>
<screen>&prompt.root; <userinput>ipfw zero</userinput></screen>
<para>Csak a <replaceable>SZÁM</replaceable>
sorszámú szabályhoz tartozó
számlálók nullázása:</para>
<screen>&prompt.root; <userinput>ipfw zero <replaceable>SZÁM</replaceable></userinput></screen>
</sect2>
<sect2 id="firewalls-ipfw-rules">
<title>Szabályrendszerek az IPFW-ben</title>
<para>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
<acronym>TCP/IP</acronym> 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.</para>
<indexterm>
<primary>IPFW</primary>
<secondary>a szabályok feldolgozásának
sorrendje</secondary>
</indexterm>
<para>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 <quote>az első
illeszkedés nyer</quote> 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.</para>
<note>
<para>A keresés a <literal>count</literal>,
<literal>skipto</literal> és <literal>tee</literal>
szabályok után még
folytatódik.</para>
</note>
<para>Az itt szereplő utasítások
különböző állapottartásra
vonatkozó opciókat, például a
<literal>keep state</literal>, <literal>limit</literal>,
<literal>in</literal>, <literal>out</literal> és
<literal>via</literal> kulcsszavakat tartalmazó
szabályokon alapulnak. Lényegében ezt
tekinthetjük az inkluzív típusú
tűzfalak kiindulási alapjaként.</para>
<warning>
<para>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.</para>
</warning>
<sect3 id="firewalls-ipfw-rules-syntax">
<title>A szabályok
felépítése</title>
<indexterm>
<primary>IPFW</primary>
<secondary>a szabályok
felépítése</secondary>
</indexterm>
<para>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 &man.ipfw.8; man
oldalán találhatjuk meg.</para>
<para>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.</para>
<para>A <literal>#</literal> 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.</para>
<para><replaceable>PARANCS SZABÁLY_SZÁM
CSELEKVÉS NAPLÓZÁS SZűRÉS
ÁLLAPOTTARTÁS</replaceable></para>
<sect4>
<title>PARANCS</title>
<para>Minden új szabály előttt az
<parameter>add</parameter> (mint hozzáadás)
parancsnak kell szerepelni, amellyel a belső
táblázatba tudjuk felvenni.</para>
</sect4>
<sect4>
<title>SZABÁLY_SZÁM</title>
<para>A szabályokhoz mindig tartozik egy sorszám
is.</para>
</sect4>
<sect4>
<title>CSELEKVÉS</title>
<para>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.</para>
<para><parameter>allow | accept | pass |
permit</parameter></para>
<para>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.</para>
<para><parameter>check-state</parameter></para>
<para>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ő <literal>keep-state</literal> vagy
<literal>limit</literal> használatánál
vonja be a rendszer.</para>
<para><parameter>deny | drop</parameter></para>
<para>Mind a két szó ugyanarra utal, vagyis a
szabályra illeszkedő csomagokat el kell dobni.
Ebben az esetben a keresés befejeződik.</para>
</sect4>
<sect4>
<title>NAPLÓZÁS</title>
<para><parameter>log</parameter> vagy
<parameter>logamount</parameter></para>
<para>Amikor egy csomag egy <literal>log</literal>
kulcsszót tartalmazó szabályra
illeszkedik, akkor a rendszernaplóban egy üzenet
keletkezik a <literal>security</literal> (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ó
<literal>logamount</literal> paraméter
értékét. Ha ezt nem adtuk meg, akkor
az itt érvényes korlát a
<varname>net.inet.ip.fw.verbose_limit</varname> 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 <command>ipfw reset log</command>
parancsot.</para>
<note>
<para>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.</para>
</note>
</sect4>
<sect4>
<title>SZűRÉS</title>
<para>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:</para>
<para><parameter>udp | tcp | icmp</parameter></para>
<para>Bármilyen más olyan protokoll is
megadható, amely megtalálható az
<filename>/etc/protocols</filename>
állományban. Ezzel adjuk a csomaghoz
tartozó protokollt. Használata
kötelező.</para>
<para><parameter>from <replaceable>forrás</replaceable>
to <replaceable>cél</replaceable></parameter></para>
<para>Mind a <literal>from</literal> és
<literal>to</literal> kulcsszavak IP-címek
illesztésére alkalmasak. A
szabályoknak tartalmazniuk kell a
<replaceable>forrás</replaceable> ÉS a
<replaceable>cél</replaceable> paramétereket
is. Az <literal>any</literal> egy olyan kulcsszó,
amely tetszőleges IP-címre illeszkedik. A
<literal>me</literal> pedig egy olyan speciális
kulcsszó, amely a tűzfalat
működtető &os;-s gép (tehát ez
a gép) adott interfészhez tartozó
IP-címét jelöli, mint ahogy a
<literal>from me to any</literal>, <literal>from any to
me</literal>, <literal>from 0.0.0.0/0 to any</literal>,
<literal>from any to 0.0.0.0/0</literal>, <literal>from
0.0.0.0 to any</literal>, <literal>from any to
0.0.0.0</literal> vagy <literal>from me to 0.0.0.0</literal>
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 <filename
role="package">net-mgmt/ipcalc</filename> port lehet
segítségünkre. Erről bővebb
információkat a segédprogram
honlapján, a <ulink
url="http://jodies.de/ipcalc"></ulink> címen
találhatunk (angolul).</para>
<para><parameter>port
<replaceable>szám</replaceable></parameter></para>
<para>A portszámokat is ismerő protokollok
esetében (mint például a
<acronym>TCP</acronym> vagy <acronym>UDP</acronym>) 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
<filename>/etc/services</filename>
állományból származó)
nevét is megadhatjuk a port száma
helyett.</para>
<para><parameter>in | out</parameter></para>
<para>A beérkező valamint a kimenő csomagokat
adhatjuk meg ezen a módon. Itt az
<literal>in</literal> és <literal>out</literal>
kulcsszavak, melyeket kötelező megadni a
szabály részeként.</para>
<para><parameter>via
<replaceable>interfész</replaceable></parameter></para>
<para>Név szerint az adott interfészen
keresztül haladó csomagokat tudjuk szűrni.
A <literal>via</literal> kulcsszó
hatására a használt interfész is
számítani fog a csomag feldolgozása
során.</para>
<para><parameter>setup</parameter></para>
<para>Ez a kulcsszó a <acronym>TCP</acronym> csomagok
esetében a kapcsolatok
felépítésére vonatkozó
kéréseket segít
beazonosítani.</para>
<para><parameter>keep-state</parameter></para>
<para>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.</para>
<para><parameter>limit
{<replaceable>forráscím</replaceable> |
<replaceable>forrásport</replaceable> |
<replaceable>célcím</replaceable> |
<replaceable>célport</replaceable>}</parameter></para>
<para>A tűzfal csak <replaceable>N</replaceable> 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
<literal>limit</literal> és a
<literal>keep-state</literal> egy szabályon
belül nem használható. A
<literal>limit</literal> ugyanazokat az
állapottartó funkciókat
képviseli, mint a <literal>keep-state</literal>, csak
a saját kiegészítéseivel
megtoldva.</para>
</sect4>
</sect3>
<sect3>
<title>ÁLLAPOTTARTÁS</title>
<indexterm>
<primary>IPFW</primary>
<secondary>állapottartó
szűrés</secondary>
</indexterm>
<para>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.</para>
<para>A <literal>check-state</literal>
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.</para>
<para>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 &os; 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
<literal>limit</literal> 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
<literal>limit</literal> 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.</para>
</sect3>
<sect3>
<title>A tűzfal üzeneteinek
naplózása</title>
<indexterm>
<primary>IPFW</primary>
<secondary>naplózás</secondary>
</indexterm>
<para>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.</para>
<para>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
<literal>log</literal> kulcsszót.
Általában csak az eldobással
járó <literal>deny</literal>
típusú szabályokat vagy a
bejövő <acronym>ICMP</acronym> pingeket
szokták naplózni. Gyakran úgy
oldják meg ezt, hogy a szabályrendszer
utolsó szabályaként
lemásolják az <command>ipfw</command>
alapértelmezett <quote>mindent eldobunk</quote>
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.</para>
<para>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.</para>
<para>A rendszermag
<literal>IPFIREWALL_VERBOSE_LIMIT=5</literal>
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é:</para>
<programlisting>last message repeated 45 times</programlisting>
<para>Ami magyarul így hangzik:</para>
<programlisting>az utolsó üzenet 45 alkalommal ismétlődött meg</programlisting>
<para>Az összes csomagokkal kapcsolatos
naplózás alapértelmezés szerint a
<filename>/var/log/security</filename>
állományba kerül, amelyet az
<filename>/etc/syslog.conf</filename> állomány
definiál.</para>
</sect3>
<sect3 id="firewalls-ipfw-rules-script">
<title>Szabályokat tartalmazó szkript
készítése</title>
<para>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.</para>
<para>A szkript felépítése kompatibilis a
&man.sh.1;, &man.csh.1; és &man.tcsh.1;
parancsértelmezőkkel. A szimbolikus mezők
helyettesítését a &dollar; vagyis
dollárjel vezeti be. Maguk a szimbolikus mezők
nem tartalmazzák a &dollar; előtagot. A
szimbolikus mezők értékeit "kettős
idézőjelek" között kell megadni.</para>
<para>A szabályok összeírását
kezdjük el így:</para>
<programlisting>####### 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
&dollar;cmd 00500 check-state
&dollar;cmd 00502 deny all from any to any frag
&dollar;cmd 00501 deny tcp from any to any established
&dollar;cmd 00600 allow tcp from any to any 80 out via &dollar;oif setup &dollar;ks
&dollar;cmd 00610 allow tcp from any to &dollar;odns 53 out via &dollar;oif setup &dollar;ks
&dollar;cmd 00611 allow udp from any to &dollar;odns 53 out via &dollar;oif &dollar;ks
#### itt fejeződik be az ipfw szabályait tartalmazó szkript ######</programlisting>
<para>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.</para>
<para>Ha az iménti példát az
<filename>/etc/ipfw.rules</filename> állományba
mentettük el, akkor az alábbi parancs
kiadásával tudjuk újratölteni a
benne szereplő szabályokat:</para>
<screen>&prompt.root; <userinput>sh /etc/ipfw.rules</userinput></screen>
<para>Az <filename>/etc/ipfw.rules</filename>
állományt egyébként
tetszőleges néven hívhatjuk és
bárhová rakhatjuk.</para>
<para>Ugyanez természetesen elérhető a
következő parancsok egymás utáni
begépelésével is:</para>
<screen>&prompt.root; <userinput>ipfw -q -f flush</userinput>
&prompt.root; <userinput>ipfw -q add check-state</userinput>
&prompt.root; <userinput>ipfw -q add deny all from any to any frag</userinput>
&prompt.root; <userinput>ipfw -q add deny tcp from any to any established</userinput>
&prompt.root; <userinput>ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state</userinput>
&prompt.root; <userinput>ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state</userinput>
&prompt.root; <userinput>ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state</userinput></screen>
</sect3>
<sect3>
<title>Állapottartó
szabályrendszerek</title>
<para>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
<quote>inkluzív</quote> 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.</para>
<para>Az &unix; mintájú operációs
rendszer, köztül a &os; is olyan, hogy a rendszerben
belüli kommunikációt a
<devicename>lo0</devicename> nevű interfészen
és a <hostid role="ipaddr">127.0.0.1</hostid>
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.</para>
<para>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 <acronym>PPP</acronym>
esetében a <devicename>tun0</devicename> eszköz,
vagy a DSL-, illetve kábelmodemhez csatlakozó
hálózati kártya.</para>
<para>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.</para>
<para>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.</para>
<para>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.</para>
<para>A következő szabályrendszerben
szereplő, a kimenő kapcsolatokat tartalmazó
csoport csak olyan <literal>allow</literal>
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 <literal>proto</literal>,
<literal>port</literal>,
<literal>in</literal>/<literal>out</literal>,
<literal>via</literal> és <literal>keep
state</literal> opciók. A <literal>proto
tcp</literal> szabályokban emellett szerepel még
egy <literal>setup</literal> opció is, amellyel a
kapcsolatokat kezdeményező csomagokat tudjuk
azonosítani és felvenni az
állapottartásért felelős dinamikus
szabályok közé.</para>
<para>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.</para>
<para>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
<filename>/etc/services/</filename> állományban
vagy <ulink
url="http://www.securitystats.com/tools/portsearch.php"></ulink>
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): <ulink
url="http://www.simovits.com/trojans/trojans.html"></ulink>.</para>
</sect3>
<sect3>
<title>Példa egy inkluzív
szabályrendszerre</title>
<para>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 <literal>deny</literal> típusú
szabályt hozzájuk. Minden szabályban
cseréljük ki a <literal>dc0</literal>
interfészt arra a hálózati
kártyára, amely közvetlenül
csatlakoztatja rendszerünket az internethez. A
felhasználói <acronym>PPP</acronym>
esetében ez a <literal>tun0</literal>.</para>
<para>A szabályok használatában
felfedezhetünk egyfajta
rendszerszerűséget:</para>
<itemizedlist>
<listitem>
<para>Mindegyik sorban, ahol az internet felé nyitunk
meg egy kapcsolatot, a <literal>keep-state</literal>
opciót használjuk.</para>
</listitem>
<listitem>
<para>Az internetről az összes hitelesített
szolgáltatás elérése
tartalmazza a <literal>limit</literal> opciót az
elárasztások kivédése
miatt.</para>
</listitem>
<listitem>
<para>Az összes szabályban az
<literal>in</literal> vagy az <literal>out</literal>
paraméterrel megadjuk szűrni
kívánt forgalom
irányát.</para>
</listitem>
<listitem>
<para>Az összes szabályban szerepel a
<literal>via</literal> paraméterrel a csomagokat
továbbító interfész
neve.</para>
</listitem>
</itemizedlist>
<para>Az alábbi szabályokat tegyük az
<filename>/etc/ipfw.rules</filename>
állományba.</para>
<programlisting>############## 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.
################################################################
#&dollar;cmd 00005 allow all from any to any via xl0
################################################################
# A rendszer belső interfészét se szűrjük.
################################################################
&dollar;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.
################################################################
&dollar;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.
&dollar;cmd 00110 allow tcp from any to x.x.x.x 53 out via &dollar;pif setup keep-state
&dollar;cmd 00111 allow udp from any to x.x.x.x 53 out via &dollar;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.
&dollar;cmd 00120 allow log udp from any to any 67 out via &dollar;pif keep-state
#&dollar;cmd 00120 allow udp from any to x.x.x.x 67 out via &dollar;pif keep-state
# Kifelé engedélyezzük a szabvány nem biztonságos WWW
# funkció elérését.
&dollar;cmd 00200 allow tcp from any to any 80 out via &dollar;pif setup keep-state
# Kifelé engedélyezzük a biztonságos HTTPS funkció
# elérését TLS SSL használatával.
&dollar;cmd 00220 allow tcp from any to any 443 out via &dollar;pif setup keep-state
# Kifelé engedélyezzük a e-mailek küldését és fogadását.
&dollar;cmd 00230 allow tcp from any to any 25 out via &dollar;pif setup keep-state
&dollar;cmd 00231 allow tcp from any to any 110 out via &dollar;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.
&dollar;cmd 00240 allow tcp from me to any out via &dollar;pif setup keep-state uid root
# Kifelé engedélyezzük a pinget.
&dollar;cmd 00250 allow icmp from any to any out via &dollar;pif keep-state
# Kifelé engedélyezzük az idő szolgáltatást.
&dollar;cmd 00260 allow tcp from any to any 37 out via &dollar;pif setup keep-state
# Kifelé engedélyezzük az nntp news szolgáltatást
# (vagyis a hírcsoportokat)
&dollar;cmd 00270 allow tcp from any to any 119 out via &dollar;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.
&dollar;cmd 00280 allow tcp from any to any 22 out via &dollar;pif setup keep-state
# Kifelé engedélyezzük a whois szolgáltatást.
&dollar;cmd 00290 allow tcp from any to any 43 out via &dollar;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.
&dollar;cmd 00299 deny log all from any to any out via &dollar;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.
&dollar;cmd 00300 deny all from 192.168.0.0/16 to any in via &dollar;pif #RFC 1918: privát IP
&dollar;cmd 00301 deny all from 172.16.0.0/12 to any in via &dollar;pif #RFC 1918: privát IP
&dollar;cmd 00302 deny all from 10.0.0.0/8 to any in via &dollar;pif #RFC 1918: privát IP
&dollar;cmd 00303 deny all from 127.0.0.0/8 to any in via &dollar;pif #helyi
&dollar;cmd 00304 deny all from 0.0.0.0/8 to any in via &dollar;pif #helyi
&dollar;cmd 00305 deny all from 169.254.0.0/16 to any in via &dollar;pif #DHCP
&dollar;cmd 00306 deny all from 192.0.2.0/24 to any in via &dollar;pif #dokumentációs célokra fenntartott
&dollar;cmd 00307 deny all from 204.152.64.0/23 to any in via &dollar;pif #Sun klaszterek összekötésére használt
&dollar;cmd 00308 deny all from 224.0.0.0/3 to any in via &dollar;pif #D és E osztályú multicast
# A nyilvános pingek tiltása.
&dollar;cmd 00310 deny icmp from any to any in via &dollar;pif
# Az ident szolgáltatás tiltása.
&dollar;cmd 00315 deny tcp from any to any 113 in via &dollar;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.
&dollar;cmd 00320 deny tcp from any to any 137 in via &dollar;pif
&dollar;cmd 00321 deny tcp from any to any 138 in via &dollar;pif
&dollar;cmd 00322 deny tcp from any to any 139 in via &dollar;pif
&dollar;cmd 00323 deny tcp from any to any 81 in via &dollar;pif
# Eldobjuk az összes későn érkező csomagot.
&dollar;cmd 00330 deny all from any to any frag in via &dollar;pif
# Eldobjuk azokat az ACK csomagokat, amelyek egyik dinamikus
# szabálynak sem felelnek meg.
&dollar;cmd 00332 deny tcp from any to any established in via &dollar;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.
#&dollar;cmd 00360 allow udp from any to x.x.x.x 67 in via &dollar;pif keep-state
# Befelé engedélyezzük a szabvány WWW funkciót, mivel webszerverünk
# is van.
&dollar;cmd 00400 allow tcp from any to me 80 in via &dollar;pif setup limit src-addr 2
# Befelé engedélyezzük a biztonságos FTP, telnet és SCP
# típusú kapcsolatokat az internetről.
&dollar;cmd 00410 allow tcp from any to me 22 in via &dollar;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.
&dollar;cmd 00420 allow tcp from any to me 23 in via &dollar;pif setup limit src-addr 2
# Dobjuk el és naplózzuk az összes többi kintről érkező csomagot.
&dollar;cmd 00499 deny log all from any to any in via &dollar;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.
&dollar;cmd 00999 deny log all from any to any
############# Itt fejeződnek be az IPFW szabályai #####################</programlisting>
</sect3>
<sect3>
<title>Példa hálózati
címfordításra és
állapottartásra</title>
<indexterm>
<primary>címfordítás</primary>
<secondary>és az IPFW</secondary>
</indexterm>
<para>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 <literal>option IPDIVERT</literal> sort a többi
<literal>IPFIREWALL</literal> sor mellett, és
fordítanunk egy saját verziót.</para>
<para>Emellett még az <filename>/etc/rc.conf</filename>
állományban is engedélyezni kell az IPFW
alapvető funkcióit.</para>
<programlisting>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</programlisting>
<para>Az állapottartó szabályok
használata a <literal>divert natd</literal>
címfordítási opcióval együtt
nagyban növeli a szabályrendszer
leprogramozásának bonyolultságát.
A <literal>check-state</literal> és <literal>divert
natd</literal> 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
<literal>skipto</literal>. A <literal>skipto</literal>
parancs használatához elengedhetetlen a
szabályok sorszámozása, mivel pontosan
tudnunk kell, hogy a <literal>skipto</literal>
hatására hova kell ugrania a
vezérlésnek.</para>
<para>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.</para>
<para>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.</para>
<para>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 <literal>keep-state</literal> 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 <literal>skipto
500</literal> (<quote>ugorjunk az 500-as
szabályra</quote>) 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 <literal>check-state</literal>
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 <literal>check-state</literal>
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 <literal>skipto 500</literal>
művelet. A csomag erre az 500-as szabályra ugrik,
ahol lefordítjuk a címét és
továbbküldjük.</para>
<para>Az bejövő oldalon minden, ami egy
korábban kialakult kapcsolat részeként
érkezik, automatikusan a <literal>check-state</literal>
és a megfelelő helyre rakott <literal>divert
natd</literal> 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.</para>
<para>Íme az első példa egy ilyen
szabályrendszerre:</para>
<programlisting>#!/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
&dollar;cmd 002 allow all from any to any via xl0 # nem szűrjük a belső hálózatot
&dollar;cmd 003 allow all from any to any via lo0 # nem szűrjük a helyi interfészt
&dollar;cmd 100 divert natd ip from any to any in via &dollar;pif
&dollar;cmd 101 check-state
# A kimenő csomagok hitelesítése:
&dollar;cmd 120 &dollar;skip udp from any to xx.168.240.2 53 out via &dollar;pif &dollar;ks
&dollar;cmd 121 &dollar;skip udp from any to xx.168.240.5 53 out via &dollar;pif &dollar;ks
&dollar;cmd 125 &dollar;skip tcp from any to any &dollar;good_tcpo out via &dollar;pif setup &dollar;ks
&dollar;cmd 130 &dollar;skip icmp from any to any out via &dollar;pif &dollar;ks
&dollar;cmd 135 &dollar;skip udp from any to any 123 out via &dollar;pif &dollar;ks
# Az összes olyan csomagot eldobjuk, amely a fenntartott
# címtartományokba tart:
&dollar;cmd 300 deny all from 192.168.0.0/16 to any in via &dollar;pif #RFC 1918: privát IP
&dollar;cmd 301 deny all from 172.16.0.0/12 to any in via &dollar;pif #RFC 1918: privát IP
&dollar;cmd 302 deny all from 10.0.0.0/8 to any in via &dollar;pif #RFC 1918: privát IP
&dollar;cmd 303 deny all from 127.0.0.0/8 to any in via &dollar;pif #helyi
&dollar;cmd 304 deny all from 0.0.0.0/8 to any in via &dollar;pif #helyi
&dollar;cmd 305 deny all from 169.254.0.0/16 to any in via &dollar;pif #DHCP
&dollar;cmd 306 deny all from 192.0.2.0/24 to any in via &dollar;pif #dokumentációs célokra fenntartott
&dollar;cmd 307 deny all from 204.152.64.0/23 to any in via &dollar;pif #Sun klaszter
&dollar;cmd 308 deny all from 224.0.0.0/3 to any in via &dollar;pif #D és E osztályú multicast
# Az érkező csomagok hitelesítése:
&dollar;cmd 400 allow udp from xx.70.207.54 to any 68 in &dollar;ks
&dollar;cmd 420 allow tcp from any to me 80 in via &dollar;pif setup limit src-addr 1
&dollar;cmd 450 deny log ip from any to any
# Ide ugrunk a kimenő állapottartó szabályoknál:
&dollar;cmd 500 divert natd ip from any to any out via &dollar;pif
&dollar;cmd 510 allow ip from any to any
##################### a szabályok vége ##################</programlisting>
<para>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.</para>
<para>A második példa:</para>
<programlisting>#!/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.
#################################################################
&dollar;cmd 005 allow all from any to any via xl0
#################################################################
# A rendszer belső interfészét se szűrjük.
#################################################################
&dollar;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.
#################################################################
&dollar;cmd 014 divert natd ip from any to any in via &dollar;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.
#################################################################
&dollar;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.
&dollar;cmd 020 &dollar;skip tcp from any to x.x.x.x 53 out via &dollar;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.
&dollar;cmd 030 &dollar;skip udp from any to x.x.x.x 67 out via &dollar;pif keep-state
# Kifelé engedélyezzük a szabvány nem biztonságos WWW funkciót
&dollar;cmd 040 &dollar;skip tcp from any to any 80 out via &dollar;pif setup keep-state
# Kifelé engedélyezzük a biztonságos HTTPS funkciót a TLS SSL
# használatával.
&dollar;cmd 050 &dollar;skip tcp from any to any 443 out via &dollar;pif setup keep-state
# Kifelé engedélyezzük az e-mailek küldését és fogadását.
&dollar;cmd 060 &dollar;skip tcp from any to any 25 out via &dollar;pif setup keep-state
&dollar;cmd 061 &dollar;skip tcp from any to any 110 out via &dollar;pif setup keep-state
# Kifelé engedélyezzük a FreeBSD (make install és CVSUP) funkcióit.
# Ezzel a rendszeradminisztrátornak ,,ISTENI'' jogokat adunk.
&dollar;cmd 070 &dollar;skip tcp from me to any out via &dollar;pif setup keep-state uid root
# Kifelé engedélyezzük a pinget.
&dollar;cmd 080 &dollar;skip icmp from any to any out via &dollar;pif keep-state
# Kifelé engedélyezzük az idő szolgáltatást.
&dollar;cmd 090 &dollar;skip tcp from any to any 37 out via &dollar;pif setup keep-state
# Kifelé engedélyezzük az nntp news szolgáltatást (tehát a
# hírcsoportokat).
&dollar;cmd 100 &dollar;skip tcp from any to any 119 out via &dollar;pif setup keep-state
# Kifelé engedélyezzük a biztonságos FTP, telnet és SCP
# funkciókat az SSH (secure shell) használatával.
&dollar;cmd 110 &dollar;skip tcp from any to any 22 out via &dollar;pif setup keep-state
# Kifelé engedélyezzük ki a whois kéréseket.
&dollar;cmd 120 &dollar;skip tcp from any to any 43 out via &dollar;pif setup keep-state
# Kifelé engedélyezzük az NTP időszerver elérését.
&dollar;cmd 130 &dollar;skip udp from any to any 123 out via &dollar;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.
&dollar;cmd 300 deny all from 192.168.0.0/16 to any in via &dollar;pif #RFC 1918: privát IP
&dollar;cmd 301 deny all from 172.16.0.0/12 to any in via &dollar;pif #RFC 1918: privát IP
&dollar;cmd 302 deny all from 10.0.0.0/8 to any in via &dollar;pif #RFC 1918: privát IP
&dollar;cmd 303 deny all from 127.0.0.0/8 to any in via &dollar;pif #helyi
&dollar;cmd 304 deny all from 0.0.0.0/8 to any in via &dollar;pif #helyi
&dollar;cmd 305 deny all from 169.254.0.0/16 to any in via &dollar;pif #DHCP
&dollar;cmd 306 deny all from 192.0.2.0/24 to any in via &dollar;pif #dokumentációs célokra fenntartott
&dollar;cmd 307 deny all from 204.152.64.0/23 to any in via &dollar;pif #Sun klaszter
&dollar;cmd 308 deny all from 224.0.0.0/3 to any in via &dollar;pif #D és E osztályú multicast
# Az ident tiltása.
&dollar;cmd 315 deny tcp from any to any 113 in via &dollar;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.
&dollar;cmd 320 deny tcp from any to any 137 in via &dollar;pif
&dollar;cmd 321 deny tcp from any to any 138 in via &dollar;pif
&dollar;cmd 322 deny tcp from any to any 139 in via &dollar;pif
&dollar;cmd 323 deny tcp from any to any 81 in via &dollar;pif
# Dobjuk el a későn érkező csomagokat.
&dollar;cmd 330 deny all from any to any frag in via &dollar;pif
# Dobjuk el azokat az ACK csomagokat, amelyekre nincs
# dinamikus szabály.
&dollar;cmd 332 deny tcp from any to any established in via &dollar;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.
&dollar;cmd 360 allow udp from x.x.x.x to any 68 in via &dollar;pif keep-state
# Befelé engedélyezzük a szabvány WWW funkciót, mivel van
# webszerverünk.
&dollar;cmd 370 allow tcp from any to me 80 in via &dollar;pif setup limit src-addr 2
# Befelé engedélyezzük a biztonságos FTP, telnet és SCP
# használatát az internetről.
&dollar;cmd 380 allow tcp from any to me 22 in via &dollar;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.
&dollar;cmd 390 allow tcp from any to me 23 in via &dollar;pif setup limit src-addr 2
# Dobjuk el és naplózzuk az összes internetről érkező hitelesítetlen kapcsolatot.
&dollar;cmd 400 deny log all from any to any in via &dollar;pif
# Dobjuk el és naplózzuk az összes internetre menő hitelesítetlen kapcsolatot.
&dollar;cmd 450 deny log all from any to any out via &dollar;pif
# Ez lesz a kimenő szabályokhoz tartozó "skipto" célja.
&dollar;cmd 800 divert natd ip from any to any out via &dollar;pif
&dollar;cmd 801 allow ip from any to any
# Minden mást alapértelmezés szerint tiltunk és naplózunk.
&dollar;cmd 999 deny log all from any to any
############# Az IPFW szabályai itt fejeződnek be #####################</programlisting>
</sect3>
</sect2>
</sect1>
</chapter>