SSH (Biztonságos héj- Védett héj) -- ez hálózati protokoll biztonságos hitelesítés, kapcsolat és biztonságos adatátvitel biztosítása a hálózati állomások között, a rajta áthaladó forgalom titkosításával, esetleges adattömörítéssel. Egy másik fontos funkcionális jellemzője, lehetővé teszi biztonságos, titkosított alagutak létrehozását a biztonságos átvitelhez nem biztonságos környezetben (például interneten), más hálózati protokollokon, valamint a forgalom tömörítésének lehetőségével. Ezen kívül a protokoll SSH kiválóan működik az egyik gép portjainak továbbításával (továbbítása, továbbítása) a másik portjaira, beleértve a távoli kliensek továbbítását XWindow... Most protokoll SSH, szabvány, és széles körben használatos például szerverrendszereknél, vagyis a szerver shellben biztonságos kapcsolaton keresztül különböző parancsok és manipulációk végrehajtása, fájlok hálózaton keresztüli másolása, például adatmentések.
Jegyzőkönyv SSH, két változatban létezik, egy kereskedelmi verziót fejlesztett ki SSH inc, és ingyenes, nyílt forráskódú, OpenSSH amelyet főként a legtöbb szerverplatformon használnak. Végrehajtás OpenSSH, elérhető a Unix család bármely operációs rendszerében, és a legtöbbben SSH szerver és SSHügyfél azok szabványos közművek... Az alábbiakban leírtak érintik OpenSSHés a FreeBSD operációs rendszer. A protokollnak két változata létezik SSH nem kompatibilisek egymással. A protokoll első megvalósítása SSH, SSH - 1 1995-ben fejlesztették ki. Második verzió, SSH - 2, 1996-ban jelent meg. 2006-ban jegyzőkönyv SSH az IETF internetes szabványként fogadta el. Most a protokoll második változata, amelyet széles körben használnak. SSH mert először is a protokoll SSH az 1-es verzió komoly sebezhetőségeket szenvedett el, másodsorban a 2-es verzió erősebb titkosítási algoritmusokat használ, emellett támogatja a szándékos adatsérülések észlelését. Titkosító algoritmusok:
- SSH protokoll 1-es verziója DES, 3DES, blowfish
- SSH protokoll 2-es verzió AES-128, AES-192, AES-256, blowfish, CAST-128, ArcFour
- SSH protokoll 1. sz
- SSH protokoll 2-es verzió HMAC-MD5, HMAC-SHA-1, HMAC-RIPEMD
SSH hitelesítési módszerek, OpenSSH szoftvercsomag
Protokoll biztonság SSH a következő szoftvermegoldások biztosítják:- Az összes áthaladó forgalom titkosítása SSH a kommunikációs munkamenetben részt vevő felek tárgyalása során kiválasztott lehetséges algoritmusok egyike szerint végrehajtott kapcsolat. A kapcsolati forgalom titkosítása megakadályozza annak elfogását és rosszindulatú felhasználását. Különböző titkosítási algoritmusok kiválasztásával a rendszer nagyon rugalmassá válik, lehetővé téve például, hogy ne használjanak olyan algoritmusokat, amelyekben sebezhetőséget vagy potenciális biztonsági fenyegetést találtak, vagy csak azokat az algoritmusokat használja, amelyeket az egyes felek támogatnak;
- Hitelesítés SSH a szerver mindig végrehajtódik, minden olyan kapcsolat esetén, amely nem teszi lehetővé a forgalom vagy a szerver cseréjét;
- Hitelesítés SSHügyfél fordulhat elő különböző utak, ami egyrészt magát a hitelesítési folyamatot teszi biztonságosabbá, másrészt még rugalmasabbá teszi a rendszert, megkönnyítve ezzel a munkát;
- A hálózati csomagok integritásának ellenőrzése, lehetővé teszi a kapcsolat forgalmában bekövetkezett illegális változások nyomon követését, ennek észlelése esetén a kapcsolat azonnal megszakad;
- Az ideiglenes hitelesítési paraméterek megakadályozzák az elfogott és egy idő után visszafejtett kapcsolati adatok használatát.
- GSSAPI alapú hitelesítés
- Gazda alapú hitelesítés;
- Felhasználó hitelesítés nyilvános kulccsal;
- Kihívás-válasz hitelesítés ( kihívás-válasz);
- És végül a szokásos felhasználói hitelesítés, jelszó használatával;
- sshd valójában SSH szerver, démon program;
- ssh- egy kliens program, amely helyettesítője lett rloginés telnet;
- scp- program távoli másolásra protokollon keresztül SSH, csere a rcp;
- sftp- biztonságos ftp kliens;
- sftp-szerver- a protokollon keresztüli fájlátvitelt biztosító alrendszer SSH;
- ssh-keygen- kulcs generátor
- ssh-keyscan- nyilvános állomáskulcsok "gyűjtője";
- ssh-agent- hitelesítő ügynök a privát kulcsok tárolására;
- ssh-add- egy kis program kulcsok hozzáadásához ssh-agent;
Az SSH lehetővé teszi a különböző titkosítási algoritmusok kiválasztását. SSH-kliensek és SSH-kiszolgálók állnak rendelkezésre a legtöbb hálózati operációs rendszerhez.
| SSH | |
|---|---|
| Név | Biztonságos héj |
| Szint (OSI modell) | Alkalmazott |
| Család | TCP / IP |
| Port / ID | 22 / TCP |
| A protokoll célja | Távoli hozzáférés |
| Leírás | RFC 4251 |
| Főbb megvalósítások (kliensek) |
A Diffie-Hellman (DH) algoritmus egy megosztott titok (munkamenetkulcs) létrehozására szolgál. A továbbított adatok titkosításához szimmetrikus titkosítást, AES, Blowfish vagy 3DES algoritmusokat használnak. Az adatátvitel sértetlenségét a CRC32 SSH1-ben vagy a HMAC -SHA1 / HMAC -MD5 az SSH2-ben ellenőrzi. A titkosított adatok a LempelZiv (LZ77) algoritmussal tömöríthetők, amely ugyanazt a tömörítési szintet biztosítja, mint a ZIP archiváló. Az SSH-tömörítés csak az ügyfél kérésére engedélyezett, és a gyakorlatban ritkán használják. Szabványok és szoftvermegvalósításokA protokoll első változatát, az SSH-1-et 1995-ben Tatu Ulönen, a Helsinki Műszaki Egyetem kutatója fejlesztette ki (Finnország). Az SSH-1 azért készült, hogy nagyobb adatvédelmet biztosítson, mint az rlogin, telnet és rsh protokollok. 1996-ban kifejlesztették a protokoll biztonságosabb verzióját, az SSH-2-t, amely nem kompatibilis az SSH-1-gyel. A protokoll még nagyobb népszerűségre tett szert, és 2000-re körülbelül kétmillió felhasználója volt. Jelenleg az "SSH" kifejezés általában pontosan SSH-2-t jelent, mivel a protokoll első verzióját jelentős hiányosságok miatt gyakorlatilag nem használják. Vannak olyan modulok, mint a python-paramiko és a python-twisted-conch az SSH használatához a Pythonban. SSH alagútAz SSH-alagút egy SSH-kapcsolaton keresztül létrehozott alagút, amelyet az alagútban lévő adatok titkosítására használnak. Internetes adatátvitel biztosítására szolgál (az IPsecnek hasonló a célja). Ha SSH-alagúton keresztül küldik, bármely protokoll titkosítatlan forgalmát az SSH-kapcsolat egyik végén titkosítják, a másik végén pedig visszafejtik. A gyakorlati megvalósítás többféleképpen is megvalósítható:
$ ssh -L 4430: jabber.example.com: 443 somehost V ebben az esetben A Jabber kliens úgy van beállítva, hogy csatlakozzon a localhost szerver 4430-as portjához (ha az ssh kliens ugyanazon a gépen fut, mint a Jabber kliens). Ssh-alagút létrehozásához olyan gépre van szükség, amelyen egy futó ssh-kiszolgáló található, és hozzá kell férnie a jabber.example.com címhez. Ez a konfiguráció akkor használható, ha a helyi gépről a jabber.example.com webhelyhez való hozzáférést tűzfal zárja le, de van hozzáférése néhány ssh-kiszolgálóhoz, amelyen nincsenek internet-hozzáférési korlátozások. |
Az SSH (Secure Shell) egy hálózati protokoll távoli hozzáférés amely titkosítást és tömörítést használ a továbbított adatokhoz. Egyszerűen fogalmazva, ez egy nagyon hasznos és hatékony eszköz, amely lehetővé teszi a hitelesítést a rendszerben és teljes körű munkát a helyi felhasználó hogy sok kilométerre van egy futó géptől. Ezenkívül a telnettől és az rsh-től eltérően az SSH az összes forgalmat titkosítja, így minden továbbított információ bizalmas marad.
Tehát az ssh már telepítve van, és az ssh-daemon hozzáadódik az indításhoz a rendszer indításakor. A következő paranccsal vezérelheti:
service ssh stop | start | restart
Ubuntun, vagy:
/etc/init.d/ssh (start | leállítás | újratöltés | kényszer-újratöltés | újraindítás | állapot)
Debianon vagy:
systemctl start | stop | újraindítás sshd.service
ArchLinuxban (a konfiguráció minden szerkesztése után újra kell indítani). A készlet tartalmaz egy klienst és egy szervert.
Próbáljuk ki működés közben! Először hozzon létre egy mappát ~ / .ssh
mkdir ~ / .ssh
Kulcsok generálása ehhez adott felhasználó szerver a következő paranccsal:
ssh-keygen (rendes felhasználóként).
Generáláskor beállíthatunk egy jelszót a kulcshoz (célszerű hosszút beállítani - akkor még a kulcs megszerzése után sem tud a kulcsból a jelszó ismeretében a támadó nem tud bejelentkezni), vagy ugorja át egyszerűen az "Enter" megnyomásával - ebben az esetben a jelszó soha nem lesz kérve. Ugyanazok a nyilvános és privát kulcsok jelentek meg a ~ / .ssh mappában.
Keress egy másik gépet (még egy okostelefon is megteszi - Androidon vannak nagyszerű SSH-kliensek, mint a ConnectBot vagy a JuiceSSH), telepítsd rá az ssh-t, és csatlakozz a szerverhez a következő paranccsal:
ssh [e-mail védett]
Ha mindent jól csinált, akkor a rendszer kéri a felhasználó jelszavát, és a belépés után a rendszerében találja magát a parancssorból kitekintve.
Windowshoz egyébként vannak ssh szerverek és kliensek is.
Miután élveztük munkánk eredményét, térjünk át egy még unalmasabb részre - a kliens/szerver beállítására.
Az ügyféloldali konfiguráció be van kapcsolva / etc / ssh / ssh_configés a szerver egy - / etc / ssh / sshd_config... A legtöbb teljes útmutatást a konfigurációhoz valószínűleg van egy oldal a man - man ssh és man sshd_config fájlokban, ezért javasoljuk, hogy olvassa el. És ebben a cikkben megvizsgáljuk a legszükségesebb dolgokat.
Testreszabás
A szabványos ssh port a 22. Bármilyen nem szabványosra cserélhető (ez megnehezíti a feltörést a biztonság miatt az ismeretlenségen keresztül, vagy hogy felkeltse a potenciális támadók figyelmét :) - ehhez törölje a megjegyzést a sorból:
#22-es port
És adjon hozzá bármit 65535-ig (bizonyosodjon arról, hogy a port nem ütközik más szolgáltatásokkal a paranccsal #netstat -tupln | grep HALLGAT).
Most, amikor csatlakozik a szerverhez, a kliensnek a következő kulccsal kell írnia:
ssh -p [port]:
Alapértelmezés szerint a root hozzáférés engedélyezett. Nagyon tanácsos korlátozni (és ehelyett megfelelően elhatárolni a helyi felhasználói jogokat a sudo segítségével). Ehhez keresse meg a „PermitRootLogin” sort, és módosítsa az értéket „no”-ra. Módosíthatod "jelszó nélkül"-re is - ebben az esetben a root alatti bejelentkezés csak megbízható kulccsal rendelkező gépekről lesz engedélyezve.
Letilthatja a jelszavas hitelesítést, és csak kulcsokkal dolgozhat - keresse meg a "PasswordAuthentication" sort, és módosítsa az értéket "no"-ra. Minek? Ha valaki valóban hozzá akar férni a rendszeréhez, akkor vagy brutálisan kikényszerítheti a jelszót az engedélyezés során, vagy meghallgathatja és visszafejtheti a kapcsolatot. Ha letiltja a jelszavas hitelesítést, és hozzáadja a ~ / .ssh / authorised_keys fájlhoz a kiszolgálón például a munkahelyi laptopja nyilvános kulcsát, akkor, mint emlékszünk, azonnal belépünk a szerverre. De mi van akkor, ha valaki más gépén dolgozik, és sürgősen hozzá kell férnie az ssh-kiszolgálóhoz, de az, ahogy az várható volt, nem enged be minket? Ekkor nem tudja letiltani a jelszavas hitelesítést, hanem használja a fail2ban segédprogramot. Csak telepítse a tárolóból, ami után az alapértelmezett beállításokat alkalmazza, és legalább megvédi az ssh-csatornát a brute force támadásoktól. További információ a fail2ban-ról: http://putty.org.ru/articles/fail2ban-ssh.html.
Abban az esetben, ha a szervere kulcsokat tárol a nukleáris rakéták kilövéséhez, a következőket teheti:
PermitRootLogin nem - a root alatti bejelentkezés tilos.
PasswordAuthentication nem – belépés jelszó nélkül
Hozzunk létre egy hosszú kulcsot a távoli gépen (-t titkosítási_típus, -b bithossz):
ssh-keygen -t rsa -b 4096
Ugyanolyan összetett jelmondattal (recover elfelejtett jelszó, mellesleg nem lehet. Megváltoztathatod az "ssh-keygen -p" paranccsal, de úgyis a régit fogják kérni). Vigyük át a távoli helyi gép nyilvános kulcsát a ~ / .ssh / authorised_keys könyvtárba a kiszolgálón, és íme - most már egyetlen gépről is elérhető a privát kulcs jelmondatával. Az SSH sok biztonsági konfiguráció beállítását teszi lehetővé, és ehhez nagyon sok specifikus beállítás van - olvassa el az emberben.
Két sshd_config beállítás ugyanazt a célt szolgálja:
BejelentkezésGraceTime- beállítja azt az időt, amely után a kapcsolat megszakad, ha a hitelesítés nem történik meg.
MaxAuthTries- beállítja a hibás bejelentkezési kísérletek számát, amelyek elérésekor a kapcsolat megszakad.
MaxSessions- az egyidejű munkamenetek száma (ha a szerver az otthoni számítógéped, amelyre az egyetemről vagy a munkahelyedről csatlakozni fogsz, akkor indokolt lenne a munkamenetek számát egyben korlátozni - ebben az esetben a visszautasított bejelentkezés a növekvő paranoia, az új kulcsok generálása és a jelszó megváltoztatásának oka). Ha azonban óvatos, észrevehette, hogy a "Utolsó bejelentkezés" sor minden egyes bejelentkezéskor megjelenik a szerverre. Ezen kívül hozzáadhat saját üdvözlő üzenetet - keresse meg a "Banner" sort, és a semmi helyett állítsa be a fájl elérési útját a bejelentkezéskor elolvasandó és megjelenített szöveggel.
Többek között csak bizonyos felhasználóknak engedélyezheti a bejelentkezést, vagy bizonyos felhasználók kivételével mindenki számára:
AllowUsers user1- csak user1 belépést engedélyez.
DenyUsers user1- mindenkit engedélyez, kivéve user1-et.
És hasonló paraméterek a hozzáféréshez bizonyos csoportok- AllowGroups és DenyGroups.
Az X11 munkamenetet SSH-val is végezheti. Ehhez keresse meg a "ForwardX11" sort, és módosítsa az értéket "yes"-re.
Keressen egy hasonló sort a kliens konfigurációjában - / etc / ssh / ssh_config, és változtassa meg "yes"-re.
Most csatlakoznia kell a szerverhez ssh-n keresztül a -X argumentummal:
ssh -X [e-mail védett]>
Csatlakozás után azonnal elindíthatja az alkalmazást:
ssh -X [e-mail védett]"Alkalmazás"
Így néz ki egy futó GIMP egy ssh-munkamenetben:
Vagy lekérheti a kimenetet egy gyanútlan felhasználó laptop webkamerájáról :)
A számításokat közvetlenül a szerveren hajtják végre, és a kimenetet elküldik a kliens gépre (vagyis még akkor is, ha maga a szerver nem rendelkezik X11-gyel, grafikus alkalmazások jeleníthetők meg a távoli gépen). Ez a séma meglehetősen lassan működik (ne felejtse el, hogy az összes forgalom dinamikusan titkosított) - de ez a funkció nagyon hasznos.
SSH-munkameneten keresztül is másolhat fájlokat – erre van egy egyszerű "scp" segédprogram. A fájlokat közvetlenül a munkamenetben viheti át a szerverről a kliensre:
scp [e-mail védett]: / elérési út / a / fájl / on / szerver / ahol / mentés / on / helyi / gép
Tehát kliensről szerverre:
scp elérési út / a / fájl / klienshez [e-mail védett]: / elérési út / on / szerver
Ez nagyon kényelmes, ha tankönyvet vagy fényképet kell másolnia, de mi van akkor, ha sok fájllal kell dolgoznia? Ehhez van egy nagyon kényelmes dolog - az sshfs (a legtöbb * nix-rendszer tárolójában telepíthető).
Csak állítsa be az elérési utat, mint az scp:
sshfs [e-mail védett]: / otthon / felhasználó / mnt /
És a szerver / home / user mappája megjelenik a helyi gép / mnt csatolási pontján!
A leválasztás az umount segítségével történik.
És végül beszéljünk egy kevéssé ismert funkcióról. Ha létrehoz egy fájlt /.ssh/configés töltsd ki így:
Házigazda [név]
Gazdanév
Felhasználó [szerver felhasználónév]
kívánt opciókat
mint
ElőreX11 igen
30.000 port
Ezután bejelentkezhetünk:
ssh [név]
ssh -X -p 30000 [e-mail védett]
És az összes opció automatikusan megjelenik. Így egy adott szerveren végzett gyakori hitelesítéssel ez a folyamat néhány pillanatra leegyszerűsödik.
Nos, mindent (és még ennél is többet) leírtunk, amit az SSH-ról tudnia kell a mindennapi használathoz – megtanultuk a kulcshitelesítés használatát, megvédtük a szervert a brute force támadásoktól, és általában befoltoztuk a lehetséges lyukak nagy részét. Valójában az SSH sok más dolgot is tud végezni - például alagútkezelést és porttovábbítást egy ssh-munkameneten keresztül, de nem valószínű, hogy Ön, mint hétköznapi felhasználó, valaha is használni fogja ezt. További források
Bevezetés
Az előző számban az internetes szerverek biztonságáról szóló cikk felvetette az internetes szerver platformjának és operációs rendszerének megválasztásával, a szerver egészének biztonságával kapcsolatos kérdéseket, szó esett a felhasználókkal való együttműködésről, valamint a munkáról és tűzfal beállításait... Hadd emlékeztessem röviden, hogy fontolgatjuk egy kis irodai vagy otthoni hálózat felügyeletét, ha egy vagy két dedikált számítógépe van. Az első esetben, amikor egy számítógép tűzfal plusz levelezőszerver, Egy webszerver és talán egy ftp szerver. Egyszerűen fogalmazva, egy dedikált számítógépet egyfajta megosztott erőforrásként használnak. A második esetben, ami a jelenlétet jelenti nagy hálózat, az egyik számítógép átjáróként plusz tűzfalként, a másik pedig levelezőszerverként, webszerverként stb. Elvileg a második módszer előnyösebb, mivel fizikailag leválasztja az átjárót, mint a hackerek első lehetséges támadásának tárgyát, és megosztott szerver hálózatok. A jövőben mindenesetre elvonatkoztathat a dedikált számítógépek számától, ne feledje, hogy még ha kettő is van belőlük, nem ésszerű más feladatokkal terhelni őket.
A következõk mind az elõzõ cikk vonalát folytatják, feltételezve, hogy egy Linux gépet használnak szerverként, és a felhasználó alapszinten ismeri a Linuxot és a hálózatépítést. A példák ötleteit különféle Linux-oktatóanyagokból kölcsönöztük. Tehát milyen kérdéseket fogunk most megvizsgálni? Először is, azokat a kiszolgálóalkalmazásokat, amelyeket telepíteni szeretne a kiszolgálóra. Másodszor, a hálózati támadások (beleértve a Linuxban található vírustípusokat és a trójai falovakat) és az ezek elleni küzdelem módszereit. Miért szerepelnek ezek a kérdések egy cikkben? Az a tény, hogy általában a hackelés vagy az adminisztrátor hanyagsága, vagy a szerveralkalmazások védelmének hiányosságai miatt következik be. A kliens, ahogy a szó maga is sugallja, nem ellenőrzi a rendszer erőforrásait, így nyilvánvaló, hogy a szerverek lehetnek támadások alanyai.
Szerveralkalmazások védelme
Aki ismeri a UNIX-ot, az szinte mindenre rájön hálózati program kliensként és szerverként is használható. Az első esetben Ön használja a szolgáltatásokat, a második esetben Ön nyújtja azokat. Nyilvánvaló, hogy egy hálózati szolgáltatásban mindkét részre szükség van. A kérdés az, hogy milyen szerver programokra van szükség a hálózaton lévő szerveren. A Linux telepítésekor természetesen legalább mindent választhatunk, hiszen a lemezre telepítés még nem jelenti az indulást. De melyiket kell aktiválni később? Van egy egyszerű recept, amelyet én magam is mindig betartok, amikor szerverekkel dolgozom - minél kevesebb az aktivált szerver, annál jobb (általánosabb: minél nehezebb egy dolog, annál könnyebb megtörni). Bármennyit is beszél a UNIX megbízhatóságáról, itt rendszeresen felfedezik és javítják a lyukakat. Ezért minél kevesebb programot futtat, annál kevésbé kell figyelnie őket. A való életben ez természetesen nem merülhet ki arra a tényre, hogy a felhasználókat szó szerint mindentől megtiltja. Természetesen biztonságos, de minek vesződni egy rendszergazdával? Felesleges dolgokat azonban, mint például a derék, semmiképpen sem szabad felszerelni.
Telnet és ssh
Most pedig nézzük meg közelebbről, mire van igazán szükségük mind a belső, mind a külső felhasználóknak. Telnetre és ssh-ra (secure shell) van szükségünk. Lehet, hogy nem túl kényelmes hozzáférés, de szükséges, legalábbis a rendszergazdák számára. Ez egy olyan program, amely terminál módban biztosít hozzáférést, amikor egy 80x25 karakteres ablak jelenik meg a számítógépen, amely teljes mértékben tükrözi a hívott szervert. Bármilyen parancsot végrehajthat, és futtathat olyan programokat, amelyek nem használnak grafikát - általában ez egy szokásos távoli terminál. A telnet és az ssh közötti különbség a nevekből adódik, de mégis hadd magyarázzuk el: a telnet védelem nélkül továbbítja az információkat, még a jelszót is tiszta szövegben továbbítja a hálózaton, az ssh pedig minden továbbított információt titkosít. Ha többé-kevésbé magabiztos akar lenni a védelemben, akkor tiltsa be a telnet használatát, vagy ne indítsa el. Nos, ha továbbra is használni szeretné, akkor természetesen tűzfalat kell használnia. A szabványos parancsok a következők lehetnek:
ipfwadm-hez -
Ipfwadm -I -a elfogadja -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 23 ipfwadm -I -a elfogadja -P tcp -S some.trusted.host -D 0.0.0.0/0 23 ipfwadm - I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 23
ipchains számára -
ipchains -A bemenet -p minden -j ELFOGADÁS -s 10.0.0.0/8 -d 0.0.0.0/0 23
Ipchains -A bemenet -p mind -j ELFOGADÁS -s some.trusted.host -d 0.0.0.0/0 23 ipchains -A bemenet -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 23
Használhatja az /etc/hosts.allow és /etc/hosts.deny fájlokat is, amelyekhez a következőket kell írnia:
az első fájlban -
In.telnetd: 10.0.0.0/255.0.0.0, some.trusted.host
a második fájlban -
In.telnetd: ALL
Vegye figyelembe, hogy még akkor is, ha ezek a szabályok engedélyezve vannak, bármely program, amely a hálózaton figyel valahol egy jelszóval rendelkező csomag útvonalán, elfoghatja azt.
Két másik fontos, a rendszerbiztonsággal kapcsolatos információkat tartalmazó fájl az / etc / securitytty és az / etc / shells. Az első azokat a terminálokat határozza meg, amelyekről a root felhasználó bejelentkezhet. A legtöbb rendszeren alapértelmezés szerint a root felhasználó csak a konzolról tud bejelentkezni. A második fájl megadja azon érvényes burkolók listáját, amelyek futhatnak, amikor a felhasználó bejelentkezik. Egy szép példa, amit a Linux kézikönyvből vettem, a passwd parancshéjként való használata. Ez biztosítja a felhasználók számára a jelszó egyszerű megváltoztatását, és azt is biztosítja, hogy terminál módban semmi mást ne tegyenek. Ehhez írja be magát a passwd programot az / etc / shells fájlba, azaz írja be a következő sort:
/ usr / bin / passwd
és az / etc / passwd fájlba írja be a felhasználót:
Felhasználónév: x: 1000: 1000 :: / home / felhasználónév: / usr / bin / passwd
Most, amikor egy felhasználó bejelentkezik a hálózatra, csak a jelszót tudja megváltoztatni. A terminál kimenete így néz ki:
1.2.3.4 próbálkozás ... Csatlakozva a localhosthoz. Az Escape karakter "^]". Red Hat Linux 5.2 kiadás (Apollo) Kernel 2.2.5 i586 bejelentkezés esetén: tesztelő Jelszó: Tesztelő jelszavának módosítása (jelenlegi) UNIX jelszó: Új UNIX jelszó: Írja be újra az új UNIX jelszót: passwd: az összes hitelesítési token sikeresen frissítve A kapcsolatot külföldi zárta le házigazda.
Még ha a jelszó megváltoztatására tett kísérlet sikertelen is volt, a rendszer leválasztja a rendszerről. Csatlakozáskor figyelni kell az indítási kimenetre is: a telnet őszintén megírja a rendszer nevét és verzióját. Általában ez kényelmes, de ebben az esetben olyan információkat ad meg egy potenciális hackernek, amelyet saját céljaira használhat fel. Hogyan lehet ezt elkerülni? Amikor egy felhasználó bejelentkezik, a telnet megjeleníti a rendszer indításakor létrehozott /etc/issue.net fájlt. Ezt az rc.local fájl parancsai hozzák létre:
# Ez minden rendszerindításkor felülírja az /etc / problémát. Tehát végezzen el minden változtatást, amelyet # itt szeretne végrehajtani az /etc/problémán, különben újraindításkor elveszik. echo ""> / etc / issue echo "$ R" >> / etc / issue echo "Kernel $ (uname -r) on $ a $ (uname -m)" >> / etc / issue cp -f / etc / probléma /etc/issue.net echo >> / etc / issue
Ezért, ha nem terheli túl a rendszert, egyszerűen szerkesztheti az /etc/issue.net fájlt, ellenkező esetben magát az rc.local fájlt. Mindenesetre csak akkor javasolt a telnet használata, ha valóban szükséges, és nem helyettesíthető ssh-val.
Az Ssh felhasználói szempontból hasonló a telnethez. A 23-as portot használó telnettől eltérően a 22-es portot használja, de a fő belső különbség az, hogy minden forgalom titkosított. Minden más tekintetben hasonlóak. Az ssh esetében ugyanazokat a tűzfalszabályokat (a portszám cseréjével) használhatja az /etc/hosts.allow, /etc/hosts.deny fájlokban. Egy jó tulajdonság a saját / etc / sshd / sshd_config konfigurációs fájl jelenléte, amely a következő konfigurációs sorokat tartalmazza:
22-es port # portszám, amely több lehet, mint 22 ListenAddress 0.0.0.0 # milyen címeket szolgál ki a HostKey démon / etc / ssh / ssh_host_key # kliens kódok fájl RandomSeed / etc / ssh / ssh_random_seed # véletlen számok fájlja a kódok generálásához ServerKeyB 768 # kódhossz bitben LoginGraceTime 300 # név és jelszó megadásának ideje KeyRegenerationInterval 3600 # kódok újragenerálásának gyakorisága PermitRootLogin nem # hogy a root felhasználó bejelentkezhet-e az ssh-n keresztül IgnoreRhosts igen # Figyelmen kívül hagyja vagy sem a felhasználó fájljából származó információkat rhosMostsyestric # szigorú mód, a felhasználói hibák blokkolása, például a jelszó 5-szöri megadása # vagy véletlen sajtóírja be a QuietMode-t nem # igen - egyáltalán nem írja be a naplófájlt és nem - egyébként X11Továbbítás nem # információ továbbítása az X szerverről ssh-csatornán keresztül FascistLogging nem # a naplófájlok teljességének foka PrintMotd igen # a nap valamelyik kifejezésének megjelenítése KeepAlive igen # a kommunikáció fenntartása szabványos SyslogFacility DAEMON biztosításával # aki a naplók létrehozásáért felelős RhostsAuthentication nem # engedélyezi a felhasználó hitelesítést rhosts segítségével RhostsRSAAuthentication nem # függetlenül attól, hogy az rhosts vagy az /etc/hosts.equiv # alapértelmezés szerint igen van-e. RSAAuthentic # csak RSA hitelesítés használata PasswordAuthentication igen # használja a felhasználók normál jelszavát vagy nem PermitEmptyPasswords nem # engedélyezi a felhasználókat jelszó nélkül vagy sem
Van néhány hasznos beállítás is, különösen:
AllowGroups, DenyGroups, AllowUsers, DenyUsers, AllowHosts, DenyHosts, IdleTimeout idő (idő, amely után a kapcsolat megszakad inaktivitás esetén).
Ahogy a fentiekből is látszik, az ssh-nek összességében annyi opciója van, hogy pontosan szabályozhatja, hogy ki és hogyan jelentkezhet be. De ez a szerverről szól, és a hálózati felhasználóknak ssh klienseket kell futtatniuk. A Windows rendszerben elérhető telnettől eltérően az ssh nem szerepel a szabványos disztribúcióban. A Linuxnak nincs ilyen problémája – a kliens is ott van. Fontos megjegyezni, hogy az ssh démon az első és a második verzióban is elérhető. Az persze kellemetlen, hogy nincs visszamenőleges kompatibilitás, de biztos vagyok benne, hogy rendszergazdaként olyan klienseket fog adni a felhasználóknak, amelyek képesek kommunikálni a szerverrel. Íme néhány ssh kliens Windowshoz:
- Friss Ingyenes FiSSH. http://www.massconfusion.com/ssh/
- Tera Term. http://hp.vector.co.jp/authors/VA002416/teraterm.html telnet kliens. http://www.zip.com.au/~roca/ttssh.html - további dll az ssh támogatáshoz
- Gitt. http://www.chiark.greenend.org.uk/~sgtatham/putty.html - csak körülbelül 200 ezer
- Mindterm http://www.mindbright.se/mindterm/ - Java ssh kliens
- A Java Telnet alkalmazás. http://www.mud.de/se/jta/ - van ssh támogatás
- Biztonságos CRT. http://www.vandyke.com/ - kereskedelmi ügyfél
Szükséges megemlíteni a terminál hozzáférést olyan programokkal kapcsolatban, mint az rlogin, rexec, rsh. Használatuk mentes mindenféle védelemtől, és néha még azt is lehetővé teszi a felhasználók számára, hogy jelszó megadása nélkül juthassanak gépről gépre. Bár ez kényelmes, biztonsági szempontból egyszerűen nem jó semmire. Ezek a szolgáltatások általában alapértelmezés szerint elindulnak. Ezek visszavonásához módosítania kell az /etc/inetd.conf fájlt, és újra kell indítania az inetd démont. Általában a telnet és az ssh kimeríti a rendszerhez való terminál hozzáférés lehetőségeit. Ezért térjünk át más, a felhasználók számára hasznos szerveralkalmazásokra.
Mail, vagy e-mail
Mi kell ahhoz, hogy az embereknek legyen levelük, ami nélkül sokszor már elképzelhetetlen az emberek közötti kommunikáció? Meglehetősen elterjedt módja a levelezőszerver telepítése, minden felhasználó számára postafiók létrehozása, és egy pop-démon beállítása, hogy az emberek felvehessék ezeket a leveleket. De ahhoz, hogy a szerver tudjon leveleket fogadni és küldeni, telepíteni kell rá levelező program mint a sendmail, postfix vagy qmail, amely UNIX gépen kezeli a leveleket. Hagyományosan a sendmailt használták erre a célra. Ma már a legtöbb gépen is ezt használják, de a másik két említett program jó, sőt továbbfejlesztett pótlása neki. A fő gondok azonban szokás szerint a védelemmel kapcsolatosak legújabb verziói sendmail (8.9.x) meglehetősen robusztus.
A Sendmail minden Linux rendszeren elérhető, a legújabb disztribúciók valószínűleg a 8.9.x verziót tartalmazzák. A program több konfigurációs fájlt használ, amelyeket a folyamat során elemzi. Mielőtt azonban a konfigurációról beszélnénk, megjegyezzük, hogy a program démonként és készenléti módban is futtatható. Az első esetben folyamatosan figyeli a portot, a másodikban pedig egyszer aktiválódik, és egyszerűen feldolgozza az összes bejövő információt. Biztonsági szempontból a második módszer előnyösebb. Ehhez csak el kell távolítania a -bd paramétert az indítási sorban.
Most a konfigurációról. A fő fájl a sendmail.cf, amely tartalmazhat hivatkozásokat más fájlokra, vagy nem. A hozzáférési fájl is elemzésre kerül, ahol olyan címeket lehet elhelyezni, amelyekről (vagy amelyekre) nem fognak levelet küldeni. Például a bejegyzések:
10.0.0 RELAY spam.com ELUTASÍTÁS
azt jelenti, hogy a .spam.com címekről érkező e-maileket nem fogadjuk el, a belső hálózatról érkező e-maileket pedig el lehet fogadni és el lehet küldeni.
Egy másik hasznos és használt fájl az álnevek. Meghatározza, hogy mely nevek legyenek értelmezve az adott postafiók neveként. Például, ha beállítja
Petrov: csillag
levelek érkeznek Petrovhoz a címre [e-mail védett] a dobozba küldjük [e-mail védett] még ha valaki nem is tudja valódi címet... Ez különösen akkor hasznos, ha azt szeretné, hogy az e-mailek olyan menedzserhez érkezzenek, aki nem a névkezelővel, hanem a sajátjával szeretne postafiókot tartani. Ez azt jelenti, hogy a menedzser csak azoknak adja meg a címét, akiknek jónak látja, és a menedzser kilóg a weboldalon. Nyilvánvalóan ez maximális kényelmet fog hozni vezetőváltás esetén. Tetszőleges számú név átirányítható ugyanabba a postafiókba.
A virtuserable fájl meghatározza az egyik címnek a másikhoz való hozzárendelését, például:
[e-mail védett] menedzser
E két fájl (aliasok és virtusertable) használatával megvalósítható a levélmásolódás, amely minden bejövő levelet ment. A trükk az, hogy először a virtuserable fájlt nézik meg, majd az álneveket. Ha a virtusertable utolsó bejegyzésével írja be az alias fájlba:
Menedzser: csillag, "/ var / spool / mail2 / star"
akkor a kezelő és a csillag címre érkező levelek a normál / var / spool / mail könyvtárba és a / var / spool / mail2 könyvtárba kerülnek.
Az egyik fő különbség a postfix és a sendmail között a modularitás (ami a qmailben is megvan). A sendmail-lel ellentétben a kódnak csak egy kis része, csak egy modul fut rootként, a többi rész pedig szükség szerint fut, és saját beállításai vannak. A postfix konfigurációs fájlok általában az / etc / postfix fájlban találhatók. A manager.cf fájl a különféle modulok működését kezeli, megadva azokat a felhasználókat, amelyek alatt futnak, és a folyamatok számát. A main.cf fájl a fő konfigurációs fájl, és magának a levélnek az alapvető paramétereit állítja be. Íme a hozzávetőleges nézet magyarázatokkal (pontosabban azok az összetevők, amelyeket valószínűleg szerkeszteni kell):
# gépnév myhostname = mail.example.org # domain mydomain = example.org # melyik címről küld e-maileket myorigin = $ mydomain # mely felületeken futtassa a programot inet_interfaces = all # virtuális nevek fájl virtual_maps = hash: / etc / postfix / virtual # névhelyettesítések fájlja alias_maps = hash: / etc / postfix / aliases # könyvtár, ahol a leveleket tárolni kell, amikor a felhasználó megkapja azt home_mailbox = Maildir / # a levél tárolási helye mail_spool_directory = / var / spool / mail # parancs levelek lekéréséhez mailbox_command = / usr / sbin / scanmails # fájl, amely jelzi a címeket, ahonnan és ahová a leveleket küldeni kell # relay_domains = / etc / postfix / relaydomains # helyi gépek mynetworks = 10.0.0.0/24, 127.0.0.0/8 # mit kell kiadni, ha a felhasználók a 25-ös porthoz csatlakoznak smtpd_banner = $ myhostname ESMTP $ mail_name
A postfix program letölthető a http://www.postfix.org webhelyről.
Most beszéljünk a POP és IMAP protokollokról. Az első a 110-es, a második a 143-as porton működik. Elvileg mindkettő ugyanazt a célt követi, de különböző módon valósulnak meg. A POP (postahivatali protokoll) meglehetősen régi és gyenge protokoll. Mindössze annyit tesz lehetővé, hogy csatlakozzon a szerverhez, fogadjon leveleket és törölje azokat a szerveren lévő postafiókból. IMAP protokoll fejlettebb. Lehetővé teszi a levelek kezelését közvetlenül a szerveren. Nem kell letöltenie az összes levelet, hanem csak a levelek fejlécét kell vennie, könyvtárakat kell létrehoznia a szerveren, és elosztani közöttük a leveleket. Biztonsági szempontból ezek a protokollok megegyeznek, ezért a baj elkerülése érdekében célszerű tűzfalat használni. Ezen protokollok forgalmát az ssh-n belül is elhelyezheti. Nagyon fontos, hogy ellenőrizze a leveleit vírusok szempontjából. Bár a vírusok nem ijesztőek a UNIX rendszerben, mivel sok felhasználó Windows rendszert használ, bölcs dolog az e-maileket egy szkenner programmal, például az AMAVIS-en keresztül futtatni. Ennek legegyszerűbb módja (persze feltételezzük, hogy az AMAVIS program már telepítve van), ha a konfigurációs sorban postfixben van
Mailbox_command = / usr / bin / procmail
Mailbox_command = / usr / sbin / scanmails
Röviden arról, hogy a felhasználó hogyan fogad és küld leveleket a munkahelyén. Szerencsére minden népszerű program POP vagy IMAP kliens (legalábbis a Netscape-re és az Outlookra gondolok). Ráadásul, ha az adminisztrátor lehetőséget adott a szerver elérésére telneten vagy ssh-n keresztül, akkor megtekintheti a leveleket, és terminál módban dolgozhat velük (ebben az esetben a felvétel nehezebb). Ehhez csatlakozni kell a szerverhez, és a terminálban futtasson valamilyen levelezőprogramot, például mailt vagy pine-t. Ez utóbbi sokkal kényelmesebb, és egy teljes képernyős program menüvel, csak szöveges módban.
Fájlhozzáférés és hálózati nyomtatás
UNIX rendszeren kettő van szabványos szerszámok- NFS és LPD. Az első lehetővé teszi a hálózati fájlrendszerek létrehozását, a második a nyomtatóra való nyomtatást. Ami egy UNIX-os gép erőforrásait illeti Windowsból, erre a Samba (SMB) a legalkalmasabb, ahogy látom. Ez a program lehetővé teszi a fájlok elérését, és lehetővé teszi a hálózati nyomtatást Windows rendszerű gépről UNIX kiszolgálón keresztül. Mivel ez a cikk elsősorban a szerverek biztonságáról szól, meg kell jegyezni, hogy a hálózaton belüli erőforrások megosztása nem veszélyes, természetesen a külső tűzfalszabályok normál konfigurációja mellett. Itt más tervproblémák merülhetnek fel, amelyek azzal kapcsolatosak, hogy nem mindenkinek kell hozzáférnie ehhez vagy ahhoz az információhoz, de ezt teljes mértékben a fájlok és könyvtárak attribútumainak beállításai szabályozzák. Bármilyen ügyes rendszergazda is vagy, nem tudod megakadályozni azt a helyzetet, amikor például valaki elfelejti bezárni az ssh-munkamenetet, és elhagyja a számítógépet. Más kérdés, hogy bizonyos fájlokhoz olvasási hozzáférést ad-e, de ezek túl nyilvánvaló dolgok ahhoz, hogy elgondolkodjunk rajtuk. Ezért most olyan szerveralkalmazások mérlegelésére térünk rá, amelyek nemcsak a belső, hanem a külső felhasználók számára is hasznosak. Elsősorban webszerverre gondolok és talán ftp-re. Ma már nehéz elképzelni a legkisebb céget vagy akár csak egy hálózatot az első nélkül, a második megléte pedig attól függ, hogy valóban szükség van-e egyes adatok külön feltöltésére egy ftp szerverre.
Web és ftp szerverek
Az Apache vitathatatlanul vezető szerepet tölt be a ma létező néhány webszerver között a népszerűség és a teljesítmény tekintetében. Ez a szerver egyesíti a sebességet, a stabilitást, a magas szintű biztonságot, ugyanakkor ingyenes. Nem mindig lehet ilyen programot találni saját célra, de itt van. És el kell ismernünk, hogy a program készítői rengeteg erőfeszítést tesznek a maximális hatékonyság és megbízhatóság elérése érdekében. Mindenekelőtt vegye figyelembe, hogy ha a webszervert csak belső célokra használja, például rendszeradminisztrációra vagy fájlmegosztásra, akkor mindenképpen tűzfalat kell helyeznie a külvilágból. Ha ez a szerver mindenki számára elérhető, akkor meg kell értenie, hogy mindenki számára nyitva áll. Ezért szükséges a megfelelő figyelése, nevezetesen: gondosan és helyesen konfigurálja, és figyelje a naplófájlokat, hogy előre meghatározhassa az esetleges támadást. Ami a biztonságot illeti, maga a szerver nagyon kevés hozzáféréssel rendelkezik a rendszerhez, mivel csak az első példánya indul rootként, a többi pedig általában senkiként. Ezenkívül a szerver beállításaiban, azaz a httpd.conf, smr.conf, access.conf fájlokban egyértelműen fel van tüntetve, hogy a szerver mely könyvtárakhoz fér hozzá és melyekhez nem. Ha például a httpd.conf fájlba írod:
akkor kifejezetten jelezni fogja, hogy a szerver csak a / WWW könyvtárhoz fér hozzá, ahová el kell helyezni az oldal (vagy oldalak) összes anyagát, amelyek munkáját a szerver biztosítja. Ha biztos akar lenni abban, hogy senki sem változtatja meg a hozzáférési jogokat azáltal, hogy például a .htaccess fájlt valamilyen könyvtárba helyezi, akkor az srm.conf fájlba a következőket kell beírnia:
Biztonsági szempontból nincs értelme más beállításokról részletesebben beszélni, különösen azért, mert az Apache-kiszolgáló telepítését és minimális konfigurációját az előző számban egy e témának szentelt cikkben ismertettük.
Külön ki kell térni a https (biztonságos http) protokoll használatára. Ez a protokoll általában a 443-as porton fut (szemben a 80-as porton futó szabványos http-vel). Legalább kétféleképpen gazdagíthatjuk az Apache-t biztonságos http-vel. Az első az open-ssl bővítmény, a második a mod_ssl modul használata. Mindkét lehetőség közel azonos eredményhez vezet. Általánosságban elmondható, hogy a 443-as porton https használatával lehet kapcsolatokat létesíteni. Ez létrehoz egy tanúsítványt a szerver számára, amelyet az ügyfelek a csatlakozáskor ellenőriznek. Ez kizárja (természetesen nem teljes garanciával) a forgalom lehallgatását. Tanúsítvány létrehozásához openssl használatakor a következő parancsokat kell kiadnia:
Openssl genrsa -des3> httpsd.key openssl req -new -key httpsd.key> httpsd.csr
továbbá a fájloknak ugyanabban a könyvtárban kell lenniük, ahol a szerver konfigurációs fájljai találhatók. Ahhoz, hogy a szerver megfelelően működjön a 443-as porttal, a konfigurációs fájlokat is módosítani kell. Valami ilyesmit kell írniuk
# figyel a 443-as porton (alapértelmezés szerint a szerver csak a 80-as porton figyel) Listen 443 # disable globális használat ssl SSLDisable # az a hely, ahol a szerver ideiglenes információkat tárol az ssl kapcsolat során. # e beállítás nélkül a szerver nem fog működni SSLCacheServerPath / usr / bin / gcache # port, amelyen keresztül a szerver kommunikál a CashServerrel SSLCacheServerPort 12345 # CashServer időtúllépés SSLSessionCacheTimeout 300
Ezen beállítások után a szervere alapvetően készen áll a https protokoll használatára, de egyelőre ez a protokoll tilos. Célszerű létrehozni egy virtuális gazdagépet, amelynek neve megegyezik az alapértelmezettvel, de a 443-as portot kifejezetten meg kell jelölni, vagyis most már fut egy webszerver. A 80-as porton fut, és a http protokollt használja. Az apache-ssl és a fent leírt beállítások hozzáadásával lehetővé tette a felhasználók számára, hogy a https protokollon keresztül kommunikáljanak a szerverével. Nem valószínű, hogy a szerverén lévő összes információ annyira titkosított, hogy csak biztonságos kapcsolati módban szeretné kiadni az összes információt. Az Apache szerver lehetővé teszi virtuális gépek létrehozását, azaz deklarálhatunk valamilyen gyökér alkönyvtárat egy gazdagéphez, nevet adunk neki, beírhatunk konfigurációs fájlokat és minden mást, ami szükséges, de fizikailag az a számítógépét, és a saját szervere fogja vezérelni... Esetünkben nem is szükséges más nevet adni, hiszen ugyanaz, csak más port. Így nézhet ki egy ilyen beállítás:
A http mellett létezik még az ftp is - ez egy hasznos és kényelmes szolgáltatás, különösen akkor, ha sok fájlja van, amelyeket a felhasználóknak le kell tölteniük (például bizonyos kutatások adatait adjátok meg). Az ftp előnye a http-vel szemben a sebesség. Az ftp protokoll minimális többletköltséggel rendelkezik. Sok probléma van azonban vele. A fő a "kora": az ftp egyidős a telnettel. Ebből azonnal biztonsági bonyodalmak keletkeznek: a felhasználónév és a jelszó tisztán továbbításra kerül, a továbbított információk forgalmát pedig semmi sem védi. Ezen kívül az ftp csak fájlokat tud továbbítani. Ezért, ha rendelkezik olyan információval, amely mindenki számára elérhető, akkor célszerű létrehozni egy felhasználót, akinek a neve alatt mindenki belép. Az ilyen ftp-archívumokban ezt a felhasználót gyakran anonimnak hívják, és jelszóként megadja az e-mail címét. Ebben az esetben sokkal kevesebb a biztonsági probléma. Ezenkívül abban az esetben, ha több felhasználónak kell ftp hozzáférést biztosítania, készítsen egy chrootot, hogy csak a saját könyvtáraikba helyezhesse el a fájlokat. Ami a szervereket illeti, természetesen szabványos csomagokban kaphatók, de lehet, hogy nem szabványos ftpd-t akarsz telepíteni, hanem valami mást.
Az egyik népszerű ftp szerver a proftpd. Konfigurációs fájljai hasonlóak az Apache fájlokhoz, ami megkönnyíti a hozzájuk való alkalmazkodást, mivel valószínűleg az Ön webszervere az Apache. A fő konfigurációs fájl az /etc/proftpd.conf. Hozzávetőleges kinézete a következő lehet:
Kiszolgálónév "ProFTPD alapértelmezett telepítés" Kiszolgálótípus inetd DefaultServer a 21-es porton Umask 022 MaxInstances 30 Felhasználó senki sem Csoportosít senki
A fenti felsorolás azt jelzi, hogy a szerver az inetd-n keresztül indul, a szabványos 21-es porton, a másolatok maximális száma 30, és csoportként és felhasználóként senkiként indul. 022 - a fájlattribútumok maszkja a létrehozás során, amely kezdetben standardként kerül alkalmazásra. Ez a konfiguráció nem ad hozzáférést az anonim felhasználónak. Ehhez körülbelül a következő konfigurációs beállításokat kell beírnia:
E kiegészítés után lehetővé válik a névtelen munka, és csak fájlok olvasása, azaz letöltése. Mondok még egy példát a könyvtárhasználati jogok beállítására:
A konfigurációs fájl ilyen bejegyzése írási jogosultságot ad, de nem ad jogot a fájlok letöltésére. Ez akkor hasznos, ha azt szeretné, hogy a felhasználók feltölthessenek fájlokat, de ne lássák, mit tettek be mások.
Ezzel a szerveralkalmazások témája lezárult. Persze meg kell jegyezni, hogy sokkal több szerveralkalmazás létezik: van még DNS, hírszerver, NIS szerver, az X szerver és még sok más érdekes és hasznos alkalmazás. Igyekeztem azonban arra összpontosítani, hogy valójában mire lehet szükség egy olyan hálózat működtetésekor, amely nem állítja magát globális kiberpolisznak vagy szolgáltatónak. Most térjünk át a cikk elején jelzett második kérdés megvitatására - a hálózati támadásokra és hackekre.
Hálózati támadások és hackek
Először is néhány általános szó. UNIX-ban a Windows-tól eltérően nincs probléma a vírusokkal. A memóriafoglalás és a fájlengedélyek belső struktúrája önmagában képes megbirkózni azzal, amit a vírusok általában a régi DOS-ban vagy Windowsban csinálnak. A vírusok (szokásos értelemben) fő akadálya a fizikai eszközökhöz való hozzáférés hiánya a normál felhasználó nevében futó programok számára, valamint az, hogy a fájlattribútumok nem általában, hanem a felhasználó, csoport, ill. minden felhasználó. A Windowsban nincs ilyen (ez részben a Windows 2000-ben van megvalósítva). Bár a hagyományos vírusok által okozott kellemetlenségek szinte lehetetlenek, a UNIX rendszereket még mindig feltörik és megsemmisítik. Ennek oka a teljesen eltérő technológiák jelenléte, amelyek nagyjából két kategóriába sorolhatók. Az első az úgynevezett trójai falók, amelyek látszólag és talán valójában is meglehetősen ésszerű és legális műveleteket hajtanak végre. Ezzel párhuzamosan azonban más "munkát" is végeznek: hallgatják a hálózatot, vagy információkat gyűjtenek a jelszavakról és elküldik a hálózatra, stb. Ezek a programok önmagukban valószínűleg nem okoznak közvetlen kárt – inkább közvetítők lesznek a rendszer és a külső támadó között. A második kategória a hálózati hackek. Ezek a műveletek kezdetben nem a gép belső tartalmára vonatkoznak, hanem megpróbálják tönkretenni a rendszert, vagy hozzáférni bizonyos információk elküldésével, például szándékosan hibás hálózati csomagokkal, vagy speciálisan kialakított kérésekkel próbálnak „becsalogatni” néhány rejtett adatot. . Miért kell egyáltalán feltörni a rendszereket? Ez inkább pszichológiai, mint gyakorlati kérdés. Az a helyzet, hogy a valóságban a gépekbe való betörések meglehetősen nagy része nem önző célokra vezethető vissza, hanem egyszerűen a folyamat iránti érdeklődésből. A rendszerint hackernek nevezett emberek között nem csak azok vannak, akik valódi haszon érdekében hackelnek, hanem olyan "rajongók" is, akik a hálózat feltörése érdekében törik meg a hálózatot. Ez váratlannak tűnik, de így van, és a statisztikák ezt mutatják. Ezenkívül gyakran meglehetősen nehéz egy személyt hibáztatni azért, amit tett, mivel néha lehetetlen bizonyítani, hogy ő és erről a számítógépről hajtott végre bizonyos illegális tevékenységeket. Ebben a cikkben azonban magukról a hackekről beszélünk, nem pedig azok pszichológiai és jogi vonatkozásairól, ezért konkrét dolgokra térünk át.
A hálózat feltörése, függetlenül attól, hogy milyen gondosan hajtják végre, és bármilyen módszert alkalmaznak is, elkerülhetetlenül bizonyos változásokhoz vezet a rendszerben. Ez lehet a figyelő portok új listája, az ismeretlen programok, a meglévő programok átméretezése, különösen a ps vagy a netstat, vagy akár új felhasználók. Így vagy úgy, a lényeg az, hogy valaminek változnia kell, és ez elkerülhetetlen. Ezért az első ésszerű lépés, amelyet a rendszer telepítése és konfigurálása után azonnal meg kell tenni, egy fájl létrehozása a rendszerrel kapcsolatos információkkal. Valami olyan, mint egy fénykép abban a pillanatban, amikor mindent helyesnek tartasz, ami történik. Pontosabban a netstat, vmstat, free, du, df programok által szolgáltatott információkra gondolok. A második tipp az, hogy készítsen biztonsági másolatot a rendszerkonfigurációs fájlokról és a kezdeti beállításokról. Ezek egymással való összehasonlítása is adhat némi információt arról, hogy mi történt a közelmúltban a rendszerben.
Kezdjük a fájlrendszer figyelésével, ami nem csak a fájlrendszer használatának figyelését foglalja magában (amit a du és df parancsokkal lehet megtenni), hanem bizonyos fájlok (például rendszerfájlok) megváltoztathatatlanságának ellenőrzését is. Számos program hajtja végre ezeket a funkciókat:
- AIDE - egy program, amely lehetővé teszi a fájlok ellenőrző összegeinek létrehozását, így ellenőrizve azok integritását; több algoritmus használatát teszi lehetővé. http://www.cs.tut.fi/~rammer/aide.html. (A többi program hasonló funkciókat lát el, mindegyik ingyenes.)
- Gog & Magog - létrehozza az attribútumok és fájltulajdonosok listáját, lehetővé teszi az automatikus összehasonlítást. http://www.multimania.com/cparisel/gog/
- Sentinel – létrehoz ellenőrző összegeket a RIPEMD-160bit MAC algoritmus használatával rendelkezik grafikus felület... http://zurk.netpedia.net/zfile.html
- A SuSEauditdisk egy hajlékonylemezre helyezett program, amely lehetővé teszi a rendszerellenőrzés teljesen autonóm végrehajtását, közvetlenül hajlékonylemezről indítva. A SuSELinux alapfelszereltsége. http://www.suse.de/~marc
- ViperDB – Ellenőrzi a fájltulajdonosokat és az attribútumokat azáltal, hogy naplófájlokat hoz létre, amelyek rögzítik a bekövetkezett változásokat. A programnak három paramétere van: -init - adatbázisokat hoz létre fájlok szerint, -check - ellenőrzi a fájlokat az adatbázisban, és változtatásokat hajt végre az adatbázison, ha azok lemezen vannak, -checkstrict - ellenőrzi a fájlokat az adatbázisban, és visszaadja a régi paramétereket, ha változások történtek. . http://www.resentment.org/projects/viperdb
- Sxid – Fájlok ellenőrző összegeit hozza létre, valamint ellenőrzi az attribútumokat és a tulajdonosokat. ftp://marcus.seva.net/pub/sxid/
- nannie - emlékszik a fájl létrehozási idejére. ftp://tools.tradeservices.com/pub/nannie/
- confcollect – emlékszik rendszer információ mint például a megállapított szoftver, router asztalok stb. http://www.skagelund.com/confcollect/
- A Pikt egy belső szkriptnyelvet tartalmazó eszköz programok készítése szabványos, de nem konkrét parancsok, funkciók formájában megvalósított funkciókat (a rendszer óránkénti használatának figyelése, hosszan tartó folyamatok kiiktatása, méret beállítása postafiók stb.). Különféle platformokhoz érhető el: Solaris, Linux és FreeBSD. http://pikt.uchicago.edu/pikt/
Lehet beszélni biztonsági mentési funkciókat ellátó programokról is, de ennek véleményem szerint semmi köze a rendszerbiztonsághoz, ráadásul a UNIX disztribúcióban különféle szabványos eszközök szerepelnek. A biztonság csak akkor lényeges, ha biztonsági mentések meg kell tenni, de erről már fentebb volt szó.
Most nézzük meg, mit tegyünk a hálózati támadások megelőzése érdekében. Természetesen tűzfalat kell telepíteni az átjáróra. Így vagy úgy, de csomagszintű védelem szükséges. Ha a tűzfalat bármilyen módon megkerüli, akkor a következő programok szükségesek:
- DTK - szabványos szolgáltatásokat és programokat emulál, és az ezeknek a programoknak küldött nem szabványos kérések esetén szándékosan hamis információkat bocsátanak ki a támadó megzavarása érdekében. http://all.net/dtk/
- Psionic PortSentry – Figyeli a portok vizsgálatát. A fő feladat a portok ellenőrzése a vizsgálathoz, és minden megjelenítése egy naplófájlban. http://www.psionic.com/abacus/portsentry/
- Psionic HostSentry – Adatbázist hoz létre a felhasználók géphasználati adataiból, és üzenetet jelenít meg, ha az erőforrás-használat rendellenes. http://www.psionic.com/abacus/hostsentry/
- Scanlogd - átvizsgálja a hálózati csomagokat, és a beállítások alapján naplófájlokat generál. http://www.openwall.com/scanlogd/
- A tűzfalak a tűzfalként funkcionáló programok gyűjtőneve.
- TCP-WRAPPERS – olyan programok, amelyek név vagy számítógépszám alapján korlátozzák a hozzáférést bizonyos erőforrásokhoz. Néhány ilyen program elérhető a következő címen. ftp://ftp.porcupine.org/pub/security/
- Az NFR egy felépítésében a szippantóhoz hasonló program (a sniffer a hálózati forgalom meghallgatására szolgáló program). Rögzíti a naplófájlokat, és valós időben észleli a támadásokat és a portvizsgálatokat. http://www.nfr.com/
- A hálózati támadásokkal és azok észlelésével kapcsolatos részletes és hasznos GYIK a http://www.robertgraham.com/pubs/network-intruusio-detection.html címen található.
Nehéz egyértelműen válaszolni arra a kérdésre, hogy mit és hogyan kell tenni a hálózati támadások során. Itt sok múlik mind az adott hálózat, mind a szervezet sajátosságaitól, amelyben található. Még egy azonos típusú támadásnál is az egyik esetben először menteni kell az adatokat, a másodikban pedig blokkolni a támadás forrását, vagyis minden a prioritásoktól függ. A támadások nagyon nehéz problémát jelentenek azokban a szervezetekben, ahol a hálózati leállás elfogadhatatlan. Ott minden műveletet online kell végrehajtania, amennyire csak lehetséges, tartva a kapcsolatot a külvilággal. Nagyon sok múlik a támadás természetén is. A hackelés a hackelés érdekében egy dolog, a minősített adatok céltudatos ellopása pedig egy másik dolog. Talán igaz, és egy kifinomultabb változat, amikor a támadást azzal a céllal hajtják végre, hogy elvonják a rendszergazdát a párhuzamosan végrehajtott kifinomultabb és átgondoltabb hackeléstől. De ne gondold, hogy támadás csak kívülről jöhet. Lehet, hogy belülről indul. Egy lehetséges forgatókönyv egy trójai faló elindítása egy Windows számítógépen a belső hálózaton. Nyilvánvaló, hogy ez egyszerűen megtehető egy levél küldésével. Most nézzük meg közelebbről a szippantó programokat.
Általában a szippantás azt jelenti, hogy kiszimatolunk. Ezért a snifferek olyan programok, amelyek valamilyen módon hallgatják a hálózatot és az azon áthaladó összes információt. Szemléltető példa egy olyan jelszó, amely tiszta szövegben érkezik innen belső számítógép a szerverre. Mivel a csomagok az egész hálózaton keresztül haladnak, amíg meg nem találják a címzettet, a sniffer telepítése a belső hálózat legalább egy számítógépére (például levél használatával, ahogy fentebb említettük) kényelmes eszköz külső kekszhez. A legtöbb esetben a szimatolók meglehetősen passzívak, ami megnehezíti észlelésüket. Az alábbiakban felsorolunk néhány olyan programot, amelyek szippantóként működnek, és amelyek segítségével nyomon követheti, mi történik a hálózaton:
- A Tcpdump az összes UNIX-szal szállított legrégebbi program.
- Sniffit - képes a csomagok szűrésére és az információk szöveges formátumba való lefordítására; grafikus felülettel ellátva. http://sniffit.rug.ac.be/~coder/sniffit/sniffit.html
- Az Etheral egy hálózati protokollelemző.
- Snort - a hálózat figyelésére tervezték, képes észlelni a port vizsgálatokat. http://www.clark.net/~roesch/security.html
- A SPY szimatoló, de nem ingyenes. Legfeljebb öt géphez ingyenes egyfelhasználós hálózati licenc áll rendelkezésre. http://pweb.uunet.de/trillian.of/Spy/
Nem szabad azonban megfeledkezni arról, hogy a szoftverek mellett hardveres lehallgatás is létezik, például egyszerűen csak csatlakoztatunk egy másik számítógépet, vagy egyszerűen csak kábelre csatlakozunk. Érdekes módon, ha vékony Ethernet-kábelt (koaxiális kábelt) használsz, akkor kinyitás nélkül is hallgathatod.
- Az AntiSniff egy olyan program, amely megkeresi a hálózatot szippantókra. Működési elve nagyon egyszerű: kérést küld, és a válasz és a válaszidő alapján meghatározza, hogy azt valamilyen más program feldolgozza-e vagy sem. http://www.l0pht.com/antisniff/
A szippantókkal kapcsolatos részletes és hasznos GYIK a következő címen található:. http://www.robertgraham.com/pubs/sniffing-faq.html.
Egy másik módszer, amely segíthet a támadások megelőzésében, a rendszer tesztelése olyan programokkal, amelyek támadásokat emulálnak, vagy magukkal a programokkal, amelyekkel ezeket a támadásokat végrehajtják. Ellenőrzi a rendszert harci körülmények között. Ha ennél a gépnél valóban a biztonság a legfontosabb, akkor a rendszerkonfiguráció ellenőrzése a csatlakoztatás előtt nagyon fontos lépés. Felhívom a figyelmet néhány ilyen programra.
A rendszert belülről vizsgáló programok:
- A Tiger egy még fejlesztés alatt álló program. ftp://net.tamu.edu/pub/security/TAMU/
- check.pl - Perl szkript, amely ellenőrzi a könyvtárfát és a benne lévő fájlokat, és rámutat a különböző megkérdőjelezhető attribútumokra és tulajdonosnevekre. http://opop.nols.com/proggie.html
Hálózati szkennerek, amelyek egy másik rendszeren könnyen elérhető szolgáltatásokra mutatnak (jó ötlet például a tűzfalbeállítások ellenőrzéséhez):
- A Strobe egy régi, de gyors és még mindig hatékony hálózati szkenner. Néha a UNIX része. ftp://suburbia.net/pub/
- Az Nmap egy olyan program, amely új portellenőrzési módszereket használ, és nagymértékben konfigurálható. Lehetővé teszi az operációs rendszer paramétereinek (név, verzió) beszerzését. http://www.insecure.org/nmap/index.html
- A Portscanner egy kis portszkenner, amely számos formátummal rendelkezik a feldolgozott információk kimenetére. http://www.ameth.org/~veilleux/portscan.html
- A Queso valójában nem szkenner; ez egy program, amelyet arra terveztek, hogy meghatározza az operációs rendszer típusát egy távoli számítógépen. http://www.apostols.org/projectz/queso/
A potenciális biztonsági rések keresésére szolgáló szoftver kétségtelenül egy lépés a portszkennerekhez képest. Itt magasabb szintű információelemzést alkalmaznak, és nem magukat a nyitott portokat határozzák meg, hanem a rendszer azon sérülékenységeit, amelyek felé ezeken a portokon keresztül nyitva van az út. Megnevezek néhány ilyen programot:
- A Nessus egy kliens-szerver támadáskövető szoftver. Vannak szerverek Linuxhoz, FreeBSD-hez, NetBSD-hez és Solarishoz, valamint kliensek Linuxhoz és Windowshoz. A portok ellenőrzése és a támadások nyomon követése mellett a program DNS-kereséseket is végezhet a feltört géphez társított számítógépek megtalálása érdekében. http://www.nessus.org/
- Saint a Sátán program leszármazottja, amely korábban az egyik legnépszerűbb volt az autókkal kapcsolatos információgyűjtésben. A Saint kliens-szerver architektúrát használ, de a klienst egy webprogrammal helyettesíti. A fő cél az, hogy információkat gyűjtsenek a rendszer védelmének sérülékenységeiről. http://www.wwdsi.com/saint/
- A Cheops egy olyan program, amely térképet készít az IP hálózati környezetről a számítógépeken futó operációs rendszer jelzésével. http://www.marko.net/cheops/
- A SARA (Security Auditor's Research Assistant) a Saint-hez hasonló program. Egyszerre több gépet is képes szkennelni, ráadásul HTML formátumban készíti el a munka eredményét. http://home.arc.com/sara/
- A BASS (Bulk Auditing Security Scanner) egy olyan program, amelynek ideológiája azon a tényen alapszik, hogy az internet nem védett. A fő feladat a rendszerek átvizsgálása, hogy vannak-e "biztonsági lyukak" bennük. http://www.securityfocus.com/data/tools/network/bass-1.0.7.tar.gz
A Firewalk a tűzfal átvizsgálására és megfelelő beállítására irányuló program. A program különféle csomagok küldésével igyekszik kiszámítani, hogy a tűzfal milyen szabályok szerint működik. http://www.packetfactory.net/firewalk/
A http://www.rootshell.com/ címen található archívum ismert adatokat tartalmaz a rendszervédelem hibáiról, és hivatkozásokat tartalmaz az operációs rendszer gyártóitól származó, ezeket a hibákat kijavító kiegészítőkre. Igaz, néha egy ilyen hivatkozás helyett a "Frissítés a következő verzióra" üzenet látható, ami sértő, főleg, ha a rendszer kereskedelmi jellegű. Ez például gyakran előfordul az IBM AIX esetében.
Ezzel szeretném befejezni a rendszerek biztonságával kapcsolatos kérdések ismertetését Internet szerverek... Ez egy leírás, nem cselekvési útmutató és nem egy részletes hivatkozás. Fő célom az volt, hogy képet adjak arról, mit kell tenni a rendszer védelme érdekében. Valószínű, hogy bizonyos esetekben a tanácsok egy része feleslegesnek vagy egyszerűen szükségtelennek tűnik, és talán a programokra mutató hivatkozások sem lesznek elegendőek. Számomra azonban úgy tűnik, hogy a UNIX rendszerek és hálózatok védelmével kapcsolatos főbb szempontok valamilyen szinten tükröződtek. Néhány magánkérdésről talán a magazin következő számaiban lesz szó.
ComputerPress 3 "2001
SSH - (Secure Shell) - egy hálózati protokoll, amely lehetővé teszi távirányító számítógép és fájlátvitel. Funkciójában hasonló a Telnet és az rlogin protokollokhoz, de titkosítási algoritmusokat használ a továbbított információkhoz.
A telnet hiányosságai a protokoll nagyon gyors fokozatos megszüntetéséhez vezettek, a biztonságosabb és funkcionálisabb SSH protokoll javára. Az SSH mindezt biztosítja funkcionalitás amelyeket a telnetben mutattak be, hatékony kódolással, amely megakadályozza az adatok, például a felhasználónevek és jelszavak elfogását. Az SSH nyilvános kulcsú hitelesítési rendszer biztosítja ezt távoli számítógép tényleg az, akinek mondja magát.
Az SSH protokoll kriptográfiai biztonsága nem rögzített, többféle titkosítási algoritmus választható. Az ezt a protokollt támogató ügyfelek és szerverek különféle platformokon érhetők el. Ezenkívül a protokoll nemcsak biztonságos távoli shell használatát teszi lehetővé a gépen, hanem a grafikus felület alagútba helyezését is - X Tunneling (csak Unix-szerű operációs rendszerhez vagy az X Window System grafikus felületet használó alkalmazásokhoz). Az SSH arra is képes, hogy biztonságos csatornán (Port Forwarding) keresztül bármilyen más hálózati protokollt továbbítson, biztosítva (megfelelő konfiguráció mellett) nemcsak az X-interfész, hanem például a hang biztonságos továbbítását is.
Az SSH azonban nem old meg minden hálózati biztonsági problémát. Csak a biztosításra összpontosítja a figyelmét biztonságos munkavégzés alkalmazások, például terminálemulátorok. Az SSH-protokoll-megvalósítások kiszolgálókon és ügyfélalkalmazásokban való használata csak az átvitel során védi az adatokat. Az SSH semmiképpen sem helyettesíti a tűzfalakat, a behatolásjelző rendszereket, a hálózati szkennereket, a hitelesítési rendszereket vagy a védelmet segítő egyéb eszközöket. Információs rendszerekés hálózatokat a támadásoktól.
39. A szerver szerepe és feladatai a helyi hálózatban.
Általános értelemben a szerver olyan számítógép, amely rendszerint nagy teljesítményű és egyéb számítási erőforrásokkal rendelkezik, amelyeket arra terveztek, hogy bizonyos képességeket biztosítsanak a helyi vagy globális hálózaton lévő számítógépek számára. Ezeket a lehetőségeket ún hálózati szolgáltatások .
Szerverfeladatok:
1. hozzáférés biztosítása a szervezet szerverlemezein tárolt adatokhoz;
2. tárolás, feldolgozás és hozzáférés a cég adatbázisaihoz;
3. a felhasználó által neki küldött adatok programozott feldolgozása, és ennek a felhasználónak adja meg a végeredményt;
4. a weboldal eljuttatása az azt igénylő felhasználóhoz;
5.küldés, fogadás, tárolás és terjesztés e-maileket amelyeket a helyi hálózat összes felhasználója küld.
Hálózati szolgáltatások.
A végfelhasználó számára a hálózat nem számítógépek, kábelek és hubok vagy akár információáramlás, számára a hálózat mindenekelőtt a hálózati szolgáltatások összessége, amellyel megtekintheti a hálózaton lévő számítógépek listáját, olvashat egy távirányítót. fájlt, nyomtasson dokumentumot „idegen” nyomtatón vagy küldjön e-mailt. A nyújtott képességek összessége – hogy milyen széles a választékuk, mennyire kényelmesek, megbízhatóak és biztonságosak – határozza meg, hogy a felhasználó számára milyen megjelenésű egy adott hálózat.
A hálózati szolgáltatásoknak a tényleges adatcsere mellett más, specifikusabb feladatokat is meg kell oldaniuk, például elosztott adatfeldolgozással generált feladatokat. Ilyen feladatok közé tartozik a különböző gépeken található több adatmásolat konzisztenciájának biztosítása (replikációs szolgáltatás), vagy egy feladat párhuzamos végrehajtásának megszervezése a hálózat több gépén (távoli eljáráshívás szolgáltatás). A hálózati szolgáltatások között megkülönböztethetők az adminisztratív szolgáltatások, vagyis azok, amelyek elsősorban nem egy egyszerű felhasználóra, hanem egy rendszergazdára összpontosítanak, és a hálózat egészének megfelelő működését szolgálják.
A hálózati szolgáltatások megvalósítása megtörténik szoftverrel... Az elsődleges szolgáltatásokat – a fájlszolgáltatást és a nyomtatási szolgáltatást – jellemzően a hálózati operációs rendszer nyújtja, míg a kiegészítő szolgáltatásokat, mint például az adatbázis-, fax- vagy hangszolgáltatást a rendszerhálózati alkalmazások vagy segédprogramok biztosítják, amelyek szorosan együttműködnek a hálózati operációs rendszerrel. hálózati operációs rendszer. Általánosságban elmondható, hogy a szolgáltatások elosztása az operációs rendszer és a segédprogramok között meglehetősen önkényes, és az operációs rendszer egyes megvalósításaitól függően változik.
Az átláthatóság kifejezést gyakran használják a megosztott erőforrások kényelmének meghatározására. Az átlátszó hozzáférés olyan hozzáférés, amelyben a felhasználó nem veszi észre, hogy a szükséges erőforrás hol található - a számítógépén vagy egy távoli számítógépen. Miután felcsatolta a távoli fájlrendszert a könyvtárfájába, lépjen be a következőhöz: törölt fájlok teljesen átlátszóvá válik számára. Maga a beillesztési művelet is eltérő fokú átlátszósággal rendelkezhet - a kisebb átlátszóságú hálózatokban a felhasználónak ismernie kell és a parancsban meg kell adnia annak a számítógépnek a nevét, amelyen a távoli fájlrendszer tárolva van; a nagyobb átlátszóságú hálózatokban , a hálózat megfelelő szoftverösszetevője megkeresi a megosztott fájlköteteket, függetlenül azok helyétől.tárolás, majd a felhasználó számára megfelelő formában, például lista vagy ikonkészlet formájában átadja azokat a felhasználónak.
A megosztott hálózati erőforrások címzésének (elnevezésének) módja fontos az átláthatóság szempontjából. A megosztott hálózati erőforrások neve nem függhet az adott számítógépen lévő fizikai helyüktől. Ideális esetben a felhasználónak nem szabad semmit megváltoztatnia a munkájában, ha a hálózati rendszergazda áthelyezett egy kötetet vagy könyvtárat egyik számítógépről a másikra. Maga a rendszergazda és a hálózat operációs rendszer rendelkezik helyinformációkkal fájlrendszerek, de rejtve van a felhasználó elől. Ilyen mértékű átláthatóság még mindig ritkán látható a hálózatokban – általában ahhoz, hogy hozzáférjünk egy adott számítógép erőforrásaihoz, először logikai kapcsolatot kell létrehozni vele. Ezt a megközelítést alkalmazzák pl Windows hálózatok NT
