Számítógép rendszerek. 2. óra. Alkalmazásrétegi internetes protokollok Egyszerű szabványos adatcsere formátumok Titkosítás, biztonságos adatcsere

Számítógép rendszerek

2. óra

Alkalmazásrétegi internetes protokollok Egyszerű szabványos adatcsere formátumok Titkosítás, biztonságos adatcsere

Névfeloldás: domain nevek • DNS (Domain Name System): domain nevek IP címekhez rendelése • Eredetileg: IETF RFC 882, IETF RFC 883 (1983), azóta sok módosítás és kiegészítés született • Egy domain név felépítése: www.agt.bme.hu TLD (Top Level Domain): legfelsőbb szintű domain (hu, de, com, org, stb.) pl. ország megjelölése Első aldomain pl. intézet, cég megnevezése Második aldomain pl. szervezeti egység megnevezése Harmadik aldomain pl. szolgáltatás megnevezése Stb. Számítógép rendszerek, 2. óra: Alkalmazásrétegi internetes protokollok; egyszerű szabványos adatcsere formátumok

1/39

Névfeloldás: névkiszolgálók

• A domain név → IP cím hozzárendeléseket a névkiszolgálók (Name Server) tartják nyilván • A névkiszolgálók hierarchikus rendszert alkotnak: ◦ 13 legfelsőbb szintű (root) névkiszolgáló (a.root-servers.net, b.root-servers.net, stb.) ◦ nemzeti szintű és egyéb magas szintű névkiszolgálók (pl. ns.nic.hu, a.nic.de, stb.) ◦ vállalatok, intézmények, szolgáltatók névkiszolgálói (pl. nic.bme.hu, ns2.pantel.net, stb.) ◦ és így tovább, egyre alacsonyabb szinteken • A névkiszolgálókon tárolt bejegyzések típusai pédául: ◦ „A” (Address) record: név → IP cím hozzárendelés ◦ „CNAME” (Canonical Name) record: alternatív név → név hozzárendelés ◦ „MX” (Mail Exchange) record: levelezést bonyolító kiszolgáló megadása

Számítógép rendszerek, 2. óra: Alkalmazásrétegi internetes protokollok; egyszerű szabványos adatcsere formátumok

2/39

Névfeloldás: példa Péda: kutakodjunk egy kicsit a NASA háza táján! Elindítjuk az nslookup programot

nslookup > set q=CNAME > www.nasa.gov www.nasa.gov

canonical name = www.nasa.gov.speedera.net

> www.nasa.gov.speedera.net www.nasa.gov.speedera.net

canonical name = www.nasa.gov.edgesuite.net

> www.nasa.gov.edgesuite.net www.nasa.gov.edgesuite.net

Valójában mi a neve annak a gépnek ami a www.nasa.gov honlapot szolgáltatja?

canonical name = a1718.x.akamai.net

> set q=A > a1718.x.akamai.net

És mi az IP címe ennek a gépnek?

Name: a1718.x.akamai.net Address: 195.228.246.168 > set q=MX > nasa.gov nasa.gov nasa.gov nasa.gov nasa.gov nasa.gov nasa.gov

mail exchanger = mail exchanger = mail exchanger = mail exchanger = mail exchanger = mail exchanger =

10 10 10 10 10 10

ndjsnpf01.ndc.nasa.gov. ndjsnpf02.ndc.nasa.gov. ndjsnpf03.ndc.nasa.gov. ndmsnpf01.ndc.nasa.gov. ndmsnpf02.ndc.nasa.gov. ndmsnpf03.ndc.nasa.gov.

Az [email protected] címre kimenő e-mailek melyik szerveren kötnek ki?


3/39

További információk egy domainről: WHOIS • További információk tudhatók meg egy domain bejegyzőjéről a WHOIS szolgáltatással • Eredetileg: IETF RFC 812 (1982), ma: IETF RFC 3912 (2004) • 43-as TCP portra küldött egyszerű lekérdezés • Példa: mit tudunk az index.hu bejegyzőiről? > telnet hu.whois-servers.net 43 index.hu … domain: org: org: address: address: address: phone: fax-no: …

A telnet programmal TCP kapcsolatot létesítünk a hu.whois-server.net 43-as portjával Egyszerű lekérdezést küldünk

Válaszként a WHOIS szerver inforindex.hu mációkat küld a cím tulajdonosáról org_name_eng: Index.hu Ltd org_name_hun: Index.hu Rt Klapka 1-3 1134 Budapest HU 06-1-450-5350 06-1-450-5361


4/39

Hálózati beállítások automatikus lekérése: DHCP • DHCP: Dynamic Host Configuration Protocol • Kiszolgáló részéről a 67-es, kliens részéről a 68-as UDP portot használja • Tipikus munkamenet: ◦ DHCP discovery („felderítés”) ▪ Kliens részéről UDP/IP csomag a 255.255.255.255 broadcast címre ▪ Cél: az alhálózaton található DHCP kiszolgáló(k) felderítése, beállítások lekérése ◦ DHCP offer („ajánlat”) ▪ Kiszolgáló részéről IP cím és egyéb hálózati beállítások felkínálása ▪ Kliens azonosítása MAC címmel (a discovery-ben megadott cím) ◦ DHCP request („kérelem”) ▪ Kilens részéről a felkínált beállítások elfogadása ◦ DHCP acknowledgement („elfogadás”) ▪ Kiszolgáló részéről a kérelem jóváhagyása


5/39

Hálózati beállítások automatikus lekérése: DHCP • Tipikusan DHCP-n keresztül kiszolgált információk: ◦ Kliens IP címe ▪ A kiszolgáló beállításaiban rögzített tartományból ▪ Adott időtartamra biztosítva (lease time) ◦ Alhálózati maszk ◦ Alapértelmezett átjáró ◦ DNS kiszolgálók ◦ Stb.


6/39

Weboldalak lekérése

• HTTP (Hypertext Transfer Protocol): egyszerű dokumenumok, képek, egyéb fájlok átvitelére

szövegalapú

protokoll

HTML

• Legújabb elterjedt változata a HTTP/1.1: IETF RFC 2616 (1999)

• A 80-as TCP portot használja

• Példa: a http://www.debian.org/index.html dokumentum magyar nyelvű változatának lekérése (a következő oldalon →)


7/39

> telnet www.debian.org 80 GET /index.html HTTP/1.1 Host: www.debian.org Accept-Language: hu Connection: close HTTP/1.1 200 OK Date: Thu, 26 Feb 2009 04:58:42 GMT Server: Apache Last-Modified: Thu, 26 Feb 2009 03:29:12 GMT ETag: "3fb4078-38aa-f4b63200" Accept-Ranges: bytes Content-Length: 14506 Cache-Control: max-age=86400 Expires: Fri, 27 Feb 2009 04:58:42 GMT Connection: close Content-Type: text/html

kapcsolat létesítése (80-as TCP port) index.html lekérése kiegészítő információk a lekéréshez a lekérést egy üres sor zárja le a szerver 200-as kóddal válaszol (OK)

kiegészítő információk a válasz fejlécében

a válasz fejlécét egy üres sor zárja le <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> Debian -- The Universal Operating System ...

végül a kiszolgáló elküldi a kért dokumentumot


8/39

Levelezés: SMTP

• Levelek küldése: pl. SMTP (Simple Mail Transfer Protocol), IETF RFC 821 (1982) → IETF RFC 5321 (2008) • Használják a levelezőprogramok levelek elküldésére, és a levelezőszerverek az egymás közötti levéltovábbításra • Szintén szöveges protokoll, a 25-ös TCP portot használja • Példa munkamenet: Bob levelet küld Alice-nak, amit másolatban a főnök is megkap (a következő oldalon →)


9/39

Levelezés: SMTP példa

220 smtp.example.com ESMTP Postfix HELO relay.example.org

A kapcsolat létrejötte után a szerver köszönt Megkezdjük a munkamenetet nevünk közlésével

250 Hello relay.example.org, I am glad to meet you MAIL FROM:

Levél feladója

250 Ok RCPT TO:

Levél címzettje

250 Ok RCPT TO:

Levél második címzettje

250 Ok DATA 354 End data with .

Jelezzük, hogy jön a levél maga A szerver utasít, hogy a levelet egy „.”al zárjuk majd le


10/39

Levelezés: SMTP példa (folytatás) From: "Bob Example" To: Alice Example Cc: [email protected] Date: Tue, 15 Jan 2008 16:02:43 -0500 Subject: Test message Hello Alice. This is a test message. Your friend, Bob . 250 Ok: queued as 12345 QUIT 221 Bye

Maga a levél (MIME e-mail formátumban)

A szerver visszaigazolja hogy a levél készen áll kézbesítésre (várólistára került) Befejezzük a munkamenetet A szerver elköszön


11/39

Levelezés: POP3

• Levelek fogadása: pl. POP3 (Post Office Protocol version 3), IETF RFC 1939 (1996) • A levelezőprogramok levelek letöltésére használják • Szintén szöveges protokoll, a 110-es TCP portot használja • Példa munkamenet: mrose felhasználó letölti leveleit a dbc.mtview.ca.us kiszolgálóról (a következő oldalon →)


12/39

+OK POP3 server ready (dbc.mtview.ca.us) USER mrose +OK User accepted PASS xxxxxxxxx +OK Pass accepted

A kiszolgáló köszönt minket Megadjuk felhasználói nevünket és jelszavunkat

+OK mrose's maildrop has 2 messages (320 octets) STAT +OK 2 320

Összesített információt kapunk postafiókunkról: 2 levél, összesen 320 byte

LIST +OK 2 messages (320 octets) 1 120 2 200 .

Részletes listát kapunk postaládánkról: az 1. levél mérete 120 byte, a 2. levélé 200 byte

RETR 1 +OK 120 octets .

Lekérjük az 1. levelet

DELE 1 +OK message 1 deleted

Töröljük az 1. levelet

RETR 2 +OK 200 octets .

Lekérjük a 2. levelet

QUIT +OK dewey POP3 server signing off

Kijelentkezünk a kiszolgálóról


13/39

Biztonságos parancssori hozzáférés: SSH • SSH: Secure Shell • Általában a 22-es TCP portot használja • Régebbi, nem titkosított hozzáférési módok (pl. telnet) kiváltása • Alrendszerek: SFTP, SCP (titkosított file-átvitel) • Egyéb felhasználások: pl. titkosított port-továbbítás, asztali munkamenetek titkosított továbbítása, stb. • Azonosítás: felhasználói név és jelszó, nyilvános kulcs, stb. • Nem csak a belépő felhasználónak, hanem a kiszolgálónak is azonosítania kell magát!


14/39

Erőforrások megosztása hálózaton • SMB: Server Message Block / CIFS: Common Internet File System ◦ Tipikusan a 445-ös TCP portot használja ◦ Állományok és egyéb erőforrások (pl. nyomtatók) megosztása Windows hálózatokon ◦ Nyílt forrású, multiplatform implementáció: Samba, minden jelentősebb platformon elérhető • NFS: Network File System ◦ Eredetileg a Sun Microsystems fejlesztette ki saját UNIX rendszeréhez ◦ Mára minden jelentősebb platformon elérhető • IPP: Internet Printing Protocol ◦ Tipikusan a 631-es TCP portot használja ◦ A kommunikáció a HTTP protokollra épít ◦ Minden jelentősebb platformon elérhető • LPD Line Printer Daemon protocol / LPR: Line Printer Remote protocol ◦ Tipikusan az 515-ös TCP portot használja ◦ Minden jelentősebb platformon elérhető Számítógép rendszerek, 2. óra: Alkalmazásrétegi internetes protokollok; egyszerű szabványos adatcsere formátumok

15/39

Egyszerű szövegfájlok: ASCII (1968)

Megnevezések: ANSI_X3.4-1968, ISO-IR-6, ANSI_X3.4-1986, ISO_646.IRV:1991, ASCII, US-ASCII, US, IBM367, CP367 Számítógép rendszerek, 2. óra: Alkalmazásrétegi internetes protokollok; egyszerű szabványos adatcsere formátumok

16/39

Egyszerű szövegfájlok: ISO 8859-1


17/39



18/39



19/39

Egyszerű szövegfájlok: ISO 8859-2 vs. UTF-8 • Az Unicode az UCS (Universal Character Set, ISO/IEC 10646:2003, a 00 00 00 – 10 FF FF tartományban 1114112 féle karaktert definiál) megvalósítására vonatkozó szabvány, karbantartója a Unicode Consortium. • Megvalósulása pl. az UTF-8 (8-bit UCS/Unicode Transformation Format) kódolás, ami a karaktereket változó hosszon (1-4 byteon) tárolja; az 1 byteos tartomány ASCII kompatibilis. • Példa: „Karakterkódolási példa” (bal oldalon az egyes hexadecimális számok, jobb oldalon szövegként megjelenítve)

byteoknak

megfelelő

ISO 8859-2 kódolással:

UTF-8 kódolással:

(A megjelenítő program nem ismerte az UTF-8 kódolást, ezért például a C3 A9 kombinációt helytelenül két különálló 1 byteos karakterként mint „Ã©” jelenítette meg, holott ez UTF-8ban a 2 byteos „é” karaktert jelöli.) Számítógép rendszerek, 2. óra: Alkalmazásrétegi internetes protokollok; egyszerű szabványos adatcsere formátumok

20/39

Miből áll egy MIME e-mail?

Return-Path: <[email protected]> Delivered-To: [email protected]

Feladó, végleges címzett (akinek a levél kézbesítésre került)

Received: (qmail 6970 invoked from network); 18 Feb 2009 17:12:03 +0100 Received: from fw.ggki.hu (193.224.75.110) by fmx14.freemail.hu with SMTP; 18 Feb 2009 17:11:59 +0100 Received: from localhost (localhost [127.0.0.1]) by fw.ggki.hu (Postfix) with ESMTP id E85F3340E3F6; Wed, 18 Feb 2009 17:06:06 +0100 (CET) Received: from fw.ggki.hu ([127.0.0.1]) by localhost (fw.ggki.hu [127.0.0.1]) (amavisd-new, port 1025) with ESMTP id cqBcyUGmGbbR; Wed, 18 Feb 2009 17:06:06 +0100 (CET) Received: from ggki.hu (xxxxxxxx.lan.ggki.hu [10.0.0.117]) by fw.ggki.hu (Postfix) with ESMTP id BA78C340E3F4; Wed, 18 Feb 2009 17:06:05 +0100 (CET) Message-ID: <[email protected]>

A levél továbbításának útvonala (a továbbításban résztvevő kiszolgálók mind hozzáfűzik magukat)


21/39

Miből áll egy MIME e-mail? (folytatás) Date: Wed, 18 Feb 2009 17:11:49 +0100 From: Aaaaaa Bbbbbb <[email protected]>

A feladó által megadott, és a levelezőprogram által hozzáfűzött adatok

X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: [email protected] Subject: A level targya Content-Type: multipart/mixed; boundary="------------885E77E9A5CCC18589CC393F" X-Freemail: message scanned This is a multi-part message in MIME format. --------------885E77E9A5CCC18589CC393F Content-Type: text/plain; charset=iso-8859-2

A levél több részből áll, elsőnek jön a szöveges rész...

Content-Transfer-Encoding: 8bit Kedves Címzett! Ez itt a levél szövetes része. Üdv:

xxxxxx


22/39

Miből áll egy MIME e-mail? (folytatás) --------------885E77E9A5CCC18589CC393F Content-Type: application/x-zip-compressed; name="Csatolmany.zip"

...másodiknak pedig a csatolmány, esetünkben egy zip fájl

Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Csatolmany.zip" UEsDBBQAAgAIACuRUTrEh3EfIGwAAAB2AQAPAAAAYmlyLWZyZXktbHMuZG9j7J0LdFRFmser kw4JkfAIIWLk0WoOiyxmeQRE9MgbQwiIIWCIDJOEPDoPmpg0CNmVUQ+jHHU4yGY5LgdzcA96 ZthZlkWMjHAWcF2Mr8A4mmUYZoegssYdXA5wsk6GJfv/vqrbXbf7dtIhacjO3urz63urbt2q … R2VvbWF0aWthX21pbnRhLkRPQ1BLBQYAAAAAAwADALkAAADcCxEAAAA= --------------885E77E9A5CCC18589CC393F--

• MIME = Multipurpose Internet Mail Extensions • Részletes információk a MIME formátumról: IETF RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289, RFC 2049


23/39

XML: Extensible Markup Language • Általános szabályrendszer különböző típusú adatstruktúrák leírására • Konkrét felhasználási módok (konkrét formátumok): pl. formázott szöveg, vektoros grafika, adatbázis-tartalom, matematikai képletek, stb. • Előnyök: ◦ Emberileg olvasható (sok esetben a konkrét formátum leírása nélkül is értelmezhető) ◦ Gépileg (programmal) könnyen feldolgozható ◦ Széleskörű szoftvertámogatottság (különböző operációs rendszerek és programozási nyelvek) • Hátrány: nem kifejezetten tömör formátum (helytakarékosság ill. átviteli sebesség tekintetében)


24/39

XML: Extensible Markup Language • Felépítés: ◦ Deklaráció (a dokumentum kezdetén): pl. ◦ Jelölő (tag): ▪ Nyitó: <jelölő neve> ▪ Záró: ▪ „Üres”: <jelölő neve /> ◦ Elem (element): ▪ Egy nyitó és egy záró jelölő, köztes tartalommal, pl. <jelölő>tartalom, vagy ▪ Üres jelölő, pl. <jelölő /> ◦ Attribútum (attribute): a jelölő tulajdonságait leíró név-érték páros, pl. <jelölő tulajdonság1=”érték1” tulajdonság2=”érték2”>tartalom <jelölő tulajdonság1=”érték1” /> ◦ Egy XML dokumentum 1 db gyökér elemmel (root element) rendelkezik


25/39

XML: Extensible Markup Language • Példa: egy könyvtár tartalmának leírása A dzsungel könyve Én, a robot A Gyűrű Szövetsége A két torony A király visszatér

• Adatok elérése: pl. XPath lekérdezésekkel ◦ A Gyűrűk Ura sorozat összes kötete: /könyvtár/könyv[sorozat=”A Gyűrűk Ura”] ◦ 2000-nél újabb kiadású könyvek szerzői: /könyvtár/könyv[év>2000]/@szerző ◦ Összetett lekérdezés: /könyvtár/könyv[év>2000 and polc=”2B”] Számítógép rendszerek, 2. óra: Alkalmazásrétegi internetes protokollok; egyszerű szabványos adatcsere formátumok

26/39

XML példák: SVG dokumentum <svg version="1.1" xmlns="http://www.w3.org/2000/svg"> <polyline points="100,70 170,30 240,70 310,30 380,70 450,30 520,70" style="fill:none;stroke:red"/> <ellipse cx="300" cy="150" rx="200" ry="80" style="fill:none; stroke:green"/> <polygon points="100,240 520,240 540,260 80,260" style="fill:none;stroke:blue"/>


27/39

XML példák: XHTML dokumentum

XHTML példa dokumentum
Gyümölcsválasztó

Válasszon az alábbi gyümölcsök közül!

<select name="gyumolcs">

A böngésző így jeleníti meg


28/39

XML példák: GML dokumentum-töredék 0,0 100,0 100,100 0,100 0,0 100,200 100,200 150,300


29/39

XML példák: WFS lekérdezés

<wfs:GetFeature xmlns:wfs="http://www.opengis.net/wfs" xmlns:ogc="http://www.opengis.net/ogc" xmlns:gml="http://www.opengis.net/gml" xmlns:cgf="http://www.opengis.net/cite/geometry" outputFormat="GML2" version="1.0.0" service="WFS"> <wfs:Query typeName="esri:sc_cities-6" bbox="-71.00,42.00,-72.00,43.00">


30/39

Titkosítás • Szimmetrikus kulcsú titkosítás: ◦ Mind a küldő, mind a feladó ismeri a titkosítás kulcsát ◦ Az információ titkosítása és visszafejtése a kulcs segítségével történik ◦ Ilyen algoritmusok például: Twofish, AES, Blowfish, 3DES • Aszimmetrikus (nyilvános) kulcsú titkosítás: ◦ A küldő fél rendelkezik egy privát és egy publikus kulccsal ◦ Az egyik kulcs csak az információ titkosítását, a másik pedig csak a visszafejtését teszi lehetővé (az egyik kulcs ismeretében a másik „kitalálása” csak igen nagy erőforrásokkal és igen hosszú idő alatt lehetséges) ▪ Ha a titkosító kulcs nyilvános: lehetséges titkosított üzenet küldése a visszafejtő kulcs tulajdonosának (a titkosított üzenetet csak a címzett tudja elolvasni) ▪ Ha a visszafejtő kulcs nyilvános: a titkosító kulcs tulajdonosa a titkosítással egyben hitelesíti is az elküldött üzenetet (a titkosított üzenetet csak a kulcs tulajdonosa adhatta fel) → digitális aláírás ▪ Ha mindkét fél rendelkezik egy privát és egy publikus kulccsal is, akkor a másik fél nyilvános kulcsa és a saját publikus kulcs, valamint egy közösen ismert véletlen szám alapján mindketten előállíthatnak egy közös kulcsot (Diffie–Hellman key exchange) Számítógép rendszerek, 2. óra: Alkalmazásrétegi internetes protokollok; egyszerű szabványos adatcsere formátumok

31/39

Privát-publikus kulcspárok alkalmazása

• Felhasználó azonosítása egy távoli rendszeren (pl. SSH kapcsolat) ◦ A távoli rendszeren megtalálható a felhasználó publikus kulcsa ◦ A privát kulcsot célszerű jelszóval is titkosítani, így a belépési adatok ellopásához meg kell szerezni a privát kulcsot tartalmazó állományt, és az annak titkosítására használt jelszót is • Személyazonosság igazolása / távoli rendszerek azonosítása ◦ Digitálisan aláírt elektronikus üzenetek (levelek, számlák, stb.) ◦ Távoli rendszerek megbízhatóságának ellenőrzése (on-line banki tranzakciók, stb.)


32/39

Privát-publikus kulcspárok alkalmazása ◦ A kérdés: honnan tudjuk, hogy a privát kulcs tulajdonosa valójában az, akinek vallja magát? ▪ PKI: Public key infrastructure • Megbízható tanúsítvány-kibocsátók (CA: certificate authority) ellenőrzik a kulcs tulajdonosának személyazonosságát / a webhely valódiságát, és saját kulcsukkal aláírják a kérdéses nyilvános kulcsot • A tanúsítványok láncolata visszakövethető egy megbízható legfelsőbb szintű CA-ig, amiknek a listája az operációs rendszerbe vagy a kérdéses programba be van építve ▪ Web of trust („a bizalom hálója”) • Személyek és nyilvános kulcsok egymáshoz kötődésének személyes megerősítése (key signing party-k) • Már megbízhatónak nyilvánított kulcs-tulajdonosok megbízhatónak javasolhatnak még nem megerősített nyilvános kulcsokat • Implementációk: PGP (Pretty Good Privacy), GnuPG (vagy GPG: GNU Privacy Guard) Számítógép rendszerek, 2. óra: Alkalmazásrétegi internetes protokollok; egyszerű szabványos adatcsere formátumok

33/39

PKI-problémák • Olykor még a nagy és neves CA-knak is akadhatnak problémáik... ◦ Comodo Group: betörés után hamis tanúsítványok kerültek kibocsátásra pl. a GMail, MSN, Google, Yahoo szolgáltatásaihoz (2011 március) ◦ DigiNotar: betörés után hamis tanúsítványok kerültek kibocsátásra pl. a Google, Yahoo, WordPress szoláltatásaihoz, valamint több holland kormányzati szolgáltatáshoz (2011 július) ◦ Trustwave: tanúsítvány-hitelesítésre alkalmas tanúsítványt adott ki egy magáncégnek, aki saját dolgozóinak titkosított internet-forgalmát akarta lehallgatni (2012 február) ◦ Mit lehet tenni ezek észlelése után? ▪ Tanúsítvány-visszavonási listák (CRL: certificate revocation list) közzététele: minden CA közzéteszi az általa hitelesített, de visszavont tanúsítványok listáját ▪ OCSP (Online Certificate Status Protocol) kiszolgálók használata: központi helyen gyűjtött CRL-ek alapján egyes tanúsítványok státuszának gyors ellenőrzése (pl. Firefox ▪ Végső megoldásként CA-k komplett eltávolítása a listából (operációs rendszer vagy szoftver frissítésével) Számítógép rendszerek, 2. óra: Alkalmazásrétegi internetes protokollok; egyszerű szabványos adatcsere formátumok

34/39

Adathalászat • Ami ellen semmi nem véd: a felhasználók hiszékenysége


35/39

Adathalászat • Ami ellen semmi nem véd: felhasználók hiszékenysége


36/39

Biztonságos kapcsolat létesítése

• IPsec: Internet Protocol Security ◦ Az internet protokollstruktúra 2. rétegében működik ◦ Kommunikáló felek azonosítása, teljes IP csomagok titkosítása, vagy csak az adattartalom titkosítása (a fejléc megmarad) ◦ Operációs rendszer szintű támogatás • SSL: Secure Sockets Layer / TLS: Transport Layer Security ◦ Az internet protokollstruktúra 4. rétegében működik (alkalmazásréteg) ◦ Kommunikáló felek azonosítása, alkalmazásrétegi üzenetek titkosítása ◦ Alkalmazásszintű támogatást igényel


37/39

Biztonságos kapcsolat létesítése • SSH csatornák ◦ Az internet protokollstruktúra 4. rétegében működik (alkalmazásréteg) ◦ Ponttól-pontig titkosítás (pl. otthoni számítógép és a munkahelyi hálózat egy konkrét kiszolgálója között) ▪ Helyi vagy távoli portok forgalmának továbbítása biztonságos csatornán ▪ Dinamikus port-továbbítás SOCKS proxy létesítésével ◦ A porttovábbítás nem igényel speciális támogatást, a SOCKS proxy használata alkalmazásszintű (vagy operációs rendszer szintű) támogatást igényel • VPN (virtual private network) megoldások ◦ Pl. OpenVPN ▪ SSL/TLS alkalmazása a titkosított csatorna kiépítésére ▪ Az operációs rendszer számára egy titkosított IP csatornát biztosít, vagy egy titkosított csatornán Ethernet kapcsolatot emulál Számítógép rendszerek, 2. óra: Alkalmazásrétegi internetes protokollok; egyszerű szabványos adatcsere formátumok

38/39

Források, további olvasnivalók: • Wikipedia (információk, péda munkamenetek): ∘ http://en.wikipedia.org/wiki/Domain_Name_System ∘ http://en.wikipedia.org/wiki/WHOIS ∘ http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol ∘ http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol ∘ http://en.wikipedia.org/wiki/Post_Office_Protocol ∘ http://en.wikipedia.org/wiki/ASCII ∘ http://en.wikipedia.org/wiki/ISO-8859 ∘ http://en.wikipedia.org/wiki/Unicode ∘ http://en.wikipedia.org/wiki/UTF-8 ∘ stb.

• W3Schools XHTML referencia http://www.w3schools.com/tags/default.asp

• Szövegkódolási táblázatok ∘ http://dret.net/lectures/publishing-spring07/img/iso-8859-1.gif ∘ http://dret.net/lectures/publishing-spring07/img/iso-8859-2.gif ∘ http://dret.net/lectures/publishing-spring07/img/iso-8859-7.gif ∘ http://www.asahi-net.or.jp/~yw3t-trns/code/iso646-us.jpg Számítógép rendszerek, 2. óra: Alkalmazásrétegi internetes protokollok; egyszerű szabványos adatcsere formátumok

39/39

Számítógép rendszerek. 2. óra. Alkalmazásrétegi internetes protokollok Egyszerű szabványos adatcsere formátumok Titkosítás, biztonságos adatcsere

Recommend Documents

Gyümölcsválasztó