14.6. A TCP kapcsolatok burkolása
Vissza | 14. fejezet - Biztonság | Előre

## 14.6. A TCP kapcsolatok burkolása

Írta: Rhodes, Tom.

Aki ismeri az 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 inetd beállításával kapcsolatos tudnivalók ismeretét.

### Megjegyzés:

Bár az 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.

### 14.6.1. 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 `rc.conf` állományból. Az egyébként az alapbeállítás. Természetesen nem árt, ha helyesen állítjuk be az `/etc/hosts.allow` állományt is, ellenkező esetben a syslogd(8) egyébként dobálni fogja erről az üzeneteket.

### Megjegyzés:

Eltérően a TCP burkolók egyéb implementációitól, a `hosts.deny` állományt itt már nem használjuk. Minden beállítást az `/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 `/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 `mail/qpopper` démonon keresztül, akkor a következő sorral kell kiegészítenünk a `hosts.allow` állományt:

# 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 kill(1) paranccsal, vagy pedig az `/etc/rc.d/inetd` szkript `restart` paraméterével tehetjük meg.

### 14.6.2. 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.

#### 14.6.2.1. 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 `hosts.allow` állományban:

# 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.

### Figyelem:

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:

# 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 `/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 hosts_access(5) man oldalon találhatjuk meg a teljes listát.

#### 14.6.2.2. 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:

# 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.

### Figyelem:

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 hosts_access(5) man oldalon tájékozódhatunk.

A `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.

Vissza | Fel | Előre
14.5. Egyszeri jelszavak | Főoldal | 14.7. KerberosIV

Ha kérdése van a FreeBSD-vel kapcsolatban, a következő címre írhat (angolul): <questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon: <gabor@FreeBSD.org>.