path: root/documentation/content/hu/books/handbook/security/_index.adoc

---
title: 14. Fejezet - Biztonság
part: III. Rész Rendszeradminisztráció
prev: books/handbook/users
next: books/handbook/jails
showBookMenu: true
weight: 18
path: "/books/handbook/security/"
---

[[security]]
= Biztonság
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:sectnumoffset: 14
:partnums:
:source-highlighter: rouge
:experimental:
:images-path: books/handbook/security/

ifdef::env-beastie[]
ifdef::backend-html5[]
:imagesdir: ../../../../images/{images-path}
endif::[]
ifndef::book[]
include::shared/authors.adoc[]
include::shared/mirrors.adoc[]
include::shared/releases.adoc[]
include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
toc::[]
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]

ifndef::env-beastie[]
toc::[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]

[[security-synopsis]]
== Áttekintés

Ez a fejezet egy alapvetõ bevezetés a rendszerek biztonsági fogalmaiba, ad néhány általános jótanácsot és a FreeBSD-vel kapcsolatban feldolgoz néhány komolyabb témát. Az itt megfogalmazott témák nagy része egyaránt ráhúzható rendszerünk és általánosságban véve az internet biztonságára is. A internet már nem az "békés" hely, ahol mindenki a kedves szomszéd szerepét játssza. A rendszerünk bebiztosítása elkerülhetetlen az adataink, szellemi tulajdonunk, idõnk és még sok minden más megvédésére az internetes banditák és hasonlók ellen.

A FreeBSD segédprogramok és mechanizmusok sorát kínálja fel a rendszerünk és hálózatunk sértetlenségének és biztonságának fenntartására.

A fejezet elolvasása során megismerjük:

* az alapvetõ rendszerbiztonsági fogalmakat, különös tekintettel a FreeBSD-re;
* milyen olyan különbözõ titkosítási mechanizmusok érthetõek el a FreeBSD-ben, mint például a DES és az MD5;
* hogyan állítsunk be egyszeri jelszavas azonosítást;
* hogyan burkoljunk az inetd segítségével TCP kapcsolatokat;
* hogyan állítsuk be a KerberosIV-t a FreeBSD 5.0-nál korábbi változatain;
* hogyan állítsuk be a Kerberos5-t a FreeBSD-n;
* hogyan állítsuk be az IPsec-et és hozzunk létre VPN-t FreeBSD/Windows(R) gépek között;
* hogyan állítsuk be és használjuk az OpenSSH-t, a FreeBSD SSH implementációját;
* mik azok az ACL-ek az állományrendszerben és miként kell ezeket használni;
* hogyan kell használni a Portaudit segédprogramot a Portgyûjteménybõl telepített külsõ szoftvercsomagok biztonságosságának ellenõrzésére;
* hogyan hasznosítsuk a FreeBSD biztonsági tanácsait tartalmazó leírásokat
* mit jelent a futó programok nyilvántartása és hogyan engedélyezzük azt FreeBSD-n.

A fejezet elolvasásához ajánlott:

* az alapvetõ FreeBSD és internetes fogalmak ismerete.

A könyvben további biztonsági témákról is szó esik, például a crossref:mac[mac,Kötelező hozzáférés-vezérlés (MAC)]ben a Kötelezõ hozzáférés-vezérlésrõl (MAC) és a crossref:firewalls[firewalls,Tűzfalak]ben pedig az internetes tûzfalakról.

[[security-intro]]
== Bevezetés

A biztonság egy olyan funkció, ami a rendszergazdától indul és nála is végzõdik. Míg az összes többfelhasználós BSD UNIX(R) rendszer önmagában is valamennyire biztonságos, a felhasználók "fegyelmezéséhez" szükség további biztonsági mechanizmusok kiépítésére és karbantartására, ami minden bizonnyal egy rendszergazda egyik legfontosabb kötelessége. A számítógépek csak annyira biztonságosak, mint amennyire beállítjuk, és a biztonsági megfontolások állandó versenyben vannak az emberi kényelemmel. A UNIX(R) rendszerek általánosságban véve órási mennyiségû program párhuzamos futtatására képesek, melyek többsége kiszolgálóként fut - ez azt jelenti, hogy hozzájuk kívülrõl érkezõ egyedek csatlakozhatnak és társaloghatnak velük. Ahogy a tegnap kicsi és nagy számítógépei napjaink asztali gépeivé váltak és ahogy a számítógépek egyre többen csatlakoznak hálózatra és az internetre, a biztonság fontossága is egyre jobban növekszik.

A rendszerek biztonsága a támadások különbözõ formáival is foglalkozik, többek közt olyan támadásokkal, amelyek a rendszer összeomlását vagy használhatatlanságát célozzák meg, de nem próbálják meg veszélybe sodorni a `root` felhasználó hozzáférését ("feltörni a gépet"). A biztonsággal kapcsolatos problémák több kategóriára oszthatóak:

. A szolgáltatások mûködésképtelenné tételére irányuló (DoS, Denial of Service) támadások.
. A felhasználói fiókok veszélyeztetése.
. Rendszergazdai jogok megszerzése a közeli szervereken keresztül.
. Rendszergazdai jogok megszerzése a felhasználói fiókokon keresztül.
. Kiskapuk létrehozása a rendszerben.

A szolgáltatások mûködésképtelenné tételére irányuló támadások olyan tevékenységre utalnak, amelyek képesek megfosztani egy számítógépet az erõforrásaitól. A DoS támadások többnyire nyers erõvel kivitelezett technikák, melyek vagy a rendszer összeomlasztását vagy pedig a használhatatlanná tételét veszik célba úgy, hogy túlterhelik az általa felkínált szolgáltatásokat vagy a hálózati alrendszert. Egyes DoS támadások a hálózati alrendszerben rejtõzõ hibákat igyekeznek kihasználni, amivel akár egyetlen csomaggal is képesek romba dönteni egy számítógépet. Ez utóbbit csak úgy lehet orvosolni, ha a hibát kijavítjuk a rendszermagban. A szerverekre mért csapásokat gyakran ki lehet védeni a paramétereik ügyes beállításával, melyek segítségével korlátozni tudjuk az ezeket ért terhelést egy kellemetlenebb helyezetben. A nyers erõt alkalmazó hálózati támadásokkal a legnehezebb szembenézni. Például az álcázott támadadások, melyeket szinte lehetetlen megállítani, remek eszközök arra, hogy elvágják gépünket az internettõl. Ezzel viszont nem csak azt iktatják ki, hanem az internet-csatlakozásunkat is eldugítják.

A DoS támadásoknál még gyakrabban elõfordul, hogy feltörik a felhasználók fiókjait. A rendszergazdák többsége még mindig futtat telnetd, rlogin, rshd és ftpd szervereket a gépen. Ezek a szerverek alapértelmezés szerint nem titkosított kapcsolaton keresztül mûködnek. Ebbõl következik, hogy ha nincs annyira sok felhasználónk és közülük néhányan távoli helyekrõl jelentkeznek be (ami az egyik leggyakoribb és legkényelmesebb módja ennek), akkor elõfordulhat, hogy valami megneszeli a jelszavaikat. A körültekintõ rendszergazdák mindig ellenõrzik a bejelentkezéseket tartalmazó naplókat és igyekeznek kiszûrni a gyanús címeket még abban az esetben is, amikor a bejelentkezés sikeres volt.

Mindig arra kell gondolni, hogy ha a támadónak sikerült megszerezni az egyik felhasználó hozzáférését, akkor akár képes lehet a `root` felhasználó fiókjának feltörésére is. Azonban a valóságban egy jól õrzött és karbantarott rendszer esetén a felhasználói hozzáférések megszerzése nem feltétlenül adja a támadó kezére a `root` hozzáférését. Ebben fontos különbséget tenni, hiszen a `root` felhasználó jogai nélkül a támadó nem képes elrejteni a nyomait és legjobb esetben sem tud többet tenni, mint tönkretenni az adott felhasználó állományait vagy összeomlasztani a rendszert. A felhasználói fiókok feltörése nagyon gyakran megtörténik, mivel a felhasználók messze nem annyira elõvigyázatosak, mint egy rendszergazda.

A rendszergazdáknak mindig észben kell tartani, hogy egy számítógépen több módon is meg lehet szerezni a `root` felhasználó hozzáférését. A támadó megtudhatja a `root` jelszavát, hibát fedezhet fel az egyik rendszergazdai jogosultsággal futó szerverben és képes feltörni a `root` hozzáférést egy hálózati kapcsolaton keresztül, vagy a támadó olyan programban talál hibát, aminek segítségével el tudja érni a `root` fiókját egy felhasználói hozzáférésen keresztül. Miután a támadó megtalálta a rendszergazdai jogok megszerzésének módját, nem feltétlenül kell kiskapukat elhelyeznie a rendszerben. Az eddig talált és javított, rendszergazdai jogok megszerzését lehetõvé tevõ biztonsági rések egy része esetében viszont a támadónak akkora mennyiségû munkát jelentene eltûntetni maga után a nyomokat, hogy megéri neki egy kiskaput telepíteni. Ennek segítségével a támadó ismét könnyedén hozzájuthat a `root` felhasználó hozzáféréséhez a rendszerben, de ezen keresztül egy okos rendszergazda képes is a behatolót leleplezni. A kiskapuk lerakásának megakadályozása valójában káros a biztonság szempontjából nézve, mert ezzel nem szüntetjük meg azokat a lyukakat, amin keresztül a támadó elõször bejutott.

A támadások elleni védelmet mindig több vonalban kell megvalósítani, melyeket így oszthatunk fel:

. A rendszergazda és a személyzet hozzáférésének védelme.
. A rendszergazdai jogokkal futó szerverek és a suid/sgid engedélyekkel rendelkezõ programok védelme.
. A felhasználói hozzáférések védelme.
. A jelszavakat tároló állomány védelme.
. A rendszermag belsejének, a nyers eszközök és az állományrendszerek védelme.
. A rendszert ért szabálytalan módosítások gyors észlelése.
. Állandó paranoia.

A fejezet most következõ szakaszában az imént felsorolt elemeket fejtjük ki részletesebben.

[[securing-freebsd]]
== A FreeBSD védelme

[NOTE]
.Parancs kontra protokoll
====
A dokumentumban a félkövéren fogjuk szedni az alkalmazásokat, és `egyenszélességû` betûkkel pedig az adott parancsokra hivatkozunk. A protokollokat nem különböztetjük meg. Ez a tipográfiai elkülönítés hasznos például az ssh egyes vonatkozásainak esetén, mivel ez egyben egy protokoll és egy parancs is.
====

A most következõ szakaszok a FreeBSD védelmének azon módszereit ismertetik, amelyekrõl a fejezet <<security-intro,elõzõ szakaszában>> már írtunk.

[[securing-root-and-staff]]
=== A rendszergazda és a személyzet hozzáférésének védelme

Elõször is: ne törjük magunkat a személyzeti fiókok biztonságossá tételével, ha még a rendszergazda hozzáférését sem tettük eléggé biztonságossá. A legtöbb rendszerben a `root` hozzáféréshez tartozik egy jelszó. Elsõként fel kell tennünk, hogy ez a jelszó _mindig_ megszerezhetõ. Ez természetesen nem arra utal, hogy el kellene távolítanunk. A jelszó szinte mindig szükséges a számítógép konzolon keresztüli eléréséhez. Valójában arra szeretnénk rávilágítani, hogy a konzolon kívül sehol máshol ne lehessen használni ezt a jelszót, még a man:su[1] paranccsal sem. Például gondoskodjunk róla, hogy az [.filename]#/etc/ttys# állományban megadott pszeudó terminálokat "insecure" (nem biztonságos) típusúnak állítottuk be, és így a `telnet` vagy az `rlogin` parancsokon keresztül nem lehet rendszergazdaként bejelentkezni. Ha más szolgáltatáson keresztül jelentkezünk be, például az sshd segítségével, akkor ebben az esetben is gondoskodjunk róla, hogy letiltottuk a közvetlen rendszergazdai bejelentkezés lehetõségét. Ezt úgy tudjuk megtenni, ha megnyitjuk az [.filename]#/etc/ssh/sshd_config# állományt és a `PermitRootLogin` paramétert átállítjuk a `no` értékre. Vegyünk számba minden lehetséges hozzáférési módot - az FTP és a hozzá hasonló módok gyakran átszivárognak a repedéseken. A rendszergazdának csak a rendszerkonzolon keresztül szabad tudnia bejelentkeznie.

Természetesen egy rendszergazdának valahogy el kell érnie a `root` hozzáférést, ezért ezzel felnyitunk néhány biztonsági rést. De gondoskodjunk róla, hogy ezek a rések további jelszavakat igényelnek a mûködésükhöz. A `root` hozzáférés eléréséhez érdemes felvenni tetszõleges személyzeti (staff) hozzáféréseket a `wheel` csoportba (az [.filename]#/etc/group# állományban). Ha a személyzet tagjait a `wheel` csoportba rakjuk, akkor innen a `su` paranccsal fel tudjuk venni a `root` felhasználó jogait. A személyzet tagjait létrehozásukkor közvetlenül sose vegyük fel a `wheel` csoportba! A személyzet tagjai elõször kerüljenek egy `staff` csoportba, és majd csak ezután az [.filename]#/etc/group# állományon keresztül a `wheel` csoportba. A személyzetnek csak azon tagjait tegyük ténylegesen a `wheel` csoportba, akiknek valóban szükségük van a `root` felhasználó hozzáférésére. Ha például a Kerberost használjuk hitelesítésre, akkor megcsinálhatjuk azt is, hogy a Kerberos [.filename]#.k5login# állományában engedélyezzük a man:ksu[1] parancson keresztül a `root` hozzáférés elérését a `wheel` csoport alkalmazása nélkül. Ez a megoldás talán még jobb is, mivel a `wheel` használata esetén a behatolónak még mindig lehetõsége van hozzájutni a `root` hozzáféréséhez olyankor, amikor a kezében van a jelszavakat tároló állomány és meg tudja szerezni a személyzet valamelyik tagjának hozzáférését. A `wheel` csoport által felkínált megoldás ugyan jobb, mint a semmi, de kétségtelenül nem a legbiztonságosabb.

A hozzáférések teljes körû letiltásához a man:pw[8] parancsot érdemes használni:

[source,shell]
....
# pw lock személyzet
....

Ezzel meg tudjuk akadályozni, hogy a felhasználó akármilyen módon, beleértve az man:ssh[1] használatát is, hozzá tudjon férni a rendszerünkhöz.

A hozzáférések blokkolásának másik ilyen módszere a titkosított jelszó átírása egyetlen "`*`" karakterre. Mivel ez a karakter egyetlen titkosított jelszóra sem illeszkedik, ezért a felhasználó nem lesz képes bejelentkezni. Ahogy például a személyzet alábbi tagja sem:

[.programlisting]
....
izemize:R9DT/Fa1/LV9U:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh
....

Erre cseréljük ki:

[.programlisting]
....
izemize:*:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh
....

Ezzel megakadályozzuk, hogy az `izemize` nevû felhasználó a hagyományos módszerekkel be tudjon jelentkezni. Ez a megoldás azonban a Kerberost alkalmazó rendszerek esetén nem mûködik, illetve olyan helyezetekben sem, amikor a felhasználó az man:ssh[1] paranccsal már létrehozott magának kulcsokat.

Az ilyen védelmi mechanizmusok esetében mindig egy szigorúbb biztonsági szintû géprõl jelentkezünk be egy kevésbé biztonságosabb gépre. Például, ha a szerverünk mindenféle szolgáltatásokat futtat, akkor a munkaállomásunknak egyetlen egyet sem lenne szabad. A munkaállomásunk biztonságossá tételéhez a lehetõ legkevesebb szolgáltatást szabad csak futtatnunk, de ha lehet, egyet sem, és mindig jelszóval védett képernyõvédõt használjuk. Természetesen ha a támadó képes fizikailag hozzáférni a munkaállomásunkhoz, akkor szinte bármilyen mélységû védelmet képes áttörni. Ezt mindenképpen számításba kell vennünk, azonban ne felejtsük el, hogy a legtöbb betörési kísérlet távolról, hálózaton keresztülrõl érkezik olyan emberektõl, akik fizikailag nem férnek hozzá a munkaállomásunkhoz vagy a szervereinkhez.

A Kerberos és a hozzá hasonló rendszerek használatával egyszerre tudjuk a személyzet tagjainak jelszavát letiltani vagy megváltoztatni, ami egybõl érvényessé válik minden olyan gépen, ahová az adott felhasználónak bármilyen hozzáférése is volt. Nem szabad lebecsülnünk ezt a gyors jelszóváltási lehetõséget abban az esetben, ha a személyzet valamelyik tagjának hozzáférését megszerezték. Hagyományos jelszavak használatával a jelszavak megváltoztatása N gépen igazi káosz. A Kerberosban jelszóváltási megszorításokat is felállíthatunk: nem csak a Kerberos által adott jegyek járnak le idõvel, hanem a Kerberos rendszer meg is követelheti a felhasználóktól, hogy egy adott idõ (például egy hónap) után változtasson jelszót.

=== A rendszergazdai jogokkal futó szerverek és SUID/SGID engedélyekkel rendelkezõ programok védelme

A bölcs rendszergazda mindig csak akkor futtat szervereket, amikor szüksége van rá, se többet, se kevesebbet. Az egyéb fejlesztõktõl származó szerverekkel bánjunk különösen óvatosan, mivel gyakran hajlamosak hibákat tartalmazni. Például az imapd vagy a popper használata olyan, mintha az egész világnak ingyenjegyet osztogatnánk a rendszerünk `root` hozzáféréséhez. Soha ne futtassunk olyan szervert, amelyet nem vizsgáltunk át kellõ alapossággal. Sok szervert nem is feltétlenül kell `root` felhasználóként futtatni. Például az ntalk, comsat és finger démonok egy speciális _járókában_ (sandbox) futnak. Ezek a járókák sem teljesen tökéletesek, hacsak erre külön figyelmet nem fordítunk. Ilyenkor a többvonalas védelem eszménye még mindig él: ha valakinek sikerült betörnie a járókába, akkor onnan ki is tud törni. Minél több védelmi vonalat húzunk a támadó elé, annál jobban csökken a sikerének valószínûsége. A történelem során lényegében minden `root` jogokkal futó szerverben, beleértve az alapvetõ rendszerszintû szervereket is, találtak már biztonsági jellegû hibát. Ha a gépünkre csak az sshd szolgáltatáson keresztül tudnak belépni, és soha nem használja senki a telnetd, rshd vagy rlogind szolgáltatásokat, akkor kapcsoljuk is ki ezeket!

A FreeBSD most már alapértelmezés szerint járókában futtatja az ntalkd, comsat és finger szolgáltatásokat. Másik ilyen program, amely szintén esélyes lehet erre, az a man:named[8]. Az [.filename]#/etc/defaults/rc.conf# megjegyzésben tartalmazza a named járókában futtatásához szükséges paramétereket. Attól függõen, hogy egy új rendszert telepítünk vagy frissítjük a már meglévõ rendszerünket, a járókákhoz tartozó speciális felhasználói hozzáférések nem feltétlenül jönnek létre. Amikor csak lehetséges, az elõrelátó rendszergazda kikísérletez és létrehoz ilyen járókákat.

Vannak más olyan szerverek, amelyek tipikusan nem járókákban futnak. Ilyen többek közt a sendmail, popper, imapd, ftpd és még sokan mások. Léteznek rájuk alternatívák, de a telepítésük valószínûleg több munkát igényel, mint amennyit megérné számunkra veszõdni velük (és itt megint lesújt a kényelmi tényezõ). Ezeket a szervereket többnyire `root` felhasználóként kell futtatnunk és a rajtuk keresztül érkezõ betörési kísérleteket más módokra támaszkodva kell észlelnünk.

A `root` felhasználó keltette biztonsági rések másik nagy csoportja azok a végrehajtható állományok a rendszerben, amelyek a suid és sgid engedélyekkel rendelkeznek, futtatásuk rendszergazdai jogokkal történik. Az ilyen binárisok többsége, mint például az rlogin, a [.filename]#/bin# és [.filename]#/sbin#, [.filename]#/usr/bin# vagy [.filename]#/usr/sbin# könyvtárakban található meg. Habár semmi sem biztonságos 100%-ig, a rendszerben alapértelmezetten suid és sgid engedéllyel rendelkezõ binárisok ebbõl a szempontból meglehetõsen megbízhatónak tekinhetõek. Alkalmanként azonban találnak a `root` felhasználót veszélyeztetõ lyukakat az ilyen binárisokban is. Például 1998-ban az `Xlib`-ben volt egy olyan rendszergazdai szintû hiba, amellyel az xterm (ez általában suid engedéllyel rendelkezik) sebezhetõvé vált. Mivel jobb félni, mint megijedni, ezért az elõretekintõ rendszergazda mindig igyekszik úgy csökkenteni az ilyen engedélyekkel rendelkezõ binárisok körét, hogy csak a személyzet tagjai legyenek képesek ezeket futtatni. Ezt egy olyan speciális csoport létrehozásával oldhatjuk meg, amelyhez csak a személyzet tagjai férhetnek hozzá. Az olyan suid binárisoktól pedig, amelyeket senki sem használ, igyekszik teljesen megszabadulni (`chmod 000`). A monitorral nem rendelkezõ szervereknek általában nincs szükségük az xterm mûködtetésére. Az sgid engedéllyel rendelkezõ binárisok is legalább ugyanennyire veszélyesek. Ha a behatoló képes feltörni egy `kmem` csoporthoz tartozó sgid binárist, akkor képes lesz olvasni a [.filename]#/dev/kmem# állomány tartalmát, ezáltal hozzájut a titkosított jelszavakhoz és így megszerezheti magának akármelyik hozzáférést. Sõt, a `kmem` csoportot megszerzõ behatolók figyelni tudják a pszeudó terminálokon keresztül érkezõ billentyûleütéseket, még abban az esetben is, amikor a felhasználók egyébként biztonságos módszereket használnak. A `tty` csoportot bezsebelõ támadók szinte bármelyik felhasználó termináljára képesek írni. Ha a felhasználó valamilyen terminál programot vagy terminál emulátort használ a billentyûzet szimulációjával, akkor a behatoló tud olyan adatokat generálni, amivel a felhasználó nevében adhat ki parancsokat.

[[secure-users]]
=== A felhasználói hozzáférések védelme

A felhasználók hozzáféréseit szinte a legnehezebb megvédeni. Míg a személyzet tagjaival szemben lehetünk kíméletlenül szigorúak és "ki is csillagozhatjuk" a jelszavukat, addig a felhasználók hozzáféréseivel általánosságban véve ezt nem tehetjük meg. Ha a kezünkben van a megfelelõ mértékû irányítás, akkor még gyõzhetünk és kényelmesen biztonságba helyezethetjük a felhasználók hozzáférését. Ha nincs, akkor nem tehetünk mást, mint állandóan õrködünk a hozzáférések felett. Az ssh és Kerberos használata a felhasználók esetén sokkalta problematikusabb, mivel ilyenkor jóval több adminisztrációra és mûszaki segítségnyújtásra van szükség, de még mindig jobb megoldás a titkosított jelszavakhoz képest.

=== A jelszavakat tároló állomány védelme

Az a legbiztosabb, ha minél több jelszót kicsillagozunk és a hozzáférések hitelesítésére ssh-t vagy Kerberost használunk. Igaz, a titkosított jelszavakat tároló állományt ([.filename]#/etc/spwd.db#) csak a `root` képes olvasni, de a támadó meg tudja szerezni ezt a jogot még olyankor is, ha `root` felhasználóként nem feltétlenül tud írni.

A rendszerünkben futó biztonsági szkripteknek a jelszavakat tároló állomány változását folyamatosan tudnia kell figyelnie és jelentie (lásd lentebb a <<security-integrity,Az állományok sértetlenségének ellenõrzése>> címû fejezetet).

=== A rendszermag belsejének, a nyers eszközök és az állományrendszerek védelme

Ha a támadó megszerzi a `root` hozzáférését, akkor szinte bármit képes megtenni, de vannak bizonyos elõnyei. Például a mostanság fejlesztett legtöbb rendszermag tartalmaz valamilyen beépített csomaglehallgatót, amit FreeBSD alatt a [.filename]#bpf# eszköz valósít meg. A támadók szinte mindig megpróbálnak valamilyen csomaglehallgatót használni a feltört gépen. A legtöbb rendszeren azonban nem kell feltétlenül megadnunk ezt az örömet, ezért nem is kell beépítenünk a rendszermagba a [.filename]#bpf# eszközt.

De ha még ki is iktatjuk a [.filename]#bpf# eszközt, még aggódhatunk a [.filename]#/dev/mem# és [.filename]#/dev/kmem# miatt. Egyébként ami azt illeti, a behatoló még így is képes írni a nyers eszközökre. Sõt, a rendszermagba képesek vagyunk modulokat is betölteni a man:kldload[8] használatával. A vállalkozó kedvû támadó a rendszermag moduljaként képes telepíteni és használni a saját [.filename]#bpf# eszközét vagy bármilyen más, a csomagok lehallgatására alkalmas eszközt. Az ilyen problémák elkerülése érdekében a rendszermagot a legmagasabb védelmi szinten kell üzemeltetni, tehát legalább egyes szinten.

A rendszermag védelmi szintjét több különbözõ módon lehet állítani. A védelmi szintet úgy lehet a legegyszerûbben növelni, ha a `sysctl` paranccsal beállítjuk a `kern.securelevel` nevû, rendszerszintû változó értékét:

[source,shell]
....
# sysctl kern.securelevel=1
....

A FreeBSD rendszermag alapértelmezés szerint a `-1` védelmi szinten indul. Ez egészen addig `-1` marad, amíg a rendszergazda vagy valamelyik man:init[8] során hívott rendszerindító szkript ezt meg nem változtatja. A rendszer indítása során úgy tudjuk beállítani a megfelelõ védelmi szintet, ha az [.filename]#/etc/rc.conf# állományban megadjuk a `kern_securelevel_enable` változót a `YES` értékkel, illetve `kern_securelevel` értékeként a kívánt védelmi szintet.

A FreeBSD alapértelmezett védelmi szintje közvetlenül a rendszerindító szkriptek lefutása után `-1`. Ezt "nem biztonságos módnak" nevezik, mivel az állományok írásáért felelõs állományjelzõk nem feltétlenül mûködnek, mindegyik eszköz írható, olvasható és a többi.

Miután a védelmi szintet `1` vagy annál magasabb értékre állítottuk, akkor a rendszer figyelembe veszi a csak hozzáfûzést (append-only) és módosíthatatlanságot (immutable) megszorító állományjelzõket, nem engedélyezi a tiltásukat és az eszközök közvetlenül nem érhetõek el. A különbözõ védelmi szintek részletesebb bemutatását a man:security[7] man oldalon olvashatjuk (vagy a FreeBSD 7.0 elõtti változataiban a man:init[8] man oldalon).

[NOTE]
====
Az `1` és az afeletti védelmi szinteken többek közt az X11 nem feltétlenül lesz futtatható (mivel a [.filename]#/dev/io# eszköz elérése blokkolt), illetve a rendszer frissítése is akadályokba fog ütközni (a `installworld` futtatása során ideiglenesen ki kell kapcsolni az append-only és immutable állományjelzõket). Az X11 esetében ezt valahogy még ki lehet kerülni úgy, hogy ha az man:xdm[1] démont még a rendszerindítás elején aktiváljuk (amikor a védelmi szint még kellõen alacsony). Az összes védelmi szint és megszorítás esetén azonban nem mindig adható ilyen jellegû javaslat, ezért ilyenkor mindig érdemes elõre tervezni egy keveset. Emellett fontos alaposan megismerni a különbözõ védelmi megszorításokat, mivel jelentõs mértékben visszafoghatják a rendszer használhatóságát. Ez segít az adott helyzetben az egyszerûbb megoldást választani és ezáltal elkerülni a kellemetlen meglepetéseket.
====

Ha a rendszermag védelmi szintjét az `1` érték vagy afelé emeljük, akkor hasznos lehet a fontosabb (lényegében minden olyan programnak, amely a védelmi szint helyes beállítódása elõtt lefut) programoknak, könyvtáraknak és szkripteknek beállítani az `schg` állományjelzõt. Ilyenkor azonban vegyük figyelembe, hogy a rendszer frissítése is nehezebbé válik a magasabb védelmi szinteken. Egy mûködõképesebb megoldás lehet, ha rendszerünket egy magasabb védelmi szinten használjuk, de nem állítjuk be mindegyik rendszerszintû állományra az `schg` állományjelzõt. Másik lehetõség még a [.filename]#/# és [.filename]#/usr# partíciók írásvédett csatlakoztatása. Ne felejtsük el azonban, hogy ha túlságosan szigorúak vagyunk magunkhoz, akkor azzal egyúttal a behatolás észlelését is meg tudjuk nehezíteni!

[[security-integrity]]
=== Az állományok sértetlenségének ellenõrzése: binárisok, konfigurációs állományok stb.

Ha arról van szó, csak a legfontosabb rendszerszintû konfigurációs- és vezérlõállományokat tudjuk megvédeni, még mielõtt a korábban emlegetett kényelmi tényezõ kimutatná a foga fehérjét. Például, ha a `chflags` paranccsal beállítjuk az `schg` állományjelzõt a [.filename]#/# és [.filename]#/usr# állományrendszereken található legtöbb állományra, akkor az minden bizonnyal csökkenti a hatékonyságunkat, hiszen az állományok védelmének növekedésével csökken az észlelés lehetõsége. A védelmi vonalaink közül ugyanis az utolsó talán az egyik legfontosabb - a detektálás. A felépített biztonsági rendszerünk legnagyobb része szinte teljesen hasztalan (vagy ami még rosszabb, a biztonság hamis érzetét kelti), ha nem vagyunk képesek észrevenni a betörési kísérleteket. A védelmi rendszer egyik részére nem a támadó megállításához, hanem a lelassításához van szükség, hogy így majd munka közben érhessük tetten.

A betörés tényét legjobban a megváltozott, hiányzó vagy éppen váratlanul felbukkanó állományok utáni kutatással tudjuk felismerni. A módosított állományokat általában egy másik (gyakran központosított) korlátozott hozzáférésû rendszerbõl ellenõrizhetjük a legjobban. Fontos, hogy ha egy korlátozott hozzáférésû, kiemelten védett rendszeren írjuk a védelemért felelõs szkripteket, akkor azok szinte teljesen láthatlanok lesznek a támadó számára. A legjobb kihasználás érdekében a korlátozott hozzáférésû gépnek jelentõs mértékû rálátással kell rendelkeznie az összes többi gépre, amit írásvédett NFS exportok vagy ssh kulcspárok felhasználásával érhetünk el. A hálózati forgalmat leszámítva az NFS látszik a legkevésbé - segítségével lényegében észrevétlenül tudjuk figyelni az egyes gépek állományrendszereit. Ha a megfigyelésre használt szerver a kliensekhez switchen keresztül csatlakozik, akkor az NFS gyakran jobb választásnak bizonyul. Ha a szerver hubon vagy több hálózati elemen keresztül éri el a megfigyelni kívánt klienseket, akkor az NFS nem eléggé biztonságos (és hatékony), ezért ilyen esetekben az ssh választása lehet a kedvezõ még az ssh által hagyott nyomokkal együtt is.

Miután a korlátozott hozzáférésû gépünk legalább látja a hozzá tartozó kliensek rendszereit, el kell készítenünk a tényleges monitorozást végzõ szkripteket. Ha NFS csatlakozást tételezünk fel, akkor az olyan egyszerû rendszereszközökkel, mint például a man:find[1] és man:md5[1] képesek vagyunk összerakni ezeket. A szemmel tartott kliensek állományait naponta legalább egyszer érdemes ellenõrizni md5-tel, valamint még ennél gyakrabban is tesztelni az [.filename]#/etc# és [.filename]#/usr/local/etc# könyvtárakban található konfigurációs és vezérlõállományokat. Ha valamilyen eltérést tapasztal az ellenõrzést végzõ szerverünk és a rajta levõ md5 információk is helyesek, akkor értesítenie kell a rendszergazdát. Egy jó védelmi szkript képes megkeresni az oda nem illõ suid binárisokat, valamint az új vagy törölt állományokat a [.filename]#/# és a [.filename]#/usr# partíciókon.

A védelmi szkriptek megírása valamivel nehezebb feladat, ha ssh-t használunk az NFS helyett. A futtatásukhoz a szkripteket és az általuk használt eszközöket (például find) az `scp` paranccsal lényegében át kell másolni a kliensekre, amivel így láthatóvá válnak. Ne feledjük továbbá, hogy az ssh kliens már eleve feltört lehet. Szó, ami szó, ha nem megbízható összeköttetésekrõl beszélünk, akkor az ssh használata elkerülhetetlen, de nem feltétlenül egyszerû.

Egy jó védelmi szkript észreveszi a felhasználók és a személyzet tagjainak hozzáférését vezérlõ állományokban, mint például az [.filename]#.rhosts#, [.filename]#.shosts#, [.filename]#.ssh/authorized_keys# és társaiban keletkezett változásokat is, amelyek esetleg elkerülhetik egy `MD5` alapú ellenõrzés figyelmét.

Ha netalán órási mennyiségû tárterületettel rendelkeznénk, akkor eltarthat egy ideig, amíg végigsöprünk az összes partíció összes állományán. Ebben az esetben érdemes olyan beállításokat megadni az állományrendszerek csatlakoztatásánál, amivel le tudjuk tiltani a suid engedéllyel rendelkezõ binárisok futtatását. Ezzel kapcsolatban a man:mount[8] parancs `nosuid` opcióját nézzük meg. Hetente legalább egyszer azért mégis érdemes átnézni az ilyen partíciókat is, mivel ez a réteg a betörési kísérletek felderítésével foglalkozik, függetlenül a sikerességüktõl.

A futó programok nyilvántartása (lásd man:accton[8]) egy olyan viszonylag kevés költséggel járó lehetõség az operációs rendszerben, ami segítségünkre lehet a betörés utáni események kiértékelésében. Különösen hasznos olyankor, amikor megpróbáljuk modellezni, miképp is sikerült a támadónak bejutnia a rendszerünkbe, természetesen feltételezve, hogy az ehhez felhasznált feljegyzések a betörés után is érintetlenek maradtak.

Végül a védelmet ellátó szkripteknek javasolt feldolgozni a naplóállományokat is, valamint a naplókat magukat is a lehetõ legbiztonságosabb formában generálni - ilyenkor nagyon hasznos lehet, ha egy távoli gépre naplózunk. A behatoló megpróbálja majd eltüntetni a nyomait, a naplóállományok viszont nagyon fontosak a rendszergazda számára a betörési kísérletek idejének és módjának megállapításában. A naplókat úgy tudjuk tartósan rögzíteni, ha a rendszerkonzol üzeneteit soros porton keresztül gyûjtjük össze a konzolok felügyeletéért felelõs biztonságos gépen.

=== Állandó paranoia

Egy kis paranoia sosem árt. Elmondható, hogy a rendszergazda tetszõleges számú biztonsági intézkedéssel élhet egészen addig, amíg az nincs hatással a kényelmére, és a kényelmet _befolyásoló_ biztonsági intézkedéseket pedig megfelelõ mérlegelés mellett tegye meg. Ami még ennél is fontosabb, hogy mindig változtassunk valamit a biztonsági hálónkon - mivel ha egy az egyben követjük a dokumentumban leírtakat, akkor ezzel együtt kiadjuk a bejutás receptjét annak a leendõ támadónknak, aki szintén elolvasta ugyanezt.

=== A szolgáltatások mûködésképtelenné tételét célzó támadások

Ez a szakasz a szolgáltatások mûködésképtelenségét elérni kívánó, más néven "Denial of Service" típusú támadásokkal foglalkozik. Noha nem tudunk túlságosan sokat tenni a manapság felbukkanó álcázott, a hálózatunk totális leterhelését célbavevõ támadások ellen, akadnak olyan általános érvényû eszközök, amelyekkel elejét vehetjük a szervereink szétbomzásának:

. A létjövõ szerverpéldányok korlátozása.
. Az ugródeszkaszerû támadások (támadás ICMP-válasszal, pingszórás stb.) korlátozása.
. A rendszermag útválasztási gyorsítótárának túlterhelése.

A DoS támadások egyik jellemzõ sémája szerint egy sokszorozódni képes szervert támadnak meg, amelynek igyekeznek minél több példányát legyártatni, míg végül az ezt futtató rendszer ki nem fogy a memóriából, állományleíróból satöbbibõl és megállásra nem kényszerül. Az inetd (lásd man:inetd[8]) számos lehetõséget kínál fel ennek megakadályozására. Ezzel kapcsolatban szeretnénk megjegyezni, hogy bár ezzel el tudjuk kerülni a gépünk leállását, semmilyen garanciát nem ad arra, hogy a szolgáltatás a támadás során is zavartalanul üzemel tovább. Alaposan olvassuk el az inetd man oldalát és legyünk különös tekintettel a `-c`, `-C` és `-R` kapcsolóira. Vigyázzunk, hogy az inetd `-C` kapcsolóját képesek kijátszani az álcázott IP-vel érkezõ támadások, ezért inkább az elõbbi kapcsolók valamilyen kombinációja az ajánlott. Egyes szerverprogramoknál be lehet állítani a példányainak maximális számát.

A Sendmail rendelkezik egy `-OMaxDaemonChildren` beállítással, ami a terhelésben levõ késleltetése miatt néha mintha jobban beválna, mint a Sendmail terheléskorlátozó paraméterei. A Sendmail indításakor tehát a `MaxDaemonChildren` paramétert javasolt megadni egy olyan értékkel, amely elegendõ a Sendmail számára betervezett terhelés kiszolgálására, de még kevés ahhoz, hogy a Sendmail fûbe harapjon tõle. Továbbá bölcs dolog a Sendmailt várakozási sorral (`-ODeliveryMode=queued`) és démonként (`sendmail -bd`), külön feldolgozási menetekkel (`sendmail -q15m`) futtatni. Ha továbbra is valós idejû kézbesítést akarunk, akkor a feldolgozást kisebb idõközökkel is lefuttathatjuk (például `-q1m`), de arra _mindig ügyeljünk_, hogy a `MaxDaemonChildren` beállítása ne okozzon kaszkádosítási hibákat a Sendmail mûködésében.

A Syslogd közvetlenül is támadható, ezért határozottan javasoljuk a `-s` használatát, amikor csak lehet, minden más esetben pedig a `-a` beállítást.

Fordítsunk kellõ figyelmet a TCP kapcsolatok burkolását végzõ TCP Wrapper"reverse-ident" lehetõségére, ami szintén közvetlenül támadható. Ebbõl az okból kifolyólag valószínûleg nem is akarjuk a TCP Wrapper által felkínált reverse-ident-et használni.

Jól járunk el abban az esetben, ha a belsõ szolgáltatásainkat az útválasztóink mentén tûzfal segítségével védjük meg a külsõ hozzáféréstõl. Ezzel lényegében a helyi hálózatunkat kívülrõl fenyegetõ támadások ellen védekezünk, de ez nem nyújt elegendõ védelmet a belsõ szolgáltatásaink esetén a `root` hozzáférés megszerzésére irányuló kísérletek ellen. Mindig egy exkluzív, tehát zárt tûzfalat állítsunk be, vagyis "tûzfalazzunk mindent _kivéve_ az A, B, C, D és M-Z portokat". Ezen a módon ki tudjuk szûrni az összes alacsonyabb portot, kivéve bizonyos eseteket, mint például a named (ha az adott zónában ez az elsõdleges gép), ntalkd, sendmail vagy más interneten keresztül elérhetõ szolgáltatásokat. Ha másképpen állítjuk a tûzfalat - inkluzív, nyílt avagy megengedõ módon, akkor jó eséllyel elfelejtünk "lezárni" egy csomó szolgáltatást, vagy úgy adunk hozzá egy új belsõ szolgáltatást, hogy közben elfelejtjük frissíteni a tûzfalat. Ennél még azon is jobb, ha a tûzfalon nyitunk egy magasabb portszámú tartományt, és ott valósítjuk meg ezt a megengedõ jellegû mûködést, az alacsonyabb portok veszélybe sodrása nélkül. Vegyük azt is számításba, hogy a FreeBSD-ben a kiosztott portokat dinamikusan állíthatjuk a `net.inet.ip.portrange` sysctl változókon keresztül (`sysctl -a | fgrep portrange`), ami nagyságrendekkel megkönnyíti a tûzfal beállítását. Ennek megfelelõen például meg tudjuk adni, hogy a 4000-tõl 5000-ig terjedõ porttartomány a 49152-tõl 65535-ig húzódó tartományba kerüljön át, majd a 4000 alatti összes portot blokkoljuk (természetesen az internetrõl szándékosan hozzáférhetõ portok kivételével).

A DoS támadások másik elterjedt fajtája az ún. "ugródeszka támadás" - ilyenkor a szervert úgy próbálják túlterhelni, hogy folyamatosan válaszokat kérnek tõle a helyi hálózatról vagy egy másik számítógéprõl. Az ilyen természetû támadások közül is a legnépszerûbb az _ICMP pingszórásos támadás_. A támadó olyan ping csomagokat küld szét a helyi hálózaton, amelyek forrásának azt a gépet jelöli meg, amelyiket meg akarja támadni. Ha a hálózatokat elválasztó útválasztók nem fogják meg a pingszórást, akkor a helyi hálózatról összes gépe nekilát válaszolgatni a meghamisított forrás címére, amivel így teljesen leterhelik az áldozatot. Ez különösen akkor hatásos, amikor a támadó ugyanezt a trükköt eljátssza egyszerre több tucat különbözõ hálózatban is. Az üzenetszórással járó támadások akár százhúsz megabitnyi forgalmat is képesek generálni másodpercenként. A második legelterjedtebb ugródeszkás támadás az ICMP hiba-visszajelzési rendszere ellen irányul. Ilyenkor a támadó ICMP hibaüzeneteket kiváltó csomagok készítésével képes eltömíteni egy szerver bejövõ hálózati kapcsolatát és az ICMP válaszokkal pedig a szerver maga dugítja el a kimenõ hálózati kapcsolatát. Ez a fajtájú támadás képes kinyomni az összes memóriát a szerverbõl és ezzel összeomlasztani, különösen olyankor, amikor a szerver nem tudja elég gyorsan elnyelni az általa generált ICMP válaszokat. A `net.inet.icmp.icmplim` sysctl változóval tudunk gátat szabni a támadások ezen fajtájának. Az ugródeszkás támadások utolsó nagyobb osztálya az inetd olyan szolgáltatásait szemeli ki, mint például az udp echo. A támadó ilyenkor egyszerûen küld a helyi hálózatunkon található A és B szerverünknek egy olyan UDP csomagot, ahol forrásként az A szerver echo portját adja meg, célnak pedig a B szerver echo portját. Ezután a két szerver elkezdi egymás között passzolgatni ezt az egyetlen csomagot. A támadó még több ilyen csomag befecskendezésével pillanatok alatt képes leterhelni a két szervert és helyi hálózatot. Hasonló problémák vannak a belsõ chargen portjával is. Egy hozzáértõ rendszergazda ezért kikapcsolja az összes ilyen inetd-alapú belsõ tesztelõ szolgáltatást.

Az álcázott csomagok felhasználhatóak a rendszermag útválasztó gyorsítótárának túlterhelésére is. Ezzel kapcsolatban nézzük meg a `net.inet.ip.rtexpire`, `rtminexpire` és `rtmaxcache` sysctl változókat. A véletlenszerû IP-címekkel megcímzett álcázott csomagok hatására a rendszermag létrehoz mindegyikõjükhöz egy ideiglenesen pufferelt utat az útválasztó táblázatában, amelyet a `netstat -rna | fgrep W3` paranccsal tudunk lekérdezni. Az ilyen útvonalak nagyjából 1600 másodperc múlva elévülnek. Ha a rendszermag észleli, hogy a gyorsítótárazott útválasztási táblázat mérete túlságosan megnövekedett, akkor automatikusan csökkenti az `rtexpire` értékét, de soha nem megy a `rtminexpire` alá. Ebbõl két probléma adódik:

. A rendszermag nem reagál elég gyorsan amikor egy alig terhelt szervert hirtelen megtámadnak.
. Az `rtminexpire` nem elég kicsi ahhoz, hogy a rendszermag túléljen egy tartósabb rohamot.

Ha a szervereink az internethez T3 (kb. 45 Mbit/s) vagy gyorsabb összeköttetésen keresztül csatlakoznak, akkor határozottan javasolt kézileg behangolni a man:sysctl[8] segítségével az `rtexpire` és az `rtminexpire` értékeket. Soha ne állítsuk egyiket sem nullára (hacsak nem akarjuk összeomlasztani a gépünket). Ha például mind a kettõt 2 másodpercre állítjuk, akkor az többnyire elegendõ az útválasztási táblázat megvédéséhez.

=== Hozzáférés Kerberosszal és SSH-val

Van néhány dolog, amit a Kerberos és az ssh esetén ajánlatos tisztázni, mielõtt használjuk ezeket. A Kerberos 5 egy kifogástalan hitelesítési protokoll. A telnet és rlogin Kerberos által módosított változatában vannak olyan hibák, amelyek alkalmatlanná teszik ezeket a bináris adatfolyamok helyes kezelésére. Sõt, alapértelmezés szerint a Kerberos nem titkosítja a kapcsolatot, csak ha megadjuk neki a `-x` kapcsolót. Az ssh alapértelmezés szerint mindent titkosít.

Az ssh minden szempontból nagyon jól teljesít kivéve, hogy alapértelmezés szerint átküldi a kulcsokat is. Ez azt jelenti, hogy ha van egy olyan biztonságos munkaállomásunk, ahol a rendszer többi részéhez tartozó kulcsainkat tartjuk és egy nem biztonságos gépre akarunk vele ssh-n keresztül belépni, akkor a kulcsaink használatóvá válnak. A tényleges kulcsokat ugyan nem látja senki, de a bejelentkezés során az ssh megnyit egy közvetítéshez használt portot, amit a nem biztonságos gépen a támadó egy feltört `root` hozzáférés birtokában ki tud használni úgy, hogy a kulcsaink segítségével hozzá tudjon férni egy másik olyan géphez, amelyet a kulcsok nyitnak.

Ha lehetséges, akkor a személyzet bejelentkeztetéséhez az ssh-t és Kerberost együttesen használjuk. Az ssh lefordíható Kerberos támogatással. Ezzel csökkentjük a potenciálisan kiszivárgó ssh kulcsok esélyét, miközben jelszavainkat a Kerberosszal védjük. Az ssh kulcsokat csak biztonságos gépekrõl és csak automatizált feladatok esetén használjuk (amire a Kerberos lényegében nem alkalmas). Emellett javasoljuk azt is, hogy az ssh beállításai között tiltsuk le a kulcsok átküldését (key forwarding) vagy használjuk az `from=IP/DOMAIN` opciót, amivel az ssh csak a megadott gépekrõl engedi az [.filename]#authorized_keys# állomány és a így benne levõ kulcsok használatát.

[[crypt]]
== DES, Blowfish, MD5 és a Crypt

Minden UNIX(R) rendszer használójához tartozik egy jelszó is a hozzáféréséhez. Teljesen nyilvánvalónak tûnik, hogy ezt a jelszót csak az adott felhasználó és az adott operációs rendszer ismeri. A jelszavakat a titokban tartásukhoz ún. "csapóajtó függvényekkel" titkosítják, amelyeket könnyû titkosítani, ám nehéz visszafejteni. Tehát amit egy perccel ezelõtt még nyilvalónak tituláltunk, az mostanra már nem is teljesen igaz: _valójában_ az operációs rendszer sem ismeri a jelszót. Az operációs rendszer csak a jelszó _titkosított_ változatát ismeri. A jelszó "titkosítatlan" formáját csak nyers erõ igényebevételével tudjuk megkeresni az összes lehetséges jelszó szénakazlában.

Sajnos, annak idején, amikor a jelszavak titkosítása bekerült a UNIX(R)-ba, egyedül a DES, vagy más néven a Data Encryption Standard (Adattitkosítási szabvány) jött szóba. Ez alapvetõen nem jelentett problémát az Egyesült Államok állampolgárai számára, de mivel a DES forráskódját nem lehetett kivinni az Egyesült Államokból, a FreeBSD-nek találnia kellett valami olyasmit, ami mind megfelel az Egyesült Államok törvényeinek, mind pedig kompatibilis marad az összes többi DES-t használó UNIX(R) variánssal.

Ezt úgy oldották meg, hogy felosztották a titkosítással foglalkozó függvénykönyvtárakat, így az Egyesült Államokban élõ felhasználók tudtak DES könyvtárakat telepíteni és használni, miközben a többi nemzet felhasználói olyan más titkosítási módszert tudtak választani, amit kinn is lehetett alkalmazni. Ennek tulajdonítható, hogy a FreeBSD alapértelmezés szerint az MD5 segítségével titkosít. Az MD5-öt a DES-nél sokkalta biztonságosabbnak tartják, ezért a DES telepítésének lehetõségét leginkább csak kompatibilitási okokból ajánlották fel.

=== A titkosítási mechanizmus azonosítása

Jelenleg a könyvtár ismeri a DES, MD5 és Blowfish függvényeit. A FreeBSD a jelszavak titkosításához alapból az MD5-öt használja.

Nagyon könnyen meg tudjuk mondani, hogy a FreeBSD éppen melyik titkosítási módszert alkalmazza. Ennek egyik lehetõsége, ha az [.filename]#/etc/master.passwd# állományt vizsgáljuk meg. Az MD5 függvényével titkosított jelszavak hosszabbak, mint a DES függvényével titkosítottak és a `$1$` karakterekkel kezdõdnek. A `$2a$` karakterekkel kezdõdõ jelszavakat Blowfish-sel titkosították. A DES kódolású jelszavaknak nincs semmilyen különleges ismertetõjelük, de általánosságban elmondható róluk, hogy rövidebbek az MD5 jelszavaknál és olyan 64 karakteres ábécével kódolják ezeket, amelyek nem tartalmazzák a `$` karaktert, így tehát a viszonylag rövid, nem dollárjellel kezdõdõ karakterláncok minden bizonnyal DES kódolású jelszavak.

Az új jelszavak kódolásához használt formátumot az [.filename]#/etc/login.conf# állományban tárolt `passwd_format` bejelentkezési tulajdonság adja meg, amelynek értékei `des`, `md5` vagy `blf` lehetnek. A man:login.conf[5] man oldalon tájékozódhatunk bõvebben a bejelentkezési tulajdonságokról.

[[one-time-passwords]]
== Egyszeri jelszavak

A FreeBSD alapértelmezés szerint támogatja az OPIE-t (One-time Passwords In Everything, azaz "Egyszeri jelszavak mindenben"), ami alapból az MD5 függvényét használja.

A jelszavak három fajtáját fogjuk a továbbiakban tárgyalni. Az elsõ a megszokott UNIX(R) stílusú avagy Kerberos jelszó. Ezt a továbbiakban "UNIX(R) jelszónak" nevezzük. A második fajtában az OPIE man:opiekey[1] nevû segédprogramja által generált és a bejelentkezésnél a man:opiepasswd[1] által elfogadott jelszavak tartoznak. Ezeket "egyszeri jelszavaknak" fogjuk nevezni. A jelszavak utolsó típusa az a titkos jelszó, amit az `opiekey` programnak (és néha a `opiepasswd` programnak) adunk meg, ami ebbõl egyszer használatos jelszavakat állít elõ. Ezt innentõl "titkos jelszónak" vagy csak egyszerûen "jelszónak" hívjuk.

A titkos jelszónak semmi köze sincs a UNIX(R) jelszavunkhoz. Természetesen megegyezhetnek, de ezt nem ajánljuk. Az OPIE által használt titkos jelszavaknak nem kell a régi UNIX(R) jelszavakhoz hasonlóan legfeljebb 8 karakteresnek lenniük , bármekkorát használhatunk. A hat vagy hét szóból álló jelszavak ilyenkor igen gyakoriak. Az OPIE jobbára a UNIX(R) jelszórendszerétõl teljesen függetlenül mûködik.

A jelszavak mellett két másik fajta adat fontos az OPIE számára. Közülük az egyiket "magnak" vagy "kulcsnak" nevezik, ami két betûbõl és öt számjegybõl áll. A másik az "iterációk száma", ami egy 1 és 100 közötti számot takar. Az OPIE úgy hozza létre az egyszeri jelszavakat, hogy egymás után fûzi a magot és a titkos jelszót, majd az iterációk megadott számának megfelelõ mennyiségben kiszámolja rá az MD5 függvény értékét és az eredményt hat rövid angol szóba önti. Ez a hat angol szó lesz a mi egyszeri jelszavunk. A hitelesítéssel foglalkozó rendszer (elsõsorban a PAM) figyelemmel kíséri a legutoljára használt egyszeri jelszavunkat, és csak akkor engedi a felhasználót hitelesíteni, ha az általa megadott jelszó kódolt változata megegyezik az elõzõleg megadott jelszaváéval. A csapóajtó függvények használata miatt lehetetlen legenerálni a következõ egyszeri jelszót, ha a sikerült megszereznünk az egyiket. Az iterációk száma minden egyes sikeres bejelentkezés után csökken eggyel, amivel a felhasználót és a bejelentkeztetõ programot szinkronban tartja. Amikor így az iterációk száma eléri az egyet, az OPIE-t újra kell inicializálni.

Az említésre kerülõ rendszerek mindegyikéhez tartozik néhány program. Az `opiekey` bekéri az iterációk számát, a magot és a titkos jelszót, majd elõállít egy egyszer használatos jelszót vagy azok folytonos listáját. Az `opiepasswd` az OPIE inicializálásért, a jelszavak, az iterációk számának és a mag megváltoztatásáért felelõs. Egyaránt elfogad titkos jelmondatot, iterációs számot vagy magot és egy egyszeri jelszót. Az `opieinfo` megvizsgálja a felhasználókra vonatkozó adatbázist ([.filename]#/etc/opiekeys#) és kiírja az adott felhasználó által használt iterációs számot és magot.

Négyféle különbözõ mûveletrõl fogunk most itt beszélni. Az elsõben egy biztonságos kapcsolaton keresztül elsõként inicializáljuk az egyszeri jelszavakat, vagy megváltoztatjuk a jelszót vagy a magot az `opiepasswd` segítségével. A második mûveletben ugyanarra adjuk ki az `opiepasswd` parancsot egy nem biztonságos kapcsolaton keresztül az `opiekey` paranccsal együtt egy biztonságos kapcsolaton keresztül. A harmadikban az `opiekey` használatával nem biztonságos kapcsolaton keresztül jelentkezünk be. A negyedikben az `opiekey` paranccsal létrehozunk egy adott mennyiségû kulcsot, amelyeket aztán leírhatunk vagy kinyomtathatunk, hogy magunkkal tudjuk vinni olyan helyre, ahonnan nem tudnk biztonságos módon csatlakozni.

=== Inicializálás biztonságos kapcsolattal

Az OPIE elsõ inicializálásához adjuk ki az `opiepasswd` parancsot:

[source,shell]
....
% opiepasswd -c
[grimreaper] ~ $ opiepasswd -f -c
Adding unfurl:
Only use this method from the console; NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase:
Again new secret pass phrase:
ID unfurl OTP key is 499 to4268
MOS MALL GOAT ARM AVID COED
....

A figyelmeztetés fordítása:

[source,shell]
....
Ezt a módszert csak konzolról alkalmazzuk, SOHA ne távoli kapcsolaton
keresztül!  Ha telnetet, xtermet vagy betárcsázós kapcsolatot használunk, akkor
azonnal nyomjunk ^C-t vagy ne adjunk meg jelszót.
....

Az `Enter new secret pass phrase:` vagy `Enter secret password:` kérdések után adjunk meg egy jelmondatot, illetve jelszót. Ne felejtsük el, hogy ez nem bejelentkezéshez használt jelszó lesz, hanem ebbõl jönnek majd létre az egyszeri kulcsaink. Az "ID" sor adja meg az aktuális példányunk paramétereit: a bejelentkezéshez használt nevünket, az iterációk számát és a magot. Amikor a bejelentkezések során a rendszer emlékszik a paraméterekre és megjeleníti ezeket, nem kell megjegyeznünk. Az utolsó sor adja meg a paramétereinknek és a titkos jelszavunknak megfelelõ egyszeri jelszót. Ha most azonnal akarnánk bejelentkezni, akkor ezt az egyszeri jelszót kellene hozzá használnunk.

=== Inicializálás nem biztonságos kapcsolattal

Ha egy nem biztonságos kapcsolaton keresztül akarjuk inicializálni vagy megváltoztatni a jelszavunkat, akkor szükségünk lesz valahol egy megbízható kapcsolatra, ahol le tudjuk futtatni az `opiekey` parancsot. Ez lehet egy számunkra biztonsági szempontból elfogadható gép parancssora. Emellett ki kell találnunk egy iterációs számot (erre a 100 egy jó választás) és adnunk egy magot vagy használni egy véletlenszerûen generáltat. Az inicializálás színtere felé vezetõ nem biztonságos kapcsolaton keresztül adjuk ki az `opiepasswd` parancsot:

[source,shell]
....
% opiepasswd

Updating unfurl:
You need the response from an OTP generator.
Old secret pass phrase:
        otp-md5 498 to4268 ext
        Response: GAME GAG WELT OUT DOWN CHAT
New secret pass phrase:
        otp-md5 499 to4269
        Response: LINE PAP MILK NELL BUOY TROY

ID mark OTP key is 499 gr4269
LINE PAP MILK NELL BUOY TROY
....

Az alapértelmezett mag elfogadásához nyomjuk le a kbd:[Return] billentyût. Mielõtt megadnánk a hozzáférés jelszavát, menjünk át a biztonságos kapcsolatra és adjuk meg neki ugyanezeket a paramétereket:

[source,shell]
....
% opiekey 498 to4268
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHAT
....

Most váltsunk vissza a nem biztonságos kapcsolatra és másoljuk be az így generált egyszeri jelszót a megfelelõ programba.

=== Egyetlen egyszeri jelszó létrehozása

Miután sikeresen inicializáltuk az OPIE-t és bejelentkezünk, a következõket láthatjuk:

[source,shell]
....
% telnet example.com
Trying 10.0.0.1...
Connected to example.com
Escape character is '^]'.

FreeBSD/i386 (example.com) (ttypa)

login: felhasználói_név
otp-md5 498 gr4269 ext
Password: 
....

Mellékesen megjegyezzük, hogy az OPIE paranccsorának van egy (itt nem látható) hasznos képessége: ha kbd:[Return] billentyût nyomunk a jelszó bekérésekor, akkor a program megmutatja a begépelt betûket, így láthatjuk pontosan mit is írunk be. Ez nagyon kényelmes lehet olyankor, amikor valahonnan, például egy lapról olvassuk a jelszót.

A bejelentkezéshez ekkor le kell valahogy generálnunk az egyszeri jelszavunkat. Ezt egy megbízható rendszeresen tudjuk megtenni az `opiekey` lefuttatásával. (Ennek vannak DOS-os, Windows(R)-os és Mac OS(R)-es változatai is.) Paraméterként az iterációs számot és a magot kell megadnunk. Ezt akár közvetlenül át is másolhatjuk annak a gépnek a bejelentkezési képernyõjérõl, ahova be akarunk jelentkezni.

A megbízható rendszeren tehát:

[source,shell]
....
% opiekey 498 to4268
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHAT
....

Most már megvan a bejelentkezéshez szükséges egyszeri jelszavunk.

=== Több egyszeri jelszó létrehozása

Néha olyan helyekre kell mennünk, ahol se egy megbízható gép, sem pedig biztonságos kapcsolat nem található. Ilyen esetekben megadhatjuk az `opiekey` parancsnak, hogy elõre gyártson le több egyszer használatos jelszót, amit késõbb aztán ki tudunk nyomtatni. Például:

[source,shell]
....
% opiekey -n 5 30 zz99999
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase: <secret password>
26: JOAN BORE FOSS DES NAY QUIT
27: LATE BIAS SLAY FOLK MUCH TRIG
28: SALT TIN ANTI LOON NEAL USE
29: RIO ODIN GO BYE FURY TIC
30: GREW JIVE SAN GIRD BOIL PHI
....

Az `-n 5` öt kulcsot kér egymás után, a `30` pedig megadja az utolsó iterációs számot. Vegyük észre, hogy a kulcsokat a felhasználás sorrendjével _ellentétes_ sorrendben írja ki a program. Ha igazán paranoiások vagyunk, akkor írjuk le kézzel a jelszavakat. Ha viszont annyira nem, akkor egyszerûen küldjük át ezeket az `lpr` parancsnak. Megfigyelhetjük, hogy minden sorban látható az iterációs szám és a hozzá tartozó egyszeri jelszó. Hasznos lehet a felhasználás szerinti felírni a jelszavakat.

=== A UNIX(R) jelszavak használatának leszûkítése

Az OPIE képes a bejelentkezéshez használt IP-címek alapján leszûkíteni a UNIX(R) jelszavak használatát. Ehhez az [.filename]#/etc/opieaccess# használható, amely alapból megtalálható a rendszerünkön. Az man:opieaccess[5] man oldalán találhatjuk meg a rá vonatkozó információkat és az összes vele kapcsolatos biztonsági megfontolást.

Íme egy példa az [.filename]#opieaccess# állományra:

[.programlisting]
....
permit 192.168.0.0 255.255.0.0
....

Ezzel a sorral megengedjük a UNIX(R) jelszavak használatát minden olyan felhasználó számára, akinek az IP-je illeszkedik a megadott címre és maszkra (ez viszont álcázással kijátszható).

Ha az [.filename]#opieaccess# állományból egyetlen szabály sem illeszkedik, akkor alapértelmezés szerint nem engedélyezettek a nem OPIE típusú jelszavak.

[[tcpwrappers]]
== A TCP kapcsolatok burkolása

Aki ismeri az man:inetd[8] programot, az már biztosan hallott a TCP kapcsolatok burkolásáról, eredeti nevén a a TCP wrapperekrõl. Azonban csak kevesek képesek felfogni ezek valódi hasznát. Úgy néz ki, mindenki csak tûzfalakon keresztül akarja megoldani a hálózati kapcsolatot kezelését. Habár a tûzfalakat sok mindenre fel lehet ugyan használni, egyetlen tûzfal nem képes például szövegesen válaszolni a kapcsolatok kezdeményezõinek. Ellenben bármelyik TCP-wrapper szoftver képes erre, sõt még többre is. A következõ néhány szakaszban szemügyre vesszük a TCP wrapperek számos lehetõségét, és ahol lehetséges, ott konfigurációs állományokkal is illusztráljuk ezek használatát.

A TCP burkoló szoftverek kiterjesztik az inetd képességeit minden alatta dolgozó szerverdémon támogatására. Ezzel a módszerrel meg lehet oldani a naplózást, üzenetek küldését a kapcsolatokhoz, a démonok elérhetõségének korlátozását stb. Noha ezen lehetõségek közül néhány tûzfallal is megvalósítható, ezzel nem csupán egy további védelmi réteget húzunk fel a rendszerünk köré, hanem túllépjük mindazt, amit egy tûzfallal irányítani lehet.

A TCP burkolók használatával hozzáadott funkcionalitás azonban nem helyettesít egy jó tûzfalat. A TCP kapcsolatok burkolását tûzfallal vagy más egyéb biztonsági megoldással együtt tudjuk csak eredményesen használni, viszont a rendszerünk biztonságában egy újabb remek védelmi vonalat képvisel.

Mivel lényegében ez az inetd beállításának kibõvítése, ezért a szakasz elolvasásához feltételezzük az crossref:network-servers[network-inetd,inetd beállításával] kapcsolatos tudnivalók ismeretét.

[NOTE]
====
Bár az man:inetd[8] által indított programok nem egészen tekinthetõen "démonoknak", hagyományosan démonnak hívják ezeket. Ezért rájuk ebben a szakaszban is ezt a kifejezést használjuk.
====

=== Kezdeti beállítások

FreeBSD alatt a TCP burkolók használatának egyetlen feltétele csupán annyi, hogy az inetd parancsot a `-Ww` paraméterrel indítsuk az [.filename]#rc.conf# állományból. Az egyébként az alapbeállítás. Természetesen nem árt, ha helyesen állítjuk be az [.filename]#/etc/hosts.allow# állományt is, ellenkezõ esetben a man:syslogd[8] egyébként dobálni fogja errõl az üzeneteket.

[NOTE]
====
Eltérõen a TCP burkolók egyéb implementációitól, a [.filename]#hosts.deny# állományt itt már nem használjuk. Minden beállítást az [.filename]#/etc/host.allow# állományba kell raknunk.
====

A legegyszerûbb konfiguráció esetén a démonok kapcsolódását egyszerûen engedélyezhetjük vagy letilthatjuk az [.filename]#/etc/hosts.allow# állományban szereplõ beállításokkal. A FreeBSD alapértelmezett beállításai szerint minden inetd által indított démonhoz lehet kapcsolódni. Ennek megváltoztatásával az alapkonfiguráció áttekintése után foglalkozunk.

Az alapkonfiguráció általában `démon : cím : cselekvés` alakú. Itt a `démon` egy olyan démonra utal, amelyet az `inetd` indított el. A `cím` egy érvényes hálózati név, IP-cím vagy szögletes zárójelek ([ ]) között megadott IPv6 formátumú cím. A cselekvést tartalmazó mezõ (`action`) lehet `allow` vagy `deny` annak megfelelõen, hogy engedélyezzük vagy tiltjuk a megadott címrõl a csatlakozást. Nem szabad elfelejtenünk, hogy az így megadott beállítások közül mindig az elsõként illeszkedõ érvényesül, ami arra utal, hogy a konfigurációs állományban szereplõ szabályok egymás után növekvõ sorrendben értékelõdnek ki. Ha valamelyikük illeszkedik, akkor a keresés megáll.

Rengeteg egyéb opció is megadható még, de ezekrõl csak a késõbbi szakaszokban fogunk szólni. Egy egyszerû konfigurációs állomány már ennyi információból is könnyedén összeállítható. Például, ha engedélyezni szeretnénk a POP3 kapcsolatokat a package:mail/qpopper[] démonon keresztül, akkor a következõ sorral kell kiegészítenünk a [.filename]#hosts.allow# állományt:

[.programlisting]
....
# Ez a sor kell a POP3 kapcsolatokhoz:
qpopper : ALL : allow
....

Miután hozzáadtuk ezt a sort, az inetd szervert újra kell indítanunk. Ezt vagy a man:kill[1] paranccsal, vagy pedig az [.filename]#/etc/rc.d/inetd# szkript [parameter]#restart# paraméterével tehetjük meg.

=== Komolyabb beállítások

A TCP kapcsolatok burkolásánál is meg lehet adni további opciókat. Segítségükkel még jobban irányítani tudjuk a kapcsolatok kezelésének módját. Néhány esetben az is hasznos lehet, ha küldünk valamilyen választ az egyes gépeknek vagy démonoknak. Máskor szükségünk lehet a csatlakozások naplózására vagy e-mailen keresztüli jelzésére a rendszergazda felé. Teljesen más helyezetekben csak a helyi hálózatunkról engedjük meg a csatlakozást. Ez mind lehetséges a `helyettesítõ jelekként` ismert beállítási opciók, kiterjesztõ karakterek és külsõ parancsok végrehajtásának használatával. A következõ két szakasz az ilyen és ehhez hasonló szituációk megoldására íródott.

==== Külsõ parancsok

Tegyük fel, hogy olyan helyezetben vagyunk, amikor a kapcsolatot tiltani akarjuk, de közben azért szeretnénk errõl értesíteni a kapcsolatot kezdeményezõ felet is. Hogyan tudjuk ezt megcsinálni? Ezt a `twist` nevû opcióval tehetjük meg. Amikor megpróbál valaki csatlakozni, akkor a `twist` hívódik meg és végrehajt egy megadott parancsot vagy szkriptet. Erre találunk is egy példát a [.filename]#hosts.allow# állományban:

[.programlisting]
....
# The rest of the daemons are protected.
ALL : ALL \
        : severity auth.info \
        : twist /bin/echo "You are not welcome to use %d from %h."
....

Ez a példa a következõ üzenetet jeleníti meg: "You are not allowd to use `a démon neve` from `hálózati név`." (Jelentése: "A `démon neve` démont nem érheti el a `hálózati név` helyrõl!") Ez minden olyan démon esetén megjelenik, amirõl nem nyilatkoztunk korábban az állományban. Ezzel nagyon könnyen vissza tudunk küldeni egy választ a kapcsolat kezdményezõje felé, miután a kapcsolatot eldobtuk. Vegyük észre, hogy a visszaküldendõ üzenetet `"` karakterek közé _kell_ tennünk, ez alól semmi sem kivétel.

[WARNING]
====

DoS támadást lehet elõidézni azzal, ha egy támadó vagy támadók egy csoportja csatlakozási kérelmekkel kezdi el bombázni a démonainkat.
====

Ilyen esetekben használhatjuk a `spawn` opciót is. A `spawn` a `twist` opcióhoz hasonlóan implicit módon tiltja a kapcsolódást és arra használható, hogy lefuttassunk vele egy parancsot vagy szkriptet. A `spawn` azonban a `twist` opciótól eltérõen nem küld vissza semmilyen választ a kapcsolatot létrehozni kívánó egyénnek. Ehhez példaként vegyük a következõ sort a konfigurációs állományban:

[.programlisting]
....
# We do not allow connections from example.com:
ALL : .example.com \
	: spawn (/bin/echo %a from %h attempted to access %d >> \
	  /var/log/connections.log) \
	: deny
....

Ezzel a `*.example.com` címtartományból érkezõ összes kapcsolódási kísérlet sikertelen lesz, miközben ezzel egyidõben a [.filename]#/var/log/connections.log# állományba rögzítjük a csatlakozni akaró egyén hálózati nevét, IP-címét és a démont.

A korábban már kifejtett helyettesítõ karakterek túl, mint például az `%a`, még léteznek továbbiak is. Róluk a man:hosts_access[5] man oldalon találhatjuk meg a teljes listát.

==== Helyettesítõ jelek

Az eddigi példákban folyamatosan csak az `ALL` opciót adtuk meg. Azonban rajta kívûl léteznek mások is, amivel a megoldás funkcionalitását még egy kicsivel tovább növelhetjük. Például az `ALL` használható egy démon, egy tartomány vagy egy IP-cím illesztésére. A másik ilyen helyettesítõ jel a `PARANOID`, amelyet olyan gépek IP-címének illesztésekor alkalmazhatunk, ami feltételezhetõen hamis. Más szóval a `PARANOID` olyan cselekvések megadását teszi lehetõvé, amelyek akkor hajtódnak végre, amikor a kapcsolatot létrehozó gép IP-címe eltér a hálózati nevétõl. A most következõ példa valószínûleg segít fényt deríteni ennek lényegére:

[.programlisting]
....
# Block possibly spoofed requests to sendmail:
sendmail : PARANOID : deny
....

A példában minden olyan kapcsolatkérést elutasítunk, ami a `sendmail` felé a hálózati névtõl eltérõ IP-címrõl irányul.

[CAUTION]
====

Ha rossz DNS beállításokat használunk, a `PARANOID` megadásával súlyosan mozgásképtelenné tehetjük a kliensünket vagy szerverünket. Ezért legyünk óvatosak vele!
====

A helyettesítõ jelekrõl és hozzájuk tartozó további lehetõségekrõl a man:hosts_access[5] man oldalon tájékozódhatunk.

A [.filename]#hosts.allow# állományból ki kell venni az elsõ sort ahhoz, hogy bármilyen egyéb konfigurációs beállítás mûködõképes legyen. Ezt említettük a szakasz elején is.

[[kerberosIV]]
== KerberosIV

A Kerberos egy olyan járulékos rendszer/protokoll, amellyel a felhasználók egy biztonságos szerver szolgáltatásain keresztül tudják hitelesíteni magukat. Ilyen szolgáltatás többek közt a távoli bejelentkezés, távoli másolás, a rendszeren belüli biztonságos másolás és minden olyan egyéb veszélyes feladat, amit számottevõen megbízhatóbbá és irányíthatóbbá tettek.

A következõ utasítások a FreeBSD-hez mellékelt Kerberos beállításához adnak útmutatást. A teljes leíráshoz azonban érdemes fellapoznunk a menet közben hivatkozott man oldalakat is.

=== A KerberosIV telepítése

A Kerberos a FreeBSD egyik választható komponense. Legkönnyebben úgy tudjuk feltelepíteni, ha a FreeBSD telepítése során a sysinstall programban kiválasztjuk a `krb4` vagy `krb5` terjesztések valamelyikét. Ezzel felrakhatjuk a Kerberos "eBones" (KerberosIV) vagy "Heimdal" (Kerberos5) elnevezésû változatait. A FreeBSD azért tartalmazza ezeket az implementációkat, mert nem az Amerikai Egyesült Államokban vagy Kanadában fejlesztették, így az Egyesült Államok titkosításokkal kapcsolatos kiviteli korlátozások korában minden olyan rendszer adminisztrátora el tudta érni, aki nem ezekben az országokban lakott.

A Kerberos MIT által fejlesztett implementációját egyébként a Portgyûjteménybõl a package:security/krb5[] porton keresztül érhetjük el.

=== A kezdeti adatbázis létrehozása

Ezt a lépést csak a Kerberos szerveren kell elvégezni. Elõször is gyõzõdjünk meg róla, hogy semmilyen korábbi Kerberos adatbázis nem található a gépen. Váltsunk az [.filename]#/etc/kerberosIV# könyvtárra és ellenõrizzük a következõ állományok meglétét:

[source,shell]
....
# cd /etc/kerberosIV
# ls
README		krb.conf        krb.realms
....

Ha rajtuk kívül további állományok is feltûnnének (mint például a [.filename]#principal.*# vagy [.filename]#master_key#), akkor a `kdb_destroy` paranccsal pusztítsuk el a régi Kerberos adatbázist, vagy ha nem fut már a Kerberos, akkor egyszerûen csak törüljük le ezeket.

Ezután lássunk neki a [.filename]#krb.conf# és [.filename]#krb.realms# állományok átírásán keresztül a Kerberos egyes övezeteinek (realm) létrehozásához. Itt most az `EXAMPLE.COM` lesz a létrehozandó övezet, a hozzá tartozó szerver pedig a `grunt.example.com`. Így szerkesszük át vagy készítsünk el a neki megfelelõ [.filename]#krb.conf# állományt:

[source,shell]
....
# cat krb.conf
EXAMPLE.COM
EXAMPLE.COM grunt.example.com admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
ATHENA.MIT.EDU kerberos-3.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.gov
....

A többi övezetnek valójában nem feltétlenül kell itt lennie. Ezek csupán azért szerepelnek itt, hogy bemutassák miként lehet egyetlen géphez hozzárendelni egyszerre több övezetet is. Az egyszerûség kedvéért nyugodtan elhagyhatóak.

Az elsõ sor nevezi meg a rendszer által mûködtetett övezeteket. Az utána következõ sorokban övezeteket és hálózati neveket láthatunk. Itt az elsõ elem egy övezetet nevez meg, a második elem pedig az övezet "kulcselosztó központját" (key distribution center). A hálózati nevet követõ `admin server` kulcsszavak arra utalnak, hogy az adott gép adminisztratív szerepet ellátó adatbázist is tartalmaz. Ezeket a fogalmakat részleteiben a Kerberos man oldalain ismerhetjük meg.

Ezután hozzá kell adnunk a `grunt.example.com` nevû gépet az `EXAMPLE.COM` övezethez, valamint az `.example.com` tartományban levõ összes géphez létre kell hoznunk egy bejegyzést az `EXAMPLE.COM` övezetben. A [.filename]#krb.realms# állományt ehhez a következõképpen kellene módosítanunk:

[source,shell]
....
# cat krb.realms
grunt.example.com EXAMPLE.COM
.example.com EXAMPLE.COM
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDU
....

Ismét hozzátesszük, hogy a többi övezetnek nem kötelezõ itt szerepelnie. Ezek csupán azt demonstrálják, hogy miként kell egy gépet egyszerre több övezethez is beállítani. Az átláthatóság kedvéért minden további nélkül eltávolíthatjuk ezeket.

Itt az elsõ sor az _adott_ rendszert elhelyezi egy nevesített övezetbe. A többi sor azt mutatja meg, hogyan kell alapértelmezett módon a meghatározott altartományokba tartozó gépeket egy nevesített övezethez hozzárendelni.

Most már készen állunk az adatbázis létrehozására. Ehhez egyedül a Kerberos szerverét (avagy Kulcselosztó központját) kell elindítanunk. Adjuk ki a `kdb_init` parancsot:

[source,shell]
....
# kdb_init
Realm name [default  ATHENA.MIT.EDU ]: EXAMPLE.COM
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.

Enter Kerberos master key: 
....

Az üzenet fordítása:

[source,shell]
....
Most az adatbázis mesterkulcsát kell megadni.  Fontos, hogy
NE FELEJTSÜK EL ezt a jelszót.
....

Most el kell mentenünk a kulcsot, így a helyi gépen futó szerverek fel tudják szedni. Ehhez a `kstash` parancsra van szükségünk:

[source,shell]
....
# kstash

Enter Kerberos master key:

Current Kerberos master key version is 1.

Master key entered. BEWARE!
....

Az üzenet fordítása:

[source,shell]
....
A Kerberos mesterkulcsának jelenlegi változata: 1.

VIGYÁZAT, megadták a mesterkulcsot!
....

Ez elmenti a titkosított mesterkulcsot az [.filename]#/etc/kerberosIV/master_key# állományba.

=== Az egész beüzemelése

_Mindegyik_ Kerberosszal õrzött rendszerrel kapcsolatban két ún. szereplõt (principal) kell még hozzátennünk az adatbázishoz. A nevük `kpasswd` és `rcmd`. Minden rendszerhez létre kell hoznunk ezeket a szereplõket, példányonként (instance) az egyes rendszerek neveivel.

A kpasswd és rcmd démonok teszik lehetõvé a többi rendszer számára, hogy megváltoztathassák a Kerberos jelszavukat, valamint hogy futtathassák az man:rcp[1], man:rlogin[1] és man:rsh[1] parancsokat.

Vegyük fel ezeket a bejegyzéseket is:

[source,shell]
....
# kdb_edit
Opening database...

Enter Kerberos master key:

Current Kerberos master key version is 1.

Master key entered.  BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.

Principal name: passwd
Instance: grunt

<Not found>, Create [y] ? y

Principal: passwd, Instance: grunt, kdc_key_ver: 1
New Password:                    <---- írjuk be, hogy "RANDOM"
Verifying password

New Password: <---- írjuk be, hogy "RANDOM"

Random password [y] ? y

Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name: rcmd
Instance: grunt

<Not found>, Create [y] ?

Principal: rcmd, Instance: grunt, kdc_key_ver: 1
New Password:		<---- írjuk be, hogy "RANDOM"
Verifying password

New Password:           <---- írjuk be, hogy "RANDOM"

Random password [y] ?

Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name:         <---- ha nem adunk meg semmit, akkor kilép
....

=== A szerver állomány létrehozása

Most pedig kivonatolni kell azokat a példányokat, amelyek szolgáltatást definiálnak a gépen. Erre az `ext_srvtab` parancsot használjuk. Ennek eredményeképpen keletkezik egy állományt, amelyet _biztonságos eszközökkel_ át kell másolni vagy át kell mozgatni az egyes Kerberos kliensek [.filename]#/etc# könyvtárába. Ennek az állománynak egyaránt jelent kell lennie a szerveren és a kliensen is, nélküle a Kerberos mûködésképtelen.

[source,shell]
....
# ext_srvtab grunt
Enter Kerberos master key:

Current Kerberos master key version is 1.

Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....
....

Ez a parancs most létrehozott egy ideiglenes állományt, amit át kell nevezni az [.filename]#srvtab# névre, hogy megtalálhassák a szerverek. Az eredeti rendszeren a man:mv[1] paranccsal tudjuk a helyére rakni:

[source,shell]
....
# mv grunt-new-srvtab srvtab
....

Ha egy kliensnek szánjuk az állományt és a hálozatunkat nem tekinthetjük biztonságosnak, akkor a [.filename]#kliens-new-srvtab# állományt másoljuk egy mozgatható adathordozóra és megbízható módon jutassuk el. Ne felejtsük el az állományt [.filename]#srvtab# néven átrakni a kliens [.filename]#/etc# könyvtárába és az engedélyeit 600-ra állítani:

[source,shell]
....
# mv grumble-new-srvtab srvtab
# chmod 600 srvtab
....

=== Az adatbázis feltöltése

Ezt követõen rögzítenünk kell néhány felhasználót is adatbázisban. Elõször is hozzunk létre egy bejegyzést a `janos` nevû felhasználónak. Ezt a `kdb_edit` parancs kiadásával tesszük meg:

[source,shell]
....
# kdb_edit
Opening database...

Enter Kerberos master key:

Current Kerberos master key version is 1.

Master key entered.  BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.

Principal name: janos
Instance:

<Not found>, Create [y] ? y

Principal: janos, Instance: , kdc_key_ver: 1
New Password:                <---- adjunk meg egy biztonságos jelszót
Verifying password

New Password:                <---- itt ismét adjuk meg a jelszót
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name:		   <---- ha nem írunk be semmit, akkor kilép
....

=== Próbáljuk ki

Elsõként a Kerberos démonait kell beindítanunk. Ezzel kapcsolatban megjegyeznénk, hogy ha ehhez megfelelõen átírtuk az [.filename]#/etc/rc.conf# állományunkat, akkor ez az újraindítással együtt magától lezajlik. Ezt csak a Kerberos szerveren kell megcsinálni. A Kerberos kliensei maguktól összeszedik a mûködésükhöz szükséges adatokat az [.filename]#/etc/kerberosIV# könyvtárból.

[source,shell]
....
# kerberos &
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.

Master key entered. BEWARE!

Current Kerberos master key version is 1
Local realm: EXAMPLE.COM
# kadmind -n &
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead

Current Kerberos master key version is 1.

Master key entered.  BEWARE!
....

A fenti figyelmeztetés fordítása:

[source,shell]
....
A program leállítására ne a 'kill -9' parancsot, hanem a
normális kill parancsot használjuk
....

Ezután a `kinit` parancs használatával próbáljunk meg az elõbb létrehozott `janos` azonosítónak kérni egy jegyet:

[source,shell]
....
% kinit janos
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "janos"
Password: 
....

A `klist` paranccsal most próbáljuk meg kilistázni a tokeneket és így ellenõrizni, hogy valóban rendelkezünk velük:

[source,shell]
....
% klist
Ticket file:    /tmp/tkt245
Principal:      janos@EXAMPLE.COM

  Issued           Expires          Principal
Apr 30 11:23:22  Apr 30 19:23:22  krbtgt.EXAMPLE.COM@EXAMPLE.COM
....

Ezután a man:passwd[1] használatával próbáljuk meg megváltoztatni a jelszavunkat. Ezzel tudjuk ellenõrizni, hogy a kpasswd démon hozzáfér a Kerberos adatbázisához:

[source,shell]
....
% passwd
realm EXAMPLE.COM
Old password for janos:
New Password for janos:
Verifying password
New Password for janos:
Password changed.
....

=== Adminisztrátori jogosultságok felvétele

A Kerberos lehetõvé teszi, hogy _mindegyik_ olyan felhasználónak, akinek rendszergazdai jogokra lenne szüksége, a man:su[1] eléréséhez _külön_ meg tudjunk adni egy jelszót. Most már tudunk mondani egy olyan azonosítót is, amely jogosult a man:su[1] használatával `root` jogokat szerezni. Ezt úgy tudjuk megoldani, ha az adott szereplõhöz társítunk egy `root` példányt. A `kdb_edit` használatával készíteni tudunk egy `janos.root` bejegyzést a Kerberos adatbázisában:

[source,shell]
....
# kdb_edit
Opening database...

Enter Kerberos master key:

Current Kerberos master key version is 1.

Master key entered.  BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.

Principal name: janos
Instance: root

<Not found>, Create [y] ? y

Principal: janos, Instance: root, kdc_key_ver: 1
New Password:                    <---- ide csak egy BIZTONSÁGOS jelszót adjuk meg!
Verifying password

New Password:    	 	 <---- adjuk meg ismét a jelszót

Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- ne állítsuk nagyon hosszúra!
Attributes [ 0 ] ?
Edit O.K.
Principal name:		         <---- ha nem adunk meg semmit, akkor kilép
....

Ezt követõen úgy tudunk megbizonyosodni a mûködésérõl, hogy megpróbálunk neki tokeneket szerezni:

[source,shell]
....
# kinit janos.root
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "janos.root"
Password:
....

Most rakjuk bele a felhasználót a `root`[.filename]#.klogin# állományába:

[source,shell]
....
# cat /root/.klogin
janos.root@EXAMPLE.COM
....

Ezután próbáljunk meg kiadni a man:su[1] parancsát:

[source,shell]
....
% su
Password:
....

Nézzük meg milyen tokenjeink is vannak:

[source,shell]
....
# klist
Ticket file:	/tmp/tkt_root_245
Principal:      janos.root@EXAMPLE.COM

  Issued           Expires          Principal
May  2 20:43:12  May  3 04:43:12  krbtgt.EXAMPLE.COM@EXAMPLE.COM
....

=== Más parancsok használata

Az iménti példában létrehoztunk egy `janos` nevû szereplõt, amihez a `root` egy példányát rendeltük. Ez egy olyan felhasználón alapján történt, akinek a neve megegyezik a hozzá tartozó szereplõvel, ami a Kerberosban alapértelmezés. Amennyiben a szükséges megjegyzések megtalálhatóak a `root` könyvtárában levõ [.filename]#.klogin# állományban, akkor a `felhasználó.root` formátumú `szereplõ.példány` azonosító megengedi a `felhasználó` számára, hogy végrehajtsa a man:su[1] parancsot.

[source,shell]
....
# cat /root/.klogin
janos.root@EXAMPLE.COM
....

Ehhez hasonlóan, ha a felhasználó saját könyvtárában megtalálható egy ilyen állomány:

[source,shell]
....
% cat ~/.klogin
janos@EXAMPLE.COM
jozsef@EXAMPLE.COM
....

Ezzel a konfigurációval bárki, aki `janos` felhasználóként vagy `jozsef` felhasználóként (a `kinit` parancson keresztül) hitelesítette magát `EXAMPLE.COM` övezetbõl, ezen a rendszeren (`grunt`) bejelentkezhet a `janos` nevû felhasználóként vagy hozzáférhet az állományaihoz az man:rlogin[1], man:rsh[1] vagy man:rcp[1] használatával.

Például `janos` most egy másik Kerberost használó rendszerre jelentkezik be:

[source,shell]
....
% kinit
MIT Project Athena (grunt.example.com)
Password:
% rlogin grunt
Last login: Mon May  1 21:14:47 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.   All rights reserved.

FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
....

Vagy `jozsef` jelentkezik be ugyanazon a gépen `janos` hozzáférésével (a `janos` nevû felhasználónak a fentebb bemutatt [.filename]#.klogin# állomány található a könyvtárában és a Kerberos üzemeltetéséért felelõs személy létrehozott egy _jozsef_ nevû szereplõt egy null példánnyal):

[source,shell]
....
% kinit
% rlogin grunt -l janos
MIT Project Athena (grunt.example.com)
Password:
Last login: Mon May  1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.   All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
....

[[kerberos5]]
== Kerberos5

A FreeBSD 5.1 után következõ mindegyik FreeBSD kiadás már csak a Kerberos5 támogatást tartalmaz. Ezért bennük csak a Kerberos5 található meg, és a beállítása sok szempontból hasonlít a KerberosIV beállításához. A most következõ információk csak és kizárólag a FreeBSD 5.0 kiadás után következõkben található Kerberos5 változatra vonatkoznak. A KerberosIV szolgáltatásait a felhasználók csomagként, a package:security/krb4[] porton keresztül érhetik el.

A Kerberos egy hálózati kiegészítõ rendszer/protokoll, amivel a felhasználók egy biztonságos szerveren keresztül képesek magukat azonosítani. A távoli bejelentkezések, távoli másolások, a rendszer belüli védett másolások valamint egyéb nagyon kockázatos feladatok, szolgáltatások biztonsága és felügyelete így jelentõs mértékben javítható.

A Kerberos úgy írható le, mint az személyazonosságok ellenõrzésére feljogosított rendszer. Vagy tekinthetjük egy megbízható külsõ megfigyelõ által végzett hitelesítési rendszernek is. A Kerberos csak egyetlen funkciót kínál fel - ez a felhasználók biztonságos hitelesítése a hálózaton. Viszont nem nyújt semmilyen felhatalmazási (mit csinálhatnak a felhasználók) vagy vizsgálati (mit csináltak végül a felhasználók) lehetõséget. Miután egy kliens és a szerver a Kerberos használatával azonosították egymást, az egymás közt folyó kommunikációjuk titkosításával képesek megõrzi az átáramló adatok sértetlenségét és lehallgathatatlanságát.

Ennek tükrében a Kerberos használata csak más olyan biztonsági módszerekkel együttesen javasolt, amelyek felhatalmazást és vizsgálati szolgáltatásokkal is rendelkeznek.

A most következõ utasítások arra igyekeznek útmutatást adni, hogy miként használjuk a FreeBSD-vel együtt terjesztett Kerberos verziót. Azonban a teljes leírást csak a témához tartozó man oldalak átolvasásával együtt kapjuk meg.

A Kerberos telepítésének bemutatásához az alábbi névtereket fogjuk használni:

* A DNS tartomány ("zóna") az `example.org` lesz.
* A Kerberos övezet az EXAMPLE.ORG lesz.

[NOTE]
====
Kérjük, hogy még abban az esetben is valódi tartományneveket adjuk meg, amikor a Kerberos használatát csak a belsõ hálózaton tervezzük. Ezzel elkerülhetjük az egyes Kerberos övezetek együttmûködése során felmerülõ DNS problémákat.
====

=== A Kerberos története

A Kerberost az MIT hozta létre a hálózati biztonsággal kapcsolatos problémák egyik megoldásaként. A Kerberos erõs titkosítást használ, ezért a kliensek képesek egy nem biztonságos hálózaton is azonosítani magukat a szerver felé (és fordítva).

A Kerberos egyaránt utal egy hálózati protokoll nevére és azokra programokra, amelyek implementálják (például Kerberos telnet). Az 5 a protokoll jelenlegi verziója, amit az RFC 1510 ír le.

A protokollnak számos szabad változata létezik, rengeteg típusú operációs rendszerre. A Massachusettsi Mûszaki Intézet (Massachusetts Institute of Technology, MIT), ahol a Kerberost eredetileg kifejlesztették, napjainkban is folytatja a saját Kerberos csomagjának fejlesztését. Többnyire az Egyesült Államokban használják titkosításra, mivel régebben az amerikai kiviteli korlátozások voltak rá érvényesek. Az MITKerberos változata portként érhetõ el (package:security/krb5[]). A Heimdal Kerberos egy másik 5 verziójú implementáció, amit a kiviteli korlátozások elkerülése érdekében határozottan az Egyesült Államokon kívül fejlesztettek ki (ezért gyakran megtalálhatjuk a különbözõ nem kereskedelmi UNIX(R) variánsokban). A Heimdal Kerberos terjesztés portként elérhetõ (package:security/heimdal[]) és kisebb méretben a FreeBSD alaptelepítésének is része.

Mivel ezzel az írással a legtöbb felhasználót kívánjuk segíteni, ezért a következõ utasítások a FreeBSD telepítésében mellékelt Heimdal terjesztés használatát feltételezik.

=== A Heimdal kulcselosztójának telepítése

A kulcselosztó központ (Key Distribution Center, avagy KDC) az a centralizált hitelesítési szolgáltatás, amit a Kerberos nyújt - lényegében az a számítógép, amely Kerberos-jegyeket bocsájt ki. A KDC"megbízhatónak" tekinthetõ a Kerberos által kialakított övezetben levõ többi számítógép számára, ezért védelme kiemelten fontos.

Itt jegyeznénk meg, hogy habár a Kerberos szerver futtatása nagyon kevés számítógépes erõforrást igényel, ennek ellenére biztonsági szempontból egy külön számítógépet javasoljunk a kulcselosztó szerepének betöltéséhez.

Mielõtt nekifognánk a KDC konfigurálásának, ellenõrizzük, hogy az [.filename]#/etc/rc.conf# tartalmazza a KDC mûködéséhez szükséges beállításokat (az elérési utakat természetesen a saját rendszerünk szerint állítsuk be):

[.programlisting]
....
kerberos5_server_enable="YES"
kadmind5_server_enable="YES"
....

A következõ lépésben vegyük szemügyre a Kerberos beállításait tartalmazó [.filename]#/etc/krb5.conf# állományt:

[.programlisting]
....
[libdefaults]
    default_realm = EXAMPLE.ORG
[realms]
    EXAMPLE.ORG = {
        kdc = kerberos.example.org
        admin_server = kerberos.example.org
    }
[domain_realm]
    .example.org = EXAMPLE.ORG
....

Vegyük észre, hogy az itt szereplõ [.filename]#/etc/krb5.conf# állomány szerint a kulcselosztónk teljes hálózati neve `kerberos.example.org`. Ha a kulcselosztónknak nem ez a neve, akkor a zónákat leíró állományba vegyünk még fel egy ilyen CNAME (álnév) bejegyzést.

[NOTE]
====
Ha egy nagyobb hálózatban vagyunk, ahol a DNS szervert is megfelelõen beállították, akkor az iménti példa ennyire leszûkíthetõ:

[.programlisting]
....
[libdefaults]
      default_realm = EXAMPLE.ORG
....

Itt már a következõ sorokat hozzáadták `example.org` zónát leíró állományhoz:

[.programlisting]
....
_kerberos._udp      IN  SRV     01 00 88 kerberos.example.org.
_kerberos._tcp      IN  SRV     01 00 88 kerberos.example.org.
_kpasswd._udp       IN  SRV     01 00 464 kerberos.example.org.
_kerberos-adm._tcp  IN  SRV     01 00 749 kerberos.example.org.
_kerberos           IN  TXT     EXAMPLE.ORG
....

====

[NOTE]
====
A kliensek csak akkor lesznek képesek elérni a Kerberos szolgáltatásait, ha vagy _kötelezõ jelleggel_ megadunk egy teljesen beállított [.filename]#/etc/krb5.conf# állományt, vagy egy minimális [.filename]#/etc/krb5.conf# állományt _és_ egy helyesen beállított DNS szervert használunk.
====

Ezután létrehozzuk a Kerberos adatbázisát. Ez az adatbázis tartalmazza az összes szereplõ kulcsát a mesterkulcssal titkosítva. Erre a jelszóra nem kell feltétlenül emlékeznünk, mivel ez egy állományban tárolódik ([.filename]#/var/heimdal/m-key#). A mesterkulcsot a `kstash` parancs kiadásával és egy jelszó megadásával tudjuk létrehozni.

Ahogy a mesterkulcs elkészült, a `kadmin` parancs `-l` (mint "lokális", azaz helyi) opciójával inicializálni tudjuk az adatbázist. Ez az opció arra utasítja a `kadmin` programot, hogy ne a `kadmind` hálózati szolgáltatást használja, hanem közvetlenül az adatbázis állományait módosítsa. Ezzel oldható meg az adatbázis kezdeti létrehozásának problémája. Miután megkaptuk a `kadmin` parancssorát, az övezetünkhöz tartozó adatbázis inicializálásához adjuk ki az `init` parancsot.

Végül, még mindig a `kadmin` parancssorát használva, az `add` paranccsal hozzuk létre az elsõ szereplõnket. Egyelõre érjük be az alapértelmezett értékekkel, a `modify` paranccsal késõbb úgyis meg tudjuk változtatni ezeket. Hozzátesszük, hogy itt a `?` parancs segítségével bármikor lekérhetjük az opciók ismertetését.

Példa egy adatbázis létrehozására:

[source,shell]
....
# kstash
Master key: xxxxxxxx
Verifying password - Master key: xxxxxxxx

# kadmin -l
kadmin> init EXAMPLE.ORG
Realm max ticket life [unlimited]:
kadmin> add tillman
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
Password: xxxxxxxx
Verifying password - Password: xxxxxxxx
....

Most már ideje elindítani a KDC szolgáltatásait. Ezeket az `/etc/rc.d/kerberos start` és `/etc/rc.d/kadmind start` parancsok kiadásával tudjuk felhozni. Megjegyezzük, hogy most még semmilyen kerberizált démont nem kell elindítanunk. Ellenben igyekezzünk ellenõrizni a KDC mûködõképességét azzal, hogy KDC parancssorából kérünk egy jegyet a frissen hozzáadott szereplõnknek (felhasználónknak) és kilistázzuk:

[source,shell]
....
% kinit tillman
tillman@EXAMPLE.ORG's Password:

% klist
Credentials cache: FILE:/tmp/krb5cc_500
	Principal: tillman@EXAMPLE.ORG

  Issued           Expires          Principal
Aug 27 15:37:58  Aug 28 01:37:58  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
....

Miután végeztünk, nyugodtan törölhetjük a jegyet:

[source,shell]
....
% kdestroy
....

=== Szerverek kerberizálása a Heimdal használatával

Ehhez elõször is szükségünk lesz a Kerberos konfigurációs állományának, az [.filename]#/etc/krb5.conf# másolatára. Ezt úgy tudjuk megtenni, ha egyszerûen átmásoljuk a kulcselosztóról az egyik kliensre valamilyen megbízható módon (vagy az man:scp[1] programhoz hasonló hálózati segédprogramok, vagy például fizikailag egy floppy lemez használatával).

Ezután szükségünk lesz egy [.filename]#/etc/krb5.keytab# nevû állományra. Ez az alapvetõ különbség a kerberizált démonokat felkínáló szerver és egy munkaállomás közt - a szervernek rendelkeznie kell egy [.filename]#keytab# állománnyal. Ez az állomány tartalmazza a szerver kulcsát, amivel így a kulcselosztóval kölcsönösen azonosítani tudják egymást. Ezt a szerverre biztonságosan kell eljuttatnunk, mivel ennek napvilágra kerülésével a szerver védelme komoly veszélybe kerül. Tehát, ha egy titkosítás nélküli csatornán, például FTP-n keresztül visszük át, akkor kifejezetten rossz ötlet.

A szerverre általában a `kadmin` program használatával érdemes átvinni a [.filename]#keytab# állományt. Ez azért is hasznos, mert ehhez a `kadmin` segítségével létre kell hoznunk a befogadó szereplõt is (a kulcselosztó a [.filename]#krb5.keytab# állomány végén).

Vegyük észre, hogy már kaptunk egy jegyet és ezzel a jeggyel jogosultaknak kell lennünk a [.filename]#kadmind.acl# állomány `kadmin` felület használatára. A hozzáférést vezérlõ listák (ACL-ek) tervezésével kapcsolatban olvassuk el Heimdal info oldalán található "Remote administration" címû szakaszt (`info heimdal`). Amennyiben nem kívánjuk engedélyezni a `kadmin` távoli elérését, egyszerûen csak csatlakozzunk valamilyen biztonságos módon (helyi konzolon, man:ssh[1] vagy egy kerberizált man:telnet[1] használatával) a kulcselosztóhoz, és a `kadmin -l` paranccsal végezzük el helyben az adminisztrációt.

Miután telepítettük az [.filename]#/etc/krb5.conf# állományt, a Kerberos szerverrõl el tudjuk érni a `kadmin` felületét. Az `add --random-key` paranccsal most már hozzáadhatjuk a szerver befogadó szereplõjét és az `ext` paranccsal ki tudjuk vonni a szerver befogadó szereplõjét a saját keytab állományából. Például:

[source,shell]
....
# kadmin
kadmin> add --random-key host/myserver.example.org
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
kadmin> ext host/myserver.example.org
kadmin> exit
....

Itt jegyeznénk meg, hogy az `ext` parancs (az "extract" rövdítése) a kivont kulcsot alapértelmezés szerint az [.filename]#/etc/krb5.keytab# állományba menti ki.

Ha a kulcselosztón nem fut a `kadmind` szolgáltatás (valószínûleg biztonsági okokból) és ezért távolról nem tudjuk elérni a `kadmin` felületét, akkor így tudjuk közvetlenül hozzáadni a befogadó szereplõt (`host/myserver.EXAMPLE.ORG`), majd kivonatolni azt egy ideiglenes állományba (elkerülve az [.filename]#/etc/krb5.keytab# felülírását):

[source,shell]
....
# kadmin
kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org
kadmin> exit
....

Ezután valamilyen biztonságos eszközzel (például `scp` vagy floppy használatával) át tudjuk másolni keytab állományt a szerverre. A kulcselosztón levõ keytab felülírását elkerülendõ, ne feledkezzünk el egy megfelelõ név megadásáról sem.

Ezen a ponton már a szerver képes felvenni a kapcsolatot a kulcselosztóval (a [.filename]#krb5.conf# állomány miatt) és bizonyítani a személyazonosságát (a [.filename]#krb5.keytab# állomány miatt). Így tehát készen állunk a szolgáltatások kerberizálására. Ebben a példában most a `telnet` szolgáltatást vesszük célba úgy, hogy elõször az [.filename]#/etc/inetd.conf# állományba berakjuk az alábbi sort, majd újraindítjuk az man:inetd[8] szolgáltatást az `/etc/rc.d/inetd restart` paranccsal:

[.programlisting]
....
telnet    stream  tcp     nowait  root    /usr/libexec/telnetd  telnetd -a user
....

Itt az a legfontosabb, hogy az `-a` (mint authentication, azaz hitelesítés) paramétert a "user" beállítással adjuk meg. A man:telnetd[8] man oldalán olvashatunk ennek pontos részleteirõl.

=== Kliensek kerberizálása a Heimdal használatával

A kliensek beállítása szinte majdnem gyerekjáték. A Kerberos beállításához egyedül az [.filename]#/etc/krb5.conf# állományra lesz szükségünk. Valamilyen biztonságos eszközzel másoljuk át a kulcselosztóról a kliensre.

Úgy tudjuk letesztelni klienst, ha megpróbáljuk róla kiadni a `kinit`, `klist` és `kdestroy` parancsokat a fentebb létrehozott szereplõ jegyének megszerzéséhez, lekérdezéséhez és megsemmisítéséhez. A Kerberos használatával megpróbálkozhatunk csatlakozni valamelyik kerberizált szerverre is, ha viszont ez nem mûködik még egy jegy megszerzése után sem, akkor a gond többnyire a szerverrel van, nem pedig a klienssel vagy a kulcselosztóval.

Amikor egy `telnet` vagy egy hozzá hasonló alkalmazást tesztelünk, egy csomaglehallgató (mint amilyen például a man:tcpdump[1]) elindításával gyõzödjünk meg róla, hogy a jelszavak ilyenkor titkosítva mennek át. Próbáljuk meg titkosítani a teljes kommunikációt a `telnet -x` paraméterével (hasonlóan az `ssh` parancshoz).

Alapból még számos más kiegészítõ Kerberos kliensalkalmazás is telepítõdik. Ezeken érezhetõ meg valójában az alaprendszerhez tartozó Heimdal változat "minimalitása": ebben a `telnet` az egyedüli kerberizált szolgáltatás.

A Heimdal port igyekszik pótolni a hiányzó klienseket a kerberizált `ftp`, `rsh`, `rcp`, `rlogin` és néhány kevéséb ismert program telepítésével. Az MIT változat portja szintén tartalmazza a Kerberos kliensek teljes kelléktárát.

=== A felhasználók konfigurációs állományai: a [.filename]#.k5login# és a [.filename]#.k5users#

Általában az övezetben található felhasználók mindegyikéhez tartozik egy Kerberos-szereplõ (mint például a `tillman@EXAMPLE.ORG`), ami a felhasználó helyi hozzáférésére mutat (mint például a `tillman` nevû helyi hozzáférés). A `telnet` és a hozzá hasonló kliensalkalmazások általában nem igényelnek felhasználót vagy szereplõt.

Elõfordulhat azonban, hogy valaki olyan szeretné elérni egy helyi felhasználó hozzáférését, aki nem rendelkezik a hozzá tartozó Kerberos-szereplõvel. Például a `tillman@EXAMPLE.ORG` nevû felhasználó el szeretné érni a helyi számítógépen levõ `webdevelopers` hozzáférést. Más szereplõk is elérhetik a helyi hozzáféréseket.

A probléma megoldásához a felhasználók könyvtárában található [.filename]#.k5login# és a [.filename]#.k5users# állományok használhatóak a [.filename]#.host# és [.filename]#.rhosts# állományok kombinációjához hasonlóan. Például a [.filename]#.k5login# így néz ki:

[source,shell]
....
tillman@example.org
jdoe@example.org
....

Ezt a `webdevelopers` nevû helyi felhasználó könyvtárában kell elhelyeznünk, így a felsorolt szereplõt megosztott jelszó használata nélkül képesek elérni a hozzáférést.

Az említett parancsok man oldalának elolvasása ajánlott. Megjegyezzük, hogy a `ksu` man oldal foglalkozik a [.filename]#.k5users# állománnyal.

=== Tippek, trükkök a Kerberos használatáról és hibaelhárítás

* Akár a Kerberos Heimdal vagy az MIT változatát használjuk, ne felejtsük úgy beállítani a `PATH` környezeti változóban felsorolt elérési utakat, hogy a kliensalkalmazások kerberizált változatai a rendszerben használatos verziók elé kerüljenek.
* Az övezetben minden számítógép órája ugyanúgy jár? Ha nem, akkor a hitelesítés csõdöt mondhat. A crossref:network-servers[network-ntp,Az órák egyeztetése az NTP használatával]ból tudhatjuk meg hogyan szinkronizáljunk órákat az NTP segítségével.
* Az MIT és a Heimdal verziók a `kadmin` kivételével remekül megvannak egymással, mivel az általa használt protokollt még nem szabványosították.
* Ha megváltoztatjuk a gépünk hálózati nevét, akkor a ugyanígy a `host/` szereplõnket is meg kell változtatni és frissíteni a keytab állományunkat. Ez olyan speciális keytab bejegyzésekre is vonatkozik, mint például az Apache package:www/mod_auth_kerb[] moduljához tartozó `www/` szereplõ.
* Az övezetünkben levõ összes számítógépnek (mind a két irányba) feloldható DNS névvel kell rendelkeznie (vagy legalább egy [.filename]#/etc/hosts# állománnyal). Erre a CNAME rekord megfelelõ, de az A és PTR rekordoknak mindenképpen rendben kell lenniük. Az ilyenkor keletkezõ hibaüzenet nem éppen fogja meg a lényeget: `Kerberos5 refuses authentication because Read req failed: Key table entry not found`.
* A kulcselosztó számára kliensként viselkedõ bizonyos operációs rendszerek nem állítják be megfelelõen a `ksu` engedélyeit, ezért nem lehet `root` jogokkal futtatni. Ezért a `ksu` parancs nem fog mûködni, ami alapvetõen nem egy rossz ötlet, de idegesítõ. Ez nem a kulcselosztó hibája.
* Ha a KerberosMIT változatát használjuk és a meg akarjuk hosszabbítani a szereplõknek kiadott jegyek élettartamát az alapértelmezett tíz óráról, akkor a `kadmin` felületén a `modify_principal` paranccsal tudjuk megváltoztatni mind a kérdéses szereplõ, mind pedig a `krbtgt` jegyeinek élettartamának maximumát. Ezt követõen a szereplõ a `kinit -l` opciójával tud egy nagyobb élettartammal rendelkezõ jegyet kérni.

[NOTE]
====
Amikor egy kulcselosztóval kapcsolatos hibát próbálunk felderíteni a csomagok lehallgatásával, és a munkaállomásunkról kiadjuk a `kinit` parancsot, akkor arra lehetünk figyelmesek, hogy a TGT már egybõl a `kinit` indításakor átküldésre kerül - még mielõtt egyáltalán megadtuk volna a jelszavunkat! Ezt azzal lehet magyarázni, hogy a Kerberos szerver bármilyen hitelesítetlen kérésre elküld egy TGT-t (Jegyadó jegy, azaz Ticket Granting Ticket). Azonban mindegyik ilyen TGT a felhasználó jelszavából származtatott kulccsal titkosítódik. Ezért amit a felhasználó jelszóként megad, nem megy el a kulcselosztónak, hanem vele a `kinit` a már megkapott TGT-t kódolja ki. Amennyiben a visszakódolás egy érvényes idõbélyeggel rendelkezõ, használható jegyet eredményez, akkor a felhasználó érvényes Kerberos hitelesítést szerez. Ez a hitelesítés magában foglal egy kulcsot, amellyel a késõbbiekben a Kerberos szerverekkel tudjuk felvenni biztonságos módon a kapcsolatot, és rajta kívül egy újabb jegyadó jegyet, amelyet a Kerberos szerver a saját kulcsával titkosított. A titkosítás második vonala a felhasználó számára ismeretlen, de segítségével a Kerberos szerer képes ellenõrizni az egyes jegyadó jegyek hitelességét.
====

* Ha a jegyeket hosszabb (például egyhetes) élettartammal akarjuk használni és a jegyeket tároló géphez OpenSSH segítségével csatlakozunk, akkor mindenképpen ellenõrizzük, hogy az [.filename]#sshd_config# állományban a Kerberos `TicketCleanup` beállításának értéke `no`, máskülönben a kijelentkezés után automatikusan törlõdnek a jegyeink.
* Ne hagyjuk figyelmen kívül azt sem, hogy a befogadó szereplõk is rendelkezhetnek nagyobb élettartamú jegyekkel. Ha a felhasználónkhoz tartozó szereplõ jegye például egy hét alatt évül el, de a számítógép, amire bejelentkezük, csupán kilenc óráig tartja életben ezeket, akkor a jegyeket tároló gyorsítótárunkban hamarabb elévül a hozzá tartozó jegy, ami miatt pedig hibák keletkeznek.
* Ha a rossz jelszavak használata ellen beállítjuk a [.filename]#krb5.dic# állományt (errõl a `kadmind` man oldalán találunk egy rövid leírást), akkor nem szabad elfelejteni, hogy ez csak olyan szereplõkre vonatkozik, akiknek a jelszavára is állítottunk be szabályozásokat. A [.filename]#krb5.dict# állományok felépítési nem bonyolult: minden sorban egyetlen karakterlánc szerepel. Érdemes lehet például létrehozni ezen a néven egy szimbolikus linket a [.filename]#/usr/shared/dict/words# állományra.

=== Eltérések az MIT porttól

A Heimdal és az MIT változatok közti egyik legnagyobb eltérés a `kadmin` programmal kapcsolatban van, ami eltérõ (de egyébként ekivalens) parancskészlettel rendelkezik és más protokollt használ. Ennek komoly következménye, hogy ha az MIT-féle kulcselosztót használjuk, akkor azt a Heimdal `kadmin` felületével nem tudjuk távolról adminisztrálni (és vica versa).

A kliensalkalmazások paraméterezése is eltérhet ugyanazon feladatoknál. Ezért velük kapcsolatban az MITKerberos honlapja (http://web.mit.edu/Kerberos/www/[http://web.mit.edu/Kerberos/www/]) a mérvadó. Vigyázzunk az elérési utakkal: az MIT port magát alapértelmezés szerint a [.filename]#/usr/local# könyvtárba telepíti, ezért az általuk kiváltani kívánt "normális" rendszerprogramokat esetleg hamarabb találja meg a rendszer, ha nem jól állítottuk be a `PATH` környezeti változónkat.

[NOTE]
====
Ha nem értjük, hogy miért mûködnek olyan furcsán a `telnetd` és a `klogind` által kezelt bejelentkezések, akkor olvassuk el a FreeBSD package:security/krb5[] portjával települõ MIT változat [.filename]#/usr/local/shared/doc/krb5/README.FreeBSD# állományt (angolul). Az a legfontosabb, hogy a `incorrect permissions on cache file` hiba eltüntetéséhez a `login.krb5` binárist kell használnunk, így a továbbított jogosultságoknak megfelelõen át tudja állítani a tulajdonost.
====

Az [.filename]#rc.conf# állományt is módosítani kell a következõ beállítás kialakításához:

[.programlisting]
....
kerberos5_server="/usr/local/sbin/krb5kdc"
kadmind5_server="/usr/local/sbin/kadmind"
kerberos5_server_enable="YES"
kadmind5_server_enable="YES"
....

Erre azért van szükség, mert a KerberosMIT változata a [.filename]#/usr/local# könyvtáron belülre telepíti fel a hozzá tartozó alkalmazásokat.

=== A Kerberosban talált korlátozások enyhítése

==== A Kerberos a "mindent vagy semmit" megközelítést követi

A hálózaton minden szolgáltatást módosítanunk kell ahhoz, hogy együtt tudjanak mûködni a Kerberosszal (vagy valamilyen más módon védenünk kell ezeket a támadások ellen), különben a felhasználók jogait el lehet lopni vagy újra fel lehet használni. Erre jó példa lehet az összes távoli parancssoros elérés (például az `rsh` valamint a `telnet`) kerberizálása, de a jelszavakat titkosítatlanul küldõ POP3 levelezõ szerver kihagyása.

==== A Kerberos az egyfelhasználós munkaállomások számára készült

Többfelhasználós környezetben a Kerberos már nem annyira biztonságos. Ez azért mondható el, mert a jegyeket a mindenki által olvasható [.filename]#/tmp# könyvtárban tárolja. Ha az adott felhasználó számítógépét egyszerre több emberrel is megosztja (tehát többfelhasználós), akkor a felhasználó jegyeit egy másik felhasználó bármikor lemásolhatja (ellophatja).

Ezt a `-c` opció után megadott állománynévvel vagy (inkább) a `KRB5CCNAME` környezeti változó megfelelõ beállításával tudjuk áthidalni, habár ezt ritkán teszik is meg. Ha a felhasználók könyvtárában és a megfelelõ engedélyekkel tároljuk ezeket a jegyeket, akkor némileg visszaszoríthatjuk a probléma kockázatát.

==== A kulcselosztó a rendszer legsebezhetõbb pontja

A rendszer kialakításából fakadóan a kulcselosztónak legalább annyira megbízhatónak kell lennie, mint a rajta levõ központi jelszóadatbázisnak. A kulcselosztón semmilyen más szolgáltatás nem futhat és fizikailag is biztonságba kell helyezni. A kockázat nagy, mivel a Kerberos az összes jelszót ugyanazzal a kulcssal (a "mesterkulcssal") titkosítja, amelyet a kulcselosztó egy állományban tárol.

Széljegyzet gyanánt hozzátesszük, hogy a mesterkulcs elvesztése nem annyira rossz, mint azt elsõ gondolnánk. A mesterkulcsot csupán a véletlenszám-generátor inicializálásához használják a Kerberos adatbázisának titkosításakor. Amíg a kulcselosztóhoz nem tudnak illetéktelenek hozzáférni, addig nem tudnak sokat kezdeni a mesterkulccsal.

Mellesleg ha a kulcselosztó nem elérhetõ (talán pontosan egy DoS támadás vagy éppen hálózati problémák miatt), akkor a hitelesítés nem végezhetõ el, mivel így a hozzá szükséges hálózati szolgáltatások sem használhatóak. Ez remek eszköz egy DoS támadáshoz. Ezen több (egy központi és egy vagy több alárendelt) kulcselosztó telepítésével, valamint a másodlagos vagy tartalékként használt hitelesítési eszközök (a PAM erre tökéletes) körültekintõ megvalósításával enyhíthetünk.

==== A Kerberos hiányosságai

A Kerberos révén a felhasználók, számítógépek és szolgáltatások tudják egymást hitelesíteni. Ellenben semmilyen eszközt nem kínál fel a kulcselosztó hitelességének ellenõrzésére. Így tehát (például) egy eltérített `kinit` képes ellopni az összes felhasználói nevet és jelszót. Az ilyen incidensek elkerülésére a package:security/tripwire[] és a hozzá hasonló segédprogramok segítségével lehet megõrizni a rendszer sértelenségét.

=== Erõforrások és további információk

* http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html[ A Kerberos GYIK (angolul)]
* http://web.mit.edu/Kerberos/www/dialogue.html[Egy hitelesítési rendszer kidolgozása: párbeszéd négy színben (angolul)]
* http://www.ietf.org/rfc/rfc1510.txt?number=1510[RFC 1510: A Kerberos hálózati hitelesítési szolgáltatás (V5) (angolul)]
* http://web.mit.edu/Kerberos/www/[Az MIT Kerberos holnapja (angolul)]
* http://www.pdc.kth.se/heimdal/[A Heimdal Kerberos honlapja (angolul)]

[[openssl]]
== OpenSSL

A FreeBSD-hez adott OpenSSL az egyik olyan tényezõ, amit a legtöbb felhasználó figyelmen kívül hagy. Az OpenSSL egy titkosítási réteget nyújt a hagyományos kommunikációs csatorna felett, így rengeteg hálózati alkalmazásba és szolgáltatásba bele lehet szõni.

Az OpenSSL felhasználható többek közt a levelezõ kliensek titkosított hitelesítésére, hitelkártyás fizetések weben keresztüli lebonyolítására alkalmas, és még sok minden másra. Sok port, köztük a package:www/apache13-ssl[] és a package:mail/sylpheed-claws[] is felajánlja az OpenSSL felhasználását.

[NOTE]
====
A legtöbb esetben a Portgyûjtemény megpróbálja lefordítani a package:security/openssl[] portot, hacsak a `WITH_OPENSSL_BASE` változót határozottan a "yes" értékre nem állítjuk.
====

A FreeBSD-hez mellékelt OpenSSL ismeri a Secure Sockets Layer v2/v3 (SSLv2/SSLv3) és Transport Layer Security v1 (TLSv1) hálózatbiztonsági protokollokat, és általános célú titkosítási könyvtárként is alkalmazható.

[NOTE]
====
Noha az OpenSSL ismeri az IDEA algoritmusát is, az Egyesült Államokban érvényben levõ szabadalmak miatt alapértelmezés szerint nem engedélyezett. A használatához el kell olvasni a hozzá tartozó licencet, és ha elfogadjuk a benne foglaltakat, akkor állítsuk be a `MAKE_IDEA` változót a [.filename]#make.conf# állományban.
====

Az OpenSSL-t leginkább a szoftverek tanúsítványainak elkészítéséhez használják. Ilyen tanúsítvánnyokkal lehet szavatolni, hogy az érte felelõs cég vagy egyén valóban megbízható és nem szélhámos. Amennyiben a kérdéses tanúsítványt nem vizsgálta be valamelyik "tanúsítványok hitelesítésével foglalkozó hatóság" (Certificate Authority, vagy CA), akkor errõl általában kap egy figyelmeztetést a felhasználó. A tanúsítványokat hitelesítõ cégek, mint például a http://www.verisign.com[VeriSign], írják alá ezeket a tanúsítványokat és ezzel érvényesítik az egyes cégek vagy egyének megbízhatóságát. Ez ugyan pénzbe kerül, de használatuk egyáltalán nem is kötelezõ. Azonban az átlagosnál paranoidabb felhasználók számára megnyugvást jelenthet.

=== Tanúsítványok elõállítása

A tanúsítványok létrehozására a következõ parancs áll rendelkezésre:

[source,shell]
....
# openssl req -new -nodes -out req.pem -keyout cert.pem
Generating a 1024 bit RSA private key
................++++++
.......................................++++++
writing new private key to 'cert.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:országnév (kétbetűs kóddal)
State or Province Name (full name) [Some-State]:állam vagy tartomány teljes neve
Locality Name (eg, city) []:település neve
Organization Name (eg, company) [Internet Widgits Pty Ltd]:szervezet neve
Organizational Unit Name (eg, section) []:szervezeti egység neve
Common Name (eg, YOUR name) []:általános név (hálózati név!)
Email Address []:e-mail cím

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:VALAMILYEN JELSZÓ
An optional company name []:egy másik szervezet neve
....

Az adatok bekérésére elõtt megjelenõ figyelmeztetõ üzenet fordítása:

[source,shell]
....
Itt a tanúsítvány igénylésével kapcsolatos információkat kell
megadnunk. Itt egy ún. "ismertetőnevet" (Distinguished
Name, DN) kell megadnunk. Ezen kívül van még néhány más mező is, de
ezeket akár üresen is hagyhatjuk. Néhány mezőnek van alapértelmezett
értéke, de ha oda egy pontot írunk, akkor kitöröljük.
....

A "Common Name" mezõnél ellenõrzési okokból egy hálózati nevet, tehát a szerverünk nevét kell megadnunk. Ha nem így járunk el, akkor lényegében egy használhatatlan tanúsítványt kapunk. További opciók is elérhetõek, mint például a lejárati idõ (expire time) megadása, a titkosítási algoritmus megváltoztatása stb. Ezek teljes listája megtalálható az man:openssl[1] man oldalon.

Az elõbbi parancs kiadása után két állománynak kell létrejönnie az aktuális könyvtárban. A tanúsítványkérést, vagyis az [.filename]#req.pem# állományt kell eljuttatnunk a tanúsítványok hitelesítésével foglakozó szervhez, aki majd érvényesíti az imént megadott adatainkat. A második, [.filename]#cert.pem# nevû állomány a tanúsítványhoz tartozó privát kulcs, amit semmilyen körülmények között sem szabad kiadnunk. Ha ez mások kezébe kerül, akkor el tudnak játszani bennünket (vagy a szerverünket).

Amikor a hitelesítõ szerv aláírása nem feltétlenül szükséges, akkor készíthetünk egy saját magunk által aláírt tanúsítványt is. Ehhez elõször is generálnunk kell egy RSA-kulcsot:

[source,shell]
....
# openssl dsaparam -rand -genkey -out saját_RSA.kulcs 1024
....

Most pedig készítsünk el a hitelesítõ szerv kulcsát is:

[source,shell]
....
# openssl gendsa -des3 -out hitelesítõ.kulcs saját_RSA.kulcs
....

Ezzel a kulccsal most gyártsunk le egy tanúsítványt:

[source,shell]
....
# openssl req -new -x509 -days 365 -key hitelesítõ.kulcs -out új.tanúsítvány
....

Ekkor két új állomány keletkezik a könyvtárunkban: a hitelesítõ szerv aláírása, a [.filename]#hitelesítõ.kulcs# és maga a tanúsítvány, az [.filename]#új.tanúsítvány# állomány. Ezeket tegyük az [.filename]#/etc# könyvtáron belül egy olyan könyvtárba, amelyet csak a `root` tud olvasni. A `chmod` paranccsal állítsunk be rá 0700-as kódú engedélyeket.

=== Példa a tanúsítványok használatára

Mire is jók ezek az állományok? Például kitûnõen alkalmazhatóak a Sendmail levelezõ szerverhez beérkezõ kapcsolatot titkosítására. Így lényegében felszámoljuk minden olyan felhasználó titkosítatlan módon zajló hitelesítését, aki a helyi levelezõ szerveren keresztül küldi a leveleit.

[NOTE]
====
Ez általában nem a legjobb megoldás, mivel egyes levelezõ kliensek hibát jeleneznek a felhasználónak, ha nem rendelkezik a tanúsítvánnyal. A tanúsítványok telepítésével kapcsolatban olvassuk el a szoftverhez adott leírást.
====

A helyi [.filename]#.mc# állományba ezeket a sorokat kell beletenni:

[.programlisting]
....
dnl SSL Options
define(`confCACERT_PATH',`/etc/certs')dnl
define(`confCACERT',`/etc/certs/új.tanúsítvány')dnl
define(`confSERVER_CERT',`/etc/certs/új.tanúsítvány')dnl
define(`confSERVER_KEY',`/etc/certs/hitelesítõ.kulcs')dnl
define(`confTLS_SRV_OPTIONS', `V')dnl
....

Itt a [.filename]#/etc/certs/# az a könyvtár, amit tanúsítványok és kulcsok helyi tárolására használunk. Végezetül még újra kell generálnunk a helyi [.filename]#.cf# állományokat. Ezt a [.filename]#/etc/mail# könyvtárban a `make install` parancs kiadásával könnyen elvégezhetjük. Miután ez megtörtént, akkor Sendmailhoz tartozó démont a `make restart` paraméterével indíthatjuk újra.

Ha minden jól ment, akkor a [.filename]#/var/log/maillog# állományban nem találunk egyetlen hibaüzenetet sem, és a Sendmail is megjelenik a futó programok között.

A man:telnet[1] segédprogrammal így probálhatjuk ki a levelezõ szervert:

[source,shell]
....
# telnet example.com 25
Trying 192.0.34.166...
Connected to example.com.
Escape character is '^]'.
220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT)
ehlo example.com
250-example.com Hello example.com [192.0.34.166], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP
quit
221 2.0.0 example.com closing connection
Connection closed by foreign host.
....

Ha itt megjelenik a "STARTTLS" sor, akkor mindent sikerült beállítanunk.

[[ipsec]]
== VPN IPsec felett

VPN létrehozása FreeBSD átjárók használatával két olyan hálózat között, amelyeket egymástól az internet választ el.

=== Az IPsec bemutatása

Ebben a szakaszban az IPsec beállításának folyamatát vázoljuk fel. Az IPsec beállításához elengedhetetlen, hogy tisztában legyünk egy saját rendszermag fordításának alapjaival (lásd crossref:kernelconfig[kernelconfig,A FreeBSD rendszermag testreszabása]).

Az _IPsec_ egy olyan protokoll, amely az Internet Protocol (IP) rétegére épül. Segítségével két vagy több számítógép képes biztonságos módon tartani egymással a kapcsolatot (innen ered a neve). A FreeBSD IPsec "hálózati protokollkészlete" a http://www.kame.net[KAME] implementációjára épül, mely egyaránt támogatja az IPv4 és IPv6 protokollcsaládokat.

Az IPsec két alprotokollból tevõdik össze:

* _A hasznos adat biztonságos becsomagolása (Encapsulated Security Payload, ESP)_ során egy szimmetrikus kriptográfiai algoritmussal (mint például Blowfish, 3DES) titkosítjuk az IP-csomagok tartalmát, ezáltal megvédjük ezeket az illetéktelenektõl.
* A _Hitelesítési fejléc (Authentication Header, AH)_ használatával megakadályozzuk, hogy az illetéktelenek meghamisítsák az IP csomagok fejlécét. Ezt úgy érjük el, hogy kiszámolunk egy kriptográfiai ellenõrzõ összeget és az IP-csomagok fejlécének mezõire egy biztonságos függvénnyel generálunk valamilyen ujjlenyomatot. Az ez után következõ kiegészítõ fejléc tartalmazza ezt az ujjlenyomatot, amellyel a csomag hitelesíthetõ.

Az ESP és az AH az alkalmazástól függõen használható együtt vagy külön-külön.

Az IPsec akár közvetlenül is használható két számítógép forgalmának titkosítására (ezt _Szállítási módnak (Transport Mode)_ nevezik), vagy két alhálózat között építhetünk ki vele "virtuális tunneleket", ami remekül alkalmas két vállalati hálózat kommunikációjának bebiztosítására (ez a _Tunnel mód (Tunnel Mode)_). Ez utóbbit egyszerûen csak _Virtuális magánhálózatként (Virtual Private Network, VPN)_ emlegetik. A FreeBSD IPsec alrendszerérõl az man:ipsec[4] man oldalon találhatunk további információkat.

A rendszermag IPsec támogatásának aktiválásához a következõ paramétereket kell beletennünk a konfigurációs állományba:

[source,shell]
....
options   IPSEC        # IP biztonság
device    crypto
....

Ha szükségünk van a IPsec nyomkövetésére, a következõ beállítást is hozzátehetjük:

[source,shell]
....
options   IPSEC_DEBUG  # az IP biztonság nyomkövetése
....

=== A probléma

Semmilyen szabvány nem fogalmazza meg mi is számít VPN-nek. A virtuális magánhálózatok tucatnyi különbözõ technológiával valósíthatóak meg, de mindegyiknek megvan a maga erõssége és gyengesége. Ebben a szakaszban körvonalazunk egy ilyen helyzetet, valamint a benne felépített VPN megvalósításához alkalmazott stratégiákat.

=== A forgatókönyv: adott egy otthoni és egy vállalati hálózat, amelyek külön-külön csatlakoznak az internetre, és VPN használatával ezeket egyetlen hálózatként szeretnénk használni

Elõfeltételezéseink a következõek:

* legalább két hálózatunk van;
* magán belül mind a két hálózat IP-t használ;
* mind a két hálózat egy FreeBSD átjárón keresztül csatlakozik az internethez;
* a hálózatok átjárói legalább egy publikus IP-címmel rendelkeznek;
* a hálózatok belsõ címei lehetnek publikus vagy privát IP-címek, nem számít. Fontos viszont, hogy ezek ne ütközzenek, vagyis ne használja egyszerre mind a kettõ a `192.168.1.x` címtartományt.

=== Az IPsec beállítása FreeBSD alatt

Kezdésképpen a Portgyûjteménybõl telepítenünk kell a package:security/ipsec-tools[] portot. Ez a programcsomag rengeteg olyan alkalmazást tartalmaz, amely segítségünkre lehet a beállítások elvégzése során.

A következõ lépésben létre kell hoznunk két man:gif[4] típusú pszeudoeszközt, melyeken keresztül a két hálózat között egy tunnel segítségével ki tudjuk építeni a szükséges kapcsolatot. Ehhez `root` felhasználóként futtassuk a következõ parancsokat (a _belsõ_ és _külsõ_ megnevezésû paramétereket cseréljük ki a valós belsõ és külsõ átjárók címeire):

[source,shell]
....
# ifconfig gif0 create
....

[source,shell]
....
# ifconfig gif0 belsõ1 belsõ2
....

[source,shell]
....
# ifconfig gif0 tunnel külsõ1 külsõ2
....

Tekintsük például, hogy a vállalati LAN publikus IP-címe `172.16.5.4`, valamint a privát IP-címe `10.246.38.1`. Az otthoni LAN publikus IP-címe legyen most `192.168.1.12`, valamint a belsõ privát IP-címe pedig `10.0.0.5`.

Elsõre ez talán még nem teljesen érthetõ, ezért az man:ifconfig[8] parancs használatával is nézzük meg a példában szereplõ hálózatok konfigurációját:

[.programlisting]
....
Az elsõ átjáró:

gif0: flags=8051 mtu 1280
tunnel inet 172.16.5.4 --> 192.168.1.12
inet6 fe80::2e0::81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6
inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00

A második átjáró:

gif0: flags=8051 mtu 1280
tunnel inet 192.168.1.12 --> 172.16.5.4
inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00
inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4
....

Miután elvégeztük az iménti beállításokat, a man:ping[8] paranccsal már mind a két privát IP-tartománynak elérhetõnek kell lennie, ahogy azt az alábbi példa is érzékeltetni kívánja:

[.programlisting]
....
otthoni-halo# ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5): 56 data bytes
64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms
64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms
64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms
--- 10.0.0.5 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms

vallalati-halo# ping 10.246.38.1
PING 10.246.38.1 (10.246.38.1): 56 data bytes
64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms
64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms
64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms
64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms
64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms
--- 10.246.38.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms
....

Az elvárásainknak megfelelõen tehát a privát címeken mind a két oldalnak képesnek kell lennie ICMP csomagokat küldenie és fogadnia. A következõ lépésben meg kell mondanunk az átjáróknak hogyan irányítsák a csomagokat a két hálózat közti forgalom megfelelõ áramlásához. Ezt az alábbi paranccsal elérhetjük el:

[source,shell]
....
# vallalati-halo# route add 10.0.0.0 10.0.0.5 255.255.255.0
....

[source,shell]
....
# vallalati-halo# route add net 10.0.0.0: gateway 10.0.0.5
....

[source,shell]
....
# otthoni-halo# route add 10.246.38.0 10.246.38.1 255.255.255.0
....

[source,shell]
....
# otthoni-halo# route add host 10.246.38.0: gateway 10.246.38.1
....

Itt már a belsõ gépeket az átjárókról és az átjárók mögül egyaránt el tudjuk érni. A következõ példa alapján errõl könnyedén meg is tudunk gyõzõdni:

[.programlisting]
....
vallalati-halo# ping 10.0.0.8
PING 10.0.0.8 (10.0.0.8): 56 data bytes
64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms
64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms
64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms
64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms
64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms
--- 10.0.0.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms

otthoni-halo# ping 10.246.38.107
PING 10.246.38.1 (10.246.38.107): 56 data bytes
64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms
64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms
64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms
64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms
64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms
--- 10.246.38.107 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms
....

A tunnelek beállítása volt igazából a könnyebb rész, egy biztonságos összeköttetés kialakítása azonban már valamivel komolyabb folyamatot rejt magában. A most következõ konfigurációban erre "elõre ismert" (vagyis pre-shared, PSK) RSA-kulcsokat fogunk használni. A konkrét IP-címektõl eltekintve az átjárókon a [.filename]#/usr/local/etc/racoon/racoon.conf# állományok hasonlóan fognak kinézni, nagyjából valahogy így:

[.programlisting]
....
path    pre_shared_key "/usr/local/etc/racoon/psk.txt"; # az ismert kulcsot tartalmazó állomány helye
log     debug;	# a naplózás részletességének beállítása: ha végeztünk a teszteléssel és a hibakereséssel, akkor állítsuk át a 'notify' értékre

padding  # ezeket ne nagyon változtassuk meg
{
        maximum_length  20;
        randomize       off;
        strict_check    off;
        exclusive_tail  off;
}

timer	# idõzítési beállítások, állítsuk be igény szerint
{
        counter         5;
        interval        20 sec;
        persend         1;
#       natt_keepalive  15 sec;
        phase1          30 sec;
        phase2          15 sec;
}

listen	# cím [port], ahol a racoon majd válaszolni fog
{
        isakmp          172.16.5.4 [500];
        isakmp_natt     172.16.5.4 [4500];
}

remote  192.168.1.12 [500]
{
        exchange_mode   main,aggressive;
        doi             ipsec_doi;
        situation       identity_only;
        my_identifier   address 172.16.5.4;
        peers_identifier        address 192.168.1.12;
        lifetime        time 8 hour;
        passive         off;
        proposal_check  obey;
#       nat_traversal   off;
        generate_policy off;

                        proposal {
                                encryption_algorithm    blowfish;
                                hash_algorithm          md5;
                                authentication_method   pre_shared_key;
                                lifetime time           30 sec;
                                dh_group                1;
                        }
}

sainfo  (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $hálózat/$hálózati_maszk $típus address $hálózat/$hálózati_maszk $típus
 		  # (a $típus lehet "any" vagy "esp")
{		  # a $hálózat a két összekapcsolni kívánt belsõ hálózat legyen
        pfs_group       1;
        lifetime        time    36000 sec;
        encryption_algorithm    blowfish,3des,des;
        authentication_algorithm        hmac_md5,hmac_sha1;
        compression_algorithm   deflate;
}
....

A példában szereplõ összes opció részletes kifejtése jóval meghaladná ezen leírás kereteit, ezért a bõvebb információkkal kapcsolatban inkább a racoon beállításaihoz tartozó man oldal elolvasását javasoljuk.

A gépek közti hálózati forgalom titkosításához be kell még állítanunk egy SPD házirendet is, így a FreeBSD és a racoon képes kódolni és dekódolni a csomagokat.

Ezt a most következõ, a vállalati átjárón találhatóhoz hasonló egyszerû shell szkripttel tudjuk elvégezni. Ezt az állományt a rendszer indításakor fogjuk felhasználni, melyet [.filename]#/usr/local/etc/racoon/setkey.conf# néven mentsünk el:

[.programlisting]
....
flush;
spdflush;
# Az otthoni hálózati felé
spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use;
spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use;
....

Ahogy ezzel megvagyunk, a racoon az egyes átjárókon a következõ paranccsal indítható el:

[source,shell]
....
# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log
....

A parancs eredménye ennek megfelelõen nagyjából a következõ lesz:

[.programlisting]
....
vallalati-halo# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf
Foreground mode.
2006-01-30 01:35:47: INFO: begin Identity Protection mode.
2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon
2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon
2006-01-30 01:36:04: INFO: ISAKMP-SA established 72.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a
2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 72.16.5.4[0]192.168.1.12[0]
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 92.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2)
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426)
2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0]
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b)
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66)
....

A tunnel megfelelõ mûködését úgy tudjuk ellenõrizni, ha átváltunk egy másik konzolra és a man:tcpdump[1] program segítségével figyeljük a hálózati forgalmat. A példában szereplõ `em0` interfészt természetesen ne felejtsük el kicserélni a megfelelõ eszköz nevére.

[source,shell]
....
# tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12
....

Ennek hatására az alábbiakhoz hasonló adatoknak kellene megjelennie a konzolon. Amennyiben nem ez történik, valamilyen hiba történt, ezért meg kell keresnünk azt a visszakapott adatok alapján.

[.programlisting]
....
01:47:32.021683 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xa)
01:47:33.022442 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xb)
01:47:34.024218 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xc)
....

Itt már mind a két hálózatnak elérhetõnek kell lennie és egyként kell látszódnia. A hálózatokat ezen felül még érdemes külön védeni egy tûzfallal is. Ilyenkor a csomagok két hálózati közti zavartalan oda-vissza vándorlásához további szabályokat kell még felvennünk a tûzfal szabályrendszerébe. A man:ipfw[8] tûzfal esetén ez a következõ sorok hozzáadását jelenti a tûzfal konfigurációs állományához:

[.programlisting]
....
ipfw add 00201 allow log esp from any to any
ipfw add 00202 allow log ah from any to any
ipfw add 00203 allow log ipencap from any to any
ipfw add 00204 allow log udp from any 500 to any
....

[NOTE]
====
A szabályok számozását mindig az adott gép aktuális beállításainak megfelelõen kell módosítani.
====

A man:pf[4] és man:ipf[8] felhasználók számára ehhez a következõ parancsot javasoljuk:

[.programlisting]
....
pass in quick proto esp from any to any
pass in quick proto ah from any to any
pass in quick proto ipencap from any to any
pass in quick proto udp from any port = 500 to any port = 500
pass in quick on gif0 from any to any
pass out quick proto esp from any to any
pass out quick proto ah from any to any
pass out quick proto ipencap from any to any
pass out quick proto udp from any port = 500 to any port = 500
pass out quick on gif0 from any to any
....

Végezetül a következõ sor hozzáadásával engedélyezzük az [.filename]#/etc/rc.conf# állományban a VPN indítását a rendszer indítása során:

[.programlisting]
....
ipsec_enable="YES"
ipsec_program="/usr/local/sbin/setkey"
ipsec_file="/usr/local/etc/racoon/setkey.conf" # engedélyezzük az spd házirend beállítását a rendszer indításakor
racoon_enable="yes"
....

[[openssh]]
== OpenSSH

Az OpenSSH olyan hálózati kapcsolódási eszközök összessége, amivel biztonságos módon érhetünk el távoli számítógépeket. Az `rlogin`, `rsh`, `rcp` és a `telnet` direkt kiváltására használható. Emellett SSH-n keresztül TCP/IP kapcsolatok is biztonságosan bújtathatóak vagy küldhetõek tovább.

Az OpenSSH-t az OpenBSD projekt tartja karban, és az SSH 1.2.12 verziójára épül hibajavításokkal és frissítésekkel egyetemben. Az SSH 1 és 2 protokollokkal egyaránt kompatibilis.

=== Az OpenSSH használatának elõnyei

A hétköznapi esetben, vagyis amikor a man:telnet[1] vagy man:rlogin[1] alkalmazásokat használjuk, az adatok titkosítatlan formában közlekednek a hálózaton. A szerver és a kliens közé bárhova becsatlakozó hálózati kíváncsiskodók így könnyedén el tudják lopni a felhasználói nevünket és jelszavunkat, vagy lényegében bármilyen adatot, ami az adott munkamenetben megfordul. Az OpenSSH ennek kivédésére kínál fel különféle hitelesítési és titkosítási eszközöket.

=== Az sshd engedélyezése

Az sshd a FreeBSD telepítésekor jelentkezõ `Standard` lehetõségek egyike. Az sshd engedélyezését úgy tudjuk kideríteni, ha az [.filename]#rc.conf# állományban megkeressük a következõ sort:

[source,shell]
....
sshd_enable="YES"
....

Ez tölti be a rendszer indításakor az man:sshd[8]-t, az OpenSSH démonát. Vagy az [.filename]#/etc/rc.d/sshd# man:rc[8] szkript segítségével is elindíthatjuk az OpenSSH-t:

[.programlisting]
....
/etc/rc.d/sshd start
....

=== Az SSH kliens

Az man:ssh[1] segédprogram az man:rlogin[1] programhoz hasonlóan mûködik.

[source,shell]
....
# ssh felhasználó@gép.hu
Host key not found from the list of known hosts.  Are you sure you
want to continue connecting (yes/no)?  yes Host
'gép.hu' added to the list of known hosts.
felhasználó@gép.hu's password:
*******
....

Az üzenetek fordítása:

[source,shell]
....
Nem találtam meg a gépet az ismert gépek között.  Biztosan csatlakozni
akarunk hozzá (igen/nem)?  igen A 'gép.hu'
felkerült az ismert gépek közé.
Adja meg a felhasználó@gép.hu jelszavát:
....

Bejelentkezés után minden ugyanolyan, mintha az `rlogin` vagy a `telnet` programokat használtuk volna. Az SSH egy kulcs segítségével próbálja azonosítani a számítógépeket, ezzel ellenõrzi a szerver hitelességét a kliensek csatlakozásakor. A felhasználónak ilyenkor elõször mindig `yes` választ kell adnia. A késõbbi bejelentkezési kísérletek pedig majd mindig az így kapott kulccsal történnek. Ha eltérne a kulcs, akkor az SSH kliens erre figyelmeztetni fog minket. A kulcsok a [.filename]#~/.ssh/known_hosts# vagy az SSH v2 protokoll esetén a [.filename]#~/.ssh/known_hosts2# állományba kerülnek elmentésre.

Alapértelmezés szerint az OpenSSH szerverek csak SSH v2 kapcsolatokat fogadnak el. Lehetõség szerint a kliens is ezt a változatot fogja használni, de ha nem sikerül, akkor megpróbálkozik a v1-el. A kliensnek a `-1` vagy `-2` opciók segítségével elõ is lehet írni, hogy az elsõ vagy a második változatot használja. A kliensben az elsõ változat támogatását csupán a régebbi verziók kompatibilitása miatt tartják karban.

=== Biztonságos másolás

Az man:scp[1] parancs az man:rcp[1] parancshoz hasonlóan mûködik: egyik géprõl másol a másikra, biztonságosan.

[source,shell]
....
#  scp felhasználó@gép.hu:/COPYRIGHT COPYRIGHT
felhasználó@gép.hu's password: *******
COPYRIGHT            100% |*****************************|  4735
00:00
#
....

Mivel a kulcsot már ismerjük ehhez a távoli géphez (az elõbbi példából), ezért az man:scp[1] használatakor már ezzel hitelesítünk.

Az man:scp[1] paraméterei hasonlóak a man:cp[1] parancséhoz: elsõ helyen az állomány vagy állományok neveit adjuk meg, a másodikon pedig a célt. Mivel az állományokat a hálózaton SSH-n keresztül küldik át, ezért az állományok neveit `_felhasználó@gép_:_elérési_út_` formában kell megadni.

=== Beállítások

Az OpenSSH démon és kliens rendszerszintû konfigurációs állományai az [.filename]#/etc/ssh# könyvtárban találhatóak.

Az [.filename]#ssh_config# tartalmazza a kliens beállításait, miközben az [.filename]#sshd_config# tartalmazza a démonét.

Emellett az [.filename]#rc.conf# állományban megadható `sshd_program` (ez alapból a [.filename]#/usr/sbin/sshd#) és `sshd_flags` opciókkal további beállítási szinteket nyújtanak.

[[security-ssh-keygen]]
=== ssh-keygen

Jelszavak helyett az man:ssh-keygen[1] programmal a felhasználók azonosítására DSA- vagy RSA-kulcsokat tudunk készíteni:

[source,shell]
....
% ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/felhasználó/.ssh/id_dsa):
Created directory '/home/felhasználó/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/felhasználó/.ssh/id_dsa.
Your public key has been saved in /home/felhasználó/.ssh/id_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 felhasználó@gép.hu

....

Az man:ssh-keygen[1] ekkor a hitelesítésre létrehoz egy publikus és egy privát kulcsból álló párt. A privát kulcs a [.filename]#~/.ssh/id_dsa# vagy [.filename]#~/.ssh/id_rsa# állományba kerül, miközben a publikus kulcs a [.filename]#~/.ssh/id_dsa.pub# vagy [.filename]#~/.ssh/id_rsa.pub# lesz attól függõen, hogy DSA vagy RSA a kulcs típusa. A módszer mûködéséhez a publikus DSA- vagy RSA-kulcsot a távoli számítógép [.filename]#~/.ssh/authorized_keys# állományába kell bemásolni.

Így tehát a távoli számítógépre jelszavak alkalmazása helyett SSH-kulccsal tudunk belépni.

Ha az man:ssh-keygen[1] parancsnak megadunk egy jelmondatot is, akkor a felhasználó a privát kulcsát csak ennek megadásával tudja használni. A hosszú jelmondatok állandó beirogatásától a <<security-ssh-agent>> szakaszban hamarosan bemutatásra került man:ssh-agent[1] igyekszik megkímélni minket.

[WARNING]
====

A különbözõ opciók és állományok eltérhetnek a számítógépünkre telepített OpenSSH verziójától függõen. Ilyen esetben javasolt felkeresni az man:ssh-keygen[1] man oldalát.
====

[[security-ssh-agent]]
=== Az ssh-agent és az ssh-add

Az man:ssh-agent[1] és man:ssh-add[1] segédprogramokkal be tudjuk tölteni az SSH-kulcsokat a memóriába, amivel elkerülhetjük a jelmondat állandó begépelését.

A hitelesítést az man:ssh-agent[1] program kezeli a betöltött privát kulcsok alapján. Az man:ssh-agent[1] használatával egy másik programot is elindhatunk, egy parancsértelmezõtõl kezdve egy ablakkezelõig szinte bármit.

Az man:ssh-agent[1] programot úgy tudjuk egy parancsértelmezõben használni, hogy elõször is elindítjuk vele az adott parancsértelmezõt. Ezután az man:ssh-add[1] lefuttatásával hozzá kell adnunk egy identitást, annak jelmondatának megadásával. Miután ezeket megtettük, a felhasználó bármelyik olyan távoli gépre be tud jelentkezni, ahol a publikus kulcsát ismerik. Például:

[source,shell]
....
% ssh-agent csh
% ssh-add
Enter passphrase for /home/felhasználó/.ssh/id_dsa:
Identity added: /home/felhasználó/.ssh/id_dsa (/home/felhasználó/.ssh/id_dsa)
%
....

Az man:ssh-agent[1] programot X11-el úgy tudjuk használni, ha az [.filename]#~/.xinitrc# állományba tesszük bele. Ezzel az man:ssh-agent[1] az összes X11-ben indított program számára rendelkezésre áll. Példának vegyük ezt az [.filename]#~/.xinitrc# állományt:

[.programlisting]
....
exec ssh-agent startxfce4
....

Így az X11 indulásakor mindig elindul az man:ssh-agent[1], amely pedig elindítja az XFCE alkalmazást. Miután átírtuk a saját állományunkat, a rendszer életbeléptetéséhez indítsuk újra az X11-et, az man:ssh-add[1] futtatásával pedig töltsük be az összes SSH-kulcsunkat.

[[security-ssh-tunneling]]
=== Tunnelezés SSH-val

Az OpenSSH-val létre tudunk hozni egy tunnelt, amellyel egy másik protokoll adatait tudjuk titkosított módon becsomagolni.

Az alábbi parancs arra utasítja az man:ssh[1] programot, hogy hozzon létre egy tunnelt a telnet használatához:

[source,shell]
....
% ssh -2 -N -f -L 5023:localhost:23 felhasználó@izé.mizé.hu
%
....

Az `ssh` parancsnak a következõ kapcsolókat adtuk meg:

`-2`::
Az `ssh` parancs a protokoll második változatát használja. (Ne adjuk meg, ha régi SSH szerverekkel dolgozunk.)

`-N`::
Tunnel létrehozása. Ha nem adjuk meg, akkor az `ssh` egy hagyományos munkamenet felépítését kezdi meg.

`-f`::
Az `ssh` a háttérben fusson.

`-L`::
Egy helyi tunnel a _helyiport:távoligép:távoliport_ felírásban.

`felhasználó@izé.mizé.hu`::
A távoli SSH szerver.

Az SSH által létrehozott járatok úgy mûködnek, hogy létrehozunk egy csatlakozást a `localhost` (a helyi gép) megadott portján. Ezután minden olyan kapcsolatot, ami a helyi gép adott portjára érkezik, SSH-n keresztül átirányítunk a távoli gép portjára.

Ebben a példában a helyi gép _5023_ portját átirányítjuk a helyi gép _23_ portjára. Mivel a _23_ a telnet portja, ezért az így definiált SSH járattal egy biztonságos telnet munkamenetet hozunk létre.

Ezen a módon tetszõleges nem biztonságos TCP protokollt, például SMTP-t, POP3-at, FTP-t stb. be tudunk csomagolni.

.Biztonságos tunnel létrehozása SSH-val SMTP-hez
[example]
====

[source,shell]
....
% ssh -2 -N -f -L 5025:localhost:25 felhasználó@levelező.szerver.hu
felhasználó@levelező.szerver.hu's password: *****
% telnet localhost 5025
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 levelező.szerver.hu ESMTP
....
Az man:ssh-keygen[1] és további felhasználói hozzáférések alkalmazásával ezen a módon ki tudunk alakítani egy minden további problémától és zûrtõl mentes SSH tunnelezési környezetet. A jelszavak helyett kulcsokat használunk és minden tunnel külön felhasználóként is futtatható.

====

==== Gyakorlati példák a tunnelek használatára

===== Egy POP3 szerver biztonságos elérése

Tegyük fel, hogy a munkahelyünkön van egy SSH szerver, amire kívülrõl lehet csatlakozni, illetve vele egy hálózatban van egy POP3 levelezõ szerver is. A munkahelyünk és az otthonunk között levõ hálózati útvonalat részben vagy teljesen nem tartjuk megbízhatónak. Ezért az e-mailjeinket valamilyen biztonságos módon szeretnénk elérni. Ezt úgy tudjuk megvalósítani, ha otthonról csatlakozunk a munkahelyen levõ SSH szerverre és ezen keresztül érjük a levelezõ szervert.

[source,shell]
....
% ssh -2 -N -f -L 2110:levél.gép.hu:110 felhasználó@ssh-szerver.gép.hu
felhasználó@ssh-szerver.gép.hu's password: ******
....

Miután a tunnel létrejött és mûködõképes, állítsuk be a levelezõ kliensünkben, hogy a POP3 kéréseket a `localhost` 2110 portjára küldje. Innen pedig biztonságos módon megy tovább a `levél.gép.hu` címre.

===== Egy szigorú tûzfal megkerülése

Egyes hálózati adminisztrátorok túlságosan szigorú szabályokat adnak meg a tûzfalban, és nem csak a bejövõ kapcsolatokat szûrik, hanem a kimenõket is. A távoli gépekhez csak a 22 (SSH) és 80 (böngészés) portjaikon tudunk csatlakozni.

Mi viszont szeretnénk más (nem egészen a munkánkkal kapcsolatos) szolgáltatásokat is elérni, például egy Ogg Vorbis szerverrõl zenét hallgatni. Ehhez a szerverhez viszont csak akkor tudnánk csatlakozni, ha a 22 vagy 80 portokon üzemelne.

Ezt a problémát úgy oldhatjuk meg, ha felépítünk egy SSH kapcsolatot a hálózatunk tûzfalán kívül levõ számítógéppel és segítségével átbújunk az Ogg Vorbis szerverhez.

[source,shell]
....
% ssh -2 -N -f -L 8888:zene.gép.hu:8000 felhasználó@tűzfalazatlan-rendszer.gép.org
felhasználó@tűzfalazatlan-rendszer.gép.org's password: *******
....

A zenelejátszó kliensüknek adjuk meg a `localhost` 8888 portját, amely pedig a tûzfal sikeres kijátszásával továbbítódik a `zene.gép.hu` 8000-res portjára.

=== Az `AllowUsers` felhasználói beállítás

Gyakran nem árt korlátozni a felhasználók bejelentkezését. Az `AllowUsers` erre tökéletesen megfelel. Például, ha csak `192.168.1.32` címrõl engedjük bejelentkezni a `root` felhasználót, akkor ehhez valami ilyesmit kell beírnunk az [.filename]#/etc/ssh/sshd_config# állományba:

[.programlisting]
....
AllowUsers root@192.168.1.32
....

Ezzel pedig csupán nevének megadásával engedélyezzük az `admin` felhasználó bejelentkezését (bárhonnan):

[.programlisting]
....
AllowUsers admin
....

Egy sorban több felhasználó is megadható, mint például:

[.programlisting]
....
AllowUsers root@192.168.1.32 admin
....

[NOTE]
====
Ilyenkor ne felejtsük el megadni az összes bejelentkezésre (valamilyen formában) jogosult felhasználót megadni, máskülönben kizárjuk ezeket.
====

Miután elvégeztük a szükséges változtatásokat az [.filename]#/etc/ssh/sshd_config# állományban, utasítsuk az man:sshd[8] démont a konfigurációs állományok újraolvasására:

[source,shell]
....
# /etc/rc.d/sshd reload
....

=== Ajánlott olvasnivalók (angolul)

http://www.openssh.com/[OpenSSH]

man:ssh[1] man:scp[1] man:ssh-keygen[1] man:ssh-agent[1] man:ssh-add[1] man:ssh_config[5]

man:sshd[8] man:sftp-server[8] man:sshd_config[5]

[[fs-acl]]
== Az állományrendszerek hozzáféréseit vezérlõ listák

A FreeBSD 5.0 és késõbbi változatai különbözõ fejlesztéseket hoztak az állományrendszerekben, például a pillanatképek készítése vagy a hozzáférés-vezérlési listák (Access Control List, ACL-ek) támogatása.

A hozzáférés-vezérlési listák a szabványos UNIX(R)-os engedély modellt bõvítik ki egy igen kompatibilis (POSIX(R).1e) módon. Használatával a rendszergazdák egy sokkal kifinomultabb biztonsági modellt tudhatnak a kezük ügyében.

Az UFS állományrendszerek ACL támogatását úgy tudjuk engedélyezni, ha a rendszermagot az

[.programlisting]
....
options UFS_ACL
....

paraméterrel fordítjuk le. Amennyiben ezt nem fordítottuk bele, akkor az ACL támogatással rendelkezõ állományrendszerek csatlakoztatása során egy figyelmeztetést kapunk. Ez az opció a [.filename]#GENERIC# rendszermag része. Az ACL az állományrendszeren engedélyezett kiterjesztett tulajdonságokra támaszkodik. Ezeket a kiterjesztett tulajdonságokat a következõ generációs UNIX(R) állományrendszer, az UFS2 már alapból ismeri.

[NOTE]
====
UFS1 típusú állományrendszereken sokkal nagyobb a kiterjesztett tulajdonságok kezelésének költsége, mint az UFS2 esetében. Az UFS2 jóval nagyobb teljesítménnyel képes dolgozni a kiterjesztett tulajdonságokkal. Emiatt a hozzáférés-vezérlési listák használatához az UFS2 sokkal inkább ajánlott, mint az UFS1.
====

Az ACL használatát a csatlakoztatáskor megadott `acls` beállítással engedélyezhetjük, amelyet érdemes felvennünk az [.filename]#/etc/fstab# állományba. Ha a man:tunefs[8] segédprogrammal az állományrendszer fejlécében levõ szuperblokk ACL kapcsolóját átírjuk, akkor ez a beállítás automatikussá tehetõ. A szuperblokk használata több okból is ajánlatos:

* A csatlakoztatáskor megadott ACL beállítás nem változtatható egy egyszerû újracsatlakoztatással (man:mount[8] `-u`), csak egy teljes leválasztással (man:umount[8]) és egy friss csatlakoztatással (man:mount[8]). Ennek értelmében az ACL-ek a rendszerindító állományrendszeren a rendszer indulása után nem engedélyezhetõek. Ám ez azt is jelenti, hogy egy már használatban levõ állományrendszer beállításai sem változtathatóak meg.
* Ha a kapcsolót a szuperblokkban állítjuk be, akkor az állományrendszert még akkor is ACL támogatással csatlakoztatja a rendszer, ha azt nem adtuk meg az [.filename]#fstab# állományban vagy az eszközeink átrendezõdtek. Így az állományrendszereket még véletlenül sem tudjuk ACL használata nélkül csatlakoztatni, ami egyébként így komoly biztonsági problémákat okozhatna.

[NOTE]
====
Beállíthatjuk úgy is ACL kezelését, hogy egy friss csatlakoztatás nélkül is bekapcsolható legyen, azonban az ilyen állományrendszerek ACL nélküli csatlakoztatását nem ajánljuk senkinek, mivel ha egyszer már engedélyeztük a használatukat, majd kikapcsoljuk ezeket és végül a kiterjesztett tulajdonságok törlése nélkül újra engedélyezzük, akkor nagyon könnyen pórul járhatunk. Ha elkezdtük használni az ACL-eket egy állományrendszeren, akkor ne tiltsuk le ezeket, mert az így keletkezõ állományvédelem nem feltétlenül lesz kompatibilis a felhasználók által beállítottakkal, és az ACL újraengedélyezése a változásaik elõtti korábbi ACL engedélyeket fogja visszaállítani az állományokra, aminek hatása kiszámíthatatlan.
====

A hozzáférés-vezérlési listákat használó állományrendszerek esetén egy `+` (plusz) jellel ábrázolják a kiterjesztett engedélyeket. Például:

[.programlisting]
....
drwx------  2 robert  robert  512 Dec 27 11:54 private
drwxrwx---+ 2 robert  robert  512 Dec 23 10:57 könyvtár1
drwxrwx---+ 2 robert  robert  512 Dec 22 10:20 könyvtár2
drwxrwx---+ 2 robert  robert  512 Dec 27 11:57 könyvtár3
drwxr-xr-x  2 robert  robert  512 Nov 10 11:54 public_html
....

Láthatjuk, hogy a [.filename]#könyvtár1#, [.filename]#könyvtár2# és [.filename]#könyvtár3# könyvtárakhoz tartoznak ACL típusú engedélyek, míg a [.filename]#public_html# könyvtárhoz nem.

=== Az ACL-ek használata

Az állományrendszerben található ACL engedélyeket a man:getfacl[1] segédprogrammal nézhetjük meg. Például a [.filename]#próba# állomány ACL engedélyeit a következõ paranccsal tudjuk megnézni:

[source,shell]
....
% getfacl próba
	#file:próba
	#owner:1001
	#group:1001
	user::rw-
	group::r--
	other::r--
....

Egy állomány ACL engedélyeit a man:setfacl[1] segédprogrammal tudjuk megváltoztatni. Figyeljük meg:

[source,shell]
....
% setfacl -k próba
....

A `-k` opció törli az összes ACL alapú engedélyt egy állományról vagy állományrendszerrõl. Ennél viszont sokkal hasznosabb a `-b` opció használata, mivel az meghagyja az ACL mûködéséhez szükséges alapvetõ mezõket.

[source,shell]
....
% setfacl -m u:trhodes:rwx,group:web:r--,o::--- próba
....

Ebben a fenti parancsban a `-m` opciót pedig arra használtuk, hogy módosítsuk az alapértelmezett ACL bejegyzéseket. Mivel az ezt megelõzõ parancsban teljesen töröltük még az elõredefiniált bejegyzéseket is, ez a parancs a megadott paraméterekkel kiegészítve ezeket vissza fogja állítani. Ügyeljünk arra, hogy ha olyan felhasználót vagy csoportot adunk meg, ami nem létezik a rendszerben, akkor a szabvány kimenetre egy `Invalid argument` hibaüzenetet kapunk.

[[security-portaudit]]
== A külsõ programok biztonsági problémáinak figyelése

Az utóbbi években a biztonsági kérdésekkel foglalkozó világban számos fejlesztésre került sor a sebezhetõségi figyelmeztetések feldolgozásában. Manapság tulajdonképpen bármilyen operációs rendszer fokozott veszélynek teszik ki magát a külsõ programok telepítésével és használatával.

A sebezhetõségekrõl beszámoló értesítések a biztonság egyik alapköve, azonban a FreeBSD projekt nem tud ilyen jelentéseket kiadni a FreeBSD alaprendszerén kívül minden egyes külsõ alkalmazáshoz. Azonban lehetõségünk van enyhíteni a külsõ csomagok sebezhetõségén és figyelmeztetni a rendszergazdákat az ismert biztonsági problémákra. A FreeBSD-nek van egy Portaudit nevû segédprogramja, amit kizárólag erre a célra hoztak létre.

A package:ports-mgmt/portaudit[] port egy adatbázist használ, ahol a FreeBSD biztonsági csapata és a portok fejlesztõi tartják karban az ismert biztonsági problémákat.

A Portaudit használatának megkezdéséhez telepítsük a Portgyûjteménybõl:

[source,shell]
....
# cd /usr/ports/ports-mgmt/portaudit && make install clean
....

A telepítési folyamat során a man:periodic[8] konfigurációs állományai is frissítõdnek, így a Portaudit is lefut a napi biztonsági ellenõrzések folyamán. Gondoskodjunk róla, hogy a `root` felhasználónak levélben elküldött a napi biztonsági értesítéseket rendesen elolvassuk. Nincs szükségünk további beállításokra.

A telepítés után a rendszergazda a következõ paranccsal tudja frissíteni a saját adatbázispéldányát és megnézni a pillanatnyilag telepített csomagok ismert sebezhetõségeit:

[source,shell]
....
# portaudit -Fda
....

[NOTE]
====
Ez az adatbázis a man:periodic[8] minden egy futásakor magától frissül, ezért ez a parancs lényegében elhagyható. Egyedül a soronkövetkezõ példákhoz kell kiadni.
====

A Portgyûjteménybõl telepített külsõ alkalmazások megbízhatóságának ellenõrzését az alábbi parancs kiadásával bármikor elvégezhetjük:

[source,shell]
....
# portaudit -a
....

A Portaudit ennek hatására valahogy így fogja megjeleníteni a sebezhetõ csomagokat:

[.programlisting]
....
Affected package: cups-base-1.1.22.0_1
Type of problem: cups-base -- HPGL buffer overflow vulnerability.
Reference: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html>

1 problem(s) in your installed packages found.

You are advised to update or deinstall the affected package(s) immediately.
....

Fordítása:

[.programlisting]
....
Érintett csomag: cups-base-1.1.22.0_1
A probléma jellege: cups-base -- HPGL puffer túlcsordulási sebezhetõség.
Link: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html>

A telepített csomagokkal kapcsolatban 1 problemát találtam.

Javasoljuk, hogy az érintett csomagokat azonnal frissítse vagy távolítsa el.
....

Ha a böngészõnket az itt megadott címre irányítjuk, akkor megismerhetjük a kérdéses sebezhetõség pontosabb részleteit. Ezen az oldalon megtalálhatjuk a hiba által érintett verziókat a FreeBSD portok verziója szerint, illetve más olyan honlapokat, ahol biztonsági figyelmeztetéseket találhatunk.

Röviden összefoglalva, a Portaudit egy komoly segédeszköz és hitetlenül hasznos kiegészítõje a Portupgrade portnak.

[[security-advisories]]
== A FreeBSD biztonsági figyelmeztetései

A FreeBSD több más kereskedelmi minõségû operációs rendszerhez hasonlóan "Biztonsági figyelmeztéseket" (Security Advisory) ad ki. Ezek a figyelmeztetések általában megjelennek a biztonsággal foglalkozó levelezési listákon és a hivatkozott hibák kijavítása után a megfelelõ kiadások hibajegyzékében is. Ebben a szakaszban megismerjük és értelmezzük ezeket a figyelmeztetéseket, valamint megtudhatjuk, milyen lépéseket kell megtennünk a rendszerünk kijavításához.

=== Hogyan épül fel egy figyelmeztetés?

A FreeBSD biztonsági figyelmeztetései az alább látható formában jelennek meg, amit mi most a {freebsd-security-notifications} levelezési listáról kölcsönöztünk.

[.programlisting]
....
=============================================================================
FreeBSD-SA-XX:XX.UTIL                                     Security Advisory
                                                          The FreeBSD Project

Topic:          denial of service due to some problem<.>

Category:       core<.>
Module:         sys<.>
Announced:      2003-09-23<.>
Credits:        Person@EMAIL-ADDRESS<.>
Affects:        All releases of FreeBSD<.>
                FreeBSD 4-STABLE prior to the correction date
Corrected:      2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE)
                2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6)
                2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15)
                2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8)
                2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18)
                2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21)
                2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33)
                2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43)
                2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39)<.>
CVE Name:	CVE-XXXX-XXXX<.>

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
http://www.FreeBSD.org/security/.

I.   Background<.>

II.  Problem Description<.>

III. Impact<.>

IV.  Workaround<.>

V.   Solution<.>

VI.  Correction details<.>

VII. References<.>
....

<.> A `Topic` mezõben olvashatjuk pontosan mi is maga a probléma. Alapvetõen bemutatja az érintett biztonsági figyelmeztetést és megemlíti a sebezhetõ segédprogramot.

<.> A `Category` mezõ hivatkozik a rendszer azon részére, amelyre a hiba kihatással lehet. Értéke lehet `core`, `contrib` vagy `ports`. A `core` kategória azt jelzi, hogy a sebezhetõség a FreeBSD legfontosabb komponenseit érinti. A `contrib` kategória a FreeBSD projekt számára felajánlott szoftverek, mint például a sendmail sebezhetõségére utal. Végezetül a `ports` kategória jelzi, hogy a sebezhetõség valamelyik, a Portgyûjteményben szereplõ szoftverre érvényes.

<.> A `Module` mezõ a sebezhetõ komponens helyét nevezi meg, például `sys`. Ebben a példában azt láthatjuk, hogy a `sys` modul a hibás. Ezért a sebezhetõség egy rendszermagban használt komponenst érint.

<.> Az `Announced` mezõ a biztonsági figyelmeztetés kiadásának vagy széleskörû kihirdetésének dátumát rögzíti. Ez azt jelenti, hogy a biztonsági csapat meggyõzõdött a probléma létezésérõl és a hibát orvosoló javítás már felkerült a FreeBSD forráskódjába.

<.> A `Credits` mezõ azokat az egyéneket vagy szervezeteket említi meg, akik észlelték a sebezhetõséget és jelentették.

<.> Az `Affects` mezõben megadják, hogy a FreeBSD melyik kiadásaira van hatással a sebezhetõség. Ha a rendszermag esetén lefuttatjuk az `ident` parancsot az érintett állományokra, akkor megtudhatjuk a pontos revíziójukat. A portoknál a verziószám a port neve után szerepel a [.filename]#/var/db/pkg# könyvtárban. Ha a rendszerünket nem frissítettük CVS-rõl és fordítottuk újra, akkor nagy a valószínûsége, hogy a sebezhetõség minket is érint.

<.> A `Corrected` mezõ tartalmazza a a kijavítás dátumát, idejét, idõzónáját és az ezt tartalmazó kiadást.

<.> Az ismert sebezhetõségek adatbázisában (Common Vulnerabilities Database, CVD) használt azonosítási információk alapján végzett keresések számára fenntartott.

<.> A `Background` mezõ adja meg részleteiben a sebezhetõ programmal kapcsolatos tudnivalókat. Az esetek többségében itt írják le, hogy miért jött létre az adott eszköz a FreeBSD-ben, mire használják és hogyan keletkezett.

<.> A `Problem Description` mezõ a biztonsági rést részletezi. Ebben a részben szerepelhet a hibás kódrészlet vagy akár még az is, hogy miként kell vele elõidézni a hibát.

<.> Az `Impact` mezõ a probléma lehetséges hatásait írja körül a rendszerben. Ez például lehet egy DoS támadás, speciális engedélyek ellopása vagy akár a rendszeradminisztrátori jogok megszerzése.

<.> A `Workaround` mezõ igyekszik elfogadható megoldást nyújtani a rendszerük frissítésére képtelen rendszergazdák számára. Ennek oka lehet az idõ rövidsége, a hálózati elérhetõség vagy más okokból fakadó elcsúszás. Ennek ellenére a biztonsági kérdéseket sosem szabad félvállról venni, ezért a sebezhetõ rendszereket vagy ki kell javítani vagy valamilyen módon meg kell kerülni a biztonsági rés kialakulását.

<.> A `Solution` mezõ utasításokkal segít a rendszer kijavítását. Ez egy lépésrõl lépésre tesztelt és ellenõrzött módszer, amellyel a rendszerünket megfelelõen ki tudjuk javítani és biztonságossá tenni.

<.> A `Correction Details` mezõ mutatja a CVS-ág vagy kiadás nevét, amelyben a pontokat aláhúzásra cserélték. Ezenkívül még az egyes ágakban az érintett állományok revízióját is mutatja.

<.> A `References` mezõ általában a témával kapcsolatos további forrásokat kínálja fel URL, könyv, levelezési lista vagy hírcsoport formájában.

[[security-accounting]]
== A futó programok nyilvántartása

A futó programok nyilvántartása olyan biztonsági módszer, ahol a rendszergazda figyelemmel kíséri a rendszer használatban levõ erõforrásait, a felhasználók közti megoszlását, gondoskodik a rendszer felügyeletérõl és valamennyire nyomon követi a felhasználók parancsait.

Ennek a módszernek egyaránt megvannak a maga elõnyei és hátrányai. Az egyik elõnye, hogy a használatával a behatolás egészen a betörés pontjáig visszakövethetõ. Hátranya viszont, hogy a futó programok nyilvántartása rengeteg mennyiségû naplót generál és ehhez sok lemezterületre lesz szükségünk. Ebben a szakaszban végigjárjuk a programok nyilvántartásának alapjait.

=== A futó programok nyilvántartásának engedélyezése és használata

A futó programok nyilvántartását elõször engedélyeznünk kell. Ehhez a következõ parancsokat kell kiadnunk:

[source,shell]
....
# touch /var/account/acct

# accton /var/account/acct

# echo 'accounting_enable="YES"' >> /etc/rc.conf
....

Miután aktiváltuk, a nyilvántartást elkezdi számbavenni a processzor kihasználtságát, a parancsokat stb. A nyilvántartás emberek számára nem olvasható formátumban készül, ezért csak az man:sa[8] segédprogrammal tudjuk megnézni. Ha nem adunk meg neki semmilyen opciót, akkor az `sa` kilistázza a felhasználónkénti hívásokat, az összes eltelt idõt percben, a teljes processzor- és felhasználói idõt percben, az I/O mûveletek átlagos számát stb.

A kiadott parancsokról a man:lastcomm[1] programmal tudunk tájékozódni. A `lastcomm` segítségével ki tudjuk íratni a felhasználók adott terminálon kiadott parancsait is, mint például:

[source,shell]
....
# lastcomm ls
	trhodes ttyp1
....

Ezzel megjelenik a `trhodes` nevû felhasználó `ttyp1` terminálon kiadott összes ismert `ls` parancsa.

Számos hasznos beállítást és hozzájuk tartozó leírást találhatunk még a man:lastcomm[1], man:acct[5] és man:sa[8] man oldalakon.