From 4e89a703952a0e9504a375c9dd4f4e78991ad139 Mon Sep 17 00:00:00 2001 From: Gabor Pali Date: Sat, 16 May 2009 19:24:11 +0000 Subject: [PATCH] MFen: 1.86 -> 1.87 hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml 1.190 -> 1.192 hu_HU.ISO8859-2/books/handbook/kernelconfig/chapter.sgml 1.461 -> 1.463 hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml 1.130 -> 1.131 hu_HU.ISO8859-2/books/handbook/multimedia/chapter.sgml 1.34 -> 1.35 hu_HU.ISO8859-2/share/sgml/glossary/freebsd-glossary.sgml Obtained from: The FreeBSD Hungarian Documentation Project --- .../books/handbook/firewalls/chapter.sgml | 1043 ++++++++--------- .../books/handbook/kernelconfig/chapter.sgml | 65 +- .../books/handbook/mirrors/chapter.sgml | 20 +- .../books/handbook/multimedia/chapter.sgml | 21 +- .../share/sgml/glossary/freebsd-glossary.sgml | 2 +- 5 files changed, 601 insertions(+), 550 deletions(-) diff --git a/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml index cdc2bc4348..e5135af596 100644 --- a/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml @@ -7,7 +7,7 @@ @@ -155,19 +155,38 @@ Csak azt a forgalmat engedik át, amirõl van szabály és minden mást blokkolnak. - Az inkluzív tûzfalak általában - biztonságosabbak az exkluzív - társaiknál, mivel esetükben jelentõs - mértékben visszaszorul a nem kívánatos - átfolyó forgalom. + 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. + + + 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. + Ez a típusú védelem még - tovább fokozható az állapottartó - tûzfalak (stateful firewall) - használatával. Ilyenkor a tûzfal szemmel - tartja a rajta keresztül megnyitott kapcsolatokat, és - vagy csak a már meglevõ kapcsolathoz tartozó - forgalmat engedi át, vagy nyit egy újat. Az + tovább fokozható az + állapottartó tûzfalak (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 Denial of Service (DoS) típusú támadásokkal szemben sokkal @@ -199,10 +218,10 @@ beépített csomagot tartalmaz: ez az &man.altq.4; és a &man.dummynet.4;. Általában a Dummynet az IPFW, míg az ALTQ - a PF 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 + a PF 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 IPFW a &man.dummynet.4; vagy a PF az ALTQ segítségével. Az @@ -232,8 +251,7 @@ 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 - TCP/IP + teljesen tisztában kell lennie a TCP/IP mûködésével, továbbá azzal, hogy ezekben a mezõkben milyen értékek szerepelhetnek és ezeket hogyan használják @@ -387,9 +405,9 @@ megoldásával párosítva így akár hibatûrõ tûzfalak is kialakíthatóak a PF-fel. A - CARP-ról bõvebb - ismertetést a kézikönyv e ad. + CARP megoldásáról a + kézikönyvben bõvebb ismertetést a ad. A PF rendszermag konfigurációs beállításai a @@ -592,10 +610,10 @@ options ALTQ_NOPCC # az SMP esetén kell ALTQ rendszert engedélyezi. Az options ALTQ_CBQ engedélyezi a - osztályozás alapú besorolást (Class - Based Queuing, CBQ). A - CBQ használatával a - kapcsolatunkhoz tartozó + osztályozás alapú besorolást + (Class Based Queuing, + CBQ). A CBQ + 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 @@ -603,17 +621,18 @@ options ALTQ_NOPCC # az SMP esetén kell segítségükkel a forgalmat. Az options ALTQ_RED a véletlen - korai észlelés (Random Early Detection, - RED) használatát - engedélyezi. A RED a - hálózati forgalomban keletkezõ - torlódások elkerülésére - alkalmas. A RED 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 + korai észlelés (Random Early + Detection, RED) + használatát engedélyezi. A + RED a hálózati forgalomban + keletkezõ torlódások + elkerülésére alkalmas. A + RED 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 RED az eldobásra ítélt @@ -627,18 +646,19 @@ options ALTQ_NOPCC # az SMP esetén kell Az options ALTQ_HFSC a pártatlan hierachikus szolgáltatási görbe alapú - csomagütemezõt (Hierarchical Fair Service Curve Packet - Scheduler, HFSC) engedélyezi. Vele - kapcsolatban a + csomagütemezõt (Hierarchical Fair Service + Curve Packet Scheduler, HFSC) + engedélyezi. Vele kapcsolatban a címen találhatunk bõvebben olvasnivalót (angolul). Az options ALTQ_PRIQ a prioritásos - besorolást (Priority Queuing, PRIQ) - teszi elérhetõvé. A PRIQ - mindig elsõként a nagyobb értékû - sorban levõ forgalmat továbbítja. + besorolást (Priority Queuing, + PRIQ) teszi elérhetõvé. A + PRIQ mindig elsõként a nagyobb + értékû sorban levõ forgalmat + továbbítja. Az options ALTQ_NOPCC az ALTQ SMP, vagyis @@ -657,11 +677,6 @@ options ALTQ_NOPCC # az SMP esetén kell IPFILTER - - Ez a szakasz fejlesztés alatt áll. Ennek - megfelelõen a tartalma nem minden esetben pontos. - - 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 @@ -700,10 +715,10 @@ options ALTQ_NOPCC # az SMP esetén kell drámai mértékben korszerûsítették a szabályok feldolgozásának elvét. Az IPF hivatalos - dokumentációja tartalmazza a régi - szabályok létrehozását és azok - feldolgozásának leírását. A - korszerûsített funkciók csak + 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 @@ -718,34 +733,20 @@ options ALTQ_NOPCC # az SMP esetén kell tûzfalszabályok létrehozásának alapjai. - Az inkluzív tûzfalak csak olyan csomagokat - engednek keresztül, amelyek megfelelnek a - szabályoknak. Ezen módon képesek vagyunk - megmondani, hogy a tûzfal mögül milyen - szolgáltatások érhetõek el az interneten - és segítségével azt is megadhatjuk, - hogy az internetrõl a belsõ hálózatunkon - milyen szolgáltatásokat érhetnek el. A - tûzfal alapból minden mást visszautasít - és naplóz. Az inkluzív tûzfalak sokkal, - de sokkal megbízhatóbbak az exkluzív - tûzfalaknál, ezért itt most csak ilyenekkel - foglalkozunk. - A régi típusú szabályokról a + url="http://www.obfuscation.org/ipf/ipf-howto.html#TOC_1"> és + url="http://coombs.anu.edu.au/~avalon/ip-filter.html"> címeken olvashatunk (angolul). Az IPF gyakran ismételt kérdései a címen + url="http://www.phildev.net/ipf/index.html"> címen érhetõek el (angolul). A nyílt forrású IPFILTER levelezési lista kereshetõ archívumait a + url="http://marc.theaimsgroup.com/?l=ipfilter"> címen találjuk (angolul). @@ -881,8 +882,8 @@ ipnat_rules="/etc/ipnat.rules" # az ipnat mûködéséhez ipf - Az ipf parancs használható - a szabályokat tartalmazó állomány + 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 @@ -1049,7 +1050,7 @@ ipnat_rules="/etc/ipnat.rules" # az ipnat mûködéséhez Az ipmon megfelelõ mûködéséhez be kell kapcsolnunk a - rendszermag IPFILTER_LOG + rendszermag IPFILTER_LOG beállítását. Ez a parancs két különbözõ módban használható. Ha parancsot a @@ -1065,7 +1066,7 @@ ipnat_rules="/etc/ipnat.rules" # az ipnat mûködéséhez &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 syslogd + 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 @@ -1141,12 +1142,13 @@ LOG_ERR - a naplózott csomagok közül azok, amelyek túls& &prompt.root; touch /var/log/ipfilter.log - A syslog mûködését az + A &man.syslogd.8; mûködését az /etc/syslog.conf állományban szereplõ definíciók vezérlik. A syslog.conf állomány számottevõ mértékben képes - meghatározni azt, ahogy a syslog az IPF és a + meghatározni azt, ahogy a + syslog az IPF és a hozzá hasonló alkalmazásoktól kapott rendszerszintû üzeneteket kezeli. @@ -1167,8 +1169,8 @@ LOG_ERR - a naplózott csomagok közül azok, amelyek túls& újraindítjuk a számítógépet vagy az /etc/rc.d/syslogd reload paranccsal - megkérjük a syslog programot, hogy olvassa - újra az /etc/syslog.conf + megkérjük a &man.syslogd.8; démont, hogy + olvassa újra az /etc/syslog.conf állományt. Az imént létrehozott naplót ne @@ -1203,7 +1205,7 @@ LOG_ERR - a naplózott csomagok közül azok, amelyek túls& - Annak a felületnek a neve, ahol a csomag + Azon interfész a neve, ahol a csomag feldolgozásra került, például dc0 @@ -1295,8 +1297,9 @@ LOG_ERR - a naplózott csomagok közül azok, amelyek túls& következõ példában láthatjuk. - Az itt alkalmazott felírás kompatibilis az sh, - csh és tcsh parancsértelmezõkkel. + Az itt alkalmazott felírás kompatibilis az + &man.sh.1;, &man.csh.1; és &man.tcsh.1; + parancsértelmezõkkel. A szimbolikus helyettesítést egy dollárjellel fejezzük ki: @@ -1314,7 +1317,7 @@ LOG_ERR - a naplózott csomagok közül azok, amelyek túls& ######### Az IPF szabályait tartalmazó szkript eleje ########### -oif="dc0" # a kimenõ felület neve +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" @@ -1389,7 +1392,8 @@ EOF állományba. Tegyünk egy, az alábbi szkripthez - hasonlót az /usr/local/etc/rc.d/ + hasonlót az /usr/local/etc/rc.d/ könyvtárba. A szkriptnek adjuk valamilyen értelmes nevet, például ipf.loadrules.sh. Az @@ -1416,24 +1420,29 @@ sh /etc/ipf.rules.script Szabályrendszerek az IPF-ben - Az ipf esetében a szabályrendszer olyan + 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ûzfal szabályrendszere minden - csomagot kétszer dolgoz fel: egyszer, amikor befut az - internetrõl, illetve még egyszer, amikor - visszatér az internetre. Mindegyik TCP/IP - szolgáltatást (például telnet, www, - levelezés stb.) elõre meghatározza a - hozzátartozó protokoll, cél és - forrás IP-cím vagy port. Ez az alapja a - szolgáltatások - engedélyezésérõl vagy - tiltásáról szóló - szabályok megfogalmazásának. + képeznek. A tûzfalhoz tartozó + szabályrendszer egyaránt feldolgozza a + internetrõl a hálózatunk felé + igyekvõ csomagokat, illetve a hálózatunk + ezekre adott válaszait. Az egyes + TCP/IP szolgáltatásokat (mint + például telnet, www, levelezés stb.) a + hozzájuk tartozó protokol és + szabványos (fogadó) portszám írja + le. Ezekre a forrásról általában + valamilyen nem szabványos (magasabb + értékû) portról érkeznek + csomagok. Ekkor a kommunikáció összes + paramétere (vagyis a portok és címek) + bármelyike alapján definiálhatunk + blokkolást vagy továbbengedést + leíró szabályokat. IPFILTER @@ -1462,20 +1471,6 @@ sh /etc/ipf.rules.script létrehozásának egyik alapeszköze. - Az inkluzív tûzfalak csak olyan - szolgáltatásokat engednek át, amelyek - megfelelnek valamelyik szabálynak. Ezzel - lényegében meg tudjuk adni, hogy milyen - szolgáltatások érhetõek el a - tûzfal mögül az internet felé, valamint az - internetrõl a magánhálózatunkon. A - tûzfal minden mást elutasít és - alapértelmezés szerint naplóz. Az - inkluzív tûzfalak sokkal, de sokkal - biztonságosabbak az exkluzív - tûzfalaknál, ezért itt most csak ezzel az - egyetlen típussal foglalkozunk. - A tûzfal szabályainak összeállítása során @@ -1540,7 +1535,7 @@ sh /etc/ipf.rules.script BE-KI = in | out OPCIÓK = log | quick | on - felületnév + interfész SZÛRÉS = proto érték | @@ -1595,20 +1590,19 @@ sh /etc/ipf.rules.script 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 in - vagy pedig az out, de közülük - egyszerre csak az egyiket szabad használni, - máskülönben a szabály hibásnak - minõsül. + következõ kulcsszó vagy az + in vagy pedig az out, de + közülük egyszerre csak az egyiket szabad + használni, máskülönben a + szabály hibásnak minõsül. Az in jelenti, hogy a szabályt - az internet felõl az adott felületen + az internet felõl az adott interfészen beérkezõ csomagokra kell alkalmazni. Az out jelenti, hogy a szabályt - az internet felé az adott felületen + az internet felé az adott interfészen kiküldött csomagokra kell alkalmazni. - @@ -1640,10 +1634,10 @@ sh /etc/ipf.rules.script Az on használatával a szûrés feltételei közé bevonhatjuk a csomaghoz tartozó hálózati - felületet. Itt a felületek az &man.ifconfig.8; - által megjelenített formában - adhatóak meg. Az opció - megadásával csak az adott felületen az + 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 @@ -1652,12 +1646,12 @@ sh /etc/ipf.rules.script nélkülözhetetlen. Amikor naplózunk egy csomagot, akkor a - hozzátartozó fejléc az IPL - csomagnaplózó pszeudo eszközhöz - kerül. A log kulcsszó után - közvetlenül a következõ - minõsítõk szerepelhetnek (a - következõ sorrendben): + hozzátartozó fejléc az + IPL csomagnaplózó pszeudo + eszközhöz kerül. A log + kulcsszó után közvetlenül a + következõ minõsítõk szerepelhetnek + (a következõ sorrendben): A body jelzi, hogy a csomag tartalmának elsõ 128 byte-ját még @@ -1665,13 +1659,12 @@ sh /etc/ipf.rules.script A first minõsítõt akkor érdemes használnunk, amikor a - log kulcsszót a keep - state opcióval együtt alkalmazzuk, mivel + log kulcsszót a keep + state 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. - @@ -1732,15 +1725,17 @@ sh /etc/ipf.rules.script felépítése: a from és to kulcsszavak az IP-címek illesztésére használhatóak. - Ilyenkor a szabályokban a forrás ÉS a - cél paramétereknek is szerepelniük kell. - Az any egy olyan speciális + Ilyenkor a szabályokban a forrás + és a cél + paramétereknek is szerepelniük kell. Az + any egy olyan speciális kulcsszó, amely tetszõleges IP-címre illeszkedik. Néhány példa az - alkalmazására: from any to any - vagy from 0.0.0.0/0 to any, from any to - 0.0.0.0/0, from 0.0.0.0/0 to any vagy - from any to 0.0.0.0. + alkalmazására: from any to + any vagy from 0.0.0.0/0 to any, + from any to 0.0.0.0/0, from + 0.0.0.0/0 to any vagy from any to + 0.0.0.0. Az IP-címek megadhatóak pontozott numerikus formában a hálózati maszk bitekben @@ -1749,12 +1744,16 @@ sh /etc/ipf.rules.script Nincs lehetõség olyan IP-címtartományok illesztésére, - amelyek nem adhatóak meg kényelmesen a maszk - hosszával. A hálózati maszkok - hosszának megállapításban - segíthet a következõ (angol nyelvû) - honlap: . - + amelyek nem adhatóak meg kényelmesen ponttal + elválasztott számok és maszk + hosszával. A net-mgmt/ipcalc 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: . @@ -1769,18 +1768,19 @@ sh /etc/ipf.rules.script portok számát vagy az /etc/services állományban szereplõ nevüket. Amikor a port egy - from típusú objektum + from típusú objektum leírásában jelenik meg, akkor automatikusan a forrásportot jelenti, míg a - to objektum leírásában + to objektum leírásában pedig a célportot. A to objektumoknál a port megadása elengedhetetlen a korszerûsített szabályfeldolgozás elõnyeinek kihasználásához. - Példa: from any to any port = 80. + Példa: from any to any port = + 80. - A portokat különbözõ mûveletek - segítségével, numerikusan + Az egyes portokat különbözõ + mûveletek segítségével, numerikusan hasonlíthatjuk össze, ahol akár porttartományt is megadhatunk. @@ -1799,7 +1799,6 @@ sh /etc/ipf.rules.script korszerûsített szabályfeldolgozás mûködéséhez. - @@ -1884,7 +1883,7 @@ sh /etc/ipf.rules.script Ami ilyenkor történik: - Az internethez csatlakozó felületen + 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 @@ -1892,20 +1891,22 @@ sh /etc/ipf.rules.script következõként várt csomagra, akkor átmegy a tûzfalon és a dinamikus állapottáblában frissül a kapcsolat - állapota, a fennmaradó csomagok pedig a - kimenõ szabályrendszer szerint kerülnek + állapota. Az aktív munkameneten kívül + csomagok pedig egyszerûen a kimenõ + szabályrendszer szerint kerülnek ellenõrzésre. Hasonlóan az elõzõhöz, az internethez - csatlakozó felületen 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, a fennmaradó csomagok pedig a - bejövõ szabályrendszer szerint kerülnek + 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. Amikor egy kapcsolat befejezõdik, automatikusan @@ -1929,7 +1930,6 @@ sh /etc/ipf.rules.script nyújtani a behatolók részérõl alkalmazott megannyi különbözõ támadási módszer ellen. - @@ -1942,67 +1942,82 @@ sh /etc/ipf.rules.script inkluzív tûzfalak csak a szabályainak megfelelõ szolgáltatásokat engedik keresztül, és alapértelmezés szerint - minden mást blokkolnak. Minden tûzfal - legalább két felülettel dolgozik, melyek - mindegyikéhez írnunk kell szabályokat a - tûzfal megfelelõ - mûködéséhez. + minden mást blokkolnak. Egy hálózat + gépeit védõ tûzfalnak, amelyet gyakran + hálózati tûzfalnak (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 — ezt + egyrendszeres tûzfalnak (host based + firewall) nevezik. Az ilyen típusú + megoldásokat nem biztonságos + hálózaton keresztül kommunikáló + szervereknél alkalmaznak. 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 - lo0 felületen és a 127.0.0.1 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 felületen a csomagok zavartalan - mozgását. + lo0 interfészen és a + 127.0.0.1 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. - Az internetre csatlakozó felülethez kell - rendelni a kifelé haladó forgalom - hitelesítését és az internetrõl - befelé irányuló - hozzáférés vezérlését. - Ez lehet a felhasználói PPP által - létrehozott tun0 felület - vagy a DSL-, illetve kábelmodemhez csatlakozó + 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 + tun0 interfész vagy a DSL-, + illetve kábelmodemhez csatlakozó hálózati kártya. Ahol egy vagy több hálózati kártya - is csatlakozik a tûzfal mögött elhelyezkedõ - helyi magánhálózathoz, ott ezeket a - felületeket úgy kell felvenni a tûzfal - szabályai közé, hogy a helyi - hálózaton zajló forgalmat ne - akadályozzuk. + 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. A szabályokat elõször három nagy - csoportba kell szerveznünk: az összes szabadon - forgalmazó felület, az internet felé - haladó kimenõ forgalom és az internet - felõl befelé haladó forgalom. + 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. 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 felületen + naplózzon minden csomagot az adott interfészen és irányban. A kimenõ forgalomat vezérlõ - szabályrendszer csak pass (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 quick, - on, proto, port - és keep state - beállításoknak. A proto tcp - szabályok esetében meg kell adni a - flag opciót is, amivel fel tudjuk + szabályrendszer csak pass + (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 + quick, on, + proto, port és + keep state + beállításoknak. A proto + tcp szabályok esetében meg kell adni a + flag opciót is, amivel fel tudjuk ismertetni a kapcsolatok keletkezését és ezen keresztül aktiválni az állapottartást. @@ -2010,53 +2025,57 @@ sh /etc/ipf.rules.script 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 a blokkolt - elemek lehetnek egy egyébként szabályos - csomag részei, amit a késõbbiekben a - hitelesített szolgáltatások alapján - beengedünk. Másodszor ezzel az olyan - rendszertelenül érkezõ csomagokat tudjuk - blokkolni, amelyeket nem akarunk a naplóban látni, - mivel ilyenkor a csoport utolsójaként megadott - blokkoló és naplózó - szabályhoz már nem jut el. A csoport - utolsó tagjaként megadott szabály blokkolja - és naplózza az illétektelen - hozzáféréseket, amit akár jogi - bizonyítékként is felhasználhatunk a - rendszerünket megtámadók ellen. + eltérõ oka van. Elõször is + elõfordulhat, hogy a veszélyes csomagok + részleges illeszkedés miatt szabályosnak + tûnnek. Az ilyen csomagokat értelemszerûen nem + lenne szabad beengedni a szabályok részleges + megfelelése alapján. A másodszor az eleve + ismerten problémás és értelmetlen + csomagokat csendben el kellene vetni, mielõtt a szakaszhoz + tartozó utolsó szabály fogná meg + és naplózná. Ez az utolsó + szabály egyébként szükség + esetén felhasználható a + támadók elleni bizonyítékok + begyûjtésére. A másik, amire még oda kell figyelnünk, hogy a blokkolt csomagok esetében semmilyen válasz - nem keletkezik, egyszerûen csak eltûnnek. Í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 + 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. Javasolt a beérkezõ - OS fingerprint jellegû - kéréseket az elsõ alkalmommal - naplózni, mert ez az elsõ jele annak, amikor valaki - meg akar támadni minket. + kieszelésére. A log first + 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 nmap OS + fingerprint szabálynál. Az security/nmap 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. - Amikor a log first szabály - alapján keletkezõ üzeneteket akarjuk - látni, hívjuk meg a ipfstat - -hio parancsot, ahol megjelenik, hogy melyik - szabályra mennyi csomag illeszkedett. Ennek - alapján el tudjuk dönteni, hogy éppen - elárasztanak-e bennünket, tehát meg akarnak-e - támadni. + Minden log first opcióval megadott + szabály illeszkedésénél a + ipfstat -hio 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). - Ha ismeretlen porthoz tartozó csomagokat - naplózunk, akkor az /etc/services - állományban vagy a - (angol nyelvû) honlap segítségével - tudjuk kideríteni, hogy pontosan melyik portról - van szó. + Az ismeretlen portszámok + felderítésére az + /etc/services állomány, + esetleg a + (angol nyelvû) honlap használható. Érdemes továbbá megnézni a trójai programok által használt portokat a @@ -2066,26 +2085,26 @@ sh /etc/ipf.rules.script A következõ szabályrendszer egy olyan biztonságos inkluzív - típusú tûzfal, amelyet maga a szerzõ is - használ. Ha ezt átvesszük egy az egyben, - akkor abból semmilyen bajunk nem származhat. - Egyszerûen csak vegyük ki azokat a szabályokat, - amelyek olyan szolgáltatásokra vonatkoznak, amiket - nem akarunk hitelesíteni. + típusú tûzfal, amelyet éles rendszeren + is használnak. Ezt a rendszerünkön nem + használt szolgáltatásokra vonatkozó + pass szabályok + törlésével könnyedén a + saját igényeink szerint + alakíthatjuk. - Ha nem akarunk látni bizonyos üzeneteket a - naplóban, akkor vegyünk fel hozzájuk egy - block típusú szabályt a - befelé irányuló forgalomhoz tartozó + Ha nem akarunk látni bizonyos üzeneteket, akkor + vegyünk fel hozzájuk egy block + típusú szabályt a befelé + irányuló forgalomhoz tartozó szabályok közé. - Ne felejtsük el minden szabályban - átírni a dc0 felület - nevét annak a hálózati - kártyának a felületére, amelyen - keresztül csatlakozunk az internethez. A - felhasználói PPP esetében ez a - tun0 lesz. + A szabályokban írjuk át a + dc0 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 tun0 lesz. Tehát a következõket kell beírni az /etc/ipf.rules @@ -2100,13 +2119,13 @@ sh /etc/ipf.rules.script #pass in quick on xl0 all ################################################################# -# A belsõ felületen szintén ne korlátozzunk semmit. +# 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ó felület (kimenõ kapcsolatok) +# 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é. ################################################################# @@ -2155,14 +2174,14 @@ pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state # 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 a biztonságos FTP, telnet és SCP szolgáltatások -# elérését az SSH (secure shell) használatával. +# 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. +# 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. @@ -2172,12 +2191,11 @@ pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state 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. -# Ezzel a szabállyal állítjuk be, hogy alapértelmezés szerint minden -# blokkolva legyen. +# Ez a szabály blokkol alapértelmezés szerint mindent. block out log first quick on dc0 all ################################################################# -# Az internet felõli felület (bejövõ kapcsolatok) +# 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. ################################################################# @@ -2248,19 +2266,17 @@ pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state # 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õ biztonságos FTP, telnet és SCP -# kapcsolatokat az SSH (secure shell) használatával. +# 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 gondoskodik arról, hogy a rendszer alapértelmezés -# szerint mindent eldobjon. +# 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 ############################## - @@ -2278,8 +2294,8 @@ block in log first quick on dc0 all NAT - A NAT jelentése Network - Address Translation, vagyis hálózati + A NAT jelentése Network + Address Translation, vagyis hálózati címfordítás. A &linux; esetében ezt IP masqueradingnak, vagyis IP maszkolásnak hívják. A hálózati @@ -2301,9 +2317,8 @@ block in log first quick on dc0 all 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 az IP-cím lesz az, - ami alapján az interneten elérhetõek - leszünk. + bekapcsoljuk a modemünket. Ez a dinamikus IP-cím + fog azonosítani minket az interneten. Most tegyük fel, hogy öt gépünk van otthon, viszont csak egyetlen elõfizetéssel @@ -2329,22 +2344,6 @@ block in log first quick on dc0 all esetében mindez visszafelé történik meg. - A hálózati címfordítás - gyakran a szolgáltató engedélye vagy - éppen tudta nélkül történik, - és ha a szolgáltató rájön, - akkor a legtöbb esetben ez az elõfizetés - megszûntetésével jár. Az üzleti - felhasználók jóval többet fizetnek az - internet kapcsolatért és általában - egy olyan statikus IP-címblokkot kapnak, amely sosem - változik. A szolgáltatók az üzleti - célú felhasználás esetében - gyakran ajánlják és - támogatják a hálózati - címfordítást a belsõ - hálózatok számára. - Az IP-címek közül adott egy tartomány, amit a címfordítást használó helyi hálózatok @@ -2469,14 +2468,14 @@ block in log first quick on dc0 all Egy címfordítási szabály tehát valahogy így néz ki: - map FELÜLET HELYI_IP_TARTOMÁNY -> PUBLIKUS_CÍM + map INTERFÉSZ HELYI_IP_TARTOMÁNY -> PUBLIKUS_CÍM A szabályt a map kulcsszó kezdi. - A FELÜLET helyére az - internet felé mutató külsõ felület - nevét írjuk be. + A INTERFÉSZ helyére + az internet felé mutató külsõ + interfész nevét írjuk be. A HELYI_IP_TARTOMÁNY lesz az, amelyben a kliensek címeznek. Ez @@ -2503,9 +2502,9 @@ block in log first quick on dc0 all 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ó felületre + szabályokat a csomaghoz tartozó interfészre és a forrás IP-címére illeszti. - Amikor a csomag felületének neve illeszkedik egy + 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) @@ -2522,7 +2521,6 @@ block in log first quick on dc0 all belsõ IP-címére és feldolgozásra átadni a tûzfal szabályainak. - @@ -2535,8 +2533,8 @@ block in log first quick on dc0 all állományban. Elõször engedélyezzük a - gépünknek, hogy közvetítsen forgalmat a - felületek között: + gépünknek, hogy közvetítsen forgalmat az + interfészek között: gateway_enable="YES" @@ -2580,15 +2578,16 @@ block in log first quick on dc0 all map dc0 192.168.1.0/24 -> 0/32 A fenti szabályban a csomag - forrásportját az IPNAT változatlanul a - feldolgozás után hagyja. Ha ehhez még - hozzátesszük a portmap - kulcsszót, akkor ezzel utasítani tudjuk az - IPNAT-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 IPNAT a forrásportokat egy - adott tartományon belül fogja + forrásportját az IPNAT + változatlanul a feldolgozás után hagyja. + Ha ehhez még hozzátesszük a + portmap kulcsszót, akkor ezzel + utasítani tudjuk az IPNAT-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 + IPNAT a forrásportokat egy adott + tartományon belül fogja módosítani: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000 @@ -2596,9 +2595,9 @@ block in log first quick on dc0 all Ha viszont még inkább meg akarjuk könnyíteni a dolgunkat, akkor itt egyszerûen csak adjuk meg az auto kulcsszót, - amellyel az IPNAT önmagától - megállapítja, hogy milyen portokat tud - használni: + amellyel az IPNAT + önmagától megállapítja, hogy + milyen portokat tud használni: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto @@ -2632,7 +2631,6 @@ block in log first quick on dc0 all CIDR-jelöléssel: map dc0 192.168.1.0/24 -> 204.134.75.0/24 - @@ -2647,8 +2645,8 @@ block in log first quick on dc0 all 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 IPNAT - ezt a gondot a hálózati + hálózat megfelelõ gépeihez. Az + IPNAT 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 @@ -2744,7 +2742,7 @@ block in log first quick on dc0 all 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 a felület nevét + 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 @@ -2756,10 +2754,10 @@ block in log first quick on dc0 all 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 a felületnek - és forrás IP-nek megfelelõen - átfordítjuk a címét. - + megáll a harmadiknál, ahol az + interfésznek és forrás IP-nek + megfelelõen átfordítjuk a + címét. @@ -2785,7 +2783,6 @@ pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep stat # 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 - @@ -2798,14 +2795,14 @@ pass in quick on rl0 proto tcp from any to any port = 20 flags S keep stateIPFW - Az IPFIREWALL (IPFW) 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 - egyszerû állapottartó + Az IPFIREWALL (IPFW) 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 egyszerû állapottartó megoldásnak nevezzük. Az IPFW szabvány &os;-ben levõ, mintaként @@ -2845,12 +2842,12 @@ pass in quick on rl0 proto tcp from any to any port = 20 flags S keep statedivert szabály, valamint a komolyabb + divert szabály, valamint a komolyabb célok megvalósítására alkalmas lehetõségek: a forgalom korlátozásáért felelõs dummynet, - a továbbküldésre alkalmas fwd - szabály, a hálózati hidak + a továbbküldésre alkalmas fwd + rule szabály, a hálózati hidak támogatása, illetve az ipstealth. Az IPFW egyaránt használható IPv4 és IPv6 esetén. @@ -2972,8 +2969,8 @@ net.inet.ip.fw.verbose_limit=5 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 még csak ismerkedünk a - tûzfallal. + jól, amikor elõször beállítjuk a + tûzfalat. a rendszermag @@ -3031,9 +3028,9 @@ net.inet.ip.fw.verbose_limit=5 hálózatot védi - closed — a helyi felület - kivételével minden IP alapú forgalmat - tilt + closed — a helyi + interfész kivételével minden IP + alapú forgalmat tilt UNKNOWN — tiltja a tûzfal @@ -3175,11 +3172,13 @@ ipfw add block out all &prompt.root; ipfw -t list - A nyilvántartás lekérdezésekor 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 + 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. @@ -3211,26 +3210,29 @@ ipfw add block out all Szabályrendszerek az IPFW-ben - Egy szabályrendszer lényegében nem - több, mint ipfw szabályok egy - csoportja, amelyekben a csomagokat tartalmuktól - függõen továbbengedjük vagy eldobjuk. A - gépek közti kétirányú - csomagváltás egy kapcsolat - létrejöttének számít. A - tûzfalszabályok a csomagokat kétszer - dolgozzák fel: elõször amikor az - internetrõl megérkeznek, másodjára - pedig akkor, amikor visszatérnek az internetre. Minden - egyes TCP/IP szolgáltatást - (vagyis a telnet, www, levelezés stb.) meghatároz - a saját protokollja és a - hozzátartozó port száma. Ez az az - alapvetõ szûrési feltétel, ami - alapján a szolgáltatásokhoz - engedélyezését vagy tiltását - megvalósító szabályokat - megalkotjuk. + Az IPFW esetében a szabályrendszer olyan + szabályokból áll, amelyek a + csomagokról tartalmuk alapján eldöntik, hogy + át kell engedni vagy vissza kell tartani. A gépek + közt két irányban áramló + csomagok egy munkamenet alapú társalgást + képeznek. A tûzfalhoz tartozó + szabályrendszer egyaránt feldolgozza a + internetrõl a hálózatunk felé + igyekvõ csomagokat, illetve a hálózatunk + ezekre adott válaszait. Az egyes + TCP/IP szolgáltatásokat (mint + például telnet, www, levelezés stb.) a + hozzájuk tartozó protokol és + szabványos (fogadó) portszám írja + le. Ezekre a forrásról általában + valamilyen nem szabványos (magasabb + értékû) portról érkeznek + csomagok. Ekkor a kommunikáció összes + paramétere (vagyis a portok és címek) + bármelyike alapján definiálhatunk + blokkolást vagy továbbengedést + leíró szabályokat. IPFW @@ -3251,13 +3253,12 @@ ipfw add block out all Ezt a viselkedést neveztük az elsõ illeszkedés nyer típusú keresésnek. Amennyiben a csomag egyetlen - szabályra sem illeszkedik, akkor az - ipfw 65535-ös sorszámú - állandó szabálya fogja elcsípni, - amely feladata szerint eldobja az összes hozzá - beérkezõ csomagot anélkül, hogy - bármit is válaszolna a csomag - feladójának. + szabályra sem illeszkedik, akkor az IPFW 65535-ös + sorszámú állandó szabálya + fogja elcsípni, amely feladata szerint eldobja az + összes hozzá beérkezõ csomagot + anélkül, hogy bármit is válaszolna a + csomag feladójának. A keresés a count, @@ -3266,30 +3267,15 @@ ipfw add block out all folytatódik. - Az itt szereplõ utasítások az - állapottartó keep state, a - limit, - in/out és - via szabályokra - építkeznek. Ezek szolgálnak az - inkluzív tûzfalak - megvalósításának alapvetõ - eszközeiként. - - Az inkluzív tûzfal csak a szabályoknak - megfelelõ szolgáltatásokat engedélyez. - Segítségével meg tudjuk határozni, - hogy a tûzfal mögül milyen - szolgáltatásokat érhetünk el az - interneten, valamint azt is megadhatjuk vele, hogy az - internetrõl melyik szolgáltatásokhoz - férhetnek hozzá a saját belsõ - hálózatunkban. Felépítése - szerint minden mást tilt. Az inkluzív - jellegû tûzfalak sokkal bizontságosabbak az - exkluzív tûzfalaknál, ezért itt most - csak ilyen típusú szabályrendszerekkel - foglalkozunk. + Az itt szereplõ utasítások + különbözõ állapottartásra + vonatkozó opciókat, például a + keep state, limit, + in, out és + via kulcsszavakat tartalmazó + szabályokon alapulnak. Lényegében ezt + tekinthetjük az inkluzív típusú + tûzfalak kiindulási alapjaként. A tûzfal szabályainak @@ -3412,7 +3398,7 @@ ipfw add block out all ténylegesen csak akkor kerül bele az üzenet, ha az adott szabály még nem haladta meg a hozzátartozó - logamount paraméter + logamount paraméter értékét. Ha ezt nem adtuk meg, akkor az itt érvényes korlát a net.inet.ip.fw.verbose_limit sysctl @@ -3475,31 +3461,35 @@ ipfw add block out all me pedig egy olyan speciális kulcsszó, amely a tûzfalat mûködtetõ &os;-s gép (tehát ez - a gép) adott felülethez tartozó - IP-címét jelöli, mint ahogy a from - me to any, from any to me, - from 0.0.0.0/0 to any, from any to - 0.0.0.0/0, from 0.0.0.0 to any, - from any to 0.0.0.0 vagy from me to - 0.0.0.0 paraméterekben. Az IP-címek - numerikus pontozott formában a hálózati - maszk hosszával együtt, vagy egyszerûen - csak pontozott formában adhatóak meg. A - hálózati maszkok - megállapításában a címen - található honlap nyújthat - segítséget (angolul). + a gép) adott interfészhez tartozó + IP-címét jelöli, mint ahogy a + from me to any, from any to + me, from 0.0.0.0/0 to any, + from any to 0.0.0.0/0, from + 0.0.0.0 to any, from any to + 0.0.0.0 vagy from me to 0.0.0.0 + paraméterekben. Az IP-címek numerikus + pontozott formában a hálózati maszk + hosszával együtt (CIDR-jelöléssel), + vagy egyszerûen csak pontozott formában + adhatóak meg. A hálózati maszkok + megállapításában a net-mgmt/ipcalc port lehet + segítségünkre. Errõl bõvebb + információkat a segédprogram + honlapján, a címen + találhatunk (angolul). port szám A portszámokat is ismerõ protokollok esetében (mint például a - TCP vagy UDP) adhatjuk meg. Fontos, hogy - itt annak a szolgáltatásnak a - portszámát adjuk meg, amelyre a szabály - vonatkozik. A szolgáltatás (az + TCP vagy UDP) adhatjuk + meg. Fontos, hogy itt annak a szolgáltatásnak + a portszámát adjuk meg, amelyre a + szabály vonatkozik. A szolgáltatás (az /etc/services állományból származó) nevét is megadhatjuk a port száma @@ -3514,12 +3504,12 @@ ipfw add block out all szabály részeként. via - felület + interfész - Név szerint az adott felületen + Név szerint az adott interfészen keresztül haladó csomagokat tudjuk szûrni. A via kulcsszó - hatására a használt felület is + hatására a használt interfész is számítani fog a csomag feldolgozása során. @@ -3624,7 +3614,6 @@ ipfw add block out all állapotú dinamikus szabály létezhet egy idõben. Ha ezt a korlátot átlépjük, a csomag eldobódik. - @@ -3653,9 +3642,9 @@ ipfw add block out all karbantartóinak maguknak kell eldöntenie, hogy a szabályrendszerben mely szabályokhoz tartozzon naplózás, nekik kell felvenni ezekhez a - log kulcsszót. + log kulcsszót. Általában csak az eldobással - járó deny + járó deny típusú szabályokat vagy a bejövõ ICMP pingeket szokták naplózni. Gyakran úgy @@ -3745,14 +3734,13 @@ ipfw add block out all egy konkrét példát látni. A szkript felépítése kompatibilis a - sh, csh és - tcsh parancsértelmezõkkel. A - szimbolikus mezõk helyettesítését a - $ vagyis dollárjel vezeti be. Maguk a - szimbolikus mezõk nem tartalmazzák a $ - elõtagot. A szimbolikus mezõk - értékeit "kettõs idézõjelek" - között kell megadni. + &man.sh.1;, &man.csh.1; és &man.tcsh.1; + parancsértelmezõkkel. A szimbolikus mezõk + helyettesítését a $ vagyis + dollárjel vezeti be. Maguk a szimbolikus mezõk + nem tartalmazzák a $ elõtagot. A + szimbolikus mezõk értékeit "kettõs + idézõjelek" között kell megadni. A szabályok összeírását kezdjük el így: @@ -3761,7 +3749,7 @@ ipfw add block out all # ipfw -q -f flush # töröljük az összes aktuális szabályt # Set defaults -oif="tun0" # a kimenõ felület +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 @@ -3803,7 +3791,6 @@ ks="keep-state" # csupán a lustaság miatt &prompt.root; ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state &prompt.root; ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state &prompt.root; ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state - @@ -3818,15 +3805,18 @@ ks="keep-state" # csupán a lustaság miatt inkluzív tûzfalak csak a szabályainak megfelelõ szolgáltatásokat engedik át, minden mást alapértelmezés - szerint tiltanak. Minden tûzfalhoz legalább - két felület tartozik, és a - mûködéséhez ezek mindegyikéhez - meg kell adnunk szabályokat. + szerint tiltanak. A komplett hálózati + szegmensek védelmére + összeállított tûzfalaknak + legalább két interfészük van, + amelyek mindegyikéhez tartoznia kell + szabályoknak a megfelelõ + mûködéshez. Az &unix; mintájú operációs rendszer, köztül a &os; is olyan, hogy a rendszerben belüli kommunikációt a - lo0 nevû felületen + lo0 nevû interfészen és a 127.0.0.1 IP-címen bonyolítja le. A tûzfalban mindenképpen szerepelniük kell olyan @@ -3834,15 +3824,15 @@ ks="keep-state" # csupán a lustaság miatt speciális belsõ csomagok zavartalan közlekedésérõl. - Az internet felé csatlakozó felület + Az internet felé csatlakozó interfész lesz az, amelyen keresztül a kifelé menõ kéréseket hitelesítjük és vezéreljük az internet elérését, valamint ahol szûrjük az internet felõl érkezõ - kéréseket. Ez lehet a PPP esetében a - tun0 eszköz, vagy a DSL-, - illetve kábelmodemhez csatlakozó + kéréseket. Ez lehet a PPP + esetében a tun0 eszköz, + vagy a DSL-, illetve kábelmodemhez csatlakozó hálózati kártya. Abban az esetben, amikor egy vagy több @@ -3855,18 +3845,18 @@ ks="keep-state" # csupán a lustaság miatt A szabályokat elõször három nagyobb osztályba kell sorolnunk: az összes - szabadon forgalmazó felület, a publikus - kimenõ és a publikus bejövõ felület - csoportjába. + szabadon forgalmazó interfész, a publikus + kimenõ és a publikus bejövõ + interfész csoportjába. - A publikus felületekhez 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 felületen és - irányban. + A publikus interfészekhez tartozó + csoportokban úgy kell rendeznünk a + szabályokat, hogy elõre kerüljenek a + gyakrabban használtak és hátra a + kevésbé használtak, valamint a csoportok + utolsó szabálya blokkoljon és + naplózzon minden csomagot az adott interfészen + és irányban. A következõ szabályrendszerben szereplõ, a kimenõ kapcsolatokat tartalmazó @@ -3875,60 +3865,57 @@ ks="keep-state" # csupán a lustaság miatt szûrési feltételei egyértelmûen azonosítják az interneten elérhetõ szolgáltatásokat. Az összes - szabályban megjelennek a proto, - port, - in/out, - via és keep - state opciók. A proto + szabályban megjelennek a proto, + port, + in/out, + via és keep + state opciók. A proto tcp szabályokban emellett szerepel még - egy setup opció is, amellyel a + egy setup opció is, amellyel a kapcsolatokat kezdeményezõ csomagokat tudjuk azonosítani és felvenni az állapottartásért felelõs dinamikus szabályok közé. - A bejövõ felülettel foglalkozó - csoport elsõsorban a kéretlen csomagokat igyekszik - blokkolni, aminek két oka is van. Elõször is - a blokkolt csomagról elképzelhetõ, hogy - egyébként érvényes és - valamelyik késõbbi szabály fogja - hitelesíteni. Másodszor ezekkel a - szabályokkal olyan szabálytalan - idõközönként érkezõ - csomagokat tudunk eldobni, amelyeket nem akarunk a - naplóban feljegyezni, és ennek - segítségével távoltartjuk az - utolsó, mindent blokkoló és - naplózó szabálytól. A csoport - utolsó szabálya dobja el és - naplózza a hozzá befutó összes - csomagot, illetve ezen keresztül - rögzíthetünk olyan jogi - bizonyítékot, amellyel hivatalosan fel tudunk - lépni a rendszerünket támadó emberek - ellen. + 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. - Amit még nem szabad elfelejtenünk: a - tûzfal az eldobott csomagokra egyáltalán - nem válaszol, egyszerûen csak eltûnnek, - mintha sosem lettek volna. Ennek köszönhetõen - a támadóknak fogalma sem lesz arról, hogy - a csomagjaik elérték-e a rendszerünket. - Minél kevesebbet tudnak a támadók a - rendszerünkrõl, annál biztonságosabb. + A másik, amire még oda kell figyelnünk, + hogy a blokkolt csomagok esetében semmilyen + válasz nem keletkezzen, egyszerûen csak + tûnjenek el. Így a támadó nem fogja + tudni, hogy a csomagjai vajon elérték-e a + rendszerünket. Minél kevesebb + információt tudnak összegyûjteni a + rendszerünkrõl a támadók, annál + biztonságosabbnak tekinthetõ. Amikor ismeretlen portokra érkezõ csomagokat naplózunk, érdemes az /etc/services/ állományban vagy + url="http://www.securitystats.com/tools/portsearch.php"> címen (angolul) utánanézni a porthoz tartozó szolgáltatásnak. A különbözõ trójai programok által portok számai ezen a linken érhetõek el (angolul): . - + url="http://www.simovits.com/trojans/trojans.html">. @@ -3938,8 +3925,8 @@ ks="keep-state" # csupán a lustaság miatt A most következõ, címfordítást nem tartalmazó szabályrendszer teljesen inkluzív - típusú. Ha ezt használjuk, nem - járunk rosszul. Egyszerûen csak annyit kell + 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. @@ -3949,11 +3936,11 @@ ks="keep-state" # csupán a lustaság miatt fel egy deny típusú szabályt hozzájuk. Minden szabályban cseréljük ki a dc0 - felületet arra a hálózati + interfészt arra a hálózati kártyára, amely közvetlenül csatlakoztatja rendszerünket az internethez. A - felhasználói PPP esetében ez a - tun0. + felhasználói PPP + esetében ez a tun0. A szabályok használatában felfedezhetünk egyfajta @@ -3962,21 +3949,21 @@ ks="keep-state" # csupán a lustaság miatt Mindegyik sorban, ahol az internet felé nyitunk - meg egy kapcsolatot, a + meg egy kapcsolatot, a keep-state opciót használjuk. Az internetrõl az összes hitelesített szolgáltatás elérése - tartalmazza a opciót az + tartalmazza a limit opciót az elárasztások kivédése miatt. Az összes szabályban az - vagy az + in vagy az out paraméterrel megadjuk szûrni kívánt forgalom irányát. @@ -3984,8 +3971,9 @@ ks="keep-state" # csupán a lustaság miatt Az összes szabályban szerepel a - paraméterrel a csomagokat - továbbító felület neve. + via paraméterrel a csomagokat + továbbító interfész + neve. @@ -4000,18 +3988,18 @@ 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ó - # felület neve + # 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ó -# felület nevére. +# interfész nevére. ################################################################ #$cmd 00005 allow all from any to any via xl0 ################################################################ -# A rendszer belsõ felületét se szûrjük. +# A rendszer belsõ interfészét se szûrjük. ################################################################ $cmd 00010 allow all from any to any via lo0 @@ -4022,7 +4010,7 @@ pif="dc0" # az internethez csatlakozó $cmd 00015 check-state ################################################################ -# Az internet felé forgalmazó felület (kimenõ kapcsolatok) +# 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é. ################################################################ @@ -4085,7 +4073,7 @@ pif="dc0" # az internethez csatlakozó $cmd 00299 deny log all from any to any out via $pif ################################################################ -# Az internet felõli felület (bejövõ kapcsolatok) +# 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. ################################################################ @@ -4155,7 +4143,6 @@ pif="dc0" # az internethez csatlakozó # deríteni. $cmd 00999 deny log all from any to any ############# Itt fejezõdnek be az IPFW szabályai ##################### - @@ -4174,7 +4161,7 @@ pif="dc0" # az internethez csatlakozó konfigurációs beállítások alkalmazására is szükségünk lesz. A rendszermagban opció között meg kell - adnunk az option IPDIVERT sort a többi + adnunk az option IPDIVERT sort a többi IPFIREWALL sor mellett, és fordítanunk egy saját verziót. @@ -4187,7 +4174,7 @@ natd_interface="rl0" # az internet felé mutató h&aa natd_flags="-dynamic -m" # -m = a portszámok megtartása, ha lehetséges Az állapottartó szabályok - használata a divert natd + használata a divert natd címfordítási opcióval együtt nagyban növeli a szabályrendszer leprogramozásának bonyolultságát. @@ -4231,11 +4218,12 @@ natd_flags="-dynamic -m" # -m = a portszámok megtartása összes áteresztõ és eldobó szabályban szerepel a csomag haladási iránya (tehát kimenõ vagy éppen - bejövõ) és az érintett felület - 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 + 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. @@ -4257,14 +4245,14 @@ natd_flags="-dynamic -m" # -m = a portszámok megtartása 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 opció + végbemegy. A keep-state opció hatására ez a szabály felveszi ezt a kapcsolatot az állapottartó dinamikus szabályok közé és végrehajtja a másik megadott feladatot. Ez a feladat része a dinamikus táblázatba rögzített - bejegyzésnek, ami ebben az esetben a skipto - 500 (ugorjunk az 500-as + bejegyzésnek, ami ebben az esetben a skipto + 500 (ugorjunk az 500-as szabályra) lesz. Az 500-as szabály a továbbküldés elõtt lefordítja a csomag forrás IP-címét. Ezt ne @@ -4286,7 +4274,7 @@ natd_flags="-dynamic -m" # -m = a portszámok megtartása szabály megtalálja a hozzátartozó bejegyzést a dinamikus szabályok között és végrehajtódik a - korábban letárolt skipto 500 + korábban letárolt skipto 500 mûvelet. A csomag erre az 500-as szabályra ugrik, ahol lefordítjuk a címét és továbbküldjük. @@ -4327,7 +4315,7 @@ natd_flags="-dynamic -m" # -m = a portszámok megtartása 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õ felületen keresztül + kimenõ interfészen keresztül továbbküldjük. Íme az elsõ példa egy ilyen @@ -4343,7 +4331,7 @@ good_tcpo="22,25,37,43,53,80,443,110,119" ipfw -q -f flush $cmd 002 allow all from any to any via xl0 # nem szûrjük a belsõ hálózatot -$cmd 003 allow all from any to any via lo0 # nem szûrjük a helyi felületet +$cmd 003 allow all from any to any via lo0 # nem szûrjük a helyi interfészt $cmd 100 divert natd ip from any to any in via $pif $cmd 101 check-state @@ -4400,18 +4388,18 @@ ipfw -q -f flush cmd="ipfw -q add" skip="skipto 800" pif="rl0" # az internethez csatlakozó - # hálózati felület neve + # 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ó -# felület nevére. +# interfész nevére. ################################################################# $cmd 005 allow all from any to any via xl0 ################################################################# -# A rendszer belsõ felületét se szûrjük. +# A rendszer belsõ interfészét se szûrjük. ################################################################# $cmd 010 allow all from any to any via lo0 @@ -4428,7 +4416,7 @@ pif="rl0" # az internethez csatlakozó $cmd 015 check-state ################################################################# -# Az internet felé forgalmazó felület (kimenõ kapcsolatok) +# 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é. ################################################################# @@ -4481,7 +4469,7 @@ pif="rl0" # az internethez csatlakozó $cmd 130 $skip udp from any to any 123 out via $pif keep-state ################################################################# -# Az internet felõli felület (bejövõ kapcsolatok) +# 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. ################################################################# @@ -4553,7 +4541,6 @@ pif="rl0" # az internethez csatlakozó # Minden mást alapértelmezés szerint tiltunk és naplózunk. $cmd 999 deny log all from any to any ############# Az IPFW szabályai itt fejezõdnek be ##################### - diff --git a/hu_HU.ISO8859-2/books/handbook/kernelconfig/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/kernelconfig/chapter.sgml index 43ce85c424..03df15b558 100644 --- a/hu_HU.ISO8859-2/books/handbook/kernelconfig/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/kernelconfig/chapter.sgml @@ -6,7 +6,7 @@ @@ -134,8 +134,8 @@ modul elkészítésére. Egy saját rendszermag készítése - azon legfontosabb próbatételek egyike, melyet - majdnem az összes BSD felhasználónak ki kell + azon legfontosabb próbatételek egyike, melyet egy + haladó BSD felhasználónak ki kell állnia. Ez a folyamat, habár némileg idõigényes, számos elõnyt tartogat &os; rendszerünk számára. Eltérõen egy @@ -153,17 +153,22 @@ jelentõs mértékben le tud csökkeni az induláshoz szükséges idõ. + Kisebb memóriahasználat. Egy saját - rendszermag gyakran kevesebb memóriát - emészt fel, mint a GENERIC - rendszermag, ami azért is fontos, mert a rendszermag - mindig benn van a memóriában. Emiatt egy + rendszermag a szükségtelen részek és + eszközmeghajtók elhagyása miatt gyakran + kevesebb memóriát emészt fel, mint a + GENERIC rendszermag. Ez azért is + fontos, mert a rendszermag mindig benn van a fizikai + memóriában, és ezzel az + alkalmazások elöl veszi a helyet. Emiatt egy saját rendszermag elkészítése különösen hasznos lehet egy kevés fizikai memóriával rendelkezõ rendszeren. + További hardverek támogatása. A saját rendszermagunkba olyan eszközök @@ -173,7 +178,6 @@ hangkártyákét. - @@ -694,6 +698,51 @@ sort: opciókat a /usr/src/sys/conf/NOTES állományban találjuk. + A &os; 5.0 megjelenése óta a + konfigurációs állományokban + használható az include + direktíva. Ennek segítségével egy + másik konfigurációs állomány + tartalma logikailag beilleszthetõ az aktuálisba, + így könnyebbé válik egy már + meglevõ állományhoz tartozó kisebb + mennyiségû változtatás + karbantartása. Például ha csupán + pár egyszerû kiegészítést + szeretnénk hozzáadni a + GENERIC rendszermaghoz, akkor elegendõ + a hozzá vett eltéréseket + nyilvántartanunk egy külön + konfigurációs állományban: + + include GENERIC +ident SAJAT + +options IPFIREWALL +options DUMMYNET +options IPFIREWALL_DEFAULT_TO_ACCEPT +options IPDIVERT + + + Valószínûleg sok rendszergazda + számára jelentõs elõnyt jelent ez a + megoldás a konfigurációs + állományok korábbról már + megszokott újraírásával szemben: a + helyi konfigurációs állomány csak a + GENERIC rendszermag helyi rendszerre + vonatkozó eltéréseit tartalmazza. Így + amikor frissítjük a rendszerünket, a + GENERIC rendszermag összes + újítása elérhetõvé + válik, kivéve ha explicit módon le nem + tiltottuk ezeket a noptions vagy a + nodevice megadásával. A fejezet + további részében egy átlagos + konfigurációs állománnyal fogunk + foglalkozni, mind a beállítások, mind pedig + az eszközök tekintetében. + Ha olyan állományt akarunk készíteni, amely tartalmazza az összes diff --git a/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml index e748acef00..c64fda2d0e 100644 --- a/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml @@ -7,7 +7,7 @@ The FreeBSD Hungarian Documentation Project Translated by: PALI, Gabor %SOURCE% en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml - %SRCID% 1.461 + %SRCID% 1.463 --> @@ -3066,6 +3066,16 @@ doc/zh_* + + RELENG_7_2 + + + A FreeBSD-7.2 kiadás ága, ahová + csak a biztonsági frissítések és a + kritikus hibajavítások kerülnek. + + + RELENG_7_1 @@ -3792,8 +3802,8 @@ doc/zh_* - vol/4/freebsd-core: a &os; FTP szerverének - teljes tükrözése. + FreeBSD: a &os; FTP szerverének teljes + tükrözése. @@ -3837,13 +3847,13 @@ doc/zh_* Egyesült Királyság - rsync://rsync.mirror.ac.uk/ + rsync://rsync.mirrorservice.org/ Elérhetõ gyûjtemények: - ftp.FreeBSD.org: a &os; FTP szerverének + sites/ftp.freebsd.org: a &os; FTP szerverének teljes tükrözése. diff --git a/hu_HU.ISO8859-2/books/handbook/multimedia/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/multimedia/chapter.sgml index 6f53d76e71..fd315a2798 100644 --- a/hu_HU.ISO8859-2/books/handbook/multimedia/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/multimedia/chapter.sgml @@ -7,7 +7,7 @@ @@ -517,16 +517,20 @@ kld snd_ich (1p/2r/0v channels duplex default) felhasználóként így tehetünk meg: - &prompt.root; sysctl hw.snd.pcm0.vchans=4 + &prompt.root; sysctl dev.pcm.0.play.vchans=4 +&prompt.root; sysctl dev.pcm.0.rec.vchans=4 &prompt.root; sysctl hw.snd.maxautovchans=4 A fenti példa négy virtuális csatornát hoz létre, ami egészen jellemzõ a mindennapi használatban. A - hw.snd.pcm0.vchans - pcm0 virtuális - csatornáinak számát adja meg, amelyet az - eszköz csatlakoztatása után tudunk + dev.pcm.0.play.vchans és + dev.pcm.0.rec.vchans a + pcm0 eszköz + lejátszásra és felvételre + használt virtuális csatornáinak + számát adja meg, amelyet az eszköz + csatlakoztatása után tudunk beállítani. A hw.snd.maxautovchans az új eszközhöz tartozó virtuális @@ -539,7 +543,8 @@ kld snd_ich (1p/2r/0v channels duplex default) hw.snd.maxautovchans azt tárolja, hogy a késõbb hozzá csatlakozó eszközök mennyi virtuális csatornát - fognak majd kapni. + fognak majd kapni. Errõl részletesebben a + &man.pcm.4; man oldalon olvashatunk. A használatban levõ @@ -558,7 +563,7 @@ kld snd_ich (1p/2r/0v channels duplex default) eszközre kell mutatnia, ahol az x értéke 0-tól 3-ig terjedhet attól függõen, hogy a - hw.snd.pcm.0.vchans + dev.pcm.0.rec.vchans értékét a fenti példához hasonlóan 4-re állítottuk-e. A &man.devfs.5; megoldását használó diff --git a/hu_HU.ISO8859-2/share/sgml/glossary/freebsd-glossary.sgml b/hu_HU.ISO8859-2/share/sgml/glossary/freebsd-glossary.sgml index aa74bbfa41..0801d783c9 100644 --- a/hu_HU.ISO8859-2/share/sgml/glossary/freebsd-glossary.sgml +++ b/hu_HU.ISO8859-2/share/sgml/glossary/freebsd-glossary.sgml @@ -33,7 +33,7 @@