9. Alkalmazási réteg

A hálózati alkalmzások rendszerint az OSI modell felső, alkalmazási (applikációs) rétegében helyezkednek el.

Tennivaló

• Hálózati modellek: szerver-kliens, peer-to-peer

9.1. Névszerverek

A névszerver szolgáltatást egyes források nem sorolják egyértelműen az applikációs rétegbe, hanem másokban említik, de mi ebben a fejezetben tárgyaljuk. A névszerverek fő feladata az internetes nevek IP címekké valamint az IP címek nevekké alakítása. A névszervereket gyakran DNS (Domain Name System) néven említik, de ugyanezt a megnevezést használják a folyamat során alkalmazott kommunikációs protokollra is. A DNS működése során a nevek IP címmé alakítását névfeloldásnak, a címek nevekké alakítását pedig címfeloldásnak nevezik.

Internetes nevek használatával számos ponton találkozthatunk, legtöbbször talán a böngészőprogramok alkalmazásakor gépelünk be ilyeneket. Bár a címsorba írt www.uni-nke.hu név könnyen megjegyezhető egy felhasználó számára, az eddig tanultak alapján már tudjuk, hogy a kommunikáció során a számítógépünk végül IP címeket használ, így minden név mögött valójában egy (egyes esetekben több) IP cím áll. Az internetes nevek alkalmazása hasonló egy mobiltelefon címjegyzékéhez: csak kényelmi okból használjuk, technikai szempontból nincs rá szükség, hiszen a készülék végül telefonszámot hív akkor is, ha azt a hívó nem is látja. A telefonkönyv a névszervernek, egy névhez rendelt telefonszám pedig az IP címnek felel meg. Az alábbi példában a már ismert ping parancsnak nem IP címet, hanem nevet adunk meg paraméterként, a válasz első sorában pedig látható, hogy a névfeloldás során a neptun.uni-eszterhazy.hu nevet a 193.225.32.220 IP címmé alakította, majd csak ezt követően pingelte.

feri@w3.linux-szerver.hu:$ ping neptun.uni-eszterhazy.hu
PING neptun.uni-eszterhazy.hu (193.225.32.220) 56(84) bytes of data.
64 bytes from neptun.uni-eszterhazy.hu (193.225.32.220): icmp_seq=1 ttl=119 time=6.21 ms
64 bytes from neptun.uni-eszterhazy.hu (193.225.32.220): icmp_seq=2 ttl=119 time=6.47 ms
64 bytes from neptun.uni-eszterhazy.hu (193.225.32.220): icmp_seq=3 ttl=119 time=6.39 ms

Az internetes nevek kezelésének módja az első időkben (értsd: az 1970-es években) a maitól teljesen eltérő volt. Akkoriban jó módszernek tűnt egy speciális fájl létrehozása az egyes rendszerekben, amely az egyes neveket és a hozzájuk tartozó IP címeket tartalmazta. Az alkalmazások ezt a fájlt használták a nevek IP címmé alakításakor (tehát a névfeloldáskor) ha egy név-IP páros szerepelt ebben a fájlban, akkor azt az operációs rendszer képes volt a megfeleltetésükre. Annak ellenére, hogy ez a módszer ma már teljesen idejétmúlt, az operációs rendszerek még mindig alkalmazzák ezt a módszert. A Windows rendszerekben ez a fájl a \windows\system32\drivers\etc\hosts, Unixokon, így pl. az android rendszerű telefonokon is a /etc/hosts. A fájlok szerkezete azonos, az IP címet követően az ahhoz tartozó neveket kell felsorolni:

127.0.0.1       localhost
87.229.94.242   w3.linux-szerver.hu     w3

A példában három névhez rendeltünk IP címet. Az első a localhost, melynet a rendszer a 127.0.0.1-es címre alakít át. A w3.linux-szerver.hu és a w3 nevek egyaránt a 87.229.94.242-es címnek felelnek meg.

Veszély

A hosts file módosítása egyszerű és hatékony lehetőséget nyújthat egy támadó számára ahhoz, hogy a felhasználót az eredeti célja helyett egy másik számítógépre irányítsa. Amennyiben hozzáférést nyer ehhez, képes lehet abban egy olyan sort elhelyezni, amellyel a bankunk nevéhez (pl. www.cib.hu) egy másik, hamis weboldal IP címét rendeli hozzá pl. így:

11.11.11.11 www.cib.hu

Mivel a névfeloldás általában a hosts fájl kiértékelésével kezdődik, a bank nevének megadásakor nem annak valódi IP címét használja majd a rendszer, hanem a fájlban szereplő 11.11.11.11-et. Az ilyen típusú csalások során a felhasználó a böngészó címsora alapján nem tudja megállapítani, hogy valójában egy hamisított oldalt látogatott meg.

Megjegyzés

• Egyes szoftverek „feltörése” szintén a hosts fájl tartalmának módosításán alapul. Az Adobe termékeinek illegális aktiválásakor az jogszerű felhasználást visszaigazoló szerverek nevét ebben a fájlban módosított címekkel rögzítik, ezek az eredetivel ellentétben a jogtisztaság ellenőrzéskor mindig megerősítő választ adnak. A hosts file védelme tehát a szoftver jogtisztaság fenntartása érdekében is elengedhetetlen.

• A hosts fájl egy kezdetleges megoldást adhat egyes website-ok elérhetetlenné tételére is. A 1.2.3.4 www.facebook.com bejegyzés elhelyezésekor a facebook.com nevet nem a saját, hanem az így megadott hamis (1.2.3.4) IP címmel rendeli össze az operációs rendszer, így a felhasználó az eredeti oldalt sohasem fogja elérni.

A fenti példák mutatják, hogy a névfeloldással kapcsolatos csalások nehezen felismerhető, a támadók szempontából kifejezetten hatékony módszert jelentenek, ezért a hosts file és a névszerver rendszer sértetlenségének megőrzésére különös figyelmet kell fordítani. Ez az oka annak is, hogy nagybiztonságú rendszerek felépítése során minimálisra csökkentik a nevek belső használatát, helyette „bedrótozott” (rögíztett) IP címeket alkalmaznak.

A hosts file tehát a mai modern operációs rendszerekben még mindig rendelkezésre áll, de önmagában már nem alkalmazható. A 70-es évek óta internetes nevek milliói jelentek meg, ezek mindegyikét minden gépre eljuttatni és ott tárolni ma már lehetetlen feladat lenne, ezért egy új megoldást kellett kitalálni. Ez a már említett Domain Name System, röviden DNS.

A DNS kidolgozásakor egy hierarchikus rendszert képzeltek el, ezért a nevek nem egyszerű szövegek, hanem több, egymástól pontokkal elválasztott tagból állnak. Az eredeti, az USA-ra kidolgozott rendszer egyik alapelve az volt, hogy a név utolsó eleme írja le, hogy tulajdonosa a kormányzathoz, a hadsereghez, az oktatáshoz vagy éppen a kereskedelmi szférához tartozik-e. Ezért a nevek utolsó tagjaként rendre a .gov (government), .mil (military), .edu (education) és a com (commercial) rövidítéseket határozták meg. A nevek utosó tagját Top Level Domain-nek, röviden TLD-nek nevezik. A TLD-k alá az egyes szervezetek másodlagos domain neveket ún. Second Level Domain-eket, SLD-ket regisztrálhatnak, így kerül a tulajdonukba pl. az environment.gov vagy az envinronment.edu név. Az előbbit pl. egy amerikai környezetvédelmi hatóság, a másodikat egy környezetvédelemmel foglalkozó oktatási intézmény kaphatta meg.

Az internetet idővel az Egyesült Államokon kívül is használni kezdték, ezért a meglevő rendszert újabb TLD-kkel bővítették, melyek az egyes országok neveinek rövidítései voltak. Így hozták létre a .hu, a .de, és a .uk TLD-ket. (Az aktuális teljes lista pl. itt tekinthető meg). Érdekesség, hogy a .tv domain nevet Tuvalu birtokolja, ezt a TLD-t viszont a névazonosság miatt előszeretettel használják televíziós társaságok. Az Európai Unió szintén rendelkezik TLD-vel, ez a .eu.

Veszély

• A nevek alkalmazásakor a támadók esetenként kihasználják, hogy apróbb eltéréseket a felhasználók nem vesznek észre. Ilyan magyar vonatkozású eset volt a .qov.hu: az eredeti .gov.hu-tól való eltérés egyáltalán nem feltűnő, így alkalmas lehet a felhasználók megtévesztésére és hamis weboldalakra csalogatására. A témában számos cikk jelent meg, pl. itt.

Egy domain név regisztrálása csak adott időre, nem igazán magas díj megfizetése mellett végezhető el, és a regisztrációt rendszeresen (tipikusan évente) meg kell újítani; ezzel akadályozzák meg, hogy egy név örök időkre egy megszűnt szervezet birtokoljon. A regisztrációt az arra kijelölt cégek végzik.

Amennyiben egy szervezet vagy magánszemély egy domain nevet regisztrálni szeretne, egy regisztrátor szervezethez kell fordulnia, aki a megfeleleő adatok megadása után elvégzi azt. Az egyes országok gyakorlata eltérő. Míg egy amerikai domain tulajdonjoga a kérelmet hamarabb benyújtó szervezeté lesz, a magyar szabályok kéthetes meghirdetés után teszik lehetővé annak megvásárlását. A más által birtokolt nevek átadására a tulajdonosok nem kötelezhetők, erre egy jó példa a bayer.hu amely nem a világ harmadik legnagyobb gyógyszergyára, a Bayer AG, hanem egy magánszemély birtokában van.

Érdemes tudni, hogy a leggyakrabban használt SLD-ket is köztulajdonná nyilvánították, így pl. a .konyvelo.hu név önmagában nem regisztrálható, csak a harmadik szinű neveket, pl. bartairoda.konyvelo.hu nevet lehet megvásárolni.

Megjegyzés

• Magyar domainek foglaltságának ellenőrzését a https://www.domain.hu oldalon lehet elvégezni.

• A domainek tulajdonosai csak cégek esetében ismerhetők meg, magánszemélyek adatait a felület a GDPR életbelépése óta nem közli.

• A magyar domain regisztrátorok listája a https://www.domain.hu/regisztratorok/ címen érhetők el.

• Más országok regisztrációit a nagyobb regisztrátorok végzik, az amerikaiak online igényelhetők pl. a name.com vagy a godaddy.com oldalakon.

9.2. A Névszerverek működése

A DNS szolgáltatást Domain Name Server-ek, azaz (sajnos szintén) DNS-ek végzik. Ezek a nevek felépítését követve szintén hierarchikus felépítésűek, ezért egy névhez tartozó IP cím lekérdezésében több szerver is részt vesz. A lekérdezés folyamatát az alábbi példában ismerjük meg:

1. A munkaállomásnak szüksége van a www.uni-nke.hu névhez tartozó IP címre.

2. Amennyiben az ehhez a névhez tartozó IP címet a munkaállomás már ismeri, azt azonnal használni tudja, így a folyamat ebben a pontban véget is ér. Az ismertség oka lehet pl. az, hogy a lekérdezés már korábban megtörtént, és a válaszra a munkaállomás még „emlékszik”. (A válaszok élettartamára is van TTL, így idővel ezeket a rendszer eldobja, vagy érvényességük lejárta után újra lekérdezi.)

3. Amennyiben a keresett név megtalálható a hosts fájlban, a hozzá tartozó IP címet ebből a fájlból olvassák ki, és a folyamatban a névszerverek egyáltalán nem vesznek részt.

4. Ha cím nem található meg a hosts fájlban, a munkaállomás az abban beállított névszerverhez fordul, és kéri a név feloldását. Amennyiben a névszerver maga tárolja a keresett név információit, azonnal válaszolni tud, ezt nevezzük authorative válasznak. Ezt látjuk a későbbi példákban a www.elte.hu lekérdezésekor. Amennyiben megszólíott névszervernek nincs információja az adott névről, de képes azt másoktól lekérdezni, a választ non-authorative-nak nevezzük. (Az NKE belső hálózatában levő gépek a www.uni-nke.hu név feloldását a saját szerverüktől kérdezik le, ami authoratív választ ad.)

5. Ha a megszólított névszervernek nincs információja a névhez tartozó IP címről, egy ún. gyökérnévszerver-ekhez fordul. Ezek listáját minden hálózatképes operációs rendszer egy fájlja tartalmazza.

6. A gyökérnévszerver nem rendelkezik információról az uni-nke.hu domain névről, de meg tudja adni a keresett TLD-ért (.hu) felelős DNS szerver IP címét.

7. A munkaállomás az IP cím birtokában ehhez, a .hu alá tartozó SLD-k adatait tartalmazó szerverhez fordul. Ez nem ismeri a www.uni-nke.hu címét, de meg tudja adni annak a névszervernek az IP címét, amely az uni-nke.hu alá tartozó nevek adatait tartalmazza.

8. A munkaállomás végul ehhez a névszerverhez fordul, és lekérdezi a www.uni-nke.hu névhez tartozó IP címet. Mivel ez a névszerver már az adott domain adataiért felelős szerver, meg tudja adni a választ, mely e sorok írásakor a 193.224.76.68.

9. Az operációs rendszer a visszakapott címet egy átmeneti tárban, az ún. cache-ben tárolja, így annak érvényességi idejének lejártáig azt nem kell újra lekérdeznie.

10. A címet az operációs rendszer átadja az azt kérő alkalmazásnak.

Megjegyzés

A névfeloldás mechanizmusának tehát elengedhetetlen feltétele, hogy a munkaállomások számára beállítsuk a DNS szerver IP címét. (Világos, hogy a névszervert nem adhatjuk meg névvel.)

9.3. Parancsok a névszolgáltatáshoz

Az egyes operációs rendszerek több lehetőséget is kínálnak a nevek kezelésére, ezek egy része általános, parancssori alkalmazás. Egy névhez tartozó IP cím lekrédezését a nslookup, Unixok esetén a host parancs végzi. Paramétereként a keresendő nevet vagy IP címet kell megadni. Az alábbi példában a www.elte.hu névhez tartozó IP címet kérdezzük le.

A www.elte.hu névhez tartozó IP cím lekérdezése

A lekérdezés fordítva is működik: ekkor a paraméter egy IP cím. Az alábbi példában a 157.181.1.232 IP címhez tartózó nevet kérdezzük le. (A válasz szerint ez a www-ospf.elte.hu)

A 157.181.1.232-es IP címhez tartozó nevek lekérdezése

A korábban már lekérdezett és a munkaállomás átmeneti tárában található (cache-elt) nevek törlésére az ipconfig /flushdns parancs szolgál. Ennek kiadása után a munkaállomás már nem „emlékszik” a korábban lekérdezett nevekhez tartozó címekre, így azokat a fenti mechanizmus alapján újra le fogja kérdezni.

Internetes névadatok eltávolítása a gyorsítótárból

Megjegyzés

• Unixokon nslookup helyett gyakran alkalmazzuk a host parancsot, amely sokkal rövidebb kimenetet ad. A dig szintén névszerver információk lekérdezésére szolgál, mivel a kimenete elég sok technikai információt tartalmaz, itt használatát nem részletezzük.

• Van lehetőség ún. dinamikus DNS bejegyzések alkalmazására is, melyet elsősorban olyan gépek esetében alkalmazunk, melyeknek nincs állandó IP címük (tipikus példái azok a routerek, melyek egy internet szolgáltatótól kapnak hálózati paramétereket). A cím megváltozásakor a router képes aktualizálni a hozzá tartozó domain nevet, így pl. a home.koczka.hu-hoz tartozó IP cím mindig annak függvényében változik, hogy a szolgáltató milyen címet adott át számára. A megoldás eredményeként a változó IP című gép azonos néven állandóan elérhető lesz. A dinamikus DNS általában havidíjas szolgáltatás, melyet számos szolgáltató, pl. a no.ip kínál.

• A DNS működésével szembeni egyik legnagyobb kritika, hogy az abban résztvevő felek nincsenek azonosítva, így a válaszok viszonylag könnyen hamisíthatók.

• A DNS kérésekre adott válaszok eltérítése az egyik legismertebb DDOS támadási módszer, mely során megfertőzött gépek a megbénítandó gép nevében olyan DNS kéréseket küldenek ki, melyek nagyméretű válaszokat eredményeznek. A különböző gépek irányából érkező adatcsomagokat a megtámadott gép ugyan eldobja (hiszen nem ő kérte azokat) de a feldolgozásuk rendkívül nagy erőforrás igénye következtében nem képesek alapfeladatuk ellátására.

9.4. A WhoIs adatbázis

A Whois Adatbázis adatokat tartalmaz IP címek és IP hálózatok tulajdonosairól. A szolgáltatás webes felületen (pl. az ipinfo.info) címen, vagy Unix rendszereken paranccsorból, a whois paranccsal lehet igénybe venni. Egy IP cím lekérdezése során az adatbázis megmutatja annak használóját, valamint annak a személynek a nevét és elérhetőségeit, akivel probléma esetén fel lehet venni a kapcsolatot. A Whois adatbázis különösen fontos szerepet játszhat egy incidens kezelésekor: egy támadás forrásának meghatározását követően az azt használó szervezet gyorsan azonosítható, és a kapcsolat felvétele után a támadó kiléte meghatározható, vagy egy folyamatban levő támadás megszakítása kérhető. Az alábbi példában az NKE webszerverének IP címéhez, a 193.224.76.68-hoz tartozó adatokat kérdeztük le a whois paranccsal:

feri@w3.linux-szerver.hu:$ whois 193.224.76.68

inetnum:        193.224.76.0 - 193.224.76.255
netname:        ZMKA
descr:          Zrinyi Miklos Nemzetvedelmi Egyetem
descr:          Zrinyi Miklos Military Academy
descr:          Budapest
country:        HU
admin-c:        LT11-RIPE
tech-c:         SK35-RIPE
status:         ASSIGNED PA
remarks:        hrcode=81539e0dc
mnt-by:         NIIF-MNT
created:        1970-01-01T00:00:00Z
last-modified:  2004-05-02T21:57:20Z
source:         RIPE

person:         Livia Tamaska
address:        Zrinyi Miklos Military Academy
address:        Hungaria krt. 9-11.
address:        P.O.B. 15.
address:        H-1581 Budapest
address:        Hungary
phone:          +36 1 1340740 ext. 1247
fax-no:         +36 1 1340740 ext. 1246
nic-hdl:        LT11-RIPE
created:        1970-01-01T00:00:00Z
last-modified:  2020-06-04T11:56:21Z
source:         RIPE # Filtered
mnt-by:         NIIF-MNT

person:         Sandor Kubicsko
address:        Zrinyi Miklos Military Academy
address:        Hungaria krt. 9-11.
address:        P.O.B. 15.
address:        H-1581 Budapest
address:        Hungary
phone:          +36 1 1340740 ext. 1242
fax-no:         +36 1 1340163
nic-hdl:        SK35-RIPE
created:        1970-01-01T00:00:00Z
last-modified:  2020-06-04T11:55:46Z
source:         RIPE
mnt-by:         NIIF-MNT

% Information related to '193.224.0.0/15AS1955'

route:          193.224.0.0/15
descr:          HBONE/HUNGARNET Block 02
origin:         AS1955
mnt-by:         AS1955-MNT
created:        1970-01-01T00:00:00Z
last-modified:  2008-07-02T20:15:44Z
source:         RIPE

% This query was served by the RIPE Database Query Service version 1.108 (DEXTER)

9.5. Protokollok

Az egyes szoftverek működésük során a hálózaton keresztül kommunikálnak. A böngészőprogramok a webszerverekkel beszélgetnek, mely során a webszervertől weboldalak töltődnek le a böngészőbe, amit az megjelenít. Amikor a felhasználó egy linkre kattint, a böngésző egy újabb kérést küld a webszerver felé, amire az egy újabb oldalt ad át a böngésző számára. Nincs ez másképp a levelező programok esetén sem, ezek a levelek küldését és fogadását végző szerverekkel folytatnak párbeszédet, mely során képesek egy levél elküldésére úgy, hogy a fogadó szerver számára megadják a feladó és a címzett adatait, a levél tárgyát, szövegét, esetleges mellékleteit. A beérkezett levelek letöltése másképp történik, ekkor a levelező program lekérdezheti a levelek listáját, vagy kérheti a kiválasztott levelek tartalmát. Mivel számos böngésző és levelező program létezik, a kommunikáció formáját pontosan definiálták. Ezzel lehetővé válik, hogy minden program képes párbeszédet folytatni a szerverekkel, amely a párbeszéd szabályait pontosan betartja. Ez azt jelenti, hogy a háttérben minden böngészőprogram azonos módon kommunikál a szerverrel, és minden levelezőprogram a háttérben ugyanolyan párbeszédet folytat egy levél elküldésekor vagy fogadásakor. Az egyes programok közötti párbeszéd szabályait protokoll-nak nevezzük, és részleteit az RFC-nek (Request for Comment) nevezett dokumentumok tartalmazzák. Egy elektronikus levél küldését az SMTP (Simple Mail Transfer Protocol) definiálja, részleteit az RFC 5321-es dokumentuma tartalmazza. Amennyiben az olvasó kíváncsi rá, részletesen olvashat róla a https://datatracker.ietf.org/doc/html/rfc5321 oldalon.

Az alábbi példában egy levelező program és egy szerver kommunikációja olvasható. A kliens a Batman nevében ad fel egy levelet a batman@gotham.com címről az info@linux-szerver.hu címre. A levél tárgya a Hallo, a szövege pedig a „Ich bin das Batman.” szöveg. A kommunikáció során narancssárgával emeltük ki azokat a sorokat, amelyeket a kliens küld a szervernek, világos hátterűek a szerver válaszai. (Az SMTP protokoll részletes szabályainak elsajátítása természetesen nem feladat, a lényeg a párbeszéd módjának ismerete.)

feri@w3.linux-szerver.hu:~#  telnet 212.92.23.213 25
Trying 212.92.23.213...
Connected to 212.92.23.213.
Escape character is '^]'.
220 ns.linux-szerver.hu Thu, 22 Sep 2022 12:39:07 +0200
EHLO gotham.com
250-ns.linux-szerver.hu Hello kf215.uni-eszterhazy.hu [193.225.35.215]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH LOGIN PLAIN
250-STARTTLS
250 HELP
mail from: batman@gotham.com
250 OK
rcpt to: info@linux-szerver.hu
250 Accepted
data
354 Enter message, ending with "." on a line by itself
Subject: Hallo
Ich bin das Batman.
.
250 OK id=1obJfI-0000bb-Pp
quit
221 ns.linux-szerver.hu closing connection
Connection closed by foreign host.

Az SMTP csak egy protokoll a sokszáz közül. A böngészőprogramok ún. Hipertext Transfer Protocol-on kommunikálnak, amit http-nek rövidítenek, ez látható minden esetben, amikor a címsor tartalmát ellenőrizzük. A levelező programok a leveleket Post Office Protocol-on, (röviden POP3) vagy az Internet Messaging Access Protocol-on vagyis IMAP-on kérik le. Ezek a fenti példáhz hasonlóan, de eltérő nyelvezettel működnek, a szabályokat szintén a megfelelő RFC tartalmazza.

Protokollok az Outlookban

A protokollok esetében alapvető elvárás a titkosítás. Az eddig ismertetettek nem tartalmaztak ilyet, de a legtöbbnek van „titkosításképes” változata is. Az smtp továbbfejlesztése az smtps, a http-é a https. A záró S a Secure, azaz biztonságos kapcsolatra utal, ezek a protokollok lehallgatás ellen oly módon védettek, hogy a titkosított tartalmuk egy harmadik fél számára abban az esetben sem ismerhető meg, ha az a teljes adatátvitelt lehallgatja.

9.6. A tanúsítványokról

A https protokoll nem csak a titkosítással bővítette ki a http-t, hanem az ún. tanúsítványok alkalmazását is bevezette. A tanúsítványok eredeti célja annak bizonyítása a felhasználó számára, hogy valóban az általa meglátogatni kívánt oldalon van, nem pedig egy megtévesztő, az eredeti lemásolt és módosított változatán. A tanúsítványok csak https protokollon működnek, az egyszerű http-n nem vehetők igénybe. Egy tanúsítvány működése az operációs rendszereknél megismert nyilvános kulcs - titkos kulcs páron alapul. A tanúsítányok működési mechanizmusa nyilvános, bárki megvalósíthatja, de a megfelelő kulcsok nélkül nem működőképes.

Egy website eredetiségének igazolására szervezeteket hoztak létre, akik egy weboldal címének hitelesítése előtt a szükséges iratok áttekintésével ellenőrzik a kérelmező adatait. Amennyiben mindent rendben találnak, digitálisan aláírják a weboldal tanúsítványát, hitelessé téve azt. A böngészőprogramok ismerik a hivatalos hitelesítő szervezetek aláírásait, így idegen aláíráskor észleleésekor figyelmeztető üzenetet adnak. Hasonló figyelmezetést küld a böngésző, ha a tanúsítvány más nevére szól, vagy már esetleg lejárt. Ilyen esetkeben a felhasználó döntése, hogy továbblép az adott oldalra, és ezzel vállalja a kockázatokat, vagy elfogadja a figyelmeztetést és megszakítja a böngészést. Jelenleg két magyar tanúsítványkiadó szervezetet ismernek a böngészők, a Netlock Kft-t és a Microsec Kft-t, de természetesen bármelyik, külföldi tanúsítványkiadó megfelelő lehet. Tekintettel arra, hogy a tanúsítványok árazása eltérő lehet, a beszerzése előtt érdemes lehet tájékozódni.

Az alábbi példában a https://checkip.246.hu oldalra látogatunk el, melynek hibás tanúsítványa van, erről a böngésző figyelmeztetést küld:

Figyelmeztetés hibás tanúsítványra

A Részletek, majd ez ezt követő oldalon a Tanúsítvány megtekintése gombokra kattintva megtekinthetők a tanúsítvány részletei. Ebben leolvasható, hogy a hiba oka az, hogy ezt a tanúsítványt nem a https://checkip.246.hu, hanem a https://www.adotervezo.com számára állították ki, így a tanúsítvány ezen az oldalon érvénytelen. A részletekben leolvasható a tanúsítvány érvényességi ideje, ez e sorok írásakor 2023.09.10-2023.12.09 közt érvényes. A kiállító szervezet nevét szintén feltüntetik a tanúsítványban, ami példánkban az amerikai LetsEncrypt.

Figyelmeztetés hibás tanúsítványra

Figyelem

A LetsEncrypt tanúsítványai sajnos különleges figyelemet igényelnek, mivel ezt a szervezetet egy szempontból jelentősen különbözik a többitől: a tanúsítványai ingyenesek és kiállításukhoz csupán néhány technikai beállítást követelnek meg, hivatalos iratok bemutatására esetükben nincs szükség. A LetEncrypt alkalmazásával azok a weblapok is elláthatók tanúsítványokkal, amelyekért a tulajdonosuk nem akar évente többtízezer forintos költséget vállalni, miközben (pl. jelen oldalak esetében is) a tanúsítvány szerepe másodlagos. Az ilyen oldalaknál a tnúsítvány szerepe elsősorban a titkosított átvitelben és a Google keresési eredményeinek javításaában merül ki (a Google ugyanis a találati listában hátrább helyezi a csak http-n elérhető oldalakat). A LetEncrypt-tel tenúsított oldalak valódiságáról tehát valójában nem tudunk meggyőződni, azokat nem szabad hitelesként elfogadni! Az alábbi példában a https://jelszoellenorzes.uni-esztehazy.hu oldal hibátlan tanúsítvánnyal rendelkezik, miközben ez egy megtévesztő cím, egy r betű hiányzik a névből.

A LetsEncrypt tanúsítványai nem igazolják a forrás hitelességét

9.7. Proxy szerverek

A proxy szerverek feladata információk átmeneti tárolása, és szükség esetén újbóli felhasználásának lehetővé tétele. Számos proxy szerver típus létezik, mi az ún. webproxy szerver-eket tekintjük át. Az internet korábbi szakaszában messze nem álltak rendelkezésre olyan magas átviteli sebességű vonalak, mint ma. Nem volt ritka a telefonhálózat alkalmazása a végpontok elérésére, ezek 56.6 kbit/mp-es sebessége a mai már extrém alacsonynak számítana. Abban az időben a sávszélesség megtakarításának egyik módszere a proxy szerver volt. A megoldás lényege az, hogy a hálózat számítógépei nem közvetlenül kapják meg az egyes weboldalak tartalmát a webszerverektől, hanem azt egy köztes számítógéptől, a proxy-tól kérik le. A proxy-k a saját merevlemezeiken tárolják a letöltött oldalakat, ezért azt a későbbiekben egy másik számítógép számára az eredeti oldal lekérése nélkül is át tudják adni.

A proxy szerver beállításának párbeszédablaka Windows 10-en

TODO: video: a proxy működése

Megjegyzés

Az egyes weboldalak technikai információkat is tartalmaznak, többek között azt is, hogy a tartalmukat meddig tartják érvényesnek. Egy időjárás előrejelzést, vagy tőzsdei adatszolgáltatást tartalmazó site esetén ez értelemszerűen rövidebb, míg egy ritkán változó tartalmú oldal esetében hosszabb idő. A proxy szerverek ez alapján határozzák meg, hogy meddig őrizzék az egyes oldalak korábbi változatait és előzik meg, hogy lejárt érvényességű információkat adjanak át a felhasználóknak.

A proxy szerverek rendszerint naplózzák a felhasználók által kért oldalak címét, ezekből a naplókból kinyerhető, hogy az egyes felhasználók mikor milyen oldalakat látogattak meg. Ez a GDPR alapján aggályos jogi helyzetet teremthet, melyet szabályzási és tájékoztatási úton kell kezelni. Nem mellesleg maguk a munkaállomások is rögzítik a letöltött oldalak tartalmát, melyek a számítógépről később is visszakereshetők; ezeket a böngésző megfelelő menüpontjával adott esetben érdemes törölni.

Gyorsítótárak törlése a Firefoxban

Figyelem

A böngészők privát módba kapcsolása megakadályozza a böngészési adatok lementését a számítógépre. A megtekintett oldalak azonban nem maradnak rejtve az internetszolgáltatók előtt, hiszen azok tartalmát ők juttatják el a felhasználó számítógépére, és a DNS szolgáltatók előtt sem, hiszen ők alakítják át a címsorban megadott web címeket IP címekké. Ezért a böngészők privát módja valójában nem biztosít teljes inkognitót a látogatók számára. Amennyiben erre van szükség, a később tárgyalt darknetet érdemes használni.

A proxy szervereken keresztül szabályozható az egyes weboldalak letölthetősége is. A proxy szerverek képesek elolvasni a rajtuk átfolyó forgalmat, így annak tartalma alapján akár munkaállomásonként is engedélyező vagy elutasító döntéseket hozhatnak. Korlátozásokat érvényesíthetnek az egyes weboldalak neve vagy IP címe alapján is, sőt, olyan megoldások is bevezethetők, melyek csak adott napszakban teszik lehetővé egyes weboldalak elérését.

TODO: proxy szerver video a forgalom szűréséről

9.8. VPN

A Virtual Private Network (virtuális magánhálózat - VPN) szolgáltatások biztosítják, hogy egy számítógép a belső hálózat részeként működhessen abban az esetben is, amikor az azon kívül helyezkedik el. A VPN megoldások nélkülözhetetlenek a távmunka megoldásokban, melynek során a munkatársak pl. otthonról vagy ügyfelektől kell, hogy belső hálózati szolgáltatásokat vegyenek igénybe. Az egyes megoldások különböző működési elvei miatt az OSI elértő rétegeiben működhetnek (a böngészőkbe épített VPN pl. az alkalmazási-, az ún. IPsec viszont az IP réteg protokollja).

A VPN kapcsolathoz egy, a hálózaton belül elhelyezett VPN szerverre és a munkaállomáson futó VPN kliens szoftverre van szükség, melynek számos különböző megoldása ismert. A modern Windows rendszerek sok kliensprogramot beépítve tartalmaznak, míg más esetekben (pl. a Cisco megoldásai alkalmazásakor) a gyártó által biztosított szoftvert kell telepíteni a munkaállomásokon. A VPN szerverek számos esetben routerek, de Windows szerver változataira és Linuxra is léteznek olyan szerverprogramok, melyekhez a kliensek kapcsolódhatnak.

Amikor egy munkaállomás egy VPN szerverehez kapcsolódik, egy további IP címet kap, amelyet csak a VPN kapcsolathoz használ. A routing tábla módosításával a vállalati hálózat adatforgalmát így a VPN szoftveren keresztül egy másik csatornába terelik, ahol az átküldendő adatokat erős titkosítással védik. Az ehhez tartozó adatforgalom a hagyományos internetkapcsolaton, mint egy alagúton kerül továbbításra és jut el a vállalati VPN szerverhez, ami elvégzi az adatok dekódolását és továbbítja azt a belső hálózatba. Nagyszámú munkaállomás kapcsolódása esetén a titkosítás által megkövetelt számítási feladatok erősebb számítógépet vagy routert igényelnek, ezért sem szokás ún. SOHO router-ek (Small Office/Home Office) alkalmazása vállalati környezetben. Egy VPN kapcsolaton keresztül tehát egy home office-ban dolgozó munkatárs minden olyan beslő hálózati szolgáltatást elér, amelyre a belső hálózatban, a személyes jelenléte során lehetősége van. Így nem csak a belső fájlszerver mapppáihoz fér hozzá, hanem képes a belső nyomtatók használatára is.

Figyelem

Az informatikai biztonság szempontjából a VPN-nek is vannak kockázatai, főleg a munkatársak saját tulajdonú eszközeinek alkalmazása esetén. Utóbbit a Bring Your Own Device, azaz BYOD néven említik, és legfőbb kockázatát az ellenőrizetlen szoftverek, a vírusvédelem hiánya, a feltört játékok következtében jelenlevő malware-ek jelenthetik, melyek a VPN kapcsolatokon keresztül a vállalati hálózatra is átterjedhetnek. Biztonsági okokból egyes megoldások a kapcsolat felépítése után nem csak a vállalathoz irányuló, hanem a teljes adatforgalmat a VPN csatornába irányítják azért, hogy a folyamat során a vállalat hálózatára érvényes szabályok a távoli munkaállomásra is érvényesek legyenek. Ilyen esetben a felhasználó magán internet forgalma is a vállalaton belül „fordul meg”, így naplózásra kerül. Ezért saját tulajdonú számítógépeken a VPN kapcsolatokat csak a munkavégzés ideje alatt érdemes fenntartani.

TODO: video a VPN működéséről

9.9. Hálózati forgalomelemzés

A hálózati adatforgalom a megfelelő szoftverekkel lehalgatható és elemezhető, melyehez számos szoftver áll rendelkezésre. Unix gépeken a legismertebb talán a tcpdump parancs, Windows-on pedig a WireShark. Ezekkel nyomonkövethető a hálózat pillanatnyi forgalma és az leginkább manuális úton elmezhető.

A Wireshark képes a hálózati forgalom analizálására

Ez a módszer nem elégséges azokban az esetekben, amikor a biztonság érdekében a hálózati forgalmat folyamatosan ellenőrizni szeretnénk, és jelentést szeretnénk kapni azokról az eseményekről, amelyek pl. kártékony tartalmúak.

Megjegyzés

Weboldalak megtámadásakor jellemző megoldás hogy azokban kártékony kódot tartalmazó további fájlokat helyeznek el, és azokat később megpróbálják elérni. Egy ilyen példa a Wordpress oldalak esetében a a /wp-content/uploads/wp-blockdown.php jelenléte, amely nem része az eredeti szoftvernek, és meghívásával az abban levő program aktiválható.

Amennyiben a hálózatunk adatforgalmában megjelenik egy olyan web kérés, amely a példában szereplő program meghívására irányul, annak forrását támadónak kell tekintenünk abban az esetben is, ha egyébként a hálózatunkban nincs jelen ez a sérülékenység. A kérdés csak az, hogy milyen védelmi intézkedéseket foganatosítunk ezzel szemben.

Egy Intruder Detection System (röviden IDS) folyamatosan felügyeli a hálózatba be- illetve kilépő adatforgalmat és képes detektálni a példában is szereplő kártékony elemeket. Egy jó minőségű IDS számos ilyet ismer, és listáját egy vírusvédelemhez haonlóan folyamatosan frissítik. Egy IDS fő kimenete a támadó adatforgalmat összegző riport, melynek elemzésével a szükséges ellenlépések kidolgozása támogatható. Az alábbi ábrán egy IDS jelentés egy részlete látható, mely az adott hálózat számítógépeire letöltött kártevők számát mutatja származási hely szerinti bontásban.

Részlet egy IDS riportból

Egy Intrusion Prevention System (röviden IPS) ennél továbbmegy: támadó forgalom esetén a kapcsolatot akár azonnal megszakíthatja, megvédve ezzel a hálózat elemeit a támadás kivitelezésétől. Egy IPS rendkívül hatékony védelmi eszköz, ugyanakkor sok problémát is okozhat: a káros adatforgalmú gépek azonnali kizárásával akár a szervezet működésképtelenségét is okozhatja, így bevezetését fokozatosan érdemes megtenni. Egy IPS a fenti riport elkészítésén túl képes lehet a támadó adatforgalom blokkolására megakadályozva ezzel azok letöltését.

Egy Security Information and Event Management (röviden SIEM) rendszer még szélesebb szolgáltatáskészlettel rendelkezik, számos számítógép és hálózati berendezés egyidejű felügyeletének lehetőségét biztosítják. Tipikus alkalmazási forma a SIEM rendszerek monitorain megjelenő diagramok és jelzések folyamatos, manuális nyomonkövetése. Segítségével nyomon kvethető a hálózati forgalom mennyisége és jellege, és különböző típusú támogatást nyújtanak ezek elemzésében pl. az egyes események közti összefüggések vizsgálatával. Fő céljuk az informatikai incidensekre történő azonnali reagálás elősegítése. Egy ingyenes és nagyszerű SIEM rendszer a https://wazuh.com oldalon elérhető Wazuh, mely a fenti szolgáltatások mellett képes detektálni a felügyelt szerevek beállítási hibáit, sérülékenységeit és fájlrendszerében bekövetkezett változásokat is.

A Wazuh SIEM rendszer áttekintő képe

Egy Sérülékenyésgvizsgálati rendszer az általa elérhető számítógépek és hálózati berendezések különböző sérülékenységeit vizsgálja. Számos ilyen szoftver létezik, melyek közül talán a legnépszerűbbek a Nessus vagy a Nexpose. Ezek a szoftverek a megadott hálózati berendezéseket folyamatosan vizsgálják, a felfedezett sérülékenységekről jelentést készítenek, mely alapján a védekezeséi stratégia a valós helyzetnek megfelelően alakítható ki:

Jelentés egy számítógép biztonsági vizsgálatáról

9.10. Feladatok

1. Mi a www.disney.com gép IP címe?

2. Milyen név tartozik a 212.92.23.213 címhez?

3. Ki birtokolja a byd.hu domain nevet? Milyen telefonszámon érheti el a tulajdonosát?

4. Szabad még a smack.hu domain név?

5. Milyen magyar domain nevek vannak épp regisztrálás alatt?

6. Ki birtokolja a 193.225.35.210-es IP címet?

7. Egy innen jövő incidens esetén milyen módon vehetné fel a kapcsolatot annak használójával?

8. Ki állította ki az OTP bank webes felületének tanúsítványát?