Xinetd alapozó

A Xinetd gondnok, aki kezeli a számítógépéhez az internetről való hozzáférést. Ez egy démon, amely állandóan fut, és minden porton figyeli a csatlakozási vagy szolgáltatási igényeket. Ha nem szervert futtat, akkor nem kell a xinetd-re. Még akkor is, ha a számítógépet csak otthoni használatra szánják, a jövőben esetleg engedélyeznie kell mások számára a számítógépen elérhető szolgáltatásokhoz való hozzáférést. Amikor megteszed, telepítenie kell az xinetd szoftvert, hogy megvédje számítógépét a rosszindulatú tevékenységektől.

Operációs rendszer

A xinetd segédprogramot az Unix és az Unix-szerű rendszerek számára írták. Tehát telepíti Linuxra és Mac OS-re, de nem Windows-ra. A program ingyenesen használható, és a GitHubból elérhető.

Ebből a főtárból megszerezheti a programot, és van egy kód villája is. Ez egy jól ismert és megbízható program, amelyet többször letöltöttek és telepítettek, ezért ne aggódjon a program rosszindulatú hamisításának veszélye miatt..

A xinetd célja

A xinet rendszer célja, hogy mint: egy szerver. Valószínűleg tudja, hogy egy tipikus internetkapcsolatnál az egyik számítógép kapcsolatba lép a másikkal. A kapcsolatot kezdeményező számítógépet „ügyfélÉs a kapcsolatba lépő program a „szerver.A kapcsolat szokásos oka az, hogy az ügyfél szolgáltatást kapjon a szerverről. A megkeresett számítógépnek azonban futó programnak kell lennie, és várnia kell a kéréseket. Ez a xinetd függvénye.

Az xinetd alapvető követelménye, hogy kéréseket fogadjon és továbbítson a megfelelő alkalmazáshoz, amelyet a portszám jelöl, amelyet az érkező kapcsolat vagy szolgáltatási kérés fejlécébe írnak. A xinetd program valójában nem biztosítja a kért szolgáltatást, hanem kapuőrként működik.

Alternatívák: Xinetd vs inetd

A xinetd fejlesztői nem voltak az elsők, akik olyan programra gondoltak, amely a hálózaton figyeli a bejövő kéréseket. Valójában a xinetd célja az eredeti program javítása, amely végrehajtotta ezt a feladatot, amelyet inetd-nek hívnak.

A „xinetd” név a „kiterjesztett internetes szolgáltatások démon”. Az „Internet Services démon” leírja az eredeti példányt inetd. Az inetd használatával ugyanazt a kiszolgáló kérést kapja, amelyet az xinetd biztosít. Ennek a démonnak azonban nincs védekezési mechanizmusa, ezért most bizonytalannak tekintik.

A régi inetd nem működött egyedül. A kéréseket továbbította tcpd, amely ellenőrizte az engedélyeket tartalmazó fájlokat (hosts.allow és hosts.deny). Ahogy a neve is sugallja, a tcpd kezeli a TCP csatlakozási kérelmeket. Ugyanakkor az UDP-portokat is megvizsgálja, tehát egy Transport Layer interfész megvalósítás. Lehet, hogy említést tesz egy TCP-csomagolóról is – ez csak egy újabb név a tcpd számára. A tcpd beillesztése javította a hozzáférés-vezérlést. Az engedélyezési folyamatot azonban két, kézzel kitöltött fájl hajtotta végre, és így nem volt túl átfogó biztonsági megoldás.

Xinetd jellemzői

A xinetd működési mód hasonló az inetd és a tcpd kombinációjának működéséhez. A xinetd megoldás azonban sokkal jobb biztonsági tulajdonságokkal rendelkezik, mint az inetd / tcpd kombináció. A démon jellemzői a következők:

• TCP és UDP hozzáférés-vezérlés
• eseménynaplózás, amely rögzíti a kapcsolat sikerét és kudarcát
• hozzáférés-vezérlés az időszegmensek alapján
• egyidejű szerver korlátozása – Szolgáltatásmegtagadási (DoS) támadásvédelem
• naplófájl méretkorlátja
• szolgáltatások felosztása különböző interfészekre, lehetővé téve bizonyos szolgáltatások korlátozását a magánhálózaton
• proxy funkció, beleértve a hálózati cím fordítását

A Xinetd közvetítőként képes működni RPC szolgáltatások. Ezt a funkciót azonban nem igazán hajtják végre. Az RPC biztonsági jellemzőinek hiánya csökkentette a szolgáltatáshoz való hozzáférés iránti igényt, ezért kétséges, hogy a xinetd fejlesztői időt töltenek az RPC felület tökéletesítésére.

Hozzáférés-ellenőrzési módszerek

Mint az inetd, a xinetd lehetővé teszi a kapcsolatok engedélyezését vagy blokkolását a kérelmező IP-címe szerint. Az inetd segítségével azonosíthatja az engedélyezett és a blokkolt kapcsolati forrásokat hostnév vagy domain név alapján. Ezen opciók mindegyikéhez keresési eljárás szükséges. A hostnevek opció esetén ezeket a neveket be kell állítania a saját hálózatának DNS-rendszerében. A domainek esetében valószínűleg jobb lenne, ha támaszkodna a nyilvános DNS-rendszerre.

Ön dönti el, hogy azonosítja-e a kérelmezőket IP-cím, gazdagépnév vagy domain név alapján. azonban, Az IP-címmel való ragasztás gyorsabb kapcsolatot teremt mert kiküszöböli a keresési szakasz szükségességét.

Rendszerbeállítások

A xinetd használatához először telepítenie kell, majd azután frissítse a konfigurációs fájlt. Alapvetően a konfigurációs fájl az xinetd parancsközpontja. Mivel ez a program démon, miután elindította, örökké továbbra is működni fog. Ez nem egy interaktív segédprogram, amelyet beállíthat a parancssorban. A programmal folytatott minden kommunikáció a konfigurációs fájlon keresztül történik.

A démon továbbra is ellenőrzi a konfigurációs fájlt, amikor kérést kap a külvilágtól. Az indításkor nem tölti be a konfigurációt a memóriába. Azt jelenti beállíthatja a démon teljesítményét futás közben a konfigurációs fájlban található utasítások megváltoztatásával.

A xinet konfigurációs fájlja sokkal fontosabb, mint a többi segédprogram konfigurációs rendszerei. Ennek oka az, hogy a konfiguráción keresztül módosíthatja a démon utasításait anélkül, hogy le kellene állítania a xinetd programot, és újra kell indítania..

A konfigurációs fájl beállítása

Keresse meg a fájlt /etc/xinetd.conf. Ez a program fő konfigurációs fájlja, és egy keresési táblázatként működik, amelyet az alkalmazás olvassa el annak meghatározása érdekében, hogy mely kapcsolatok engedélyezhetők és mely szolgáltatások hívhatók fel..

Az xinetd.conf fájlt létrehozhat egy meglévőből inetd.conf fájl a xconv.pl program, amely annak a csomagnak a része, amelyet letölthet a GitHub tárházból az xinetd számára. Futtassa a konvertáló programot a következő paranccsal:

/usr/local/sbin/xconv.pl < /etc/inetd.conf-ban > /etc/xinetd.conf

Az új konfigurációs fájl nem tökéletes és további módosítást igényel, mielőtt elindíthatja a xinetd programot.

A konfigurációs fájl alapértelmezett szakasza

Az újonnan létrehozott xinetd.conf fájl betekintésekor két kulcskonfigurációs szakaszra kell összpontosítania. Ezek közül az első a alapértelmezett szakasz, és a második a szolgáltatások szakasz.

Mint valószínűleg már kitalálta, az alapértelmezett szakasz megmondja a xinetd-nek, hogy mit kell tenni, ha nem talál konkrét utasításokat jelenlegi feladatához a szolgáltatási szakaszban.

Az alapértelmezett szakaszban beállítható néhány kulcsfontosságú lehetőség:

• only_from
• nincs hozzáférés
• log_type
• log_on_success
• log_on_failure
• példányok
• per_source

A következő szakaszok részletesebben ismertetik ezeket a lehetőségeket.

Hozzáférési feltételek

Only_from és nincs hozzáférés hatékonyan hajtja végre ugyanazt a feladatot, vagyis blokkolja (nincs hozzáférés) vagy engedélyezze (csak_aktól) meghatározott címet vagy címsorozatokat. Javasoljuk ezen lehetőségek egyikét, hogy alapértelmezés szerint mindent blokkoljon, majd a konfigurációs fájlban lefelé állítsa össze a szolgáltatások listáját. Ezzel a stratégiával fedezheti magát, ha olyan esemény történik, amelyhez még nem számolt be.

Ez a két lehetőség is érvényes parancs, amelyet fel kell venni a szolgáltatási szakaszba. Szóval te meg tudod kezdje el mindent alapértelmezés szerint betiltani, majd vegyen fel szolgáltatásokat. Ha van egy szolgáltatási szakasz, amely kapcsolódik az xinetd által megkapott kapcsolódási kérelem típusához, akkor nem fogja megnézni a konfiguráció alapértelmezett szakaszát.

A szolgáltatás leírásában a only_from és no_access utasításai felülbírálják az only_from és no_access utasításokat az alapértelmezés szakaszban.

E két lehetőség formátuma:

=

Ne feledje, hogy a címek IP-címekként, gazdanevekként vagy tartománynevekként is kifejezhetők. Jobb azonban, ha ragaszkodunk az IP-címekhez. A tartomány meghatározásához használhatja a CIDR jelölést. Íme két példa arra, hogyan használhatja ezeket a lehetőségeket:

no_access = 0.0.0.0/0

Ez valószínűleg a leggyakoribb sor az alapértelmezett szakaszban, mert mindenkit blokkol. Az alapértelmezett szakasz csak a konfigurációs fájlban található, hogy megmondja a xinetd-nek, hogy mit kell tenni olyan szolgáltatási igény esetén, amelyre a szolgáltatási szakasz nem vonatkozik. Feltételeznie kell, hogy minden utasításhoz képes lesz megadni minden olyan szolgáltatástípust, amelyet a számítógép nyújt, ezért ésszerű kijelenteni, hogy minden más kérés blokkolva van. Ahogyan egy exkluzív VIP partiján ajtónosa azt mondta: “Ha nem szerepel a listán, akkor nem lép be.”

Ennek a stratégiának egy alternatívája, ha mindenkit be enged. Ezt a következőkkel valósíthatja meg:

only_from = 0.0.0.0/0

Ez az irányelv nem igazán értelmes az alapértelmezés szakaszban. Az alapértelmezett szakaszra csak akkor hivatkozunk, ha még nem adott be utasításokat egy szolgáltatásra, tehát amikor a xinetd az alapértelmezésekhez folyamodik, van egy olyan eset, amelyben nem rendelkezik erre vonatkozó utasításokkal. Tehát ha a hozzáférés engedélyezése ilyen körülmények között hibát eredményezne, mert nem mondtad a xinetd-nek, hogy mit tegyen a kéréssel. Logikus ezt a “csak mindenki számára” opciót használni a szolgáltatás leírásában, tehát ez az üzenet azt mondja, hogy az xinetd engedélyezze az összes lehetséges forrás kérését a szolgáltatás használatához..

Sajnos van a only_from és no_access opciók olyan funkciója, amely konfliktust idézhet elő, ha a fent leírt irányelvet végrehajtja. Ez az, mind a no_access, mind a only_from globálisak és a xinetd mindkettőt ellenőrzi, amikor végre kell hajtania egy feladatot. Tehát ha mindkettőt beállította, a démon ellenőrzi a bejövő kérést a no_access utasítás alapján az alapértelmezett szakaszban, még akkor is, ha érvényes szolgáltatáskonfiguráció van beállítva.

Ez a no_access és csak_a globális létezés kérdése kiküszöbölhető, ha a következő politikáról döntünk csak az egyiket használja a xinetd.conf fájlban. Általános gyakorlat, hogy a only_from-on maradnak, és figyelmen kívül hagyják a no_access beállítást. Kizárólag a „mindenki számára” utasítást hozhat létre úgy, hogy a címlistát az alapértelmezett szakaszban üresen hagyja, azaz „only_from = ”És ez lehetővé teszi, hogy a xinetd program használja a only_from beállítást a szolgáltatások leírásában. Ez anélkül jelentkezik, hogy konfliktus merülne fel, mert az only_from értékét az alapértelmezett szakasz felülírja a szolgáltatás only_from beállításából.

bosszantóan, ha nem ad egy only_from vagy no_access utasítást az alapértelmezett szakaszba, akkor az xinetd engedélyezi az összes kapcsolatot amelyet még nem fedtek le a szolgáltatások részében, ami valószínűleg hibát fog eredményezni.

Több cím paramétereinek felsorolásának formája mindkét opció paramétereként helyet hagy az egyes címek között (vessző nélkül). A CIDR tartományokat is felveheti a listába.

Naplófájl-parancsok

Az log_type, log_on_success, és log_on_failure az opciók mind együtt működnek. Mindegyiknek van egy állandósága, amelyet paraméterként be kell írnia az opcióba.

Használja a log_type attribútumot adja meg a naplófájl elérési útját és nevét és használja a log_on_success és log_on_failure attribútumot annak meghatározására, hogy mely mezőket kell beírni az egyes események naplófájl-rekordjába.

Például naplófájl címet írhatna a következővel:

log_type = FILE / usr / log / internetlog

A log_type attribútummal elérhető másik lehetőség a SYSLOG, amely beállítja az események üzenet szintjét, amelyeket a syslogd jelenít meg. Lehetséges értékek:

• démon
• auth
• használó
• local0-7

Példa erre:

log_type = SYSLOG local1

Az SYLOG az attribútum nem nélkülözhetetlen, és sokkal kevésbé fontos, mint a FILE választási lehetőség. Valóban meg kell adnia az xinetd-nek a naplófájl nevét, amelybe írni szeretne; nem kell megadnia a Syslog szintet az esemény üzenetekhez.

A log_on_success elérhető jelentési lehetőségei a következők:

• PID – 0, ha belső xinetd szolgáltatásról van szó
• HOST – az ügyfél címe
• USERID – a távoli felhasználó azonosítója
• EXIT – folyamat kilépési állapota
• Időtartam – a munkamenet időtartama

A log_on_failure jelentési lehetőségei a következők:

• HOST – az ügyfél címe
• USERID – a távoli felhasználó azonosítója
• ATTEMPT – a sikertelen hozzáférési kísérletet naplózza
• FELVÉTEL – az ügyféllel kapcsolatos összes rendelkezésre álló információ

Minden log_on_success és log_on_failure sorhoz több beállítást is beilleszthet, és ezeket szóközzel kell elválasztani bármilyen írásjelek nélkül. Például:

log_type = FILE / usr / log / internetlog
log_on_success = HOST PID USERID IDŐTARTAM EXIT
log_on_failure = HOST USERID ATTEMPT RECORD

Általános gyakorlat, hogy a log_type, log_in_success és log_on_failure utasításokat a fájl egymást követő soraiban tartják..

Kapacitás-ellenőrzés

Két további lehetőség, amelyeket el kell helyeznie az xinetd.conf fájlba, korlátozza a szerver által egyidejűleg csatlakoztatható kapcsolatok számát. Ez egy fontos tényező, és egyszerű, de hatékony módja a szolgáltatásmegtagadás (DoS) támadásainak kiküszöbölésének. A stratégia végrehajtásának két lehetősége van példányok és per_source.

Az alapértelmezett szakaszban szereplő példányok megadja a kapcsolatok számát, amelyekkel az xinetd lehetővé teszi az egyidejű futtatást, és a per_source beállítás határozza meg a kapcsolódási kérelmek számát, amelyekre a démon ugyanazon forráscímtől válaszol.. Elosztott szolgáltatásmegtagadási támadások (DDoS) megkerüli a for_source korlátot, de a példányok opciót nem. Sajnos ennek a szolgáltatási korlátnak a végrehajtása a támadás időtartamára kizárja a valódi felhasználókat.

E két lehetőség formátuma nagyon egyenes:

= szám.

A per_source értéknek alacsonyabbnak kell lennie, mint a példányok értékének.

Alapértelmezett szakasz példa

Az ebben a szakaszban ismertetett összes részletet összeállítva, az xinetd.conf alapértelmezett nyilatkozatának így kell kinéznie:

alapértelmezett
{
példány = 20
per_source = 5
log_type = FILE / usr / log / internetlog
log_on_success = HOST PID USERID IDŐTARTAM EXIT
log_on_failure = HOST USERID ATTEMPT RECORD
only_from =
}

Minden xinetd.conf fájlnak alapértelmezett nyilatkozattal kell rendelkeznie. Nincs szükség szolgáltatási nyilatkozatra.

Szolgáltatáskonfigurációs szakaszok

Minden olyan szolgáltatáshoz, amelyet a kiszolgálónak teljesítenie kell, írjon egy szervizelési részt a xinetd.conf fájlban. Ha nem írsz semmilyen szolgáltatást a konfigurációs fájlba, akkor az xinetd az alapértelmezés szakaszban leírt specifikációkat fogja használni. Az alapértelmezett szakaszokban megadott beállításokat felülírhatja az is, hogy a szolgáltatás meghatározására írt szakaszban új attribútumokat állít meg különböző értékekkel..

Szolgáltatási típusok

A szolgáltatások szakaszban elérhető attribútumok mindhárom szolgáltatáskategóriánként különböznek. Ezek:

• BELSŐ
• nem listázott
• RPC

A szolgáltatás kategóriáját (BELSŐ / NEM FELSOROLT / RPC) az attribútummal lehet meghatározni típus. Ez az attribútum azonban nem kötelező, és gyakran kihagyják.

Szolgáltatás-attribútum meghatározások

Attribútum-specifikáció írásakor az összes mezőt szóközökkel vagy kocsi visszatérések választják el – a meghatározásban semmiféle elválasztó vagy írásjelet nem használ.

A szolgáltatási nyilatkozat elrendezése megegyezik az alapértelmezett szakaszban:

szolgáltatás
{
  attribútum operátor érték
}

Az attribútum utasításokhoz használt operátor általában egyenlő (“=„). Nagyon kevés attribútum teszi lehetővé az értékek hozzáadását egy meglévő listához a következővel:+=Vagy eltávolították a listát a „-=”- mindkét esetben az operátort írja az itt látható idézetek nélkül.

Itt vannak az attribútumok, amelyek elérhetők az BELSŐ A szolgáltatás típusa:

• socket_type
• zászlók
• szép
• várjon
• protokoll (ha nem szerepel az / etc / services könyvtárban)
• port (ha nem szerepel az / etc / services mappában)
• cps
• access_times

Az egy számára elérhető attribútumok RPC szolgáltatás:

• socket_type
• zászlók
• használó
• szerver
• server_args
• szép
• várjon
• jegyzőkönyv
• rpc_version
• rpc_number
• cps
• access_times

Az nem listázott a szolgáltatástípusok a következő attribútumok bármelyikével rendelkezhetnek:

• socket_type
• zászlók
• használó
• szerver
• server_args
• max_load
• szép
• várjon
• protokoll (ha nem szerepel az / etc / services könyvtárban)
• port (ha nem szerepel az / etc / services mappában)
• access_times
• cps

Szolgáltatási attribútumok célja

Ezen attribútumok jelentését az alábbi táblázat mutatja:

AttributeDescription

típus	BELSŐ, RPC, NEM FOLYTATOTT vagy BELSŐ NINCS
socket_type	stream (TCP), dgram (UDP), raw (IP közvetlen hozzáférés) vagy seqpacket ().
id	hozzon létre egyedi nevet erre a szolgáltatásra
zászlók	az alábbi táblázat magyarázata
használó	meghatározza a szerver prioritását
szerver	A szolgáltatás útja és programja
szerver args	érvek, amelyeket át kell adni a szolgáltatási híváshoz
max_load	a szolgáltatás egyidejű folyamatainak száma
szép	növeli a szolgáltatás prioritását
várjon	igen | nem blokkolja vagy engedélyezi az új kérelmek egyidejű feldolgozását
jegyzőkönyv	kihagyható, ha a protokoll szerepel az / etc / protokollban
kikötő	A portszámnak az / etc / services könyvtárban is léteznie kell, és azonosnak kell lennie
rpc_version	RPC verziója
rpc_number	RPC szám
cps	csatlakozási határ, a második argumentum nem kötelező, és másodpercek számát adja meg arra, hogy megvárják a határ elérését
access_times	a nap órája, amikor egy szolgáltatás futtatható
köt	válaszoljon egy adott IP-címre való kapcsolatokra
átirányítás	továbbítja a szolgáltatás igényléseit egy másik számítógépre

Az zászlók Az attribútumnak a következő értékei lehetnek:

IDONLY: csak az azonosító kiszolgálóval rendelkező ügyfelek kapcsolatait fogadhatja el

NORETRY: megakadályozza egy új folyamat létrehozását a kapcsolat meghibásodása esetén

NAMEINARGS: az első érv a server_args az a szerver érték. A tcpd hívására használható

A fenti attribútumokon kívül az alapértelmezések szakaszban elérhető lehetőségek a szolgáltatás meghatározásába is beírhatók. Ezek:

• only_from
• nincs hozzáférés
• log_type
• log_on_success
• log_on_failure
• példányok
• per_source

Ezen attribútumok újbóli használata felülírja az alapértelmezés szakaszban megadott értékeket. Ne feledje azonban, hogy a only_from és nincs hozzáférés az attribútumok globálisak, ezért az egymással ellentétes paraméterek elkerülése érdekében meg kell szerveznie ezen opciók használatát.

Szolgáltatási nyilatkozat példák

Íme két példa a szolgáltatás meghatározására.

service ntalk
{
socket_type = dgram
várj = igen
felhasználó = senki
szerver = /usr/sbin/in.ntalkd
hozzáférési idő = 7: 00-12: 30 13: 30-21: 00
only_from = 192.168.1.0/24
}

szolgáltatás ftp
{
socket_type = stream
várj = nem
felhasználó = gyökér
szerver = /usr/sbin/in.ftpd
server_args = -l
példány = 4
szép = 10
}

Vegye figyelembe a access_times ban,-ben ntalk meghatározás. Ez két idõtartományt használ, a kezdõ és az idõket szaggatott vonallal („-”) elválasztva. A két időtartományt szóközzel választja el egymástól. Az idődefiníciók a 24 órás formátumot használják.

Az only_from attribútum a ntalk A definíció korlátozza a szolgáltatáshoz való hozzáférést, így csak a helyi hálózat címei használhatják azt.

Az ntalk szolgáltatásnak van egy socket_type nak,-nek dgram, ami azt jelenti, hogy UDP szolgáltatás. Az socket_type ban,-ben ftp meghatározás folyam, ami azt jelenti, hogy ez egy TCP szolgáltatás.

Hozzon létre egy szolgáltatás több példányát

A szolgáltatások meghatározása alapértelmezés szerint a szolgáltatás nevét használja azonosítóként. Előfordulhat azonban, hogy létrehoz egy szolgáltatás több példányát, és különféle attribútumokat ad meg. Mivel a szolgáltatás nevének meg kell egyeznie a / Etc / services fájl, a szolgáltatás több verziójának beszerzése lehetetlen. Az id attribútum azonban lehetővé teszi ezt a működési stratégiát.

A forgatókönyv egyik leggyakoribb használata akkor lenne, ha létrehozni szeretne különféle FTP-kiszolgálók a belső és külső hozzáféréshez. Ezzel a módszerrel az irodai fájltárolót teljesen elkülönítve tarthatja a letölthető fájloktól, amelyeket a nyilvánosság számára elérhetővé tett..

Ebben a használati esetben kétszer definiálná a „Service ftp” -t. Ezután megadnánk egy példánynak az attribútumot id = ftp-belső és a másik id = ftp-external. Ettől kezdve a xinetd képes megkülönböztetni a kettőt. Annak érdekében, hogy az egyes példányok különböző közönségek számára elérhetőek legyenek, a only_from attribútum, amely az ftp-belső szolgáltatáshoz való hozzáférést csak a hálózat címeire korlátozza, és az ftp-külső szolgáltatáshoz való hozzáférést minden nem hálózati címre.

Csatlakoztasson címet egy szolgáltatáshoz

A belső és külső felhasználók számára különféle szolgáltatások létrehozásának forgatókönyvét nagyban elősegítheti a bind attribútum. A „köt”Gyakran használják a TCP programozásban. Általában azt jelenti, hogy kapcsolatot létesítenek egy porttal, ezáltal létrehozva azonosítót a munkamenethez. Ebben az esetben azonban a „kötés” valami mást jelent. Az FTP-kiszolgáló belső és külső hozzáférésének példájában, kötheti a számítógép hálózati címét az ftp-belső példányhoz, és a számítógép nyilvános IP-címét az ftp-külső példányhoz.

Ebben a példában lehetséges, hogy kihagyja az only_from attribútumot a szolgáltatás meghatározásában. Biztonságosabb azonban, ha ezeket a korlátozásokat behagyja. Tehát a belső és a külső FTP-kiszolgálók teljes meghatározása a következő lenne:

szolgáltatás ftp
{
id = ftp-external
szerver = /usr/sbin/in.ftpd
server_args = -l
példány = 4
only_from = 0.0.0.0/0
bind = 202.19.244.130
}

szolgáltatás ftp
{
id = ftp-belső
socket_type = stream
szerver = /usr/sbin/in.ftpd
server_args = -l
only_from = 192.168.1.0/24
bind = 192.168.1.5
}

Ez a stratégia megköveteli, hogy FTP-kiszolgálójának statikus IP-címe legyen hozzárendelve a nyilvános hozzáféréshez. Be kell állítania a DHCP-kiszolgálót, hogy ugyanazt a címet fenntartsa a belső FTP-kiszolgálóra. Noha a fenti forgatókönyv akkor működik, ha egyetlen számítógépet használnak belső és külső hozzáféréshez, akkor külön-külön számítógépek címeit is kioszthatja az egyes FTP-példányokhoz.

Az inetd-specifikus szolgáltatások letiltása

Vannak három xinetd szolgáltatás amelyek információkat adnak a rendszerről.

• szerverek: jelentés a használt szerverekről
• szolgáltatások: jelentés a rendelkezésre álló szolgáltatásokról, azok protokolljairól és portjairól
• xadmin: a fenti két parancsot egyesíti

Ezek a szolgáltatások biztonsági gyengeséget jelentenek mert a hackerek felhasználhatják információkat a hálózatról és a szerverről. Ezért jobb letiltani őket. Ezt megteheti a letiltott attribútummal, amely bekerül az ön fiókjába alapértelmezett meghatározás. Csak helyezze be a következő sort az alapértelmezett részbe, hogy eltávolítsa ezeket a lehetőségeket:

tiltva = xadmin kiszolgálói szolgáltatások

A konfigurációs fájl fent részletezett módosításaival mostantól kezdheti el használni az xinetd fájlt.

Fut a xinetd

A xinetd parancsot indítja el. A parancs kötegelt fájlból is futtatható, így hozzáadhatja azt a számítógép indítási eljárásaihoz. A program a következő lehetőségekkel futtatható:

SwitchOptionDescription

-d		Hibakeresési mód
-syslog	syslog_facility	Ugyanaz, mint a log_type SYSLOG a conf fájlban
-FileLog	log fájl	Ugyanaz, mint a log_type FILE a conf fájl alapértelmezésében
-f	konfigurációs_fájl	Megadja a konfigurációs fájlt – az alapértelmezett érték az /etc/xinetd.conf
-pid	pid_file	Írja be a folyamat azonosítóját a pid_file fájlba
-maradj életben		Soha ne fejezzen be
-határ	proc_limit	Az egyidejűleg futtatható folyamat maximális száma
-logprocs	határ	Az egyidejűleg futó kiszolgálók maximális száma
-változat		Nyomtassa ki a xinetd verziót
-inetd_compat		Olvassa el az /etc/inetd.conf fájlt, valamint a xinetd konfigurációs fájlt
-cc	intervallum	Végezzen konzisztencia-ellenőrzést másodpercenként

A xinetd indítása opciók nélkül is lehetséges.

Használja a xinetd-t

Ha van Linux számítógépe, akkor az xinetd telepítve lehet. Futtatásával ellenőrizheti xinetd-verzió. Ha a számítógép inkább az inetd-ben fut, akkor valószínű, hogy nem Linuxot futtat. Cserélje ki a programot xinetd-re, és konvertálja a konfigurációs fájlt az inetd kompatibilitástól a xinetd-használatra, a fentiek szerint.

Jelenleg használja a xinetd-t? Hagy egy üzenetet a Hozzászólások az alábbiakban megoszthatja tapasztalatait a közösséggel.

Lásd még: 15 legjobb ingyenes Syslog szerver

Kép: Hálózati internet kapcsolat a Pixabay-től. CC0 Creative Commons engedéllyel rendelkezik