Tcpipalapok 2

Windows Server 2008
TCP/IP Alapok
2. ktet
V1.0
Petrnyi Jzsef
2010, Petrnyi Jzsef 1.0 verzi, els kiads Minden jog fenntartva. A knyv rsa sorn a szerz s a kiad a legnagyobb gondossggal s krltekintssel igyekezett eljrni. Ennek ellenre elfordulhat, hogy nmely informci nem pontos vagy teljes, esetleg elavultt vlt. Az algoritmusokat s mdszereket mindenki csak sajt felelssgre alkalmazza. Felhasznls eltt prblja ki s dntse el sajt maga, hogy megfelel-e a cljainak. A knyvben foglalt informcik felhasznlsbl fakad esetleges krokrt sem a szerz, sem a kiad nem vonhat felelssgre. A cgekkel, termkekkel, honlapokkal kapcsolatos listk, hibk s pldk kizrlag oktatsi jelleggel kerlnek bemutatsra, kedvez vagy kedveztlen kvetkeztetsek nlkl. Az oldalakon elfordul mrka- valamint kereskedelmi vdjegyek bejegyzjk tulajdonban llnak.
Microsoft Magyarorszg 2010
Ksznetnyilvnts:
Tovbbra is hatalmas ksznet illeti Joseph Davies-t, alias Cable Guy-t az alapos, szemlletforml rsairt. A wikipedia most sem hazudtolta meg nmagt, mindenhez hozz tudott szlni, igaz, nem mindig sikerlt rdemben. De becsletesen prblkozott.
"- Felejtsk el az egszet, kedves Tt - mondta nagylelken -, s lssunk hozz a dobozolshoz. Minden percrt kr. Leltek. Tt is. Ugyanaz a Tt, aki az imnt mg lefitymlta s asszonypepecselsnek nzte ezt a munkt, most rlt, hogy dobozolhatott... Pedig senki se hvta; pp csak, hogy helyet szortottak neki. Persze, akrhogy vigyzott, csupa flresikerlt, pofoncsapott doboz kerlt ki a keze all, de szerencsre ezen se akadt fl senki, legfljebb elnzen sszemosolyogtak. Helyrellt a bke. Hossz negyedrkig senki se beszlt, csak a margvg friss kattogsa hallatszott. Ksbb friss leveg jtt a hegyekbl. Szemkzt, a Bbony tisztsain a gyantaszretelk tzraksai hunyorogtak. Ttk ezt se lttk. Mindenrl elfeledkezve vgtk s hajtogattk a dobozokat. Egy ra mlva az rnagy udvariasan rdekldtt: - Nem lmosodtak el? Tt, akinek majd leragadt a szeme, megnyugtatta az rnagyot, hogy esze gban sincs lefekdni. Tovbb dobozoltak. Egy id mlva az rnagy megismtelte az elbbi krdst. Ttk egybehangzan azt lltottk, hogy nem lmosak. A harmadik krdsre Mariska, akinek bal szeme ersen viszketni kezdett, azt vlaszolta, hogy ha az rnagy r pihenni vgyik, akkor k is ks zek abbahagyni a munkt. - Dehogyis vgyom pihenni! - mondta az rnagy. - Sajnos, nagyon rossz alv vagyok. - Ettl az les hegyi levegtl mg lmatlansgban szenved vendgeink is ellmosodtak - jegyezte meg Tt. - Nekem az se hasznl - legyintett Varr rnagy. - n a legszvesebben reggelig hajtogatnm a dobozokat. A kornfekvshez szokott Tt kezben sztroppant egy doboz. Arcvonsai a fradtsgtl amgy is sszezilldtak; ijeszt tekintettel meredt az rnagyra. Ekkor azonban Mariska bokn rgta, amire Tt - nagy erfesztssel - elmosolyodott. - n is csak most kezdek belejnni - mondta. s tovbb dobozoltak. " rkny Istvn: Ttk
TARTALOMJEGYZK
1 2 Bevezet _______________________________________________________________________________ 8 Az alkalmazs rteg webes protokolljai _____________________________________________ 9 2.1 HTTP - Aki lenyomta a pockot ___________________________________________________ 9 HTTP Request ______________________________________________________________ 20 Request-Line __________________________________________________________ 21 Message Header (Request)___________________________________________ 22 Sttusz kdok _________________________________________________________ 24 Message Header (Response) _________________________________________ 26 2.1.1.1 2.1.1.2 2.1.2 2.1.2.1 2.1.2.2 2.2 2.2.1 2.2.2 2.2.3 2.1.1
HTTP Response ____________________________________________________________ 23
FTP - A teherhord szvr _____________________________________________________ 28 FTP parancsok _____________________________________________________________ 29 FTP kdok __________________________________________________________________ 32 Az FTP protokoll lelkivilga _______________________________________________ 33 Aktv md______________________________________________________________ 34 Passzv md ___________________________________________________________ 36 FTP s NAT ____________________________________________________________ 38
2.2.3.1 2.2.3.2 2.2.3.3 2.3 2.3.1
SMTP - A npszer reg ________________________________________________________ 40 Levelek tovbbtsa, azaz a konkrt SMTP ______________________________ 41 SMTP, ESMTP parancsok _____________________________________________ 45 SMTP kdok ___________________________________________________________ 46 2.3.1.1 2.3.1.2
2.3.2 2.3.3 2.4 2.5
Az elektronikus levelek szerkezete, azaz IMF ___________________________ 48 Levelezznk mr vgre! ___________________________________________________ 68
Porttblzat _____________________________________________________________________ 77 Sztorik ___________________________________________________________________________ 81 Geek r nyaral______________________________________________________________ 81 Geek r a fogorvosnl _____________________________________________________ 88
2.5.1 2.5.2 3 3.1 3.2
A biztonsg krdse a TCP/IP-ben_________________________________________________ 90 SSL, TLS __________________________________________________________________________ 90 SSH _______________________________________________________________________________ 95
3.3
Az ismertebb protokollok biztonsgosabb ttele ___________________________ 97 HTTP ________________________________________________________________________ 97 Autentikci ___________________________________________________________ 97 HTTPS_________________________________________________________________ 103 SHTTP_________________________________________________________________ 109 FTPS___________________________________________________________________ 111 FTP over SSH _________________________________________________________ 113 A bjos flrertsek forrsa - SFTP _________________________________ 113 3.3.1.1 3.3.1.2 3.3.1.3
3.3.1
3.3.2
FTP _________________________________________________________________________ 111
3.3.2.1 3.3.2.2 3.3.2.3 3.3.3 3.4 3.4.1
A tbbiek, azaz a STARTTLS _____________________________________________ 114 Authentication Header ___________________________________________________ 117 AH Transport md ___________________________________________________ 118 AH Tunnel mode _____________________________________________________ 119 ESP Transport md __________________________________________________ 121 ESP Tunnel md______________________________________________________ 123 Main mode (ISAKMP SA) ____________________________________________ 124 Quick mode (IPSec SA) ______________________________________________ 128 IKE ____________________________________________________________________ 128 IKE v2 _________________________________________________________________ 129 AuthIP ________________________________________________________________ 131
IPSec ____________________________________________________________________________ 116 3.4.1.1 3.4.1.2
3.4.2
Encapsulating Security Payload _________________________________________ 120
3.4.2.1 3.4.2.2 3.4.3 3.4.3.1 3.4.3.2 3.4.3.3 3.4.3.4 3.4.3.5 3.4.4 3.5 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 3.5.6 3.6
Security Associations _____________________________________________________ 124
sszefoglals ______________________________________________________________ 132 PPTP _______________________________________________________________________ 136 L2TP _______________________________________________________________________ 137 L2TP / IPSec_______________________________________________________________ 138 SSTP ________________________________________________________________________ 139 VPN Reconnect ____________________________________________________________ 142 sszefoglals ______________________________________________________________ 145
VPN s trsai ___________________________________________________________________ 133
Autentikci ____________________________________________________________________ 146
3.6.1 3.6.2 4 5 6 7
RADIUS ____________________________________________________________________ 147 Ktfaktoros autentikci _________________________________________________ 151
Kivezets ____________________________________________________________________________ 155 Forrsok, linkek ____________________________________________________________________ 156 Javtsok ____________________________________________________________________________ 159 A szerz _____________________________________________________________________________ 160
A TCP/IP PROTOKOLL MKDSE
1 B EVEZET
Rendhagy knyv lesz1. Ugyanarrl a tmrl fogok rni mg egy knyvet: TCP/IP protokollok, szolgltatsok. Csakhogy eddig vertiklisan jrtuk be a teret: elindultunk alulrl s onnan msztunk fel a legfels szintre. Most viszont eleve a legfels szintrl indulunk s maximum egy szintet lpnk lejjebb. Ez a knyv ugyanis szinte kizrlag a roppant gazdagon vegetl alkalmazs rtegrl szl. (Csak az IPSec kedvrt fogunk lenzni egyszer az IP rteg szintjre.) Hogyan vlasztottam ki a bemutatand protokollokat? Web. Internet. Ma mr minden ekrl forog. Logikusnak tnt azokat a protokollokat sszeszedni, melyek a legelterjedtebbek, illetve legfontosabbak a neten. Aztn ha mr internet: mi a legnagyobb baj ezekkel a protokollokkal? Ht a biztonsg, illetve annak hinya. Hogyan lehet srbl vrat pteni alapban gyenge biztonsg protokollokbl megbzhat kapcsolatokat pteni? J krds. Lehet. Nem egyszer, de nem lehetetlen. Ilyesmikkel fogok foglalkozni ebben a knyvben.
A kapcsold els ktet, illetve az els ktet sszefoglal fzete letlthet innen: http://mivanvelem.hu/letoltheto-konyvek/
Mondtam. (-:
~8~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI
2 A Z ALKALMAZS RTEG W EBES PROTOKOLLJAI

2.1 HTTP - A KI
RFC 2616 Brmennyire is furcsa, de volt olyan idszak, amikor a web nem volt egyenl a HTTP-vel. Mg emlkszem arra, amikor BBS-ek voltak, ksbb FTP szerverek, aki pedig hipertextben utazott, az bszen nyomta a pockot - azaz a gopher protokollt.
LEN YOMTA A POCKOT
2.1. BRA E GY GOPHER OLDAL http://en.wikipedia.org/wiki/Gopher_(protocol)
Aztn 1993-ban beindult a HTTP s szp lassan gyztt. A gopher ugyanis nem volt kpes a szveg mellett grafikt is megjelenteni. De mit is tud ez a HTTP? Hypertext Transfer Protocol. Azaz amennyiben a kliens oldali bngszprogrambl krs rkezik egy webszerverhez, az olyan szvegeket kpes visszakldeni, melyekbl a kliensgpeken weboldalak llnak ssze: linkekkel, kpekkel, formzott szvegekkel - s manapsg mr videkkal is. gy nagyjbl ezzel le is fedtem most az internet 95%-t. (Warez s porn nlkl a 10%-t.)
~9~
A TCP/IP PROTOKOLL MKDSE Az elbb elhangzott kt nagyon fontos kifejezs. Nem, nem a warez s a porn. Az, hogy kliens s szerver. A HTTP egy olyan protokoll, mely mindig egy kliens s egy szerver kztt mkdik. A HTTP szerver (ma mr egyszeren csak webszerver) egy olyan szmtgp, mely tele van weblapokkal. Ezek lehetnek statikusak, vagy egy alkalmazs ltal legtbbszr valamilyen adatbzisra tmaszkodva - dinamikusan generltak. A kommunikci mindig gy kezddik, hogy jn egy HTTP kliens (a legtbbszr valamelyik bngsz) s elkr ebbl a sok weblapbl egyet. A reklmlobby szerencsre mg nem olyan ers, hogy krs nlkl toljanak le a gpedre egy hvelygomba reklmot2. A szerver fogadja a krst, rtelmezi... majd visszakldi a krt weblapot. Eddig nem gyztk rtegezni a hlzatos kommunikcit. Hol illeszkedik bele ebbe a modellbe a HTTP?
2.2. BR A A HTTP CSOMAGOK HELYE
Mint minden tisztessges alkalmazs-rtegbeli protokoll, a csomagjai a szlltsi protokoll (TCP) payload-jn bell utaznak. A kliens ide tolja be a krst, a webszerver innen veszi ki s ide rakja vissza a vlaszt. Kicsit elrerohanok.
Az ms krds, hogy ha lekrsz egy weblapot, akkor mr toljk mell a hirdetst is. De ehhez elszr neked kellett krned.
2
~ 10 ~
2.3. BRA L EKRTEM AZ INDEX NYITLAPJT
Ez egy olyan kp lesz, melyet a kvetkezkben sokszor fogunk mg nzegetni. Most csak azt tessk szrevenni, hogyan is zajlott a kommunikci: Az 58, 60, 61 csomagokban megtrtnt az gynevezett hrmas kzfog, a kt fl kiptette a TCP csatornt. A 62-es csomagban a kliens (192.168.1.99) elkldte a krst. Ezt a krst ltjuk kirszletezve is. A kzps ablakban ltszik, hogy egy GET krssel indul, s a teljes krs elfr egy TCP szegmensben. Az als ablakban binris formban is megtekinthetjk, st, a Wireshark van olyan r, hogy a teljes krds/felelet prost szveges formban is megmutatja. Mi tbb, le is tudjuk menteni. (Ezzel azrt rdekes trkkket lehet jtszani.) A 68-as csomagtl szabadult el a pokol, a webszerver nekillt kldeni az index.hu nyitlapjt. Szp nagy nyitlap, elg sok TCP szegmenst kellett befognia a szlltsi munklatokba. Habr a kpen nem ltszik, de hidd el nekem, a 114, 119, 120 csomagokban mindkt fl mindkt oldalrl lebontotta a TCP csatornt. Most alapveten kt ton indulhatunk el. Egyrszt, ragaszkodva a hagyomnyokhoz, nekillhatunk request/response csomagokat boncolni, biteket elemezni, flageket rtelmezni. Ez akkor korrekt, ha tnyleg csak a HTTP protokollt szeretnm bemutatni. De hiba lenne a HTTP kapcsn csak a protokollrl beszlni - hiszen legalbb annyira rdekes a krnyezet is, amelyben hasznljk. Ok, hogy tudjuk, hogyan pl fel egy
~ 11 ~
A TCP/IP PROTOKOLL MKDSE request csomag - de azt sem rt tudni, mikor kldi azt a kliens s hogy mondjuk hnyszor. gy most elszr beszlek nagy ltalnossgban a HTTP-t hasznl felek kommunikcijrl, sunyi kis trkkjeirl. Aztn ha mr kpben lesznk, akkor jhetnek a csomagboncolsok. Fontos, hogy a kommunikcirl lesz sz. Eszem gban sincs webszerver zemeltet fejezetet rni. Az Internet Information Server bemutatsa nmagban is megtltene egy knyvet. Teht ott jrtunk, hogy tipikus kliens-szerver kommunikci.
2.4. BRA HTTP KLIENS - SZERVER KOMMUNIKCI
Lthat, semmi faxni: csatorna kipl, jn a krs, megy a vlasz, csatorna mindkt oldal fell lebomlik. Nagyjbl gy is mkdtt a HTTP az 1.0 verziig. Sok baj nem volt vele - azon kvl, hogy borzaszt lass volt. Az 1.1 verziban gyorstottak rajta egy kicsit.
~ 12 ~
2.5. BRA F OLYAMATOS KAPCSOLAT
Egy weboldal ugyanis ritkn jn le egy krssel. (Az a gopher.:-) Kln kell krni a szveget, kln kell krni a kpeket, kln a kliens oldali szkripteket. Nyilvn ha nem nyitunk mindegyik krsnek egy kln sessiont, akkor valamivel gyorsabban jn le az oldal. Ezt a trkkt hvjk gy, hogy persistence, azaz folyamatos kapcsolat. rtelemszeren komoly sszjtk kell hozz - elssorban a szervernek kell mrskelnie magt, ne kezdje el addig lezrni a kapcsolatot, amg a kliens meg nem kapta a teljes oldalt. Gyorsnak gyors... de nzd meg jobban a rajzot. Optimlis is?
~ 13 ~
2.6. BRA P IPELINE
Mr hogy lenne? Mikor jobb a soros feldolgozs a prhuzamosnl? A kliens gppuska-sebessggel elkezdi ldzni a krseket, nem vrva meg, amg megrkezgetnek az elz krsekre a vlaszok, a szerver pedig kpni-nyelni nem tudva folyamatosan nyomja lefel az ojjektumokat. Mris gyorsabb lett az index.hu. (De mg nem elg gyors. Aki megnzi az brt ( 2.3. bra Lekrtem az index nyitlapjt), az lthat rajta mg egy trkkt. De ezt csak ksbb meslem el.) Apr kis kitr. rtam, hogy a kliens kln objektumknt kri le a kliens oldali szkripteket. De ha ez gy van, akkor el is lehet ezeket az objektumokat kapni.
~ 14 ~
2.7. BRA J AVASCRIPT AZ INDEXEN
El bizony. s ha elkaptuk, akkor az gyes kis Wireshark ssze is rakja neknk a szkriptet. Ltjuk? A piros a krs, a kk a vlasz. s ott van benne a tipus:
content-Type: application/javascript
2.8. BRA A WEBLAP FORRSA KONTR A CAPTURE
Aki szeret bogarszgatni, az innentl el lesz egy darabig az j jtkkal.
~ 15 ~
A TCP/IP PROTOKOLL MKDSE Mi viszont beszljnk komolyabb dolgokrl. Pldul a stikrl. A HTTP kapcsolat ugyanis nmagban nem tud llapotot trolni. A kliens elkldi a krst, a szerver fogadja, majd visszaadja a vlaszt. Vegyk szre, hogy a szervernek fogalma sincs, hogy ez a kliens most volt itt elszr, vagy egy perccel ezeltt is kopogtatott. Amennyire a szerver emlkezik... ahhoz kpest az aranyhal egy memriazsonglr. Baj ez? Nem annyira. Feltve, hogy szeretnk llandan bejelentkezni a kedvenc frumunkba minden topikvltskor. Ha nem zavar, hogy a delicous mindig jelszt kr, ha el akarunk menteni egy cmet. Ok, baj. Akkor okostsuk fel a webszervernket. Jegyezzen meg minden krst visszamenleg mondjuk kt htig, s minden krsnl fussa t ezeket. Elre a hasznlhatatlan webszerverekrt! Erre a problmra jelentenek megoldst a stik. (Cookies.) Hogyan mkdnek?
2.9. BRA HTTP TSVLTS
gy nz ki egy hagyomnyos HTTP romnc. A kliens lekr egy weboldalt, a szerver a 200-as kddal jelzi, hogy a krt weblapot megtallta - majd a vlaszzenetbe be is csomagolja azt. Itt mg nincs cookie.
~ 16 ~
2.10. BRA M EGJELENIK A COOKIE
Itt mr van. Amikor a szerver sszerakja a vlaszt, belerak egy stit. A kliens megkszni, lementi, majd amikor legkzelebb megint a szerverhez fordul, akkor mr viszi magval. Ebbe a stibe van belestve minden olyan informci, mely fontos lehet az ppen piszterglt webalkalmazs szmra: felhasznlnv, emailcm, kpernypozci... brmi.
2.11. BRA S TI A MIVANVELEM OLD ALHOZ
Nzznk mg egy pldt. Belptem a mivanvelem.hu oldalra, ahol rendszeresen szoktam kommentelni. A kliensprogramom mr eleve tudta, hogy ehhez az oldalhoz van egy stim, teht helybl belerakta a krsbe. Ltod, nem: valami binris zsizsa, a fene tudja, mit jelent, aztn ott van a kommentel neve (JoeP), majd nmi zsizsa utn
~ 17 ~
A TCP/IP PROTOKOLL MKDSE jn a kommentelskor legutbb megadott emailcmem. (Ezt takartam le kt tglalappal.) A sti miatt van az, hogy amikor belpek erre az oldalra, akkor mr ki vannak tltve a kommentel form elemei. Ha rdekel mg egy plda, lapozz vissza a kvetkez brhoz: 2.3. bra Lekrtem az index nyitlapjt. Miket tudsz kihvelyezni ebbl a stibl? 'Tiszavirg'. Meg 'egy nap pompa'. Meg egy lengyel weblap. gy ltszik, az index szereti az abszurd zests stiket. De biztos van r okuk. Vajon meg lehet nzni ezeket a stiket a gpeden is? Hiszen tuti, hogy ott trolja valahol a bngszprogramod.
2.12. BRA S TITR
Ott vannak, bizony. A loklis profilodban. Mghozz szveges formban. Elg kellemetlen meglepets, hogy a stik nagy rsze reklmoldal. Vajon miket jegyezhetnek meg ezek rlad? Az amazon.com mondjuk mg rthet is, ha szoktl ott vsrolni, akkor tudod, hogy minden belpskor az zlsedhez passzol knlatot dobnak fel a friss rukbl. Nyugodt vagy? Mi van akkor, ha egy weblap felolvassa az sszes stidet s komplett profilt kszt rlad? Csoda. Minden sti webszerverhez van rendelve s a kliens krskor csak azt a stit viszi magval, amelyik a beclzott webszerverhez tartozik Megnyugodtl?
~ 18 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI Kr volt. Ugyanis ha egy reklmszerveren lv banner van befzve szz oldalra, akkor ugyanaz a szerver mindegyik - nem hozztartoz, de sessionon belli - oldal ltogatsakor hozzfr a stijhez s belerakhat abba ppen az rintett oldalakra jellemz infkat. Azaz pont a reklmszerverek azok, amelyek bannereken keresztl tnyleg kpesek profilt alkotni rlad. Termszetesen a stiket le tudod tiltani a bngszdben. de ekkor visszatrtnk oda, hogy a webszerver abszolt semmit sem fog tudni rlad. Ennl mr az is jobb tlet, ha valamilyen adblock plugint hasznlsz. rzem, tkn lsz, hogy boncoljunk mr vgre krseket, vlaszokat. Nyugi. Lesz mg itt annyi tblzat, hogy jszaka is kocksat fogsz lmodni. De most ismteljnk egy kicsit. Mi is az, hogy proxy? Az inas, aki beviszi a nvjegyet. Hogyan is nz ez ki konkrtan a HTTP esetben? Ht gy, hogy a kliens a krsvel nem a webszerverhez fordul kzvetlenl, hanem a proxyhoz. Az j tanrbcsisan megvizsglja, mit is szeretne krni a kliens a webszervertl. rtelmezi a krst. Ehhez persze minimum azt a HTTP verzit kell ismernie, mint a megclzott webszerver. Aztn ha mr pontosan tud mindent, akkor kliensknt elmegy az illet webszerverhez, tolmcsolja neki a krst, majd a kapott vlaszt visszaadja az eredeti kliensnek. Ravasz krds jn: mit csinl akkor a proxy cache? Hopp. Errl eddig nem volt sz. Pedig nem nehz. St, logikus. A proxy nem csak egyszeren visszaadja a krt tartalmat a kliensnek, hanem be is rakja egy tmeneti trolba. Ez a cache. gy ha rvid idn bell valamelyik msik kliens is lekri ugyanezt az oldalt, akkor nem megy el az veghegyen tlra, hanem a sajt troljbl adja vissza. Magunk kztt vagyunk, beszlhetnk szintn. n borzasztan idegenkedek mindenfle cache techniktl. De ez rthet, mert n mr reg vagyok s amennyi varjt lttam mr karn, annyi a macskaparadicsomban sincs. Mindenhol, ahol valamilyen cache technika jtszik, ott az rdg a rszletekben bjik meg. Eleinte a cache hasznlat... mondjuk gy, hogy nem volt teljesen kifinomult. Egyszer megszakadt egy letltsed s utna rkig csak a hibs fjl jtt le a proxyrl, akrmelyik gprl is prblkoztl. Hozzszltl egy frumon, prgtt a tma, bizsergett az ujjad, kivncsi voltl a tbbiek reakcijra - de a proxy cache miatt hossz tz percekig nem lttl vltozst.
~ 19 ~
A TCP/IP PROTOKOLL MKDSE Aztn telt-mlt az id, szltek a mrnkk - s ma mr egsz jl hasznlhat technolgia lett belle. Meg j bonyolult is, mondjuk. 2.1.1 HTTP R EQ U E ST
2.13. BRA HTTP REQUEST
Kinagytottam a korbbi bra (2.3. bra Lekrtem az index nyitlapjt) egy rszlett. gy nz ki egy vadonban kborl HTTP request.
Ha nem akarunk sniffer programot telepteni, de kivncsiak vagyunk a request/response blokkokra, hasznljuk btran a kvetkez linket: http://web-sniffer.net/
Hivatalosan a HTTP Request ngy rszre oszthat.
2.14. BRA A HTTP R EQUEST ELEMEI
~ 20 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI REQUEST-LINE: Errl a sorrl van sz: GET / HTTP1.1. ltalnostva:
'<metdus> <URI> <verzi>'
alak. Itt mondjuk meg a szervernek, hogy mi a szszt is akarunk tle. MESSAGE HEADERS: Itt sorolunk fel minden olyan informcit, melyrl a szervernek tudnia kell ahhoz, hogy ki tudjon minket szolglni. MESSAGE BODY: Opcionlis mez. Ha valami inft akarunk feltlteni a szerverre a krs sorn (POST metdus), akkor az itt utazik. Az egyes mezket az klnbzteti meg egymstl, hogy j sorban kezddnek, azaz a Carriege Return-Line feed (CR-LF.) karakterekkel zrdnak. Mg az res sor is.
2. 1 .1 . 1 R E Q U E S T -L I N E GET <metdus> / <URI> HTTP1.1. <verzi>'
Haladjunk htulrl, az az egyszerbb. A verziszm azt jelenti, melyik a legmagasabb szint HTTP verzi, melyet a kliens ismer. Az URI azt a weblapot adja meg, amelyikre a krs vonatkozik. Jelen pldban ez a /, azaz a root lap. Vgl a metdus maga az ige - mit is akarunk elrni a krssel?
2.1. TBLZAT Parancs Lers GET Lekrjk a weboldalt. Ennyire egyszer. A szerver pedig visszakld valamit, ltalban egy OK -t s magt az oldalt. Nyilvn ez a leggyakoribb krs. HEAD Lekrjk a weboldalt. Ismers? De a szerver vlasza mr ms: csak a fejlcet kldi el, magt az oldalt nem. POST Feldolgozs cljbl adatokat kldnk a szerver szmra. Klasszikus plda egy kitlttt form. Az adatok a Message Body rszben utaznak, a tloldalon egy webes alkalmazs kapja el ket. PUT Feltltnk egy adatcsomagot, leginkbb egy fjlt. Szintn a Message Body rszben utazik. A szerver nem dolgozza fel, egyszeren csak egy elrhet adat lesz belle. DELETE Megkrjk a szervert, hogy a megadott valamit trlje, lccilcci. TRACE Megkrjk a szervert, hogy kldje vissza a krsnket. Ebbl fogjuk tudni, hogy mi lett a krsnkbl, mire a szerverhez rt. OPTIONS Visszaadja azokat a HTTP metdusokat, melyeket a szerver egyltaln megrt. CONNECT Kri a szervert - ami ebben az esetben ltalban proxy - hogy kezdjen el bszen csatornt pteni.
~ 21 ~
2. 1 .1 . 2 M E S S A G E H E A D E R (R E Q U E S T )
2.2. TBLZAT Tpus ACCEPT ACCEPTCHARSET ACCEPTENCODING ACCEPTLANGUAGE AUTHORIZATION CACHECONTROL CONNECTION COOKIE CONTENTLENGTH CONTENT-TYPE DATE EXPECT FROM HOST
Nv Az elfogadott tartalomtipusok Az elfogadott karakterkszletek Az elfogadott kdolsok Az elfogadott nyelvek A bejelentkezsi adatok elkldse Elrja, hogy az zenetvltsban rszt vev felek hasznlhatnak-e az zenetvltssal kapcsolatban tmeneti trolt - s ha igen, akkor hogyan. Megnevezi azt a headert, melyet trlni kell a krsbl, ha az proxyn megy keresztl. A kliensnk mr kapott egy stit (Set-Cookie), s most visszakldi a szervernek. A Request Body mrete bjtban. A Request Body adattipusa (MIME) Mikor kldtk a krst. Ha a szerver visszakldi ezt, akkor csinld azt. Jelenleg csak a '100 Continue' kdra harap. A krs kldjnek emailcme. Nem tl npszer mez. A megclzott virtulis szerver neve. A HTTP/1.1 ta ktelez.
Mi is ez a virtulis szerver? Nos, arrl van sz, hogy egy konkrt webszerver nem csak egy webalkalmazst tehet elrhetv, hanem tbbet is. Ilyenkor a request header-be rt Host mezben jelezzk, hogy melyik alkalmazshoz fordulunk. Konkrt plda: a mivanvelem.hu s az emaildetektiv.hu blogok ugyanazon a webszerveren laknak. Nzzk meg az brt (2.11. bra Sti a mivanvelem oldalhoz), tisztn lthat, hogy melyik oldalt tmadtam be. Tpus IF-MATCH IF-MODIFIEDSINCE IF-NONE-MATCH IF-RANGE IF-UNMODIFIEDSINCE MAX-FORWARDS Nv Ha letltttem valamit, majd mdosts utn vissza akarom tlteni, akkor leellenrzi, hogy kzben msvalaki nem mdostotta-e? Cache vezrls Cache vezrls Cache vezrls Cache vezrls Az zenetet max. hnyszor lehet forwardolni.
A webszerverek ugyanis kpesek ilyen huncutsgokra. A keresett weboldal mr elkltztt a szerverrl, de otthagyott egy ugroldalt, hogy az rdekldk az j helyen is megtalljk. Tous PRAGMA RANGE REFERER TE UPGRADE USERAGENT VIA WARN Nv smaradvny a korai HTTP verzikbl. Nem az egszet krjk le, csak egy rszt. Melyik weboldalrl rkeztnk a ltogatott oldalra. A statisztikkat gyrt alkalmazsok imdjk. (n is.) Transfer Encoding; megmondja a szervernek, hogy a kliens milyen kdolsokat kpes fogadni. Hogy a kliens s a szerver megtalljk a megfelel magassg kzs HTTP/TLS szintet. Kifle-mifle jszg a kliens? (Lthatod, n ppen Chrome vagyok a pldkban.) Kzli a szerverrel, hogy milyen proxykon keresztl rt el hozz a krs. Balh van.
~ 22 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI 2.1.2 HTTP R E SP O N S E
2.15. BRA HTTP R ESPONSE
A HTTP Response felptse nagyon hasonl a krs felptshez.
2.16. BRA A HTTP VLASZ SZERKEZETE
Az utols 3 mez formailag teljesen azonos (mgha a header tipusok msok is). A markns klnbsg a sttusz sor. Itt ugyanis a szerver kzli a klienssel, hogy mi is pontosan a helyzet a krsvel.
~ 23 ~
2. 1 .2 . 1 S T T U S Z K D O K
Alapveten t nagy kategria ltezik.

2.3. TBLZAT Kd Nv 1xx Informational 2xx Success 3xx Redirection 4xx Client Error 5xx Server Error
Magyarzat A szerver fogta a krst, de valamirt nem tud vlaszolni. A szerver fogta a krst s vlaszolni is tud. A szerver fogta a krst, de a krt oldal mshol van. Hibs a krs, a szerver nem tudja teljesteni. A szerver fogta a krst, de a vlasz sorn hiba keletkezett.
Minden klnsebb magyarzat nlkl lljanak itt az egyes kdok:

2.4. TBLZAT rtk Lers 100 Continue 101 Switching Protocols 102 Processing 200 OK 201 Created 202 Accepted 203 Non-Authoritative Information 204 No Content 205 Reset Content 206 Partial Content 207 Multi-Status 226 IM Used 300 Multiple Choices 301 Moved Permanently 302 Found 303 See Other 304 Not Modified 305 Use Proxy 306 Reserved 307 Temporary Redirect 400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required 408 Request Timeout 409 Conflict 410 Gone 411 Length Required 412 Precondition Failed 413 Request Entity Too Large 414 Request-URI Too Long 415 Unsupported Media Type 416 Requested Range Not Satisfiable 417 Expectation Failed 422 Unprocessable Entity 423 Locked 424 Failed Dependency 42 Upgrade Required
RFC szm [RFC2616] [RFC2616] [RFC2518] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC4918] [RFC3229] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC4918] [RFC4918] [RFC4918] [RFC2817]
~ 24 ~

500 501 502 503 504 505 506 507 510 Internal Server Error Not Implemented Bad Gateway Service Unavailable Gateway Timeout HTTP Version Not Supported Variant Also Negotiates (Experimental) Insufficient Storage Not Extended [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2616] [RFC2295] [RFC4918] [RFC2774]
Forrs: http://www.iana.org/assignments/http-status-codes
Rszletesebben ismertetni egy olyat fogok, mely nem szerepel az elz felsorolsban. Nem vletlenl. (Ettl fggetlenl teljesen hivatalosan ltezik, lsd az albbi RFC-t.) Maradjunk annyiban, hogy j ltni, hogy ebbe a szraz tudomnyba is belefr nha egy kis krkds. Mg ha geek mdra is.
RFC 2324 A fenti RFC az IETF egyik prilis elsejei trfja. Egsz konkrtan a HTCPCP 1.0 protokollt definilja. A protokoll teljes neve: Hypertext Coffee Pot Con trol Protocol, azaz hipertextes kvkint vezrl protokoll. Az a bizonyos hibakd ehhez a protokollhoz kapcsoldik.
418-AS KD: I AM A TEAPOT. 4xx-es kd, azaz a szerver nem tudja rtelmezni a kliens HTCPCP krst. Nyilvn nem is, hiszen a vlaszban a szerver jelzi, hogy egy teakint kszlk, gy nem tud mit kezdeni a kvkint kszlkek vezrlsi parancsaival.
~ 25 ~
2. 1 .2 . 2 M E S S A G E H E A D E R (R E S P O N S E )
Egy rszkkel mr tallkozhattunk a krseknl. Ha nincs vltozs, akkor ezeket itt mr nem fogom rszletezni.
2.5. TBLZAT Header ACCEPT-RANGES AGE ALLOW CACHE-CONTROL CONTENTENCODING CONTENTLANGUAGE CONTENTLENGTH CONTENTLOCATION CONTENTDISPOSITION CONTENT-MD5 CONTENT-RANGE CONTENT-TYPE DATE ETAG EXPIRES LAST-MODIFIED LOCATION PRAGMA PROXYAUTHENTICATE RETRY-AFTER SERVER SET-COOKIE TRAILER
Magyarzat Ha bedl egy letlts, akkor mi az az informatikai alapegysg, amelyikben a kliens lekrheti a hinyz rszleteket. Mennyi ideig lehet az objektum a cache-ben. (sec) Metdusok, melyek a krt objektumhoz hasznlhatk. A visszaadott adatok kdolsa A visszaadott adatok nyelve
Hol tallhat meg mg az oldal Ha ismert a MIME tipus, akkor megadja a lehetsget egy "File Download" ablak elugrsra. A vlaszbl (message body) kpzett MD5 hash, Base64 kdolsban. Ha a szerver rszletekben vlaszol, akkor itt mondja meg, melyik rszletrl van sz.
A lekrt objektum verzi jelleg azonostja. A legtbbszr MD5 hash. Mikortl nem lesz mr rvnyes a vlasz. Mikor mdostottk utoljra a krt objektumot. Hov van tirnytva a tartalom. (3xx kdok) A proxy autentikcit kr. Ha a krt tartalom nem rhet el, mennyi id prblkozzon jra a kliens. A szerver neve, pontosabban tipusa.. Megy a sti. Van olyan, amikor a message body utn mg jnnek headerek. (Chunked transfer -coding) Ezeknek az utlagos headereknek a tipusai vannak felsorolva a trailer mezben.
Na, ennek mi lehet az rtelme? Ht, az, hogy a szerver, amikor kszti a vlaszt, akkor mr tudja, milyen headerek lesznek benne, de ezek mg nem lltak ssze. Ekkor hasznlja ki a chunked kdolst. A kliens folyamatosan kapja a vlaszt, a szerver menetkzben folyamatosan gyrtja a csomagokat gy egyiknek sem kell resjratban vrakoznia.
HEADER TRANSFERENCODING VARY VIA WARNING WWWAUTHENTICATE Magyarzat Milyen kdolsban megy a vlasz. Lehetsgek: chunked, compress, deflate, gzip, identity. Cache vezrls
Milyen autentikcis mdszert kell hasznlni a krt tartalom elrshez.
~ 26 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI Igrtem, hogy megmutatom, mit trkkztt mg az index.hu, hogy gyorsabb legyen az oldal letltse. Nzzk csak meg az brt (2.3. bra Lekrtem az index nyitlapjt). REQUEST HEADER: Accept-encoding: gzip, deflate, sdch. A szerver pedig boldogan vette tudomsul, hogy a kliens elfogadja tmrtett formban is a weboldalt. RESPONSE HEADER: Content-encoding: gzip. Majd az ablak aljn (2.15. bra HTTP Response) lthatod is, hogy a message body mr egy ronda, rtelmezhetetlen binris fjl. Tmrtett.
~ 27 ~
2.2 FTP - A
RFC 959
TEHERHORD SZVR
FTP, azaz File Transfer Protocol. Hozza-viszi a biteket a drton. A HTTP-hez meglehetsen sokban hasonlt. Egyrszt ugyangy kliens-szerver formban ltezik, msrszt nagyjbl egykorak - azaz megalkotsuk pillanatban IT biztonsgi szempontokrl mg csak nem is hallottak. (De errl majd ksbb.) A felek kztti kommunikci is hasonlt annyibl, hogy itt is krsek s vlaszok vannak - de az irnyok mr nem lesznek annyira egyrtelmek. Emiatt nem is rdemes kln kezelni, egyszeren parancsoknak nevezzk mindkettt. A parancsoknak mr nincs annyira rgztett szintaktikja, mint a HTTP esetben. A session fogalom ugyangy ltezik - csak itt tbb is van bellk egy munkameneten bell. Mieltt brmibe is belevgnnk, idebortom a parancsok s a kdok listjt. Mghozz minden klnsebb magyarzat nlkl, gy, ahogy a neten is megtallhat. Ezekbl a parancsokbl ugyanis annyi van, hogy a rszletes ismertetsk bven meghaladja e knyv kereteit. Nem baj, ha elsre nem fogod rteni az sszeset. Ahogy haladunk majd elre, gy lesz rtelme a fontosabb parancsoknak. A tbbi meg gyis csak azrt van itt, hogy teljes legyen a kp.
~ 28 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI 2.2.1 FTP
P A R AN CSO K
2.6. TBLZAT Parancs RFC ABOR ACCT ADAT RFC 2228 ALLO APPE AUTH RFC 2228 CCC RFC 2228 CDUP CONF RFC 2228 CWD DELE ENC RFC 2228 EPRT RFC 2428 EPSV RFC 2428 FEAT RFC 2389 HELP LANG LIST LPRT LPSV MDTM MIC MKD MLSD MLST MODE NLST NOOP OPTS PASS PASV PBSZ PORT PWD QUIT REIN REST RETR RMD RNFR RNTO SITE SIZE SMNT STAT STOR STOU STRU SYST TYPE USER RFC 2640 RFC 1639 RFC 1639 RFC 3659 RFC 2228 RFC 3659 RFC 3659
RFC 2389
RFC 2228
RFC 3659
Lers Abort an active file transfer. Account information. Authentication/Security Data Allocate sufficient disk space to receive a file. Append. Authentication/Security Mechanism Clear Command Channel Change to Parent Directory. Confidentiality Protection Command Change working directory. Delete file. Privacy Protected Channel Specifies an extended address and port to which the server should connect. Enter extended passive mode. Get the feature list implemented by the server. Returns usage documentation on a command if specified, else a general help document is returned. Language Negotiation Returns information of a file or directory if specified, else information of the current working directory is returned. Specifies a long address and port to which the server should connect. Enter long passive mode. Return the last-modified time of a specified file. Integrity Protected Command Make directory. Lists the contents of a directory if a directory is named. Provides data about exactly the object named on its command line, and no others. Sets the transfer mode (Stream, Block, or Compressed). Returns a list of file names in a specified directory. No operation (dummy packet; used mostly on keepalives). Select options for a feature. Authentication password. Enter passive mode. Protection Buffer Size Specifies an address and port to which the server should connect. Print working directory. Returns the current directory of the host. Disconnect. Re initializes the connection. Restart transfer from the specified point. Retrieve (download) a remote file. Remove a directory. Rename from. Rename to. Sends site specific commands to remote server. Return the size of a file. Mount file structure. Returns the current status. Store (upload) a file. Store file uniquely. Set file transfer structure. Return system type. Sets the transfer mode (ASCII/Binary). Authentication username.
Forrs: http://en.wikipedia.org/wiki/List_of_FTP_commands
~ 29 ~
A TCP/IP PROTOKOLL MKDSE A szp az egszben az, hogy a hskorban gy ment az eftpzs, hogy az ember fogta s begpelte ezeket a parancsokat a command prompt-ba. Grafikus kliens? Ugyanmr.
2.17. BRA FTP PARANCSSORBL
A fenti munkamenetben az trtnt, hogy belptem egy FTP szerverre, lekrtem a knyvtr tartalomjegyzkt, lejjebb lptem egy knyvtrral, majd letltttem az index.html fjt. Feltlteni a PUT paranccsal tudtam volna. (Az brn lv parancsokat ne is keresd az elz tblzatban, ezek a parancsok a Windows beptett fapados telnet kliensnek a parancsai. Valjban a GE T parancs mgtt egy FTP parancsktegnek kell lennie, mely egszen biztosan tartalmazza tbbek kztt - a MODE s a RETR parancsokat.)
~ 30 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI Csak az rdekessg kedvrt nzzk meg, hogyan csinlja ugyanezt egy profi.
2.18. BRA FTP GRAFIKUS KLIENSBL
Mg csak addig jutottunk, hogy belptnk a szerverre s lekrtk a tartalomjegyzket - de nzzk meg, mennyi parancsot adtunk ki mr eddig is. Hiba, vlasztkosan fogalmazni tudni kell.
~ 31 ~
A TCP/IP PROTOKOLL MKDSE 2.2.2 FTP
KDOK
De nem csak parancsokat lthatunk a fenti brkon. Vannak kdok is. Olyan kdok, melyeket a szerver ad vissza.
2.7. TBLZAT Kd Magyarzat 100 Series: The requested action is being initiated, expect another reply before proceeding with a new command. 110 Restart marker replay . In this case, the text is exact and not left to the particular implementation; it must read: MARK yyyy = mmmm where yyyy is User-process data stream marker, and mmmm server's equivalent marker (note the spaces between markers and "="). 120 Service ready in nnn minutes. 125 Data connection already open; transfer starting. 150 File status okay; about to open data connection. 200 Command okay. 202 Command not implemented, superfluous at this site. 211 System status, or system help reply. 212 Directory status. 213 File status. 214 Help message.On how to use the server or the meaning of a particular non-standard command. This reply is useful only to the human user. 215 NAME system type. Where NAME is an official system name from the list in the Assigned Numbers document. 220 Service ready for new user. 221 Service closing control connection. 225 Data connection open; no transfer in progress. 226 Closing data connection. Requested file action successful (for example, file transfer or file abort). 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). 228 Entering Long Passive Mode (long address, port). 229 Entering Extended Passive Mode (|||port|). 230 User logged in, proceed. Logged out if appropriate. 231 User logged out; service terminated. 232 Logout command noted, will complete when transfer done. 250 Requested file action okay, completed. 257 "PATHNAME" created. 331 User name okay, need password. 332 Need account for login. 350 Requested file action pending further information 421 Service not available, closing control connection. This may be a reply to any command if the service knows it must shut down. 425 Can't open data connection. 426 Connection closed; transfer aborted. 434 Requested host unavailable. 450 Requested file action not taken. 451 Requested action aborted. Local error in processing. 452 Requested action not taken. Insufficient storage space in system.File unavailable (e.g., file busy). 500 Syntax error, command unrecognized. This may include errors such as command line too long. 501 Syntax error in parameters or arguments. 502 Command not implemented. 503 Bad sequence of commands. 504 Command not implemented for that parameter. 530 Not logged in. 532 Need account for storing files. 550 Requested action not taken. File unavailable (e.g., file not found, no access). 551 Requested action aborted. Page type unknown. 552 Requested file action aborted. Exceeded storage allocation (for current directory or dataset). 553 Requested action not taken. File name not allowed.
~ 32 ~

Forrs: http://en.wikipedia.org/wiki/List_of_FTP_server_return_codes
Lthat, hogy a tagozds teljesen ugyanaz, mint a HTTP esetben (2.3. tblzat). 2.2.3 A Z FTP
P R O T O K O L L L E LK I V I L G A
Kezdjk megint trtnelmi ttekintssel. Kinek mond mg valamit az, hogy anonymous FTP? Pedig volt. St, ebbl volt tbb. Pldul a gyrtk a drivereket legtbbszr FTP szervereken troltk, ahhoz meg nem kellett autentikci. Pontosabban, kellett. De j volt a kamu is. Anonymous FTP belpsnl a felhasznl az 'anonymous' user volt, a jelszava pedig egy emailcm. Melyet persze a kutya sem ellenrztt. Nos, ezek voltak a boldog bkeidk. Ma az ilyesmi ritka, mint a fehr holl: hasonl clokra mr HTTP alap letltsek szolglnak, vagy a Trivial FTP (TFTP). Sokkal izgalmasabb tma az FTP munkamenetek kavarodsa. Mint mr cloztam r, egy viszonylag egyszer feladat - pldul egy fjl letltse - az FTP-ben nem intzhet el egy munkameneten bell, mint pldul a HTTP-nl. Az FTP ugyanis kln csatornkat hasznl egyfell a vezrlinformcik (Control vagy Command) forgalmazsra, msfell az adatforgalomra (Data). Mindkt csatornt a jl ismert mdon (SYN, SYN/ACK, ACK) ptik ki a felek. Pusztn csak azrt, hogy ne legyen egyszer az leted, mindemellett a csatornk kiptse hrom klnbz forgatknyv szerint is trtnhet: Aktv md Passzv md Kiterjesztett passzv md RFC 2428 A legkevesebbet a harmadik vltozattal fogunk foglalkozni, ez gyakorlatilag a passzv md kiterjesztse IPv6, illetve NAT krnyezetekre. Az meg mr ksz provokci, hogy a Data csatornn trtn adatramls is ktfle lehet: ASCII md : plain text ramlik t a csatornn. Binris md : binris kd ramlik t a csatornn.
~ 33 ~

2. 2 .3 . 1 A K T V M D
Csak hogy tudjuk, mire kszlnk: ez a fejezet azzal fog foglalkozni, hogyan plnek ki a Command s a Data csatornk abban az esetben, ha a kliens az n. aktv FTP mdot hasznlja. gy.
2.19. BRA A KTV FTP KLIENS
Els lpsben a kliens - miutn kiptettek egy TCP sessiont - a Command csatornn keresztl kld az FTP szervernek egy PORT parancsot. Ebben benne van az IP cme s egy port szm. Ezen a porton vrja a szerver prblkozst a Data csatorna kiptsre.
~ 34 ~
2.20. BRA PORT R EQUEST
2.21. BRA D ATA FORGALOM
Az els brn a kliens (192.168.1.99) rtesti a szervert (186-os csomag), hogy az 50975-s porton vrja a behatolst. A 187-es csomagban a szerver jelzi, hogy vette az adst. A kvetkez brn pedig lthatjuk, hogy a szerver nem viccel, a 20 -as portjrl tolja a biteket a kliens 50975-s portjra. Vegyk szre, hogy a 189-191 csomagokban pl ki az j - Data - csatorna. (Az brkon munkamenetekre szrt forgalmak lthatk - ezrt nincsenek benne pldul a 189-191-es csomagok az els brban.)
Le a kalappal az EventHelix fik eltt. Az albbi cmrl le lehet tlteni egy pdf doksit, mely minden tlzs nlkl gynyren s plasztikusan mutatja be, mi is trtnik egy ltszlag egyszer fjlletlts sorn. (Aktv FTP kliens) http://www.eventhelix.com/RealtimeMantra/Networking/FTP.pdf De rdemes tnzni a tbbi anyagukat is: http://www.eventhelix.com/RealtimeMantra/Networking/
Mi a mdszer htrnya? Nzzk csak meg: a Data csatorna kiptse gy trtnik, hogy a szerver kezdemnyez kapcsolatot a kliens egyik portjra. Mit mondanak erre a a betrsi kisrletre a mai tzfalak? Azt, hogy coki.
~ 35 ~

2. 2 .3 . 2 P A S S Z V M D
Valahogy ki kellene iktatni azt a hiperaktv FTP szervert. Vrja csak meg, hogy a kliens kezdemnyezze a Data csatorna felptst is.
2.22. BRA P ASSZV FTP KLIENS
A kliens - mg a Command csatornn - kld egy PASV parancsot. Ezzel passzv mdba kapcsolja az FTP szervert. Vlaszknt a szerver kld egy portszmot - ahol immr vrja majd a kliens kezdemnyezst a Data csatorna kiptsre. A kliens j sessiont nyit - immr egy msik portjrl - a szerver elzleg megadott portjra.
~ 36 ~
2.23. BRA A SZERVER VLASZA A PASV PARANCSRA
2.24. BRA A DATFORGALOM
Mindez lthat a valsgban is. A 22-es csomagban kldi el a kliens a PASV parancsot, a 23-asban vlaszol a szerver, megadva a 22353-as portot. A 25-27 csomagokban pl fel az j TCP session s a 29-es csomagtl indul el az adatfolyam a Data csatornn.
~ 37 ~
2. 2 .3 . 3 FTP S NA T
Nem motoszkl valami kellemetlen rzs ott htul, a kisagyban? Mindkt mdszer esetn nagyon fontos IP cmek s portszmok utaznak FTP csomagokban a TCP szegmenseken bell. Aktv esetben a PORT parancsban mondta meg a kliens, hol vrja a szervert. Passzv esetben a PASV response parancsban a szerver mondta meg ugyanezt a kliensnek. Mi van akkor, ha a kett kz bepl egy NAT router?
2.25. BRA FTP S NAT
~ 38 ~
Ugye tudjuk, a NAT (ok, PAT) IP, illetve Transport rteg szinten mkdik. Az IP datagramban a forrs IP cmeket, a TCP szegmensben a forrs portszmot rja t.
2.26. BRA IP CMEK S PORTOK
A fenti bra azt mutatja, amikor a bels kliens kapcsoldik a bels FTP szerverhez. Ekkor nincs gond, mert nincs NAT. De mi van, ha a kls kliens akarja elrni az FTP szervert? A router ki fogja cserlni a 172.30.125.6 IP cmet a 192.168.1.1 cmre, a kliens portszmt meg egy msikra. Csakhogy az FTP csomagban ott marad a rgi IP s az a port, ahol majd a kliens rnyomulna a szerverre. Nem fog mkdni. Innentl a NAT routerek trsadalma kt rtegre tagozdik: Azokra, akik ismerik a TCP protokollt s cserlgetik az FTP csomagon bell is a cmeket, portokat. Ez mr gyakorlatilag FTP applikcis proxy. s azokra, akiken nem megy t az FTP.
~ 39 ~
2.3 SMTP - A
NPSZER REG
Huh. Vgre egy kicsit itthon. Eddig minden protokoll ismertetst azzal kezdtem, hogy bertam az aktulis RFC szmt. m, legyen. Teljessg nlkl a fontosabb szabvnyok:
2.8. TBLZAT RFC RFC 0821 RFC 0822 RFC 1123 RFC 1652 RFC 1869 RFC 1870 RFC 1985 RFC 2034 RFC 2045 RFC 2046 RFC 2047 RFC 2048 RFC 2049 RFC 2142 RFC 2183 RFC 2298 RFC 2476 RFC 2505 RFC 2554 RFC 2821 RFC 2822 RFC 2920 RFC 3030 RFC 3207 RFC 3461 RFC 3463 RFC 5321 RFC 5322
Megnevezs Simple Mail Transfer Protocol (STD0010) Internet Message Format (STD0011) Requirements for Internet Hosts (STD0003) SMTP Extension for 8bit-MIME SMTP Service Extensions (ESMTP) SMTP Extension for Msg. Size Declaration SMTP Extension for Remote Message Queue Starting SMTP Extension for Enhanced Error Codes Multipurpose Internet Mail Extensions (MIME) #1 Multipurpose Internet Mail Extensions (MIME) #2 Multipurpose Internet Mail Extensions (MIME) #3 Multipurpose Internet Mail Extensions (MIME) #4 Multipurpose Internet Mail Extensions (MIME) #5 Mailbox Names for Common Services and Roles Content-Disposition Header Field Message Disposition Notifications Message Submission Anti-Spam Recommendations for SMTP MTAs SMTP Service Extension for Authentication Simple Mail Transfer Protocol Internet Message Format SMTP Extension for Command Pipelining (STD0060) SMTP Extensions for Large and Binary MIME SMTP Extension for Secure SMTP over TLS SMTP Extension for Delivery Status Notifications Enhanced Mail System Status Codes Simple Mail Transfer Protocol Internet Message Format
Dtum 1982 1982 1989 1994 1995 1995 1996 1996 1996 1996 1996 1996 1996 1997 1997 1998 1998 1999 1999 2001 2001 2000 2000 2002 2003 2003 2008 2008
Nos, rgtn lthat, hogy a levelezs mr nem lesz olyan egyszer tma. Ha alaposan megnzzk a listt, lthat, hogy vannak benne ismtldsek. Az RFC 5321 pldul kinyrta a 2821-et, illetve a 0821-et. Az RFC 5322 pedig a 2822-est s a 0822-est. Erre azrt alaposan oda kell figyelni, tekintve, hogy ez a kt RFC alkotja az internetes levelezs gerinct. Amikor SMTP-rl beszlnk, hallgatlagosan kt szabvnyrl beszlnk. Mr eredetileg is gy szlettek: a 821-es mellett ott figyelt a 822-es is. Az els foglalkozott azzal, hogyan vndorolnak a levelek. Posts hasonlattal lve, ez az RFC rta le azt, hogyan kell cmezni egy bortkot s hogyan kell azt tovbbtani a cmzetthez.
~ 40 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI A 822-es RFC viszont magnak a levlnek a tartalmval foglalkozott. Hogyan kell kinznie egy levlnek: megszlts, bevezets, trgyals, befejezs, alrs. A kt szabvny nagyjbl prhuzamosan mozgott: a nagy renovlsok alkalmval mindkett egyarnt vltozott. (A kztes idben pedig hol az egyikhez jttek ki mdost szabvnyok, hol a msikhoz.) Mi is gy fogjuk ttekinteni a protokollt. 2.3.1 L EV E L EK
T O V B B T SA , A Z A Z A K O N K R T
SMTP
RFC 5321 Hogy kpben legynk, kezdjk egy brval.
2.27. BRA LTALNOS LEVELEZSI TRTNET
Ez egy teljesen ltalnosnak mondhat sma. Van egy cg, akik Exchange 2007 levelezsi infrastruktrt hasznlnak. Van egy Mailbox szerverk, egy HUB Transport szerverk s egy Client Access szerverk (ez a hrom lehet ugyanaz is), smarthostknt egy Edge Transport szervert hasznlnak. Zmben Outlook klienseik vannak, de nhny ers, nll egynisg inkbb Mozilla Thunderbird kliensrl nyomul. Az Outlook kliensek MAPI-n keresztl kapcsoldnak a Mailbox szerverhez, mely szintn MAPI-n keresztl a HUB Transport szerverhez.
~ 41 ~
A TCP/IP PROTOKOLL MKDSE A Thunderbird felhasznlk lete egy kicsit izgalmasabb, k kldskor a HUB Transport szerverhez kapcsoldnak SMTP-Submission protokollon keresztl, letltskor viszont a Client Access szerverhez vagy POP3, vagy IMAP4 protokollon keresztl. A lnyeg, hogy elbb-utbb minden kldend levl a HUB Transport szerveren kt ki. Ez a szerver SMTP-MTA (a tovbbiakban SMTP) protokollon keresztl tovbbtja a levelet a DMZ-ben lv smarthostnak. Az Edge Transport szervernek, mieltt tovbbklden a levelet, meg kell tallnia, hov is kldje. A levl cmzettjnek suffixbl kiolvassa a tartomnynevet s egy DNS szervertl lekrdezi a tartomnyhoz tartoz MX (Mail eXchanger) rekordot. Ez mutat a tartomny levelezszervernek cmre. Megvan a cm, az Edge Transport szerver SMTP protokollon keresztl ttolja a tls SMTP szervernek a levelet, ahonnan a tloldali felhasznlk valamilyen mdszerrel leszedik azt. Ugye, nem bonyolult? Mindjrt az lesz.
2.28. BRA A Z ELEKTRONIKUS LEVEL EZS SZEREPLI
~ 42 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI Br az els brn nem ltszik, de valjban ennyi komponens teszi szorgalmasan a dolgt, mikzben elkldesz egy levelet a melletted l kollgdnak, hogy jn-e ebdelni. Ahelyett, hogy sznn magyarznm a fogalmakat, prbljuk sszepontozni a kt brt. Ltjuk, hogy a MUA az gyakorlatilag a kliensprogram. Mely konkrtan a felhasznl (fj) asztaln lv szmtgpben ketyeg. Amikor a felhasznl levelet akar kldeni, akkor els krben ez a levl feliratkozik kldsre. Ezt vgzi az MSA, a Message Submission Agent. Ha Outlookbl kldk, akkor gyakorlatilag a Mailbox szervert rugdosom meg, hogy tegye bele a levelet a HUB Transport szerver Submission vrakozsi sorba. Ha Thunderbird-bl, akkor kzvetlenl a HUB Transport szerverhez fordulunk, mghozz a submission SMTP protokollon keresztl. (Ugye mindenki emlkszik arra a trks client receive konnektorra?) Innentl Message Transfer Agent-ek (MTA) hossz sora kvetkezik. Ezek hoprl hopra3 passzolgatjk SMTP protokollon keresztl a leveleket, amg azok el nem jutnak a cmzett MTA szerverhez. (MX rekord.) ltalban az MTA-nak van ppen elg dolga a levelekkel (routols, higinia), ezrt kln szoktk vlasztani azt a funkcit, mely mr konkrtan a levelek felhasznlkhoz szlltst intzi. Ezt gy hvjk, hogy Mail Delivery Agent (MDA) s a kifejezs az Exchange 2007 szerver esetben a Mailbox szervert takarja. A felhasznlknak innentl nincs is ms dolguk, mint elvinni a levelket. Ha Exchange 2007 szervernk van s Outlook kliensnk, akkor egyszerbb a helyzet, mert a Message Access Agent (MAA) az ugyanaz a szerepl, mint az MDA. (Megjegyzem, ez az llts Exchange 2010 szerverre mr nem igaz. Ott az MAA funkci minden kliens esetn - teht a MAPI/RPC-t hasznl Outlook esetben is tkerlt a Client Access szerverre.) Ha nem Exchange szervernk van, vagy nem MAPI kliensbl leveleznk, akkor az MAA egy POP3/IMAP4 szerver, mely Exchange 2007 esetben a Client Access szerver. Nos, gyakorlatilag megrkeztnk. A tloldali MUA vagy MAPI-n, vagy POP3/IMAP4 protokollokon keresztl egyszeren letlti a levelt.
Akit mlyebben rdekel az Exchange 2007 lelkivilga, minden rszrehajls nlkl tudom neki ajnlani az albbi knyvet: Petrnyi Jzsef: Exchange 2007 spontn http://www.microsoft.com/hun/technet/article/?id=e1d46c3f-dbb8-4fdb-865a-73c3b9cce433
Eltekintve persze az Exchange 2007 Direct Relay elvtl.
~ 43 ~
A TCP/IP PROTOKOLL MKDSE Habr az elz szvegben elhangzott egy csom protokollnak a neve (POP3, IMAP4, MAPI, RPC), ezeket itt nem fogom kibontani. Tudjunk rla, hogy lteznek. Laztskppen elmeslem, mirt pont ezt a cmet adtam az alfejezetnek. Ahogy egy rkkvalsggal ezeltt is rtam, a hetvenes vek vge fel rdekes konkurenciaharc volt a hlzati architektrk tern. Egyszerre kezdtk szabvnyba nteni az n. 7 rteges ISO-OSI modellt s nagyjbl ugyanabban az idben formldott a 4 rteges TCP/IP is. Nagy kzdelem volt. Hogy manapsg a 7 rteges modellel mr csak a fanatikusok tallkoznak, a TCP/IP-vel pedig mg a keresztanym is (csak ppen nem ismeri fel) - az nem kis mrtkben a rendkvl npszer SMTP-nek ksznhet. - Hoh - mondhatja erre a figyelmes olvas - Az SMTP els RFC-je 1982-ben kszlt. Hogyan vitzkedhetett volna ez a hetvenes vekben? gy, hogy az SMTP-nek voltak elzmnyei. Mr a hatvanas vekben is lteztek kezdetleges zenetkld alkalmazsok, melyek 1973 s 1980 kztt, amikor az ARPANET kezdte kiforrni magt s kezdett belle kialakulni az internet, mr vadul tettk a dolgukat. Jon Postel 1980-ban foglalta ezeket ssze Mail Transfer Protocol nven - melybl vgl 1982-ben alakult ki a Simple Mail Transfer Protocol, azaz az SMTP. Ez a kezdeti npszersg ksbb csak fokozdott. Manapsg az SMTP s a HTTP fej fej mellett llnak a legnpszerbb netes protokollok kztt. s van egy olyan szempont, ahol az SMTP bven le is krzi a HTTP-t: ez a nlklzhetetlensg. Meglehetsen sok gyfelnk van, de az email mindenhol kiemelten kritikus rendszernek minsl. Ha nincs web, akkor legfeljebb nem bngsznek annyit az alkalmazottak. Ha nem mkdik a levelezs, akkor viszont megll az let. Ez a nagy npszersg persze nem csak elny. Gzsba is kti az SMTP -t. Harminc vvel ezeltt kicsit ms volt a vilg, mint ma. A protokoll vltozott ugyan, de ma mr annyi, de annyi SMTP szerver van a vilgon, hogy a rendszer tehetetlensge miatt gykeres talaktsokra kevs az esly. Pedig igny lenne r: a levelezs 75-80%-t manapsg a levlszemt teszi ki. Spam, malware, phishing. Ezek mind azrt ilyen virulensek, mert az SMTP eredeti hinyossgait hasznljk ki. (Egyet meg is fogunk nzni.) Kipihentk magunkat, folytathatjuk.
~ 44 ~
2. 3 .1 . 1 S M TP , ES M TP P A R A N C S O K
Amikor indult az SMTP, a kvetkez parancsokat tartalmazta: HELO, MAIL FROM, RCPT TO, DATA, RSET, SEND FROM, SOML FROM, SAML FROM, VRFY, EXPN, HELP, NOOP, QUIT, TURN Aztn jtt nhny rncfelvarrs (egy szekrderk RFC) s most nagyjbl gy llunk:
2.9. TBLZAT Parancs 8BITMIME ATRN AUTH BDAT BINARYMIME BURL CHECKPOINT CHUNKING DATA DELIVERBY DSN EHLO ENHANCEDSTATUSCODES ETRN EXPN FUTURERELEASE HELO HELP MAIL FROM MTRK NO-SOLICITING NOOP ONEX PIPELINING QUIT RCPT TO RSET SAML SEND SIZE SOML STARTTLS SUBMITTER TURN UTF8SMTP VERB VRFY
Lers A levl kiterjesztett karakterkszletet tartalmaz Ugyanaz, mint a TURN, csak autentikci nlkl nem megy Autentikci Binris adat Binris MIME adat A levl tartalma egy IMAP szerverrl jn Nagy levelek megbzhatatlan vonalon - a checkpoint jeltzi, hogy eddig minden rendben van DATA helyett BDAT A levl tartalma kvetkezik Megadott idn belli tovbbts Delivery Status Notification, azaz rtests a levltovbbts alakulsrl Extended HELO. A szerver a kibvtett stuszkd kszletet ismeri Kibvtett TURN: az a trkkje, hogy szerverek kztt is mkdik. Kibontja a cmlistkat Jvben elkldend levl sszelltsa dv Help Felad a bortkon Message Tracking. Nem krnk spamszrst Semmi Csak egy zenet megy Egy munkameneten bell tbb parancs Viszlt s ksz a halakat A bortk cmzettje Kezdjk jra Send And MaiL (Terminlrl) Send (Terminlrl) Levlmret megadsa Send Or MaiL (Terminlrl) Trjnk t TLS-re. A kleins megadhat egy olyan emailcmet, mely a levelek feladsrt felels (Responsible Submitter) A kliens s a szerver szerepet cserlnek - azaz a kliens magra hzza a leveleit. Nemzetkzi emailcmek Bbeszden. Hibakeressre. Ltezik-e a postafik?
Visszavonva
Igen Igen Igen
Igen
Egyltaln nem ktelez, hogy egy levelezszerver az sszes parancsot ismerje. Ltezik egy minimum kszlet, azt igen - de azon fell mr egyrszt magn az SMTP szerveren, msrszt a rendszergazdn mlik, mit enged. Pldul a VRFY parancsot a
~ 45 ~
A TCP/IP PROTOKOLL MKDSE '*' paramterrel hatrozottan tiltja mindenki (ne tudjanak a spammerek cmeket begyjteni), de van olyan termk (pl. az Exchange is), mely alaprtelmezsben magt a parancsot sem engedlyezi. Jogos lehet a krds, hogyan tudjk eldnteni a szerverek, hogy ki melyik parancsot ismeri? Nos, ha az egyik szerver a HELO paranccsal kszn be a msiknak, akkor sehogy. Ellenben ha az EHLO parancsot hasznlja, akkor vlaszknt megkapja az ismert parancsok listjt.
2. 3 .1 . 2 SM TP K D O K
A szerverek ltal visszaadott kdokkal ugyanaz a csfsg trtnt, mint a parancsokkal: valamikor ltezett egy szkebb kr, melyet ksbb RFC-k hossz sorn keresztl bvtgettek. Lnyeges klnbsg, hogy itt a kommunikci sorn nem llnak neki tisztzni a szerverek, hogy az eredeti kld oldal rti-e a vlaszkdot. Megkapja, oszt azt csinl vele, amit akar.
2.10. TBLZAT Kd Lers 211 System status, or system help reply. 214 Help message. 220 Domain service ready. Ready to start TLS. 221 Domain service closing transmission channel. 250 OK, queuing for node node started. Requested mail action okay, completed. 251 OK, no messages waiting for node node. User not local, will forward to forwardpath. 252 OK, pending messages for node node started. Cannot VRFY user (e.g., info is not local), but will take message for this user and attempt delivery. 253 OK, messages pending messages for node node started. 354 Start mail input; end with <CRLF>.<CRLF>. 355 Octet-offset is the transaction offset. 421 Domain service not available, closing transmission channel. 432 A password transition is needed. 450 Requested mail action not taken: mailbox unavailable. ATRN request refused. 451 Requested action aborted: local error in processing. Unable to process ATRN request now 452 Requested action not taken: insufficient system storage. 453 You have no mail. 454 TLS not available due to temporary reason. Encryption required for requested authentication mechanism. 458 Unable to queue messages for node node. 459 Node node not allowed: reason. 500 Command not recognized: command. Syntax error. 501 Syntax error, no parameters allowed. 502 Command not implemented. 503 Bad sequence of commands. 504 Command parameter not implemented. 521 Machine does not accept mail. 530 Must issue a STARTTLS command first.
~ 46 ~

Encryption required for requested authentication mechanism. Authentication mechanism is too weak. Encryption required for requested authentication mechanism. Requested action not taken: mailbox unavailable. User not local; please try forwardpath. Requested mail action aborted: exceeded storage allocation. Requested action not taken: mailbox name not allowed. Transaction failed.
534 538 550 551 552 553 554
Szndkosan hagytam meg az angol szveget: a szerver is gy fog vlaszolni. Vegyk szre, hogy a visszajelzsek csoportostsa ugyanazt a szmozsi logikt kveti, mint a HTTP, illetve FTP esetben. (Eltekintve a 3xx kategritl. A rekurzirl ugyanis az SMTP kapcsn tl sok rtelme nincs beszlni, azaz a kdmez felhasznlhat msra.)
~ 47 ~
A TCP/IP PROTOKOLL MKDSE 2.3.2 A Z

E L EK T R O N I K U S L EV E L EK S Z ER K E Z ET E , A ZA Z
IMF
RFC 5322 IMF: Internet Message Format. Azaz hogyan kell kinznie egy virtigli levlnek. (Figyelem, immr a bortkon bell vagyunk.) Egy levlen bell alapveten kt nagy rszt klntnk el: Header: a levlre vonatkoz kisrinformcik. Body: Maga a levl tartalma: szveg, csatols. Az SMTP viszonya a szabvnyokhoz meglehetsen laza. Egyltaln nem ktelez kitlteni minden fejlc mezt, egyltaln nem ktelez brmit is rni a body rszbe , st egyltaln nem ktelez rtelmes dolgokat rni magba a levlbe, mint ahogy a cges levelezsekben ez nem is ritkn elfordul. (A bortkra rt informcik alapjn a levl mindenkppen eljut a cmzett levelezszerverre - maximum a szerver szri ki, mint spam.)
220 mail02a.mail.t-online.hu ESMTP You must authenticate before sending mail ehlo hq 250-mail02a.mail.t-online.hu 250-PIPELINING 250-SIZE 26214400 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN auth login 334 VXNlcm5hbWU6 cGV0cmVueWlq 334 UGFzc3dvcmQ6 Ez_itt_a_jelszavam_helye 235 2.7.0 Authentication successful mail from:jpetrenyi@t-online.hu 250 2.1.0 Ok rcpt to:jpetrenyi@gmail.com 250 2.1.5 Ok data 354 End data with <CR><LF>.<CR><LF> from:Petrenyi Jozsef to:Petrenyi Jozsef GMAIL subject: HELLO WORLD! Ez egy tesztlevel . 250 2.0.0 Ok: queued as BE6E625BC0A quit 221 2.0.0 Bye
~ 48 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI Ez a szvegrszlet egy capture fjlbl val. Bekapcsoltam a sniffer programot, sszelltottam egy levelet parancssorbl majd elkldtem.
2.29. BRA T ESZTLEVL PARANCSSORBL
A capture fjlban rszrtem a konkrt kommunikcira, majd sszerakattam a programmal a teljes adatramot. gy kaptam az elz oldalon lthat listt. Itt pedig az elkapott csomagok lthatk.
2.30. BRA P ARANCSSORBL KLDT T LEVL DARABJA A CAPTURE FJLBAN
(Megjegyzem, az a sok szemtnek tn TCP csomag a lass gpelsem miatt van. Istenem, nem vagyok egy Outlook.)
~ 49 ~
A TCP/IP PROTOKOLL MKDSE Ez az els lveboncolt levl a knyvben, el lehet rajta csemegzni. (Ksbb ltunk majd mg eleget.) Megkereshetjk a parancsokat, kibogarszhatjuk a vlaszokat. J jtk. Pldul szreveheted, hogy a levlben lthat 334-es kd vlasz - igen, az az rtelmezhetetlen zsizsa - nem szerepel a vlaszkdok kztt. Nem is, ugyanis ez sokkal inkbb egy challenge, mint kd. De errl majd ksbb. A lnyeg a szvegben az, hogy mivel n a kt sajt kezemmel gpeltem be a parancsokat, igyekeztem minimalizlni azokat. Az volt a clom, hogy mr rtelmezhet levl legyen, mg elfogadhat mennyisg parancs eredmnyekppen. Hasonltsuk ssze a prblkozsomat az Outlook prblkozsval. A levl feladja, a cmzettje s a levl szvege azonos. St, az elkapsi mdszer is.
220 mail01a.mail.t-online.hu ESMTP You must authenticate before sending mail EHLO hq 250-mail01a.mail.t-online.hu 250-PIPELINING 250-SIZE 26214400 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN AUTH LOGIN 334 VXNlcm5hbWU6 cGV0cmVueWlq 334 UGFzc3dvcmQ6 Mg mindig a jelszavam helye 235 2.7.0 Authentication successful MAIL FROM: <jpetrenyi@t-online.hu> 250 2.1.0 Ok RCPT TO: <jpetrenyi@gmail.com> 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> From: "Petrenyi Jozsef" <jpetrenyi@t-online.hu> To: <jpetrenyi@gmail.com> Subject: Hello World! Date: Sun, 10 Jan 2010 11:31:24 +0100 Message-ID: <000001ca91e0$0f568270$2e038750$@hu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CA91E8.711B1180" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqR4A7u+m0GG6/8SpKyPhj1+sMNtQ== Content-Language: hu This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CA91E8.711B1180 Content-Type: text/plain;
~ 50 ~

charset="us-ascii" Content-Transfer-Encoding: 7bit Ez egy tesztlevel.
------=_NextPart_000_0001_01CA91E8.711B1180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-/* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:black; font-weight:normal; font-style:normal;} ..MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:612.0pt 792.0pt; margin:70.85pt 70.85pt 70.85pt 70.85pt;} div.Section1 {page:Section1;} --> </style>  </head> <body lang=3DHU link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><span style=3D'color:black'>Ez egy = tesztlevel.<o:p></o:p></span></p> </div> </body> </html> ------=_NextPart_000_0001_01CA91E8.711B1180-. 250 2.0.0 Ok: queued as 5CFB3797A02 QUIT 221 2.0.0 Bye
Na, itt aztn van minden, mint a bcsban. A parancsok mg hagyjn, azok ugyanazok. De a levl fejlce... na meg az a vadt teste! Az bizony jcskn ms. Kezdjk ott, hogy az Outlook nlam gy van belltva, hogy a default formtum a HTML. A legtbb cifra dolgot rgtn ez magyarzza. Jval tbb kisr informci kellett hozz. Mivel a HTML esetben nagyon fontos a formzs is, gy a stlus kln XML bettknt utazik a levllel. St, lthat, hogy a tartalom benne van a levlben plain text formban - s benne van HTML lapknt is. Tiszta rm. De tnyleg. Remek plda arra, hogy milyen bonyolult is tud lenni egy csatolsokat, nem angol belltsokat hasznl levl, illetve hogy mennyi rdekes fejlc is ltezik a vilgban. RFC 1426, 1521, 1847, 3156, 2045, 2046, 2047, 2048, 2049, 2183, 2231, 2387, 4288, 4289 Illetve remek alkalom, hogy ejtsnk pr szt arrl a roppant kellemetlen rzseket okoz valamirl, ami a MIME. Mr a neve is olyan... iz. Multipurpose Internet Mail Extensions. Ilyen idetekergetem, odatekergetem, brmit is jelenthet. Ha meg meg akarom nzni a szabvnytrban, rgtn egy gigr szabvnykupacon kell keresztlrgnom magamat. Megri? tbogarszni nem biztos. De hasznlni, tudni, hogy nagyjbl mirl is van sz, azt mindenkppen.
~ 52 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI Mieltt a MIME megjelent volna, az let egyszer volt. Levlrsra hasznlhattuk az ASCII tbla als felt (7 bites kdkszlet), mghozz a 127 karakterbl rgtn le is kellett vonni a 32 vezrlkaraktert, A maradkot nevezzk printable karaktereknek. De itt mg le kell vonnunk a '.' - azaz 'pont' - karaktert is. Ez ugyanis a levl lezr karaktere. (Nzd meg a pldkat: a DATA paranccsal lpnk be a levlsszeraksi rszbe s a '.' karakterrel zrjuk azt be.) Nagyon hamar felismerheted, kik azok az reg rutinok, akik ebben a korban szocializldtak: k azok, akik a mai napig nem hasznlnak kezeteket a levelezsben. Csatols... az nem volt. Ahogy az internet egyre inkbb megsznt csak a katonk s a tudsok jtsztere lenni, gy szaporodtak az ignyek is az egyes protokollokkal szemben. Mirt ne lehetne ms, nemzeti kdkszletet hasznlni a levlben? Elismerem, ez is nagy knyszer lehetett a protokoll megjti szmra. De a legnagyobb nyomst felteheten az tette rjuk, amikor megprbltak nekik egy pucrns kpet tkldeni, de az istennek sem brta el a 7 bit4. Nos, j ha tudod, hogy az elektronikus levl formtuma a mai napig 7 bites. Ugyanazt a nhny karaktert hasznljuk, mint a hsi idkben. Minden mst, azaz a 8 bites kdols teljes kdtblkkal rdott szvegeket, a binrisnak tekintett csatolt fjlokat, mindent, kln t kell kdolni 7 bitesre. A MIME gyakorlatilag ezzel foglalkozik. A kvetkez funkcii vannak: Olyan szveges levelek kezelse, ahol a levl trzsben kiterjesztett kd karakterek (pldul kezetesek) vannak. Nem szveges csatolsok kezelse. Olyan levelek kezelse, melyek fejlc imformciiban (cmek, subject, stb) tallhatak kiterjesztett kd karakterek. Amennyiben tbb csatols van a levlben, vagy tbb, klnbz ASCII kd rsz, vagy a kett egytt, akkor tudnia kell kezelni a tbb MIME blokko t is, azaz menedzselnie kell a sajt bonyolultsgt. Lthat, a MIME egy kln birodalom az SMTP-n bell. Sajt fejlcei vannak, kpes blokkokra osztani a levl trzst, annak tartalmtl fggen. Termszetesen ehhez a levelez klienseknek is MIME kompatibilisnek kell lennik, de ez ma mr nem problma.
4
Br az reg rutinok erre azt mondjk, hogy ugyanmr, ott volt az ASCII grafika.
~ 53 ~
A TCP/IP PROTOKOLL MKDSE Vizsgljuk meg nhny pldn, hogyan is nz ez ki. Ha visszalapozol pr oldalt ahhoz a nagyon hossz levlhez, szpen lthatod, hogyan is pl fel ez az egsz. Elszr jn a levl fejlce.
DATA 354 End data with <CR><LF>.<CR><LF> From: "Petrenyi Jozsef" <jpetrenyi@t-online.hu> To: <jpetrenyi@gmail.com> Subject: Hello World! Date: Sun, 10 Jan 2010 11:31:24 +0100 Message-ID: <000001ca91e0$0f568270$2e038750$@hu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CA91E8.711B1180" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqR4A7u+m0GG6/8SpKyPhj1+sMNtQ== Content-Language: hu This is a multi-part message in MIME format.
Lthatod, hogy magba a fejlcbe is belekerltek mr MIME informcik. Ilyen a MIME verziszma, de ilyen a Content-Type vltoz is. (A vltoz tartalmazza a MIME blokkok hatrait jelz azonostt is.) Plusz a vgn ott van egy fenyegets is, miszerint a levlben tbb MIME blokk is lesz.
------=_NextPart_000_0001_01CA91E8.711B1180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ez egy tesztlevel.
Ez az els MIME blokk. A tartalom tipusa text/plain, a hasznlt karaktertbla us ascii, a kdols pedig 7bit. Ez azt jelenti, hogy a blokk minden karaktere printable azaz a MIME-nek ezzel a darabbal az gegyadta vilgon semmi dolga sincs.
------=_NextPart_000_0001_01CA91E8.711B1180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
A msodik blokkot nem msolom teljesen ide, mert borzaszt hossz. De ha tnzed, lthatod, hogy ez ugyanaz a tartalom, mint az els MIME blokkban, csak ez HTML kd. Azaz tele van formz utastssal - de a tartalom az ugyanaz a rvid mondat. Viszont rdemes elmeditlni a kdolson. Ez mr nem 7bit, ugyanis a HTML kdban vannak tiltott karakterek is. Ekkor jn be a kpbe a quoted printable kdols. Ez a kvetkezkppen mkdik. Fogja a 8 bites kdot s egy hrom karakterbl ll sorozattal vltja ki. Az els karakter mindig az egyenlsgjel, a msik kett pedig a karakter ASCII kdja, hexadecimlis formban.
~ 54 ~
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40">
Rgtn gy kezddik a MIME blokk. Ltunk benne quoted printable kdot? Persze, ott van az '=3D' sorozat. Kdoljuk vissza. 3D -> 61; az us-ascii tbla 61-es kdja pedig pont az '=', azaz az egyenlsgjel kdja.
http://en.wikipedia.org/wiki/US-ASCII#ASCII_printable_characters
Hopp. Az egyenlsgjellel jelezzk, hogy a berakott illeglis karakter az egyenlsgjel? Ez csak els rnzsre holdat nyalogat baromsg. Ugyanis ha a quoted printable kdolsnl az egyenlsgjel az egy foglalt vezrlkarakter, akkor tnyleg illeglis a hasznlata. A szmtgp nem tudja intuitven eldnteni, hogy a szvegben elfordul egyenlsgjel most ppen vezrlkarakter-e vagy sem. Nzznk egy egyrtelmbb pldt. rtam egy msik levelet.
2.31. BRA T ESZTLEVL
Nzzk meg a capture fjlt.
~ 55 ~
2.32. BRA RVZTR TKRFRG P
Milyen protokollnak is rzkeli a Wireshark a csomagot? IMF. Aranyos. Brmennyire is hlyn hangzik, de a kk cskkal jelzett szvegrszlet az a bizonyos 'rvztr tkrfrgp' karaktersorozat. Nzzk meg a MIME blokkot.
------=_NextPart_000_000D_01CA93C6.65716B60 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Itt indul a szoveg: --=E1rv=EDzt=FBr=F5 t=FCk=F6rf=FAr=F3g=E9p ---Itt =E9r v=E9get
Az iso-8859-2 kdtbla mr szigoran 8 bites. Vannak benne 128-nl magasabb sorszm ASCII karakterek is. Itt mr nem csak a tiltott egyenlsgjel jelenik meg, hanem olyan karakterek is, melyek nem tartoznak a printable csoportba.
~ 56 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI Szrprbaszeren kdoljunk vissza nhny karaktert.

2.11. TBLZAT Quoted printable kd =E1 =ED =FB =F5
Decimlis rtk 225 237 251 245
Az iso-8859-2 kdtblzat kdja
http://en.wikipedia.org/wiki/ISO/IEC_8859-2
Ok. Ezzel a mdszerrel elrtk, hogy - igaz, egy karakter helyett hrommal - de le tudjuk rni az sszes karaktertbla sszes elemt. De mi van akkor, ha csatolst rakunk a levlbe? MIME blokk:
------=_NextPart_000_0070_01CAB73D.4D8BB510 Content-Type: text/plain; name="teszt.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="teszt.txt" VGV0c3r1bGVnZXMgdHh0IGbhamwuDQoNCsFydu16dPty9SB0/Gv2cmb6cvNn6XAu ------=_NextPart_000_0070_01CAB73D.4D8BB510--
Szemmel lthatan bejttek jabb vltozk a MIME blokk fejlcbe. A leginkbb szembetn, hogy egy jabb kdolssal tallkozunk: ez a base64. Volt mr rla sz a knyvben, jl le is dorongoltuk. Ez persze nem azt jelenti, hogy nem szeretjk pusztn csak arrl van sz, hogy mindenkit a maga helyn szeretnk. A base64 kdols tkletes arra, hogy brmilyen 8 bites rtkbl 7 bites rtket lltson el de borzasztan bna, ha arrl van sz, hogy egy karaktersorozatot titkostsunk. Ezzel el is rultam, mire hasznlja a MIME a base64 kdolst: arra, hogy mindent, ami csatolt fjl, gyorsan bjt szinten lekdol 7 bitesre, majd gy mr bele tudja illeszteni - MIME blokkokon keresztl - az SMTP DATA mezbe. Magrl a kdolsrl nem szndkozom sokat rni. Nagyjbl arrl van sz, hogy 3 bjtos blokkokat ngyfel szednk (ekkor egy egysg hat bites lesz), ezeknek ugye 64 klnbz rtke lehet. Minden rtkhez egy karaktert rendelnk az n. Base64 ABC-bl. (Ez egy 64 elem karaktertblzat, szigoran semleges printable karakterekbl.) A felhgulsi arny 1,37, azaz a 8 bites kdols fjl 1,37-szer lesz nagyobb base64 kdols utn. (Plusz 814 bjt fejlc.)
~ 57 ~

http://en.wikipedia.org/wiki/Base64
Gyors ellenrzs.
2.33. BRA S ZVEGES FJL VISSZAFEJTSE
Habr a visszafejts nem sikerlt tkletesen, de ez mr a weblap hibja. Nem ismeri a magyar karaktereket. mlesztve mg nhny csatols. JPG:
------=_NextPart_000_007F_01CAB73E.6761D2C0 Content-Type: image/jpeg; name="feed.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="feed.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCAEAAQADASIA
~ 58 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI MP3

------=_NextPart_000_0091_01CAB73F.CEC85AA0 Content-Type: audio/mpeg; name="cohen-mbx.mp3" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="cohen-mbx.mp3" AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
(A fjl maga rengeteg space karakterrel kezddik. Amiatt van a sok A karakter.) XLS:
------=_NextPart_000_008B_01CAB73F.3644C660 Content-Type: application/vnd.ms-excel; name="abc.xls" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="abc.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAHAAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////////
(A vnd a vendor rvidtse.) EXE:

------=_NextPart_000_009D_01CAB740.1CA6BDC0 Content-Type: application/x-msdownload; name="myuninst.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="myuninst.exe" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA+AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAAA1L+4CcU6AUXFOgFFxToBRClKMUXROgFHyUo5Rck6AUR5Ri1FzToBRHlGK
Nem beszltnk mg a levelek fejlcben tallhat czifra karakterekrl. Nzzk meg pldul ezt:
From: =?iso-8859-2?Q?Petr=E9nyi_J=F3zsef?= <jpetrenyi@gmail.com>
Ltjuk rajta, hogy hasonlt a quoted-printable kdolsra... de azrt nem teljesen az. Itt ugyanis magba az rtkbe kell elrejtennk, hogy melyik ASCII tblt hasznltuk, s milyen kdolst. A fenti sorban pldul az iso-8859-2 tblt s a Q, azaz quotedprintable kdolst. Az egyes mezket a '?' karakter vlasztja el.
~ 59 ~
A TCP/IP PROTOKOLL MKDSE (Vannak mg megktsek, a space helyett pl. '_' karakter lp be, az rtkek hossza sem lehet vgtelen, 75 karakteres blokkokba trdelnk - de ennyire mlyen foglalkozzanak vele a kderek.) Azaz sszefoglalva: a MIME f feladata, hogy brhol, ahol a levlben 7 bitesnl bonyolultabb karaktertipus jelenik meg, azt t tudja kdolni 7 bitesre. (Hogy ne kelljen hozznylni az SMTP szerverekhez.) Ehhez kt kdolst hasznl, mr amikor egyltaln szksge van r: quoted printable base64 Emellett megteszi azt a szvessget is, hogy ha egy konkrt binris kupacot kell a levlbe belerakni, akkor a content-type vltozban be is kategorizlja azt. Ez a kategorizls meglehetsen rgztett. Imhol a f kategrik.
2.12. TBLZAT MIME tipus Application Audio Example Image Message Model Multipart Text Video
A f kategrikon bell aztn kismilli altipus ltezik.

Content types and subtypes: http://www.iana.org/assignments/media-types/
Ez az egsz MIME kategorizls vgl annyira sikeres lett, hogy tvettk a HTTP -be is. Hiszen pucrns kpet ne csak emailben lehessen mr kldeni, valahogyan a webrl val letltsnek is mkdnie kell. (Br itt a 7/8 bit problma nem jtszik.)
http://en.wikipedia.org/wiki/Internet_media_type
Huh. Azt hiszem, a body rszt ezzel ki is vgeztk. Nzzk akkor a fejlceket. Minden klnsebb rtests helyett:
~ 60 ~
2.13. TBLZAT Fejlc neve A-IM Accept Accept-Additions Accept-Charset Accept-Encoding Accept-Features Accept-Language Accept-Language Accept-Patch Accept-Ranges Age Allow Also-Control Alternate-Recipient Alternates Apply-To-Redirect-Ref Approved Archive Archived-At Archived-At Article-Names Article-Updates Authentication-Info Authentication-Results Authorization Auto-Submitted Autoforwarded Autosubmitted Bcc C-Ext C-Man C-Opt C-PEP C-PEP-Info Cache-Control Cc Comments Comments Connection Content-Alternative Content-Base Content-Base Content-Description Content-Disposition Content-Disposition Content-Duration Content-Encoding Content-features Content-ID Content-ID Content-Identifier Content-Language Content-Language Content-Length Content-Location Content-Location Content-MD5 Content-MD5 Content-Range
Protokoll http http http http http http http mail http http http http netnews mail http http netnews netnews mail netnews netnews netnews http mail http mail mail mail mail http http http http http http mail mail netnews http MIME http MIME MIME http MIME MIME http MIME http MIME mail http MIME http http MIME http MIME http
Sttusz
obsoleted
standard standard standard standard obsoleted obsoleted standard standard
standard
standard standard standard
~ 61 ~

Content-Return Content-Script-Type Content-Style-Type Content-Transfer-Encoding Content-Type Content-Type Content-Version Control Conversion Conversion-With-Loss Cookie Cookie2 DASL DAV DL-Expansion-History Date Date Date Date-Received Default-Style Deferred-Delivery Delivery-Date Delta-Base Depth Derived-From Destination Differential-ID Digest Discarded-X400-IPMS-Extensions Discarded-X400-MTS-Extensions Disclose-Recipients Disposition-Notification-Options Disposition-Notification-To Distribution DKIM-Signature Downgraded-Bcc Downgraded-Cc Downgraded-Disposition-Notification-To Downgraded-From Downgraded-Mail-From Downgraded-Rcpt-To Downgraded-Reply-To Downgraded-Resent-Bcc Downgraded-Resent-Cc Downgraded-Resent-From Downgraded-Resent-Reply-To Downgraded-Resent-Sender Downgraded-Resent-To Downgraded-Return-Path Downgraded-Sender Downgraded-To Encoding Encrypted ETag Expect Expires Expires Expires Expiry-Date Ext Followup-To From From mail http http MIME http MIME http netnews mail mail http http http http mail http mail netnews netnews http mail mail http http http http http http mail mail mail mail mail netnews mail mail mail mail mail mail mail mail mail mail mail mail mail mail mail mail mail mail mail http http http mail netnews mail http netnews http mail
standard
standard
standard standard obsoleted
standard standard experimental experimental experimental experimental experimental experimental experimental experimental experimental experimental experimental experimental experimental experimental experimental experimental
standard
standard standard
~ 62 ~

From Generate-Delivery-Report GetProfile Host IM If If-Match If-Modified-Since If-None-Match If-Range If-Unmodified-Since Importance In-Reply-To Incomplete-Copy Injection-Date Injection-Info Keep-Alive Keywords Keywords Label Language Last-Modified Latest-Delivery-Time Lines Link List-Archive List-Help List-ID List-Owner List-Post List-Subscribe List-Unsubscribe Location Lock-Token Man Max-Forwards Message-Context Message-ID Message-ID Message-Type Meter MIME-Version MIME-Version Negotiate Newsgroups NNTP-Posting-Date NNTP-Posting-Host Obsoletes Opt Ordering-Type Organization Original-Encoded-Information-Types Original-From Original-Message-ID Original-Recipient Original-Sender Originator-Return-Address Original-Subject Overwrite P3P Path PEP PICS-Label netnews mail http http http http http http http http http mail mail mail netnews netnews http mail netnews http mail http mail netnews http mail mail mail mail mail mail mail http http http http mail mail netnews mail http http MIME http netnews netnews netnews mail http http netnews mail mail mail mail netnews mail mail http http netnews http http standard
standard standard standard standard standard
deprecated
standard standard
standard obsoleted obsoleted
standard standard standard standard standard standard
standard
~ 63 ~

PICS-Label Pep-Info Position Posting-Version Pragma Prevent-NonDelivery-Report Priority ProfileObject Protocol Protocol-Info Protocol-Query Protocol-Request Proxy-Authenticate Proxy-Authentication-Info Proxy-Authorization Proxy-Features Proxy-Instruction Public Range Received Received-SPF Redirect-Ref References References Referer Relay-Version Reply-By Reply-To Reply-To Resent-Bcc Resent-Cc Resent-Date Resent-From Resent-Message-ID Resent-Reply-To Resent-Sender Resent-To Retry-After Return-Path Safe Security-Scheme See-Also Sender Sender Sensitivity Server Set-Cookie Set-Cookie2 SetProfile SLUG SoapAction Solicitation Status-URI Subject Subject Summary Supersedes Supersedes Surrogate-Capability Surrogate-Control TCN TE Timeout mail http http netnews http mail mail http http http http http http http http http http http http mail mail http mail netnews http netnews mail mail netnews mail mail mail mail mail mail mail mail http mail http http netnews mail netnews mail http http http http http http mail http mail netnews netnews mail netnews http http http http http
standard obsoleted
standard
standard standard obsoleted standard standard standard standard standard standard standard obsoleted standard standard standard
obsoleted standard standard
standard
standard standard standard standard
~ 64 ~

To Trailer Transfer-Encoding URI Upgrade User-Agent User-Agent Variant-Vary Vary VBR-Info Via WWW-Authenticate Want-Digest Warning X400-Content-Identifier X400-Content-Return X400-Content-Type X400-MTS-Identifier X400-Originator X400-Received X400-Recipients X400-Trace Xref mail http http http http http netnews http http mail http http http http mail mail mail mail mail mail mail mail netnews standard
standard
standard
standard
Forrs: http://www.iana.org/assignments/message-headers/perm-headers.html
Alrom, ez kiss mr sok volt. De ennyi van. Biztos vagyok benne, hogy a legtbbel nem fogsz tallkozni. n magam is sokat tprengtem, hogy rdemes-e ekkora tblzatokat belerakni a knyvbe, amikor hivatkozni is lehet a neten lv anyagokra. Vgl gy dntttem, jobb az, ha egy knyvben ott van minden. Ha kell, akkor nem leszel rknyszertve, hogy egy csom bngszablak legyen nyitva olvass kzben, illetve ha kinyomtatod, akkor elg csak magt a knyvet. Ha meg nem kell, akkor legfeljebb tlapozod. Lehet, most fogsz megkvezni, de a kvetkezkben azokrl a header mezkrl fogok beszlni, amelyek _nincsenek_ benne a fenti tblzatban. Nem gondoltad volna, mi? Akkora ez a tblzat, hogy ebben elmletileg a teljes vilgegyetemnek bele kellett volna frnie. De van egy olyan fejlc kategria, mely nem szabvnyos ugyan - ezrt nincs benne a tblzatban - mgis nagyon elterjedt: ez a borzaszt npes X-header csald. Az X-headereknek ugyanis nincs defincijuk. X-headert brki olyat csinl magnak, amilyet csak akar.
~ 65 ~
A TCP/IP PROTOKOLL MKDSE Nzd meg pldul az X-Face header tipust. Itt van nhny kpviselje:
X-Face
About... The Cheshire Cat
ASCII-code
X-Face: ,l9N8F.A~!GX.Yz#yYAZtvpk7aF(an!BVo3%Xb,`Q]*$Oh'RtXB 5n4iisiGw8l3nY)lnh(G]9[ud;QeX:W}'r)1F9gEQD4o::mBU9J ZAXI\y_0t$P#*/o|!TSG9OtqY+`NX>cpjf?w~w1RY_}M5731El5 2pUnI}OaRi~PA+n[fiO>=TS|2h~f%c9zy]*i2LajTWLJ_X^1No" P#D_(t*t-5n]wW1
Dilbert
X-Face: Xw|'+}IE3RcO/4u;MCw_rVT6OB<-PgDq{'[qF%;xVX;*,S9g9:c#LRR*tVhOl'+uZ&Ial.?6]1IjF^vvo:T<D+:[(_Z+Cp};:9Zotv Or<(#4RP7aF[JT?p9MjTCGa3kP'2C;?ILRb+QYx~WO6{Ala1;v9^2_.BDdnY/.^8PeD3SKJY=',t2vXpx7m;Z>xr@C*,<ND6W?uokQW ;.QsPuk>WaFwl7'ig[9
Goat
X-Face: K?^RDm#'Ec,&g%3z!blP\np<Az>B]y~Y!(oHZmR7#Jf4{r(s&5@ dKA*m5G4'6U'p[id6U$z<0+)=LMn^2J+yohN"Pk@7zd;0I8V~AB ynvf5xL|B9r<cFfBxFpWjP+fQTwv5rd'A*+HE%pH(k'F9T~6Srp U7Ifl+;eGh6|}
J nagy adagot tallhatsz itt: http://www.xs4all.nl/~ace/X-Faces/
Ok, ez elg extrm baromsgnak tnik... de mi lehet az rtelme? Pldul n belerakom minden levelembe a kvetkez fejlcet: X-Face: <valamelyik fenti X-Face kd> Mit csinlnak vele a levelezszerverek? Semmit. X-header, azaz nem szabvnyos, azaz nem ktelesek ismerni. Fogalmuk sincs, mit takar a bjtsorozat. Ugyangy fognak eljrni velk a levelez kliensek. De mi van akkor, ha valaki msnak is megtetszik az tlet? Mondjuk belefejlesztik egy MUA kliensbe, hogy ismerje fel ezt a fejlctipust, kdolja vissza a kdot - s a kialakult brt illessze bele mondjuk a levl vgre, alrsknt. Innentl akik ilyen levelezklienst hasznlnak, meg lesznek gyzdve, hogy mekkora cool bergeek-ek. Hlyesg? Lehet. De a mobiltelefonokra gyrtott httrkp is hlyesgnek tnt, aztn egy idben mgis mindenkinek olyan figyelt a kijelzjn.
~ 66 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI Termszetesen az X-header-eknek ltezik rtelmes felhasznlsa is. Ezekbl szemezgetek nhnyat.
2.14. TBLZAT X-header X-Sender X-Mail From X-Mailer X-envelope-from X-envelope-to X-SCL X-PCL X-MS-Exchange-OrganizationSCL X-MS-Exchange-OrganizationPCL X-MS-Has-Attach X-MS-Exchange-OrganizationPRD X-MS-Exchange-OrganizationSenderIDResult
Jelentse Az Eudora kliens rakja ssze, a login nvbl s a levelezszerver nevbl A Fastmail kliens rakja bele a levlbe, nagyjbl senki nem tudja, mi clbl A levelezkliens neve, amelyik sszerakta a levelet. Szleskren elterjedt. Bizonyos levelezkliensek bemsoljk a levlbe is a bortk adatait. (mail from) gy az esetleges kls srls esetn is clba tud rni a levl. Lsd, mint fent. (rcpt to) Spam Confidence Level Phishing Confidence Level Lsd fent, csak az MS levelezkliensekben. Lsd fent, csak az MS levelezkliensekben. Van-e csatols a levlben Domain nv A sender ID azonostsa sikerlt-e, vagy sem
~ 67 ~
A TCP/IP PROTOKOLL MKDSE 2.3.3 L EV E L EZ Z N K

M R V G R E !
Habr mr lttunk levlkldsi prblkozst, de akkor inkbb csak a hatsukat vizsgltuk. Most viszont vgig fogunk menni egy levl sszeraksn, lpsrl lpsre.
2.34. BRA L EVL KLDSE PARANCS SORBL
Elszr is kezdjk azzal, hogy br a command prompt elg okos jszg, de smtp szerver funkci azrt mg nincs beleptve. Ahhoz, hogy ssze tudjunk rakni s el tudjunk kldeni egy levelet, elzetesen nyitnunk kell egy SMTP sessiont egy ltez SMTP szerver fel. Erre a clra a beptett telnet kliens programot fogjuk hasznlni.
Ignyesebb olvasknak ajnlom a svjcibicskt, a putty programot. http://www.chiark.greenend.org.uk/~sgtatham/putty/
~ 68 ~
Termszetesen olyan SMTP szervert kell keresnnk, mely engedi is a session megnyitst. Nekem a T-Online az internetszolgltatm, logikusan az SMTP szerverket fogom hasznlni.
telnet mail.t-online.hu 25
Az SMTP a 25-s TCP porton dolgozik, rtelemszeren erre a portra kell nyitnunk is. A munkamenet kialaktsa utn ksznnk, mert udvarias fik vagyunk.
ehlo hq
Mondhattuk volna azt is, hogy helo hq - de ekkor nem kapjuk vissza, milyen ESMTP parancsokat ismer a szerver. A hq jelen esetben a kliens gp neve - s a konkrt szituciban teljesen indifferens adat. Brmit is rhattam volna ide. De ez nem jelenti azt, hogy les krnyezetben is ilyen lazn bnhatunk a paranccsal. Lteznek olyan paranoid SMTP szerverek, melyek leellenrzik, hogy az itt megadott node-nak tnyleg az-e az IP cme, mint amelyikrl ppen nyomulunk - s ha nem, akkor eldobjk a sessiont. Ok, tlvagyunk a beksznsen. Vegyk szre, hogy a szerver nem csak azt mondja meg, milyen parancsokat ismer, de arra is figyelmeztet, hogy autentikci nlkl semmire sem megynk. Kezdjk el.
auth login
Erre a szerver kromkodik valamit. Majd szemtelenl villog a prompt, jelezve, hogy erre vlaszoljl valamit, kcsg. Mg ha felttelezzk is, hogy ez egy krds lenne, akkor is milyen nyelven van? Ezt mindenkppen tisztzni kell ahhoz, hogy vlaszolni tudjunk.
~ 69 ~
A TCP/IP PROTOKOLL MKDSE Azrt annyira nem veszlyes a helyzet. Mint ahogy titkosrsnl is az az els, mondhatni sztns reakcink, hogy megprbljuk visszafel olvasni a szavakat, ugyanez igaz az informatikai titkostsokra is. Megnzzk, htha Base64. Ennek a legegyszerbb mdja, ha keresnk a weben egy Base64 encoder/decoder oldalt.
Pldul valamelyiket: http://www.motobit.com/util/base64-decoder-encoder.asp http://www.opinionatedgeek.com/dotnet/tools/Base64Decode/Default.aspx
2.35. BRA B ASE 64 DECODE
gy legyen lott tsnk. A szerver azt krdezi tlnk bzhatvanngyl, hogy mi a felhasznli nevnk. Mondjuk meg neki.
2.36. BRA B ASE 64 ENCODE
Lthat (2.34. bra Levl kldse parancssorbl), ezt a karaktersorozatot nyomtam vissza neki. Jtt a kvetkez krds. Gondolom, nem huppansz le a fldre, ha
~ 70 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI elrulom, hogy ekkor a jelszavamat krdezte, melyet hasonl kdols utn adtam meg neki. Az eredmny ltszik:
235 2.7.0 Authentication successful
RFC 2554 Ha nem megrzs alapjn dolgozunk, hanem a tudomnyosabb mdszereket preferljuk, akkor akr el is olvashattuk volna az SMTP autentikcira vonatkoz RFC-t. Ott szpen le van rva, hogy a kdols Base64. Bent vagyunk vgre, kezdhetnk dolgozni.
mail from:jpetrenyi@t-online.hu rcpt to: jpetrenyi@gmail.com
Rrjuk a bortkra a feladt s a cmzettet. Rnzsre nem egy bonyolult dolog, de nagyon sokszor hasalunk el ezen a lpsen. Nem, nem azrt, mert bnk vagyunk s nem tudunk gpelni - hanem azrt, mert ekkor szokott aktivldni a szerverek open relay elleni vdelme. Relay Open relay Close relay : Tovbbpasszols. : Mindenkitl elfogad levelet s tovbbpasszolja. : Csak egy kivlasztott krtl fogad el levelet.
Jegyezzk meg: Open Relay fj. A szpemmels meleggya. Nlam mindkt parancsra az a vlasz rkezett, hogy
250 2.1.5 Ok
Ez azt jelenti, hogy mivel az IP cmem a T-online tartomnyba esik, szmomra engedlyezve van a rel. Csinljunk egy ellentesztet.
2.37. BRA C LOSE R ELAY
~ 71 ~
A TCP/IP PROTOKOLL MKDSE Belptem egy tetszleges SMTP szerverre. Megvolt a kszngets, itt nem krtek jelszt. Lthat, hogy a mail from parancson simn tjutottam. Ilyenkor a szerver kls embernek tart - akinek csak bels cmre lenne szabad levelet kldenie. Mivel n az rcpt to parancsban is kls cmet adtam meg, gy ez mr relnek szmt - ami az n IP cmemrl szemmel lthatan nincs engedlyezve. Jhet magnak a levlnek az sszeraksa.
data
A szerver figyelmeztet, hogy majd a '.' karakterrel kell lezrnom.

354 End data with <CR><LF>.<CR><LF>
Fejlcekkel kezdnk.
From: "A Yeti, a Yeti, a Hegyiember" <jpetrenyi@t-online.hu> To: "Petrenyi Jozsef GMAIL" <jpetrenyi@gmail.com> Subject: Hello World!
Most szpen kitltttem minden fejlcelemet, gy, ahogy el van rva. Vegyk szre, hogy a bortkon lv cmekhez kpest egy kicsit trkkztem a bels cmekkel. A fejlcek utn a body jn.
Ez egy tesztlevel .
Nos, igen. Nem bonyoltottam tl az letet mindenfle MIME tagolssal. Oldschool mdra csak 7 bites karaktereket hasznltam, gy nem is volt r szksgem. Vegyk szre a zr pttyt.
250 2.0.0 Ok: queued as 637DB797A14 quit 221 2.0.0 Bye
A szerver kzlte, hogy tvette a levelemet s berakta a vrakozsi sorba. Egyszer majd el is kldi. Mindenesetre az n dolgom itt vget rt, kilptem. Nzzk meg, mit csinltunk:
~ 72 ~
2.38. BRA T ESZTLEVL G MAIL - BEN
2.39. BRA T ESZTLEVL O UTLOOKBAN
Abszolt normlis levlnek tnik. Mit okozott az apr trkkzsnk: A To mezben eltakartuk a cmzett SMTP cmt, gy csak az ltalunk kitallt nv ltszik. A cmet elcsalogatni csak a nvre kattintssal lehet. A From mezben azrt mg a rendes cm ltszik. Mg. Eddig j fik voltunk. A kvetkezkben nzzk meg, milyen kevssel kell tbb ahhoz, hogy rossz fik lehessnk. runk mg egy levelet.
~ 73 ~
2.40. BRA I RNY A STT OLDAL
Nzzk meg, mi is trtnt. Ahogy eddig, most is sszeraktunk egy levelet. Csakhogy most - ahhoz kpest, mint amit a bortkra rtunk - gykeresen eltr feladt adtunk meg a bortkon bell. Mit fognak erre lpni a levelez kliensek?
2.41. BRA K AMU LEVL A G MAIL - BEN
Rossz hrem van. Simn beszopjk. Nem azt a feladt mutatjk meg, aki tnyleg kldte a levelet - hanem azt, akinek a nevt a levlbe rtuk. Pedig amit ltsz, az mr az n. details nzet. Ok, egy halvny clzs azrt van arra, hogy valami nem klappol, az a 'mailed-by t-online.hu' gyans lehet - de ha itt egy addig sose ltott levelezszerver neve szerepel, egy tlagos felhasznl mennyire fogna gyant?
~ 74 ~
2.42. BRA K AMU LEVL O UTLOOKBL
Outlookban mg rosszabb a helyzet. Ha itt rncolom a szemldkmet s krem le a details nzetet, semmi nem jelzi, hogy tvers trtnt.
2.43. BRA K AMU LEVL FEJLCE
Egyedl akkor tudom lebuktatni a csalt, ha megnzem a levl fejlct, ott nem riadok vissza a borzasztan teki krikszkrakszoktl s megkeresem a Return-Path fejlc mezt. Itt ltszik az igazi felad: jpetrenyi@t-online.hu.
~ 75 ~
A TCP/IP PROTOKOLL MKDSE Ezen a borzasztan egyszer trkkn alapul a legtbb megtveszt levl. gy lehet elrni, hogy felhborodott leveleket kapjl olyan emailekrt, melyeket nem is te kldtl. Egyszer kaptam mltatlankod levelet egy ltalam blvnyknt tisztelt magyar karikaturisttl, hogy azonnal lljak le a mindenfle hlye emailek kldzgetsrl. Alig brtam tisztzni magamat. Pedig csak annyi trtnt, hogy volt valaki, akinek a cmlistjban mindkettnk neve szerepelt, a gpe pedig megfertzdtt egy olyan freggel, mely a cmlistbl vett cmeket vletlenszeren prostva kldzgetett kamu leveleket. s ez csak a tesztelsi fzisa volt egy techniknak, melyet ma phishing-nek neveznk: hitelesnek ltsz emailekkel vesznek r gyantlan embereket arra, hogy pnzt utaljanak t, jelszavakat adjanak meg.
~ 76 ~
2.4 P ORTTBLZAT
A portok... ezek meglehetsen furcsa lnyek. Egy rszket RFC rja el, ms rszket szoksjog alaktotta ki. Nem vletlen, hogy a foglalt portokat well -known portoknak, azaz jl ismert portoknak is nevezik. Radsul hiba rja el RFC az egyes protokollok ltal hasznlt portot - ha semmi nem szankcionlja azokat, akik eltrnek ettl. Nem visz el a spanyol inkvizci, ha a webes alkalmazsomat nem a 80-as porton publiklom ki. J, persze, nehezebb lesz megjegyezni a cmt, mert oda kell tenni mg a port szmot: http://furamuki.hu:53. Az is igaz, hogy ezzel kizrtam mindenkit, aki tzfal mgl jtt volna. Nem valszn, hogy az n kis webshopom kedvrt tnek egy plusz lyukat a cges tzfalakba. Az anonymous proxikat meg nem mindenki ismeri. De mg ha ki is lyukasztjk, akkor sem biztos, hogy el fognak tudni rni. n ppen nemrg futottam ssze egy olyan vicces webmesterrel, aki a 8443-as porton adta a HTTPS-t. Az ISA2006 ettl egybl dobott is egy htast, mert a HTTPS proxy modulja (webproxy) ezt a trkkt nem brta lekezelni. Arrl meg aztn nem is beszlve, hogy az 53-as port a DNS szolgltatshoz tartozik, teht ha oda rakom a HTTP-t, akkor ezen a gpen nem futhat majd DNS szerver alkalmazs. Szval ezeket mind vgig kell gondolni, s ezen szempontok alapjn kell dnteni arrl, hogy hasznljuk-e az ajnlsokat, vagy sem. Ha a jzan sz dominl, akkor igen.
2.15. TBLZAT Port No. Protocol 7 TCP 7 UDP 9 TCP 9 UDP 13 TCP 13 UDP 17 TCP 17 UDP 19 TCP 19 UDP 20 TCP 21 TCP 23 TCP 25 TCP 37 TCP 37 UDP 39 UDP 42 TCP 42 UDP 43 TCP 53 TCP 53 UDP 67 UDP
Service Name echo echo discard discard daytime daytime qotd qotd chargen chargen ftp-data ftp telnet smtp time time rlp nameserver nameserver nicname domain domain bootps
Aliases sink null sink null
quote quote ttytst source ttytst source
mail
resource name name whois
dhcps
Comment Echo Echo Discard Discard Daytime Daytime Quote of the day Quote of the day Character generator Character generator File Transfer FTP Control Telnet Simple Mail Transfer Time Time Resource Location Protocol Host Name Server Host Name Server Who Is Domain Name Domain Name Server Bootstrap Protocol Server (DHCP server)
~ 77 ~

68 69 70 79 80 88 88 101 102 107 109 110 111 111 113 117 119 123 135 135 137 137 138 139 143 158 161 162 170 179 194 213 389 443 443 445 445 464 464 500 512 512 513 513 514 514 515 517 518 520 520 522 525 526 530 530 531 532 533 540 543 544 548 UDP UDP TCP TCP TCP TCP UDP TCP TCP TCP TCP TCP TCP UDP TCP TCP TCP UDP TCP UDP TCP UDP UDP TCP TCP TCP UDP UDP TCP TCP TCP UDP TCP TCP UDP TCP UDP TCP UDP UDP TCP UDP TCP UDP TCP UDP TCP UDP UDP TCP UDP UDP TCP TCP UDP TCP TCP UDP TCP TCP TCP TCP bootpc tftp gopher finger http kerberos kerberos hostname iso-tsap rtelnet pop2 pop3 sunrpc sunrpc auth uucp-path nntp ntp epmap epmap netbios-ns netbios-ns netbios-dgm netbios-ssn imap pcmail-srv snmp snmptrap print-srv bgp irc ipx ldap https https dhcpc Bootstrap Protocol Client (DHCP client) Trivial File Transfer Gopher Finger World Wide Web Kerberos Kerberos NIC Host Name Server ISO-TSAP Class 0 Remote Telnet Service Post Office Protocol - Version 2 Post Office Protocol - Version 3 SUN Remote Procedure Call SUN Remote Procedure Call Authentication Sevice UUCP Path Service Network News Transfer Protocol Network Time Protocol DCE endpoint resolution DCE endpoint resolution NETBIOS Name Service NETBIOS Name Service NETBIOS Datagram Service NETBIOS Session Service Internet Message Access Protocol PC Mail Server SNMP SNMP TRAP Network PostScript Border Gateway Protocol Internet Relay Chat Protocol IPX over IP Lightweight Directory Access Protocol
www, http krb5 krb5 hostnames
postoffice postoffice rpcbind portmap rpcbind portmap ident tap usenet loc-srv loc-srv nbname nbname nbdatagram nbsession imap4 repository snmp snmp-trap
MCom MCom Microsoft CIFS Microsoft CIFS Kerberos (v5) Kerberos (v5) Internet Key Exchange (IPSec) Remote Process Execution Notifies users of new mail Remote Login Database of who's logged on, average load Automatic Authentication Listens for incoming connections Establishes TCP Connection Extended File Name Server RIPv.1, RIPv.2 Netmeeting User Location Service Timeserver Newdate RPC RPC IRC Chat Readnews For emergency broadcasts Uucpd Kerberos login Kerberos remote shell Macintosh, File services (AFP/IP)
kpasswd kpasswd isakmp exec biff login who cmd syslog printer talk ntalk efs router timed tempo courier courier conference netnews netwall uucp klogin kshell
ike comsat whod shell spooler
router routed timeserver newdate rpc rpc chat readnews uucpd krcmd
~ 78 ~

550 556 560 561 563 636 749 749 993 995 1109 1167 1433 1433 1434 1434 1503 1512 1512 1524 1701 1720 1723 1731 1801 1812 1813 2049 2053 2101 2103 2105 2504 3268 3269 3389 3527 5060 5060 5061 5061 6665 6667 8000 8001 8002 9535 UDP TCP UDP UDP TCP TCP TCP UDP TCP TCP TCP UDP TCP UDP TCP UDP TCP TCP UDP TCP UDP TCP TCP TCP UDP UDP UDP UDP TCP TCP TCP TCP UDP TCP TCP TCP UDP TCP UDP TCP UDP TCP TCP TCP TCP TCP TCP new-rwho remotefs rmonitor monitor ldaps kerberos-adm kerberos-adm new-who rfs rfs_server rmonitord New-who Rfs Server Rmonitor NNTP-TLS LDAP over TLS/SSL Kerberos administration Kerberos administration IMAP (SSL) POP3 (SSL) Kerberos POP Conference calling Microsoft-SQL-Server Microsoft-SQL-Server Microsoft-SQL-Monitor Microsoft-SQL-Monitor Netmeeting T.120 Microsoft Windows Internet Name Service Microsoft Windows Internet Name Service Ingres Layer Two Tunneling Protocol Netmeeting Audio Call Control Point-to-point tunneling protocol Netmeeting Audio Call Control Microsoft Message Queue Server RRAS (RADIUS authentication protocol) RRAS (RADIUS accounting protocol) Sun NFS server Kerberos de-multiplexer Microsoft Message Queue Server Microsoft Message Queue Server Microsoft Message Queue Server Network Load Balancing GC LDAP GC LDAP SSL/TLS Terminal Server Microsoft Message Queue Server Session Initiation Protocol (SIP nonencrypted) Session Initiation Protocol (SIP nonencrypted) Session Initiation Protocol (SIP TLS) Session Initiation Protocol (SIP TLS) Microsoft Chat Server to Server Microsoft Chat Client to Server Cybercash Administration Cybercash Coin Gateway Cybercash Credit Gateway Remote Man Server
sldap
kpop phone ms-sql-s ms-sql-s ms-sql-m ms-sql-m wins wins ingreslock l2tp pptp
ingres
radiusauth radacct nfsd knetd
nfs
nlbs
man
Termszetesen a tblzat bven nem teljes. Mint mindenhol, itt is igaz az, hogy a npszerbb, mondhatni celeb portok nagyobb nyilvnossgot kapnak, jobban figyelembe veszik az emberek. Ha pldul a sajt alkalmazsomban a 2002-es portot hasznlom, aztn az els sniffelsnl azt rja ki a Wireshark, hogy ez a globe protokoll portja... akkor mennyire kell a kardomba dlnm? Mekkora az eslye annak, hogy hasznlom is valaha ezt a protokollt, ha mg csak nem is hallottam rla? Egyltaln, bartsgos protokollrl van-e sz, vagy ellensgesrl? Jelen esetben az utbbirl, ugyanis a portot egy
~ 79 ~
A TCP/IP PROTOKOLL MKDSE TransScout nev virnyk hasznlta. Nyilvn nem RFC alapjn foglalta le... de a sniffer program mr jlt ismertnek tekintette, hogy ez a port ehhez a vrushoz tartozik. Ergo egy tlbuzg antivrus program simn elkaszlhatja a nagyremny alkalmazsomat. Van egy nagyon durva hatr. Azt szoktk mondani, hogy 1024 alatt vannak a nagyon fontos portok. Innen akkor sem mazsolzunk sajt portot a magunk szmra, ha ppen szabad az rtk. Brmikor jhet egy rlt egy j protokollal s kiszrjk neki az addig szabad cmet. 1024- 65535 kztt vannak az gynevezett kliens portok. (Azrt ennyi a plafon, mert kt bjtnyi helyen lehet trolni a portszmokat a TCP/UDP fejlcekben.) Itt mr jval inkbb szabad a vsr, btrabban lehet rabolni. Itt is belefuthatunk persze szerencstlen vletlenekbe (3268: GC LDAP, 3389: RDP, hogy csak kt nagyon fontos portot emltsek) - de itt azrt mr jval kisebb esllyel.
~ 80 ~
2.5 S ZTORIK
Pihenjnk egy kicsit. Elmeslek kt sztorit. Mindkett most, frissen, rs kzben esett meg velem. Mindkett kapcsoldik valamilyen mdon az eddig rtakhoz. Mintha csak megrendelsre jttek volna. 2.5.1 G E EK
R N Y A R AL
Nem tudom, te hogyan vagy vele, n nagyon aggds utazsszervez vagyok. Akkor nyugszom meg, ha elre minden le van foglalva, ki van fizetve. Igaz, ekkor meg azon szoktam parzni, hogy idben odarnk-e mindenhov. Tudtam, hogy hov akarunk menni a nyron. Igaz, mg janur volt, de mivel konkrt esemnyre terveztnk, az idpont biztos volt. Maga az esemny miatt jkora tmeg vrhat, a kivlasztott kemping pedig picike. Radsul ppen ers is a forint - ergo minden jel afel mutat, hogy mr most foglaljam le a szllst. Elmentem a weblapra, megkerestem a Reservation menpontot.
2.44. BRA R ESERVATION
Erre feljtt egy iframe-be gyazott webes form. Kitltttem az adatokat, rnyomtam a 'send' gombra. Kaptam egy kvr 404-est.
2.45. BRA A DATBEVITEL
~ 81 ~
A TCP/IP PROTOKOLL MKDSE Ez bizony baj. Lemenjek gy, hogy nincs biztos szlls? Egy ilyen frekventlt idpontban? Akkor mr inkbb varzsoljunk. Els lps: keressk meg, melyik az az oldal, amely vgl nem rhet el. Szerencsre a Wireshark mostanban gyakorlatilag bootolskor indul, gy nem okozott gondot a berffentse. Eljtszottam ugyanezt a foglalst.
2.46. BRA S IKERTELEN POSZTOLS
A webes formok adatait az OK gomb megnyomsra egy POST paranccsal szoktk elkldeni a webes alkalmazs szmra. Rakjuk ssze a HOST headert s a POST paramtert: www.veniceincoming/camp/.okmailnew.asp. Ennek az alkalmazsnak kellene tadni a kp aljn tallhat szp nagy emaildest vltoz rtkt. Csakhogy az alkalmazs sztrjkol. Vagy kiment pisilni. Nincs. Ami elsre gyans, az a '.' karakter az URI-ban. Nem szoktak. rjuk be anlkl az egszet a bngsz cmsorba: s rgtn egy alkalmazsoldali hibazenetet kapunk. Els lpsnek j. Megvan az alkalmazs, a hiba meg jogos, hiszen tnyleg nem adtam t semmilyen paramtert. Nosza. Alapveten kt stratgia kzl vlaszthatunk. Kezdjk az 'kllel szget falbavers' technikval. Megkrtem a Wireshark-ot, hogy az elkapott csomagokbl rekonstrulja a teljes forgalmat.
~ 82 ~
GET /camp/auk.asp HTTP/1.1 Host: www.veniceincoming.com Connection: keep-alive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0 Referer: http://www.campingsannicolo.com/uk/contattaci-italiano.htm Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Cookie: ASPSESSIONIDSQRCQASS=CGGHHKLCBAPCGHMGBFPEJFIC Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,hu;q=0.4 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Ez volt a kemping weblapjnak lekrse.

HTTP/1.1 200 OK Date: Tue, 19 Jan 2010 18:19:33 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Content-Length: 26933 Content-Type: text/html; Charset=windows-1252 Cache-control: private
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html>
Innen jtt egy bazi nagy HTML lap. Mirt is? Ugye elment egy GET krs, arra jtt egy 200 OK vlasz. Nemrg tanultuk, hogy ennek a vlasznak a message blokkjban jn vissza a lekrt oldal. Mi vlasztja el a message s a header blokkokat? res sor. s tnyleg.
</body> </html> POST /camp/.okmailnew.asp HTTP/1.1 Host: www.veniceincoming.com Connection: keep-alive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0 Referer: http://www.veniceincoming.com/camp/auk.asp Content-Length: 342 Cache-Control: max-age=0 Origin: http://www.veniceincoming.com Content-Type: application/x-www-form-urlencoded Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Cookie: ASPSESSIONIDSQRCQASS=CGGHHKLCBAPCGHMGBFPEJFIC Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,hu;q=0.4 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 emaildest=info%40campingsannicolo.com&cognome=Jozsef&nome=Petrenyi&email=jpetrenyi%40gmail .com&fax=&mese_arrivo=05&giorno_arrivo=21&anno_arrivo=2010&totale_notti=3&numero_adulti=4&
~ 83 ~

numero_bambini=&V-TADU=0&V-B2%2F10=0&V-R%2BAUTO=0&V-CAMP=0&V-TG=0&N-TX2=0&N-TX4=0&NR4%2F5=1&N-SP=0&N-LAV=0&N-BICI=0&N-ELE=1&N-PARK=0&N-PARK-M=0&Note=&Submit=Send
Itt trtnik a lnyeg. Elszr vge van a nagy HTML oldalnak. (Nyilvn kzben kitltttem a mezket s rnyomtam a Send gombra.) A POST paranccsal indul az adatok feltltse. Egy csom fejlc mez utn jn az res sor, majd a message blokkban ott figyel az a karakterlnc, melyet a form rakott ssze s melyet az alkalmazsnak mr j tvggyal el kellene fogyasztania.
HTTP/1.1 404 Not Found Content-Length: 1635 Content-Type: text/html Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Date: Tue, 19 Jan 2010 18:20:12 GMT <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML><HEAD><TITLE>The page cannot be found</TITLE>
De nem teszi meg, ehelyett visszajn egy 404-es hibakd. (Emlksznk, kliens oldali hiba.) Azaz nincs olyan weblap - jelen esetben alkalmazs, melyet meg akartunk hvni. Az zenet message blokkjban mg ott van egy formzott HTML zenet is, hogy a nem kockafejek is rtsk, mirl is van sz. Nos, itt van elttnk a teljes folyamat. Minden parancsot, minden fejlcet, minden message blokkot ismernk. Azt is tudjuk, hogy a POST parancsban van elgpelve az alkalmazs neve. Mire vrunk? Putty.
2.47. BRA W EBLAP MANULISAN I
~ 84 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI Rcsatlakoztam a webszerver 80-as portjra. Soronknt tmsoltam a parancsokat a Wireshark kimenetbl. Ahogy egy res enter-rel jeleztem, hogy vge a parancsnak, rgtn meg is kaptam a weblapot.
2.48. BRA W EBLAP MANULISAN II
Ha ez most egy bngsz lett volna, akkor rtelmezte volna a HTML kdot s szp, sznesszagos weblapom lett volna. De most szveges kliensem van, abban meg gy nz ki a weblap. Kpzeletben kitltttk a formot, vissza szeretnnk kldeni.
2.49. BRA W EBLAP MANULISAN III
~ 85 ~
A TCP/IP PROTOKOLL MKDSE Vegyk szre, a klds els sort, a POST parancsot nem sz nlkl msoltam be. Trltem a '.' karaktert. A tbbi maradt. A message blokk utni res enter utn el is ment a csomag.
2.50. BRA W EBLAP MANULISAN
Sajnos kibrndt eredmnnyel. Hiba talltuk meg az alkalmazst, hiba adtunk t neki egy teljesen szablyos adatcsomagot, az alkalmazs hibt dobott. Maximum annyi vigaszt merthetnk, hogy ez egy 500-as hibakd, azaz kliensknt mr jk vagyunk, most a szerver dobta el az agyt. Mondtam, hogy van egy msik mdszer is. Egyszerbb is, elegnsabb is... de kevesebbet lehet belle tanulni. Els lpsben lementjk az iframe-ben lv weboldal forrskdjt. Remlem, ezt nem kell kln rszleteznem.
2.51. BRA A Z IFRAME FORRSKDJA
~ 86 ~
AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI Megkeressk a form parancs action paramtert. s tnyleg, ott van a hibs hivatkozs az alkalmazsra. Kijavtjuk, mghozz gy, hogy nem a relatv hivatkozst hagyjuk benne - hiszen a HTML fjl most mr itt van a loklis vinynkon - hanem az abszolt URI-t. Elmentjk, megnyitjuk a bngsznkben. Kitltjk a formot, send. Hiba.
2.52. BRA A BOSSZANT HIBA
Ugye ltjuk, hogy ez nagyjbl ugyanaz a hiba, mint amilyet a Puttyban kaptunk csak itt a bngsz jelentette meg a szveget. A hibazenetbl egybknt annyit lehet ltni, hogy ez egy asp alkalmazs, mghozz a nevbl itlve egy levlkld alkalmazs. Valsznleg az lett volna a terv, hogy az alkalmazs emailben elkldi a kempingnek a regisztrcis adataimat - csakhogy a form s a progi nem igazn vannak sszhangban, nincs olyan cm, ahov a csomagot kldeni kellene. Ez ellen mr nem segt semmilyen trkkzs. Megkerestem a kemping emailcmt s elkldtem nekik szp, ember ltal is rthet szveges formban a foglalsi ignyemet.
~ 87 ~
A TCP/IP PROTOKOLL MKDSE 2.5.2 G E EK
R A FO GO R V O S N L
Nemrgiben kellett elmennem a fogorvosomhoz. Mivel nem voltam elre bejelentve, egy kicsit vrnom kellett. A dokinrl tudni kell, hogy egy kifejezetten mediterrn szemlyisg, gyors hangulatvltsokkal, nagy hangervel. A vrterem egytt van a titkrsggal, st, maga a rendelajt is csak a legritkbb esetekben van zrva. gy egy lgtrben rohangl fel-al mindenki, harsnyan kiablva, nevetve. Mg a betegek is igyekeznek hangos nygsekkel kivenni a rszket a kavalkdbl. Nos, amikor itt voltam, a szoksosnl is nagyobb hajcih volt. A fogorvos szerette volna lemondani a rendel internet elfizetst, de a titkrn nem tudott zldgra vergdni az ISP gyflszolglatval. llandan usernevet s jelszt krtek tle - de arra mr senki sem emlkezett. Nyilvn volt valahol szerzds, de az vek alatt dosszistl nyelte el valamelyik szekrny feneketlen gyomra. Mondanom sem kell, mindenki kiablt mindenkivel. A vge az lett, hogy gy dntttek, nem fizetik a djakat, aztn az ISP egyszer csak rjn, hogy kvzi lemondtk a szolgltatst. Mr az utcn jutott eszembe a megolds. Bosszantott is, mert hatalmas piros pontot szerezhettem volna az orvosnl. Oda kellett volna kredzkedni a szmtgpkhz. Nyolc ve vagyok trzsbeteg nluk, msok kocsit vesznek annyi pnzbl, amennyit n mr ott hagytam, simn odaengedtek volna. Els lpsben letltttem volna egy Wiresharkot. Telept, elindt. Majd benztem volna a levelezprogramba s rnyomtam volna a send/receive gombra. Ennyi. Ezzel mr gyakorlatilag kszen is vagyunk. Egyszeren szgyen, de Magyarorszgon gyakorlatilag minden ISP titkosts - azaz SSL - nlkli POP3 hozzfrst biztost. (Eltekintve a Gmailtl, de az ugye nem tlzottan magyar.) Ez azt jelenti, hogy amikor bejelentkezek a postafikomba, plain text formban megy t a drton a usernv s a jelsz.
~ 88 ~
2.53. BRA POP3 FORGALOM
Kitakartam pirossal, de hidd el nekem, hogy a 46-os csomagban a jelszavam ugyanolyan jl olvashat, mint a 38-as csomagban a usernevem. Most jn a kvetkez szgyen. Legalbbis az ltalam ismert ISP-k esetben a POP3 usernv/jelsz megegyezik a f jelszval. Azaz ugyanezzel a usernvel, jelszval lehet belpni a webes admin felletre.
Sorolhatnm mg a sztorikat, de inkbb mr csak utalok. Nem tl rgen keringett egy levl a neten. Kzel 1000 magyar ftp szerver usernv/jelsz adata volt benne. Egyszeren valaki lerakott egy stratgialiag j helyre egy sniffert s begyjttte. Mind titkostatlanul kzlekedett. Nem rtem... mibl gondoljuk, hogy az internet bartsgos hely? s akkor a bongrl mg nem is beszltem.
~ 89 ~
3 A BIZTONSG KRDSE A TCP/IP- BEN

3.1 SSL, TLS
Az eddig trgyalt protokolloknak mind volt egy kzs tulajdonsguk: vnek, mint az orszgt. Ez nmagban persze mg nem lenne olyan nagy baj - csakhogy azta nem is kicsit vltozott a vilg. Brmi elterjed, npszer lesz - ott megjelennek a rossz arcok s el kell kezdennk gondolkozni a vdekezsrl. A gond az, hogy ezek a protokollok strukturlisan alkalmatlanok a hatkony vdelemre, talaktani meg az elterjedtsgk miatt nagyon nehzkes ket. Mr sokadszorra rom le, hogy reg, meg bizonyos szempontbl alkalmatlan - de eddig soha nem mondtam meg konkrtan, hogy mgis, hol szort a cip. Egyrszt az autentikcinl. A HTTP mg csak-csak, ott legalbb vannak vlasztsi lehetsgeink. Igaz, mindegyiknek van valamilyen htultje. Az FTP-nl mr teljesen bajban vagyunk: ha elkapjuk a hlzati forgalmat, tisztn kiszedhetjk az FTP jelszavunkat. SMTP? Lthattad. Az sszes vdelem az a paprtigris erssg Base64 autentikci. A tbbi, eddig ppen csak emltett internetes protokoll sem lehet bszke magra: a POP3, az NNTP, a telnet szintn sima szveges formban kldik t a felhasznli nevet s a jelszt. (Az IMAP4 egy kicsit ms.) Msrszt pedig ott van a forgalom titkostsa. Volt sz rla eddig? Nem vletlenl nem. Mi lehet az a varzsszer, amelyik egyszerre fogja megoldani az sszes protokoll biztonsgi problmjt? Ht a csatorna. Azaz alagt. Azaz kapszula. Illetve ez mind gy egytt. Ugyanis magt a protokollt nem tudjuk mr tovbb tkolni. Jrhatbb megolds az, hogy a kt vgpont kztt atombiztos csatornt ptnk ki, aztn ezen bell gy mennek a jelszavak, ahogy kedvk tartja. (Azrt tudjunk rla, hogy vannak olyan eszkzk - pl. ISA, TMG - melyek bridzselik az SSL-t s kzben bele is tudnak nzni.) A csatornzst mr ismerjk. Beszltnk rla az IPv4/IPv6 talaktsoknl. Ugye az megvan mg, hogy br a csatorna/alagt vizulisan nagyon ers fogalmak s tnyleg sokat segtenek a kommunikci elkpzelsben - de a technolgit illeten nem igazn fedik a valsgot? Pontosabb hasonlat lenne, ha azt mondannk, hogy a felad beleteszi egy dobozba a cuccot, lezrja lakattal s odaadja a postsnak. A posts elviszi a cmzettnek, aki kibontja a dobozt, kiveszi a tartalmt, belerak valami mst s visszakldi a feladnak.
~ 90 ~
A BIZTONSG KRDSE A TCP/IP-BEN A hasonlat persze snta: a lakat nem mindig lakat. Van, amikor csak egy kibontsjelz: nem akadlyoz meg senkit abban, hogy belepiszkljon a dobozba, de a cmzettnek jelzi, hogy ez bizony nem az eredeti tartalom (Authentication Header, AH). Van, amikor mg csak lakat sincs: ha olyan orszgon vezet t a csomag tja, ahol hallbntets jr a piros szn csomagokrt, akkor a hatron gyorsan becsomagoljuk a csomagunkat egy kk dobozba, a hatr tloldaln meg kicsomagoljuk (IPv6 over IPv4). s termszetesen a lakat lehet igazi postsll/gazfickll lakat is: akrmilyen vad vidken is vezet t a posts tja, a doboz tartalmhoz senki nem frhet hozz. Mindegyik mdszer egyfajta csatornzs. Ltunk is rjuk pldkat hamarosan. Az SSL az egy ilyen titkosts-lakatos fajta csatorna. Maga a titkosts kulcsokon alapul5. A kulcs egy j nagy szm, mellyel konkrt informcit lehet nyitni-zrni. Ismtlnk. Amikor kulccsal akarok titkostani egy kommunikcit, akkor azt ktflekppen tehetem meg: vagy egy szimmetrikus kulcs titkostst hasznlok, vagy egy asszimetrikusat. A szimmetrikus kulcs titkosts gyors. Piszkosul gyors. Sokkal gyorsabb, mint az asszimetrikus. Ilyenkor zrsra/nyitsra ugyanazt a kulcsot hasznljuk. Az asszimetrikus titkostsnl egy kulcsprt hasznlunk: amit az egyik kulccsal bezrtunk, azt csak s kizrlag a msik kulcs tudja kinyitni. s vicaversa. A mdszer elnye, hogy az egyik kulcsot (publikus kulcs) simn lehet kldzgetni a legvadabb vidken keresztl is, ha a prja (privt kulcs) biztonsgban lapul. Htrnya, hogy lass. A szimmetrikus kulcs titkostsnak is van egy slyos hibja: a kulcsot valahogy el kell juttatni mindkt kommunikl flhez, mg akkor is, ha azok tbbezer kilomter tvolsgra vannak egymstl, kzttk pedig ott feszl a hekker cen. Gondolom, nem kell hozz zseninek lenni, hogy beugorjon a megolds: ht kldjk el a szimmetrikus titkosts kulcst (session key) asszimetrikus titkostssal, ez lass ugyan, de csak egyszer, maximum ktszer kell hasznlni - utna pedig hadd szljon, ami a csvn kifr, szimmetrikus titkostssal.
A titkostsi mdszerekbe, a kulcshosszsgok szerepbe nem mennk mlyebben bele. Nagyon hossz tma - gyakorlatilag a titkostsokrl s a PKI-rl kln knyveket szoktak rni.
5
~ 91 ~
A TCP/IP PROTOKOLL MKDSE Ezt hvjk gy, hogy SSL, azaz Secure Sockets Layer. Pontosabban gy, hogy TLS, azaz Transport Layer Security. Evolci a szmtstechnikban is ltezik. RFC 2246, 4346, 5246 Az elv mindkettnl ugyanaz, de van egy risi klnbsg: a TLS az SSL utdja. SSL bl volt az 1.0 (mely soha nem lett publiklva), volt a 2.0 (mely bugzott, mint macska jjel), aztn jtt a 3.0, mely mr egszen j volt - de nem folytattk a sort, mert jtt helyette a TLS 1.0, aztn az 1.1 s most ppen az 1.2 az aktulis. Hogy mi minden vltozott az egyes verzikban, arra most nem trnk ki. A TLS-nek van egy risi elnye: lehetv teszi a klcsns autentikcit. De elszr nzzk meg az egyszeres autentikcit.
3.1. BRA TLS EGYSZERES AUTENTIKC IVAL
A kliens szeretne kommuniklni a szerverrel. Elkri a tanstvnyt. (Melyben ugye ott van hitelt rdemlen a szerver publikus kulcsa.) Ezzel a publikus kulccsal betitkostja a session key-t, majd visszakldi. (Eltte termszetesen megllapodnak abban a maximlis erssg titkostsban, melyet mg mindketten ismernek.) Az aszimmetrikus titkosts lnyegbl kvetkezen ezt a csomagot csak a szerver tudja kicsomagolni. Miutn mind a kt flnl megvan a session key, letre kel a szimmetrikus titkostson alapul csatorna, indulhat a kommunikci.
~ 92 ~
A BIZTONSG KRDSE A TCP/IP-BEN
3.2. BRA TLS KLCSNS AUTENTIKC IVAL
Lthat, a klcsns autentikci trkkje az, hogy a kliensnek is rendelkeznie kell rvnyes tanstvnnyal. Zavar lehet, hogy vegyesen hasznltam a kulcs, illetve a tanstvny szavakat. Fussunk ezekkel egy krt. Kpzeld el, hogy kldk neked egy publikus kulcsot, miszerint n vagyok a Nemzeti Bank. Innentl minden titkodat ezzel a kulccsal titkostva kldd el, lcci. Mi lenne az eredmnye? Csak n tudnm elolvasni a bizalmas informcidat - pedig most mr elrulhatom, hogy nem is n vagyok a Nemzeti Bank. ppen ezrt a kulcsprokra rplt egy hitelestsi szint. Ltrejttek minden gyan feletti hitelest szervezetek. Amit ezek mondanak, az kurva fix - hogy az egyik kedvenc szerzmtl idzzek6. A legismertebb hitelestssel foglalkoz nemzetkzi cg a Verisign. Nlunk a Netlock zi nagyban ezt az ipart. A lnyeg, hogy ezek a cgek minden gyan felett llnak. Az publikus kulcsaik mr belepltek az opercis rendszerbe. (Legalbbis a Windowsokba biztosan.) Ha k
"Bsnk Egon Bondy,pokad kdy mu Vladimr etl ze svho denku, dupal podrkami svch malchstevc do podlahy a kival: Kurva fix! Ne j najdu jeden takov obraz, takprstkem musm pekopat cel nmst! A von jich cel stovky sype takhle z rukvu.Vladimre, proboha! Pite bsn, kurva fix J u se s Vladimrem zlobit nebudu. Jho zabiju a bude pokoj! Dyk to, co k, je to sam, jak iju j, jako marxist lev, vestavu permanentn revoluce, ve stavu trval vzpoury proti otci, protoe doposavad zakadho zabitho otce nastoupil syn, a tak stav se otcem, musel ekat, a ho zasenkdo zabije ale my jsme, kurva fix, jen a jen synov"
6
~ 93 ~
A TCP/IP PROTOKOLL MKDSE azt mondjk egy publikus kulcsra, hogy az a Nemzeti Bank, akkor mrget vehetsz r, hogy tnyleg az is. De hogyan adja t egy hitelest ezt az inft? Itt jnnek kpbe a tanstvnyok. A tanstvny ugyanis egy korrekten sszecsomagolt dosszi. Benne van a krdses publikus kulcs. Bele lehet tenni a privt kulcsot is, de ez veszlyesebb, mint napos csibe a root jelszval. (Biztonsgi ments cljra, illetve SSL bridge kiptshez szoktk hasznlni.) R van pecstelve egy rvnyessgi id. Benne van a krdses cg egy csom azonost adata: nv, orszgkd, vros, stb. Benne van a hitelest cg egy csom azonost adata. gynevezett egyb adatok. Majd ez az egsz - pontosabban egy kis darabja - al van rva a hitelest cg privt kulcsval. (Azaz ha a hitelest cg mindenhol meglv publikus kulcsval el tudom olvasni a betitkostott darabot, akkor a tanstvny egsz biztosan ugyanaz, mint amelyet a hitelest cg killtott.) A tanstvnyoknak szintjei vannak. Csak a legpimflibb szinten lehet gyet intzni a weben. A tbbihez szpen be kell vndorolni a cg hivatalos paprjaival, igazolva, hogy tnyleg mi vagyunk mi. Lteznek kevsb ers tanstvnyok is. Mi magunk is gyrthatunk hitelest szervert. (Certificate Authorithy, CA szerver) Ha mi magunk megbzunk benne, akkor megbzhatunk az ltala kiosztott tanstvnyokban is. Ha a partnereink is megbznak benne - megjegyzem, nem szoktak - akkor hasznlhatjk k is. (Ha cgen bell bohckodunk, ott mg elmegy a sajt CA. Cgen kivl mr g.) Ok, trjnk vissza a TLS-hez. Ott jrtunk, hogy kipl a biztonsgos csatorna. (Doboz, lakatok, trelmetlen posts.) Mi utazhat a csatornban? Stay tuned.
~ 94 ~
3.2 SSH
Most ugyanis egy msik protokollrl lesz sz, mely ltszlag nagyon hasonlt ugyan az SSL-re, de ha jobban megnzzk, lthatv vlnak a klnbsgek. Kezdjk trtnelemrval. A Unix vilgban nagyon npszerek voltak az RSH s bartai: RCP, RLOGIN 7. (Hogy vglis melyik protokoll melyik csomagnak volt rsze, abba most nem mennk bele. Neknk Windows oldalrl lnyegtelen.) Nagyjbl ugyanebbe a krbe tartozott a telnet is. Ez utbbit nzzk meg jobban, mert ilyesmi van a Windowsban is8. RFC 15, 854 A telnet egy kliens-szerver alap alkalmazs. A telnet szerver a 23-as TCP porton vrja a kliensek jelentkezst. Maguk a kliensek tipikusan szveges programok, mivel a szerver is parancssor alap hozzfrst biztost. Lttunk is mr pldt rjuk, ilyen volt a Putty, de ilyen a command promptbl indtott telnet parancs is. Ne keverjk ssze a telnet protokollt a telnetelni igvel. A telnet protokoll a 23as TCP porton ad remote shell-t, a 'telnetelni' kifejezs viszont azt jelenti, hogy a telnet segdprogram segtsgvel tetszleges porton keresztl hozzfrni egy szerver olyan protokolljhoz, mely szintn biztost parancssor jelleg hozzfrst. A 'telnet mail.t-online.hu 25' parancs - dacra annak, hogy a telnet programot hasznljuk - pldul egy SMTP sessiont indt. Ugyanez igaz a Putty-ra is. Mindegyik protokoll tvoli varzslsokra adott lehetsget. s egyik protokoll sem volt biztonsgos: a felhasznlnv/jelsz prosok kdolatlanul utaztak a csomagokban. RFC 4250-4254 Aztn jtt a Secure Shell, azaz SSH (port 22). Egyszeren fogtk a fenti protokollmatuzslemeket s beljk hegesztettek egy biztonsgos csatornaptsi kpessget. Az elv ugyanaz, mint az SSL-nl: a csatornaptshez kulcsokat hasznlunk. Vigyzat: nem tanstvnyokat! Azaz az SSH-hoz nem kell kiptett PKI rendszer, a kliensek maguknak gyrtanak kulcsokat.
Remote Shell, Remote Copy, Remote Login Figyelem, Vista ta mr a kliens sem rsze az alap teleptsnek. Kln feature, melyet utlag kell hozzadni a rendszerhez.
7 8
~ 95 ~
A TCP/IP PROTOKOLL MKDSE gy vgl az SSH gyakorlatilag levltotta a telnetet, az RSH-t s az RCP-t (SCP). Itt is rdemes elklnteni a protokollt az ugyanolyan nev segdprogramtl. Szerencsre az OpenSSH ta ez nem olyan nehz. sszefoglalva: Az SSL/TLS egy csatornapt protokoll. PKI-t hasznl, user/password alap autentikcit nem tud. Magt a kiptett csatornt brmelyik msik protokoll kpes hasznlni, feltve, ha felksztettk r. Pldk: HTTPS, FTPS, POP 3S, NNTP-TLS, SMTP-TLS. A protokoll a szlltsi rteg hatrn dolgozik - azaz a HTTP fell gy tnik, hogy a szlltsi rtegben, a TCP fell pedig gy, mintha az alkalmazs rtegben dolgozna. Az SSH egy tvoli menedzselst lehetv tev protokollcsald. Sajt magnak pt csatornt az SSL-hez hasonl mdon, de nem kell hozz PKI rendszer. Ms protokollokat nem igazn tmogat9. Az alkalmazs rtegben dolgozik.
3.3. BRA A TLS/SSL S AZ SSH HELYE A TRKPEN
Errl azrt mg beszlnk.
~ 96 ~
3.3 A Z
ISMERTEBB PROT OKOL LOK BIZTONSGOSABB TTELE
3.3.1 HTTP Ez egy olyan megfoghatatlan kifejezs, hogy 'biztonsgosabb ttele'. Eleve a HTTP azon protokollok kz tartozik, amelyikben beptve is van valamilyen biztonsgi funkci: tud autentiklni. De ez csak a biztonsg egyik oldala10. Hiba j az autentikci - ha a forgalmat nem lehet titkostani, akkor nem kldhetek rzkeny adatokat. Mrpedig egy webruhzban tnferegve, a Paypal-en vagy a webbankunkban kattogtatva nem gyznek repkedni a knyes informcik.
3. 3 .1 . 1 A U T E N T I K C I
Mikor trtnik egy HTTP forgalom sorn autentikci? Ha a szerver kri. Mikor kri a szerver? Amikor az alkalmazs fejleszti gy gondoltk, hogy innentl bizonyos weboldalak csak akkor legyenek elrhetek, ha a prblkoz meg tud adni egy megfelel jogosultsggal br felhasznli nevet s egy jelszt - vagy legalbb hitelt rdemlen bizonytani tudja, hogy orszgos cimborja a webmesternek.
3.4. BRA H OPP , AUTENTIKCI
A kliens elmegy a webszerverhez, lekr egy weblapot. A webszerver kliens oldali hibt (401) jelez vissza, melyben megadja, milyen autentikcis mdszerrel lehet
10
A tzezerbl. A Koh-i-noor-nak nem csiszoltak annyi oldalt, mint amennyi a biztonsgnak van.
~ 97 ~
A TCP/IP PROTOKOLL MKDSE megkrnykezni. A kliens sszelltja az autentikcis csomagot s elmegy jbl a weboldalrt. Ha j volt a csomag, akkor meg is kapja. Melyek lehetnek azok az autentikcis mdszerek?
3.3 .1 .1 .1 B A S I C
3.5. BRA BASIC AUTENTIKCI
A fenti brn egy IIS6 webszerveren fut ASP.NET alkalmazs van olyan remekl belltva, hogy Basic autentikcit kr. Br a kpen nem ltszik, de az interneten keresztl. A klienstl elment a krs, valami ilyesmi formban:
GET /micsodacsoda/index.html
Erre jtt a 401-es kd vlasz:

HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="ecpecckimehecc.hu"
Ezzel jelzi a szerver, hogy autentikcit kr, abbl is a Basic tipust. Az autentikci az ecpecckimehecc.hu tartomnybl fog trtnni. A kliens elszr is bekri az adatokat.
~ 98 ~
3.6. BRA A UTENTIKCIS ABLAK
Majd bsz matekozsba kezd. sszerakja a felhasznli nevet s a jelszt egy karakterlncba (kettsponttal elvlasztva), majd az egszre rkldi a flelmetes Base64 kdol algoritmust. Vgl megismtli az elz krst, de immr mellcsomagolja a kdot is.
GET /micsodacsoda/index.html Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
Amennyiben az autentikci sikeres volt a fenti usernv/jelsz prossal, megnylik elttnk az oldal. Meg mindenki ms eltt is, aki el tudja kapni a vad interneten ezt a forgalmat. Bnuszknt jr hozz egy rvnyes felhasznli nv az eccpecckimehecc.hu tartomnybl. Jelszval. Gondolom, sejted, hogy nem ez a legbiztonsgosabb mdszer. Szigoran csak akkor javallott a hasznlata, ha a kommunikci ms mdszerrel mr vdve van.
3.3 .1 .1 .2 D I G E S T
Kezdjk rgtn egy defincival: a digest az a hash msik neve. Elcspelt plda, mr hasznltam egy msik knyben is a hasonlatot (s mr akkor is mstl loptam): a hash az gyakorlatilag a darlt hs. Azaz van egy szp nagy szm, azt ledarljuk a hsdarln - s kapunk egy kisebb szmot. Ez teljesen jellemz arra a nagy szmra, amelybl kiindultunk, de nem lehet belle kiindulva visszakapni a kiindulsi szmot. (Mint ahogy a fasrtmasszbl sem tudjuk visszalltani a disznt. Klnsen a menzn nem, mert az a massza mg csak nem is ltott hst.)
~ 99 ~
A TCP/IP PROTOKOLL MKDSE A vgtermket nevezzk hash-nek, a hsdarlt pedig OWF-nek. Nem, nem WTFnek. OWF: One Way Function. Ide tartozik minden olyan fggvny/eljrs, mely csak az egyik irnyba mkdik. Finom a darlt hs s nlkl? Nem igazn. Ezrt a kiindulsi szmhoz (mely ugye simn lehet egy karakterlnc, egy blob11, de akr egy komplett binris fjl is) hozz szoktak tenni egy tbb-kevsb vltoz msik szmot, az gynevezett st is. Digest autentikcibl legalbb ktfajta ltezik: Az eredeti Digest autentikci a HTTP 1.0-ban. A fejlettebb Digest autentikci a HTTP1.1-ben. A kt eljrs nem kompatibilis egymssal. Mindkett gykeresen ms OWF -et hasznl. Ha most azt hiszed, hogy oldalakon keresztl nekillok rszletezni, hogyan gytrik meg ezeket a szerencstlen szmokat, hogyan vlasztjk ki a st - akkor tvedsz. Bonyolult dolgok ezek. A korbban emltett TCP/IP Alapok cm knyvben ki van bontva nhny algoritmus a PPP fejezetben. Azrt pr mondatban sszefoglalom a lnyeget: az autentikl szerveren megvan a felhasznl neve s jelszava. A szerver kld egy st a kliensnek. A begpelt usernvvel, jelszval s a sval a kliens eltncolja az OWF-et, majd a digestet visszakldi a szervernek. A szerver szintn vgig tudja szmolni az eljrst - s ha ugyanazt a vgeredmnyt kapja, akkor sikerlt az autentikci. Lthat a mdszer elnye: a vad interneten nem utazik t visszafejthet formban a jelsz.
HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="ecpecckimehecc.hu" nonce="asldenwpbsdeifbgiuitrdubnsdtrbuin"
A 401-es zenet WWW-Authenticate fejlce ebben az esetben kibvlt egy jabb paramterrel. A nonce maga a s, amellyel a kliensnek dolgoznia kell. Sehol nincs szigoran rgztve, minek kell lennie a snak. Abszolt a szervereken mlik, milyen algoritmussal generljk. (Azt azrt sejthetjk, hogy nem lehet konstans rtk.)
11
Binary Large OBject: bazi nagy binris adatkupac.
~ 100 ~
A BIZTONSG KRDSE A TCP/IP-BEN A kliens veszi a lapot, bekri a felhasznli adatokat. Feltrt ingujjal sszegyrja az egszet, majd az eredmnyt visszakldi a szervernek.
GET /micsodacsoda/index.html Authorization: Digest username="EgahazaDideki" realm="eccpecckimehecc.hu" nonce="asldenwpbsdeifbgiuitrdubnsdtrbuin" uri="/micsodacsoda/index.html" response="ufhbvuefvbfujfb456546sfs6ef5gb4se6sefb486"
Ez az autentikcis mdszer mr jval fejlettebb, mint a Basic. A Windows vilgban viszont van nhny kellemetlensge. IIS5 alatt pldul a webszervernek DC-nek kell lennie - s a jelszavakat reverzibilis titkostssal kell trolnia. (Nemnemsoha.) IIS6 alatt mr nem ennyire durva a helyzet, az Advanced Digest autentikcinl mr MD5 hash formban troljuk a jelszavakat a DC-n. (AltSecId tulajdonsg a user objektumon.) Itt mr csak azon kell tltennnk magunkat, hogy ezt az autentikcit brmelyik bngsz tudja hasznlni, feltve, ha gy hvjk, hogy Internet Explorer, a felhasznlnak s az elrend szervernek ugyanabban a tartomnyban kell lennie (ha nem, akkor trust kell), az IIS szervernek s a DC-nek minimum Windows 2003nak kell lennie s a felhasznl termszetesen domaintag kell legyen. s az MD5 mr nem is annyira cool. A Digest s a Basic ltalnos autentikcis eljrsok voltak. A kvetkezkben rstartolunk az IIS autentikcis mdszereire. (Mondjuk gy, hogy ezek elvi lersok lesznek. Mivel ez nem IIS knyv, nem fogok belemenni abba, hogy melyik autentikcis mdszert melyik IIS verzi tudja, meg hogy milyen vltozsok trtntek az egyes mdszerekben a klnbz verzik kztt.)
3.3 .1 .1 .3 A N O N Y M O U S A U T E N T I K C I
Egyszer, mint a fak. A szerver senkitl nem krdez semmit. Mindenki, az anonymous felhasznlhoz rendelt felhasznl nevben fog hozzfrni a krt lapokhoz. Ez a felhasznl alaprtelmezsben az IUSR_computername felhasznl, de mdosthat.
3.3 .1 .1 .4 I N T E G R A T E D W I N D O W S A U T E N T I K C I
Hatrozottan ers autentikci. A krlmnyektl fggen hol NTLM, hol Kerberos autentikcit hasznl. Eddig tartottak a j hrek.
~ 101 ~
A TCP/IP PROTOKOLL MKDSE Htultk: NTLM autentikci: Nem megy t a HTTP proxyn. Csak Internet Explorer bngszvel mkdik. Kerberos: A kliensnek kzvetlenl kell elrnie egy tartomnyvezrlt. Az ilyesmi az interneten nem igazn megszokott. Maradjunk annyiban, hogy ez remek mdszer, feltve, hogy a cg bels hlzatrl prblkozunk.
3.3 .1 .1 .5 .N ET P A S S W O R D A U T E N T I K C I
A .NET Framework rsze egy gynevezett .NET Passport single sign-in szolgltats, melyen keresztl elrhetjk az alkalmazsainkbl a Microsoft .NET passport rendszert. (Melyet mostanban Live ID-nak hvnak.)
3.3 .1 .1 .6 C L I E N T C E R T I F I C A T E M A P P I N G A U T E N T I K C I
Ez se tl bonyolult. Ha a kliensnek megfelel tanstvnya van, akkor minden egyb autentikls nlkl hozzfr a krt tartalomhoz. Ltezhet one-to-one, illetve manyto-one verziban, ez utbbi esetben tbb felhasznlt rendelhetnk ugyanahhoz a tanstvnyhoz.
3.3 .1 .1 .7 F O R M - B A S E D A U T E N T I K C I
A szerver autentikci esetn tirnytja a klienst egy webes formhoz, melyet egy autentikl alkalmazs kezel. Tipikus plda egy OWA bejelentkez kperny.
3.3 .1 .1 .8 E X T E N D E D P R O T E C T I O N - CBT
RFC 2743 Egy n. Generic Security Service (GSS) API-n keresztli autentikci. A mveletben kliens oldalrl egy Channel Binding Token (CBT) vesz rszt. Ez a token autentiklja a felhasznlt. Az autentikci szigorsgt (CbtHardeningLevel) kln lehet konfigurlni. (Csak CBT-vel lehessen, vagy annak hinyban ms mdszerrel is.) Kizrlag TLS felett mkdik (HTTPS) - azaz elzetesen kell neki a biztonsgos csatorna.
~ 102 ~

3.3 .1 .1 .9 E X T E N D E D P R O T E C T I O N - SPN
Meglehetsen hasonl az elbbihez, de itt a token nem csatornt kt be, hanem egy szolgltatshoz rendeldik. Az sszekts a Service Principle Name (SPN) alapjn trtnik. Akkor hasznljk, ha a kapcsolat alatt nincs TLS, illetve olyan trkks esetekben, amikor vagy egy proxy, vagy egy NLBS farm beleszl a TLS csatorna mkdsbe.
3.3 .1 .1 .1 0 S S Z E F O G L A L T B L Z A T A Z A U T E N T I K C I K R L (IIS6)
3.1. TBLZAT Mdszer Anonymous authentication Basic authentication Digest authentication Advanced Digest authentication Integrated Windows authentication
Biztonsg None Alacsony Kzepes Kzepes Magas
Jelsz kdolst N/A Base64 kdols szveg Hashed Hashed Hashed, NTLM esetben. Egybknt Kerberos ticket. Titkostott
Proxyn tmegy? Igen Igen Igen Igen Nem, maximum PPP-vel hasznlva
Bngsz? Brmelyik A legtbb Min. Internet Explorer 5 Min. Internet Explorer 5 NTLM: Internet Explorer 2.0 felett Kerberos: Windows 2000 + min. Internet Explorer 5 Internet Explorer s Mozilla
.NET Passport authentication
Magas Nan.
Igen. SSL
3. 3 .1 . 2 HT TPS
A TLS-rl mr rtam. vatlanul azt is elrultam a fejezet vgn, hogy a TLS csatornn tzavart HTTP-t nevezzk HTTPS-nek. De azt mg nem mondtam, hogy igazbl a HTTP kt szp szemrt talltk ki eredetileg az SSL protokollt. Hogy biztonsgosabb tegyk az egyik legsrbben hasznlt protokoll forgalmt. Legyen egy olyan burok, egy vastagfal kls cs a konkrt kommunikci krl, mely biztostja, hogy az adatfolyamba a kt kommunikl flen kvl senki nem lthat bele. (A TMG mg mindig kuncog a sarokban.) Aztn annyira jl sikerlt a produkci, hogy aprnknt az sszes fontosabb protokollt alkalmass tettk arra, hogy hasznlja. Gondolom az elv mr mindenkinek tiszta. Ezen nem is akarok tlzottan rgdni. Inkbb nzzk, milyen buktatkba tudunk beleszaladni akkor, amikor a HTTP -t a TLS csatornn vezetjk keresztl.
~ 103 ~
3.7. BRA HTTPS RSZLETESEN
A fenti brhoz hasonlt lthattunk mr. (3.1. bra TLS egyszeres autentikcival) Ugyanarrl van sz, csak most konkrtan a HTTP-t vizsgljuk meg - s egy kicsit mlyebben.
3.8. BRA A C LIENT H ELLO CSOMAG
~ 104 ~
A BIZTONSG KRDSE A TCP/IP-BEN A capture brn lthatjuk, hogy a kapcsolat a szoksos mdon kezddtt: a szlltsi rteg szintjn kiplt egy TCP session. 1. A kliens kld egy Client Hello parancsot a szervernek. Ezt a parancsot vehetjk szemgyre rszletesen is a fenti brn. Lthatjuk, hogy a content type az egy kzrzs (22-es kd), a kzrzs protokollja pedig a Client Hello. Lthatunk mg nhny rdekessget: n pldul komolyan meghatdtam, amikor a kliensem ltal felknlt listban (cipher suites) meglttam az elliptic_curves lehetsget. Istenem, eddig mg csak hallottam arrl, hogy ltezik ilyen... most meg ltom is. 2. A szerver kld egy Server Hello zenetet. Ebben mondja meg, hogy milyen SSL/TLS verzit fognak hasznlni. (Jelen pldban TLS 1.0, mert ennyit tud a kliensem.) 3. A szerver egy Certificate zenetben elkldi a tanstvnyt. 4. A szerver egy Server Hello Done zenettel jelzi, hogy rszrl befejezte a kzrzst. 5. A kliens kld egy Client Key Exchange zenetet, benne a session kulccsal. Ezt a csomagot a szerver publikus kulcsval titkostja be. 6. A kliens kld egy Change Cipher Spec zenetet. Ezzel jelzi, hogy innentl mindent a session kulccsal fog titkostani. 7. A kliens kld egy Finished zenetet. Ezzel jelzi, hogy rszrl vget rt a csatornapts, 8. A szerver is kld egy Change Cipher Spec zenetet. rtelemszeren a jelentse ugyanaz, mint korbban a kliensnl - innentl kezdve a szerver is mindent a session kulccsal titkostva fog kldeni. 9. Vgl a szerver is kld egy Finished zenetet. A csatorna elkszlt. Innentl aztn mr abszolt semmit sem ltunk a forgalombl. (Pontosabban ltjuk, csak nem tudjuk rtelmezni.)
~ 105 ~
A TCP/IP PROTOKOLL MKDSE Krds egy nyalkrt: mindenki ltja, mi itt a problma? Ha nem, akkor elmondom. Mit ltunk a Client Hello csomagban? Pontosabban, mit nem? Pldul hatrozottan nem ltunk GET zenetet, logikusan emiatt nem ltunk HOST nev headert sem. Ez termszetes, hiszen itt mg csak a TLS csatorna kiptst lttuk. A HTTP majd csak ksbb lesz beleterelve. Igenm, de akkor milyen tanstvnyt fogunk kapni a szervertl? Konkrtan milyet akkor, ha ez egy olyan webszerver, mely tbb virtulis host-ot kezel? Mit tenne az ISP-m, ha szlnk neki, hogy mostantl a mivanvelem.hu s az emaildetektiv.hu weblapjaimat HTTPS-en keresztl szeretnm elrhetv tenni? Elszr valsznleg maghoz nylna. Aztn meg n12, amikor kzln az rait. Nem megy. A tanstvny vagy a mivanvelem.hu vagy az emaildetektiv.hu nvre van killtva. De amikor a kliens benygi a Client Hello zenetet, akkor mg nem lehet tudni, melyiket akarja elrni. Emiatt a szerver csak egy olyan tanstvnyt tud visszakldeni, amely az IP cmre lett kiadva. Mi kvetkezik ebbl? Az ISP mindegyik virtulis host-ot ms IP cmre rakja. (Ezrt lenne drga.) Az ISP ugyanazt a tanstvnyt rendeln mindegyik virtulis host-hoz. Ha mindegyik virtulis host ugyanabban a gykrtartomnyban van, akkor hasznlhat wildcard tanstvnyt. Ha nem - mint nlam - akkor knytelen lesz Subject Alternate Name tanstvnyt hasznlni. Ezzel nem csak az a baj, hogy k. drga, hanem az is, hogy ha bejn egy jabb host, akkor a teljes SAN tanstvnyt kell megjtani. Ez pedig rinti az sszes virtulis host-ot. RFC 4366 Erre a csapdahelyzetre jelent megoldst a Client Hello parancs egy kiterjesztse, az n. Server Name Indication (SNI). Ebbe a mezbe rja bele a kliens, hogy melyik virtulis host-ot clozta be, gy a szerver el tudja dnteni, melyik tanstvnyt kldje vissza. Ehhez persze olyan bngszre is van szksgnk, mely ismeri az SNI-t: minimum Firefox 2, Opera 8 vagy Internet Explorer 7. Elemezgessk mg egy kicsit ezt a folyamatot. Alaposan tnzted, amit rtam? ssze is vetetted a capture fjl ltal mutatott folyamattal? s mg nem hbrgsz?
12
Mrmint sajt magamhoz.
~ 106 ~
A BIZTONSG KRDSE A TCP/IP-BEN A 2. pontban azt rtam, hogy a szerver kld egy Server Hello zenetet. Valjban viszont (376. csomag) kld mell egy Change Cipher Spec zenetet is. Tudjuk, hogy ez mit jelent: a szerver innentl a session kulccsal titkostva kld mindent. s valban: a 377. csomagban elmletileg egy Certificate zenetnek kellene rkeznie, de mr csak annyit ltunk, hogy Encrypted Handshake Message. Na de ezt... hogyan? Milyen szn session kulcsot hasznl a szerver, amikor a kliensem mg el sem kezdett gondolkodni arrl, hogy generljon egyet? A megolds kulcsa az els Client Hello csomagban rejlik. Ott van olyan, hogy Session ID mez, melynek rtke egy bazi hossz szm. A kliens ugyanis szleli, hogy errl a gprl mr kapcsoldtunk a szerverhez, azaz mr van egy rvnyes session kulcs mind a kt gpen. Nincs ms dolga, mint hogy kzlje a szerverrel, hogy melyik session volt az, amelyiknek a kulcst jra tudjuk hasznostani. gy a szerver mr a msodik lpsben t tud vltani titkostott kommunikcira. Nyilvn innentl borul a tncrend, hamarosan a kliens is kveti. Mg mindig a csatornapts. Az brn (3.7. bra HTTPS rszletesen) az egyszeres autentikcis TLS csatorna kiptst lthattuk. Termszetesen csatornapts itt is ltezik klcsns autentikcival is - de ilyet elg nehz csak gy tallni a neten. Gondold el, hogy pldul csak az frne hozz a Paypal-hez vagy az Amazonhoz, akinek az otthoni gpn rvnyes - s igazi - tanstvnya lenne. Nem hiszed el, de mg mindig a csatornaptst fogjuk boncolgatni. A TLS tud egy rdekes trkkt az SSL-hez kpest. Azt ugye mr a htulgombols csppsgek is tudjk, hogy a HTTP a 80-as porton megy, a HTTPS meg a 443-ason. (Br lttam mr hiperaktv rendszergazdkat, akik tpakolgattk, de a kettssg, mrmint a kln port megmaradt.) A TLS elvileg kpes megugrani azt, hogy egy alkalmazs ugyanazon a 80-as porton forgalmazzon titkostott s titkostatlan csomagokat - azaz menetkzben tudjon TLSre vltani. Legalbb annyit mondjunk, hogy vov. De mieltt megnznnk, hogyan csinlja ezt a trkkt, lssuk, hogyan csinltuk ezt eddig, a hagyomnyos mdon.
~ 107 ~
3.9. BRA HTTP REDIRECT
Bertam a bngszmbe, hogy http://www.paypal.com. Erre azt mondta a szerver, hogy

HTTP/1.1 301 Moved Permanently Location: https://www.paypal.com
Azaz csak azrt fut a webszerver 80-as portjn egy alkalmazs, hogy az odarkez krseket tdobja a szerver 443-as portjra. Ennl sokkal elegnsabb az a mdszer, amikor menetkzben upgrade -ljk fel a kommunikcit HTTP-rl HTTPS-re. Ehhez a kvetkez formban kell kliens oldalrl kiadni a GET parancsot:
GET http://kintisvagyokbentisvagyok.hu/kint.aspx HTTP/1.1 Host: kintisvagyokbentisvagyok.hu Upgrade: TLS/1.0 Connection: Upgrade
Erre ezt fogja mondani a szerver:

HTTP/1.1 101 Switching Protocols Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade
~ 108 ~
A BIZTONSG KRDSE A TCP/IP-BEN s belekezdenek egy TLS csatorna kiptsbe, a mr korbban ltott mdon. Amint felplt a csatorna, a szerver vlaszol a kliens eredeti GET krsre. Mr ha tud. Kpzeljk el, mi van, ha a szerver nem ismeri ezt az Upgrade koreogrfit? Majd mindenfle TLS csatorna kiptse nlkl visszatolja a knyes weblapot, csak gy, HTTP-n keresztl? Nyilvn a kliensnek kell mg ennl is vatosabbnak lennie. Elszr nem a GET-et kell betolni az ajtn, hanem be kell prblkozni az OPTIONS paranccsal.
OPTIONS * HTTP/1.1 Host: kintisvagyokbentisvagyok.hu Upgrade: TLS/1.0 Connection: Upgrade
Ha a szerver partner, akkor kipl a csatorna, a kliens elkldi az igazi GET parancsot. Ha nem, akkor a kliens nem kld semmit.
3. 3 .1 . 3 S HT TP
Megint trtnelemra. Tudni kell, hogy az SSL-t a Netscape fejlesztette ki. Azaz nem volt rla RFC - de ettl fggetlenl megrt 3 verzit s meglehets npszersgre tett szert. RFC 2660 Erre gondoltk azt az IETF-nl, hogy neknk is kell egy ilyen. Igaz, els krben k csak a HTTP-t akartk felturbzni. gy szletett a Secure HTTP, azaz SHTTP. Habr maga a protokoll rnzsre egszen kellemes tulajdonsgokkal brt, elterjedni nem igazn tudott. A kor kt risa (Netscape s Microsoft) a HTTPS mellett tette le a vokst, a bngszpiac maradk 0.0001%-a meg nem rdekelte a kutyt sem.
~ 109 ~
A TCP/IP PROTOKOLL MKDSE Mik is ezek a kellemes tulajdonsgok? Kinzetre teljesen ugyanolyan szerkezet, mint a HTTP. Ez hatrozott szndk volt, hogy a fejlesztknek ne kelljen sok jat tanulniuk. Nem ignyel kln portot. A 80-as abszolt j neki. A titkostsi mdszereknek valami hatalmas arzenljt vonultatja fel. Nem kell hozz PKI, csak szimmetrikus titkostssal dolgozik. Aztn a vgn az IETF hagyta az egszet a fenbe s beemelte az SSL3,0-t TLS1.0 nven az RFC-k kz.
Rszletesebb lers: http://www.javvin.com/protocolHTTPS.html
~ 110 ~
A BIZTONSG KRDSE A TCP/IP-BEN 3.3.2 FTP Tudom, hogy nem ez a legerteljesebb FTP szerver implementci, de nzznk meg egy korai IIS szervert. Milyen autentikcit engedett az FTP-nek? A Digest s az Integrated Windows autentikcik szba sem jhettek. Maradt az Anonymous, illetve a Basic. De minek. s igazbl mshol sem volt jobb a helyzet. Az FTP vagy nem krt autentikcit, vagy plain text-ben kldte t a jelszt.
3. 3 .2 . 1 FTPS
Nyilvn az FTP is az elsk kztt volt, amelyik ment a HTTP utn az SSL csatornba. Mghozz rgtn meg is cifrzta a lpseit, ugyanis kt klnbz mdon kpes S SL csatornt pteni: EXPLICIT MD RFC 2228, 4217 Ebben az esetben a kliens hatrozottan javasolja a szervernek, hogy kezdjenek el beszlgetni az autentikcis lehetsgekrl. Ezt az AUTH paranccsal jelzi. A parancsnak paramtere a csatorna tpusa (SSL, illetve TLS). Ha a kliens nem tallja el, mit tud a szerver, akkor egy AUTH 504-es kdot kap vissza. Hogy elkerlje ezt a frusztrcit, a kliens kezdheti egy FEAT paranccsal, amelyre a szerver megmondja, melyiket ismeri. Utna pedig az ismert mdon nekillnak titkostott csatornt pteni. Ebben a mdban a kliensnek lehetsge van kapcsolgatni. Ha be akarja kapcsolni a titkostst a command csatornra, akkor azt az AUTH TLS v. AUTH SSL paranccsal teheti meg. A kikapcsols a CCC paranccsal trtni. (Clear Control Channel.) Az adatcsatorna titkostsnak bekapcsolsa a PROT paranccsal trtnik, kikapcsolsa pedig a CDC paranccsal.
~ 111 ~
A TCP/IP PROTOKOLL MKDSE IMPLICIT MD - Semmi cic, nlam van a slukker - mondja a kliens. Azaz senki nem trgyal semmit, ha a kliens beszl egy Client Hello-val, akkor a kvetkez pillanatban mr falazzk is a csatornt.
3.10. BRA K APCSOLDS I MPLICIT FTPS SZERVERHEZ
Lthatod, mg semmi sem trtnt... de a kliensem mr vadul ptette a csatornt. Ahol a logban zld lesz a felirat, onnan mr titkostott csatornban folyik a kommunikci. (Nem is tettem be kpet a capture fjlbl. Nem ltni semmit.) Varilni maximum a titkosts szintjben lehet (PROT P), de kikapcsolni, azt nem. Az egsz session titkostva lesz. Emltsnk meg egy apr problmt - mely mindkt mdot egyarnt rinti. A tzfal. Pontosabban az FTP protokoll proxy. Ez ugye csak akkor tud mkdni, ha a command csatornbl ki tudja olvasni, hogy a szerver melyik portjt fogja felajnlani a kliensnek data csatorna ltestse cljbl. (Mivel tzfalazunk, beszljnk eleve csak a passzv FTP-rl.) Ha TLS/SSL csatornba zavarom a kommunikcit, akkor mit fog tudni kiolvasni a tzfal? Semmit. Ezt a problmt lehet gy krbedolgozni, hogy ersen lekorltozzuk az FTP szerveren a szbajhet portokat, majd a tzfalon engedlyezzk ezt a mr nem tl nagy szm porthalmazt.
~ 112 ~
3. 3 .2 . 2 FTP O V E R S S H
rtam, hogy az SSH az egy nll, zrt vilg. Nem kooperl ms protokollokkal. Egyetlen kivtelre hajland csak: az FTP-t valamirt nagyon szereti. Az SSH-ban meg lehet oldani, hogy az FTP forgalom teljes egszben - belertve a command s data csatornk forgalmait - SSH-ba csomagolva utazzon. Ezt nevezik FTP over SSH-nak. (Lsd a legrdl ment: 3.10. bra Kapcsolds Implicit FTPS szerverhez)
3. 3 .2 . 3 A B J O S F L R E R T S E K F O R R S A - S FT P
Az FTP over SSH nem keverend ssze az SFTP protokollal (SSH File Transfer Protocol), mely csak nevben hasonlt az FTP-re. Igazbl ez az SCP utdja: RCP -> SCP -> SFTP. Azaz az SFTP rsze az SSH-nak, annak gyakorlatilag a fjltovbbt, fjlmenedzsel alkalmazsa. (Ezt szoktk sszekeverni a Simple File Transfer Protocol-lal, mivel ugyanaz a rvidtsk. Az let nem habostorta.)
3.11. BRA M INDENFLE FTP- K
Egy igazi ingyenes FTP szerver, mely ismeri mind az FTPS-t, mind az SFTP-t. http://filezilla-project.org/client_features.php
~ 113 ~
A TCP/IP PROTOKOLL MKDSE 3.3.3 A

T B BI EK , AZ A Z A
STARTTLS
Habr az SSL/TLS olyan protokoll, melyen keresztl brmilyen ms protokollt t lehet vezetni, de azrt ez nem olyan egyszer. Lthattad eddig is, hogy bizony bele kell nylni az eredeti protokollba. Minimum annyira, hogy legyen benne egy olyan parancs, amelyik elindtja a TLS csatorna ptst. Ez a STARTTLS. Gyakorlatilag ezt a bvtst hasznlja az SMTP, a POP3, az IMAP4 s az NNTP is.
3.12. BRA STARTTLS
Lthatod, a parancs neve szerepel az EHLO parancsra visszaadott listban. Ha berom, akkor a szerver a 220-as kddal jelzi, hogy fel van kszlve a csatornaptsre, kezdhetem az sst. Erre mr nem is rdemes tbb szt vesztegetni. Ha mr a levelezsnl jrunk, beszljnk mg egy msik fajta vdelemrl is: nem csak teljes forgalmakat lehet csatornba terelni, a legtbbszr megoldhat egyes levelek titkostsa, illetve digitlis alrsa is. Ezekre tbb mdszer is ltezik, tnyleg csak felsorolsknt kett: S/MIME, PGP/GPG. Hogyan trtnhet egy levl titkostsa? Hasznlhatunk szimmetrikus kulcsot? Persze, ha mr van belle egy pldny a tloldalon. Hogyan juthat t? Motoros futrral? Nem igazn biztonsgos. Asszimetrikus kulccsal titkostott csomagban? Deht az a TLS.
~ 114 ~
A BIZTONSG KRDSE A TCP/IP-BEN Ergo nem tudunk szimmetrikus kulcsokat biztonsgosan hasznlni. Marad az, hogy a teljes titkosts/alrs mka asszimetrikus titkostssal, azaz kulcsprokkal trtnik. Nem akarok ebbe tlzottan belemenni, itt csak pr mondatban sszefoglalom a lnyeget: LEVL ALRSA Elveszem a privt kulcsomat. Ezzel betitkostom a kldend levelemet - illetve a gyakorlatban csak egy kis darabjt. Mivel a publikus kulcsomat az egsz vilg ismeri, gy brki ki tudja nyitni a levelet. Azaz nem titkos. Viszont ha az n publikus kulcsommal tudtk kinyitni, akkor az csakis az n privt kulcsommal lehetett lezrva - ergo hiteles. Azaz alrt. LEVL TITKOSTSA Els krben megszerzem _a cmzett_ publikus kulcst. (Tanstvny.) Ha megvan, akkor ezzel betitkostom a kldend levelet. Ki tudja elolvasni? Brki, akinl ott van a cmzett privt kulcsa. J esetben ez egyedl csak a cmzett. (rted mr, mirt szoktak jt derlni az informatikusok azon, amikor bejn Vezrigazgat Istvn s kzli, hogy 10 perc mlva titkostott levelet akar kldeni az Arrogns zRT-nek? Ha ugyanis a cmzettnek nincs tanstvnya, a fejnk tetejre is llhatunk, akkor sem tudunk neki titkostott levelet kldeni.)
~ 115 ~
3.4 IPS EC
Igen bajban vagyok, ha valahogy definilnom kell, mi is az az IPSec. Taln mg az hangzik a legpontosabban, ha azt mondom, hogy az IPSec az egy nagy kteg IETF szabvnygyjtemny. Olyan szabvnyokbl ll, melyek hlzati forgalom titkostsra vonatkoznak. Pontosabban nem is a titkosts kifejezs a leginkbb megfelel - maradjunk annyiban, hogy a hlzati csomagokat birizglja. gy, hogy azoknak jl essen. Mg mindig pontostanom kell. Mi az, hogy hlzati csomagokat? Az SSL szintn gynyren titkost. A klnbsg az, hogy az SSL az alkalmazsbl kijv csomagot. azaz a szlltsi rteg payloadjt titkostja. Az IPSec viszont a szlltsi rtegbl kijv csomagot, azaz az IP rteg payloadjt piszterglja. Egy szinttel lejjebb tnykedik. Ezrt hvjk _IP_Sec-nek. s akkor rakjuk mr rendbe ezt a titkost/birizgl dolgot is. A levelezsnl mr lthattuk, hogy kulcsprokkal ktflekppen jtszhatunk: Alrtunk. Ekkor mindenki el tudta olvasni a levelet - de maga az a tny, hogy el tudtk olvasni, igazolta, hogy mi s csak mi kldhettk a levelet s annak tartalma nem vltozott meg. Titkostottunk. Ekkor csak a kivlasztottak tudtk elolvasni a levelet. Illetve a kett egytt. Az IPSec esetben - cljait tekintve - hasonl a fellls. (Technolgiailag nem.) Alrunk : Authentication Header, azaz AH. Titkostunk : Encapsulating Security Payload, azaz ESP Mg mindig csak vadul definilgatunk. Ugyanis mindkt trkkt helybl ktflekppen is be tudjuk mutatni: TRANSPORT MD: Kt node kztt biztost biztonsgos/autentiklt kapcsolatot. Tipikusan cgen - azaz biztonsgosabbnak tekintett hlzaton - bell hasznljk. TUNNEL MD: ltalban kt router kztti csatorna kiptsre hasznljk, megbzhatatlan kzegben. (Mint pl. az internet.) Ez annyi, mint ngy IPSec aleset. Hzzunk bele.
~ 116 ~
A BIZTONSG KRDSE A TCP/IP-BEN 3.4.1 A U T H EN T I C AT I O N H E A D ER RFC 4302 Az autentikcis fejlc gyakorlatilag azt a trkkt tudja, hogy az IP datagram bizonyos rszeibl s magnak az autentikcis fejlcnek egyes rszeibl kszt egy tl darlt hst: azaz a mezk tartalmt keresztlpasszrozza egy OWF-en. A Windows Server 2008 / Vista esetben ez vagy HMAC-MD5, vagy HMAC- SHA1 hash gyrtst jelent.
3.13. BRA A UTHENTICATION HEADER
NEXT HEADER: Spoilerezek egyet: az AH egy - valamilyen - IP fejlc s egy IP payload kz furakszik be. Emiatt elromlik az IP fejlcben a PROTOCOL mez rtke - hiszen a kvetkez blokk nem a payload, hanem az AH. Ergo az IP fejlcben lv PROTOCOL mez rtke 51 lesz (az AH kdja), az autentikcis fejlcben lv NEXT HEADER mez rtke pedig a kvetkez blokkra utal kd. (brn rthetbb lesz.) PAYLOAD LENGTH: Egy bjt, az AH bjtokban mrt rtke. RESERVED: Nulla. Majd valamikor hasznljuk valamire. SECURITY PARAMETERS INDEX: Egy kd, mely az IP fejlcben lv Destination IP cmmel egytt az SA-t (Security Association, lsd. ksbb) azonostja. SEQUENCE NUMBER: Sorszm. Fontos, hogy bele van vve a darlsba, gy a csomagfolyamot nem lehet tvgni visszajtszsos technikkkal.
~ 117 ~
A TCP/IP PROTOKOLL MKDSE AUTHENTICATION DATA: Maga a lnyeg. A blokk mrete bjtban mrve nggyel oszthat kell legyen, ha nem gy jn ki, akkor kiptoljk. Ebben a mezben utazik maga a darlk, azaz a hash.
3. 4 .1 . 1 AH T R A N S P O R T M D
3.14. BRA AH T RANSPORT MD
A legegyszerbb mdszer. Az IP fejlc s a payload kz csusszan be az autentikcis fejlc. Logikusan az IP fejlc Protocol mezjbe 51 kerl, az AH Next Header mezjbe pedig a payload tartalma, mondjuk 17, azaz UDP. Nzzk, hogyan keletkezik az ICV. (Az ICV egy jabb neve a darlt hsnak. Jelen esetben az Integrity Check Value kifejezst takarja.) Az IP fejlcbl beledolgoznak minden mezt, mely nem vltozik tovbbts kzben. Amelyek vltoznak (TOS, Flags, Fragment Offset, TTL, Header Checksum), azoknak az rtke nulla lesz a szmols sorn. Belekerl maga az AH is, br az Authentication Data mez helyett 0 szerepel. (Egybknt az rkkvalsgig darlnnk.) Vgl beledobjuk a teljes IP payload blokkot. Azaz az AH igazolja, hogy sem az IP payload, sem az IP fejlc zemszeren nem vltoz mezi s legfkppen maga az igazol blokk rtkei nem vltoztak meg szllts kzben, a cucc bitrl-bitre ugyanaz, mint amit feladtak.
~ 118 ~
3. 4 .1 . 2 AH T U N N E L M O D E
3.15. BRA AH T UNNEL MD
Az AH megint furakodik, de most az IP fejlc megmakacsolta magt. sszezrtak a payload-dal. Az AH gy a csomag elejre kerlt - de mivel azrt nem egy IP fejlc, gy a csomag el oda kellett bigyeszteni egy igazit. Jelen esetben az eredeti IP datagram nem vltozott semmit. Az j IP fejlc Protocol mezjbe kerl bele az 51-es kd, az AH Next Header rtke meg a mgtte jv IP datagramra mutat. Tltelk recept: A kls IP fejlcbl bekerl minden mez, melyek rtke zemszeren nem vltozik. Bekerlnek az AH mez rtkei, kivve persze nmaga, az Authentication Data. Vgl beledobjuk a teljes, eredeti IP datagramot. Fontos megrteni a klnbsget a Tunnell s a Transport md kztt. A Tunnelnl az eredeti IP fejlc - azaz az eredeti felad s cmzett IP cmei - bent maradnak a bels IP fejlcben. A kls IP fejlcbe a tunell kt vgpontjt biztost hdfllsok IP cmei kerlnek. Ahogy megrkezik a csomag a bejrati kapuhoz, kap egy AH-t s egy j fejlcet, melyben cl cmknt a kijrati kapu IP cme lesz. A kijrati kapunl meg leszedik rla az j fejlcet, az AH-t - s az eredeti IP csomag mehet tovbb az tjn. Transport md esetn ilyen varils nincs, a vgs cmzett ugyanaz a host, akinl az IPSec is vgzdik.
~ 119 ~
A TCP/IP PROTOKOLL MKDSE 3.4.2 E N C AP SU L AT I N G S E C UR I T Y P A Y LO A D RFC 4303
3.16. BRA E NCAPSULATING S ECURITY P AYLOAD
SECURITY PARAMETERS INDEX: Mint korbban. SEQUENCE NUMBER: Sorszm. PADDING: A titkostott rsznek szintn akkornak kell lennie, hogy a bjtban szmolt mrete nggyel oszthat legyen. Ezrt toldozunk, ha kell. PADDING LENGTH: Mennyivel toldottunk. NEXT HEADER: Szintn, mint korbban. AUTHENTICATION DATA: Teljesen azonos, ugyangy az ICV-t tartalmazza. Ejtsnk pr szt arrl, milyen titkostsok jhetnek szba Windows Server 2008, illetve Vista alatt: Advanced Encryption Standard 128 bites kulccsal (AES-128) AES 192 AES-256 Triple Data Encryption (3DES) 56 bites kulccsal Data Encryption Standard (DES) 56 bites kulccsal. (Brof.)
~ 120 ~

3. 4 .2 . 1 ES P T R A N S P O R T M D
3.17. BRA ESP T RANSPORT MD
Lthat, itt egy egsz siserehad vetdtt r az IP datagramra. Az ESP fejlc befurakodott az IP fejlc s az IP payload kz. Emiatt az IP fejlcben lv Protocol mez tartalma 50-es rtkre (ESP) vltott. A csomag vgre pedig bejtt az ESP trailer, illetve egy Authentication Data blokk. A titkosts mdjra utal informcik az ESP headerben utaznak. Azaz eddig a blokkig nem lehet titkostani, utna viszont mr igen. A teljes IP payload s az ESP trailer is le van kdolva.
3.18. BRA ESP CSOMAG
Lthatod, a Wireshark is csak az ESP headert tudja mutatni: SPI s sorszm.
~ 121 ~
Az ICV a kvetkezkbl ll ssze: A teljes ESP header A teljes IP payload Az ESP trailer, de az Authentication Data mez mr nem. Nzzk meg, ezzel mit csinltunk. Egyrszt igazoltuk, hogy a payload, illetve a titkostshoz hasznlt mezk garantltan nem lettek mdostva. Msrszt a payload, azaz a hasznos teher, titkostva ment t a drton. Viszont az is tny, hogy semmilyen mdon nem vdtk meg az eredeti IP fejlcet. Mg annyira sem, mint az AH Transport mdban. Emiatt szoktk a kt Transport mdszert kombinlni.
3.19. BRA AH S ESP T RANSPORT MDBAN
Lthat, hogy az elz brhoz kpest annyi a klnbsg, hogy bejtt egy plusz autentikcis fejlc. Azaz az ESP tovbbra is autentiklja s titkostja a sajt kis szemtdombjt, de az egsz meg lett mg fejelve egy AH blokkal. Nyilvn ebben a krben az IP fejlc PROTOCOL mezjbe az 51-es rtk kerl, az AH blokk NEXT HEADER mezjbe 50-es, s csak az ESP Trailer NEXT HEADER mezje fogja mutatni a Payload tartalmt. Az AH szempontjbl az ESP csomag az IP payload - azaz ennek fggvnyben kszti el az AH Transport mdnl mr ismertetett ICV-t.
~ 122 ~

3. 4 .2 . 2 ES P T U N N E L M D
3.20. BRA ESP T UNNEL MD
Na, itt aztn vdjk ezerrel az eredeti IP fejlcet. Lthat, Tunnel mdban ugyanaz a lnyeg: ahogy az IP datagram megrkezett a csatorna bejrathoz, teljesen ugyangy kell ki is mennie a kijraton. Emiatt az eredeti IP datagram titkostva van, autentiklva van, st, autentiklva vannak a titkostshoz szksges mezk is. (Jelzem, ez a mdszer sem vdi meg az j fejlcet a mdoststl.)
~ 123 ~
A TCP/IP PROTOKOLL MKDSE 3.4.3 S E CU R I T Y A SSO CI AT I O N S Egy jabb kteg szabvny kvetkezik. Ahhoz ugyanis, hogy kt host beszlni tudjon egymssal ipszekl, ahhoz le kell tisztzniuk, melyik az a nyelvjrs, melyet mindketten ismernek. Ha megtalltk, akkor az gy kialakult kapcsolatot - melyben egyarnt vannak biztonsgi szolgltatsok, klnbz vdelmi mechanizmusok s klcsns kulcscserlsi algoritmusok - nevezzk biztonsgi szvetkezseknek, ngliusul Security Associations-nek. Az IPSec kommunikciban alapveten kt SA alakul ki: elszr az Internet Security Association and Key Management Protocol (ISAKMP) SA, mely kialaktja azt a biztonsgos csatornt, ahol mr beszlgethetnek a hostok a finomabb rszletekrl. Utna jn a msodik SA, az IPsec SA, aholis a korbban emltett finomabb rszletekben egyeznek meg a felek. Ez utn indulhat csak be a forgalom, a korbban emltett technikk valamelyikvel.
3. 4 .3 . 1 M A I N M O D E (IS AK M P S A )
RFC 2408 Alapveten az SA kialaktsa hrom lpsben trtnik: A felek - plain textben - megbeszlik, milyen vdekez mechanizmusokat ismernek. Mg mindig plain textben nekillnak kulcsokat cserlni. Elkezdik egymst autentiklni. (Na, ez mr titkostva megy.)
3.21. BRA ISAKMP SA KIALAKTSA , PLAIN TEXT
~ 124 ~
3.22. BRA ISAKMP KIALAKTSA , MR TITKOSTVA
Jl lthat maga az SA-k kialaktsa: elindul a plain text kommunikci, majd ttrnek titkostottra (ekkor mr csak annyit ltunk a payload-bl, hogy Encrypted payload), vgl elkszltnk, jhet maga az ESP. Az brkrl kiolvashatunk mg egy fontos informcit: az ISAKMP, legalbbis amg nem titkostott, addig UDP-t hasznl, mghozz az 500-as porton - illetve NAT esetn a 4500-as porton. Mg egy megjegyzs: az brkon is lthat Aggressive md kifejezs alatt nagyjbl hasonlt kell rteni, mint a Main mdnl. A tartalma ugyanaz, csak a Main md esetben a felek identitsa vdve marad.
~ 125 ~
3.23. B RA A Z ISAKMP CSOMAG ELHELYEZKEDS E
Remlem, senkit nem lepett meg, hogy az ISAKMP csomag is fejlcbl s payload-bl ll. Ellenben most az egyszer nem mennk bele a fejlc lveboncolsba. Valahol abba kell hagyni, mert a vgn mg az ember szenvedlyv vlik. Az brn (3.21. bra ISAKMP SA kialaktsa, plain text) lthat egy kifejlett pldny. Piszkljuk inkbb a payload-ot. Ugyanezen az brn lthat bellk is egy j nagy kupac. Igen, egy csomagban nem csak egyfle lehet. s hogy mg bonyolultabb legyen a helyzet, mindegyik payload tipusban vannak specilis mezk. Az egybknt az ISAKMP fejlcben is megtallhat - Next Payload mez rtke mondja meg, hogy milyen payload tipus jn a lncban. Az oldals brn lenyitottam pr payload blokkot. Az sszeset nem, st, a kinyitottaknl sem mentem le a teljes mlysgekig - borzasztan hossz listt kaptunk volna. Az ISAKMP esetn tnyleg minden fontos dolgot megbeszlnek a felek.
~ 126 ~
A BIZTONSG KRDSE A TCP/IP-BEN Pusztn csak felsorols jelleggel, mivel csak egy kicsit nem lehet rszletezni az egyes tipusok tartalmt - nagyon pedig nem akarok belemszni. Payload tipusok: SA payload Proposal payload Transform payload Vendor ID payload Nonce payload Key Exchange payload Notification payload Delete payload Identification payload Hash payload Certificate Request payload Certificate payload Signature payload
~ 127 ~
3. 4 .3 . 2 Q U I C K M O D E (I PS E C S A)
Az ISAKMP SA utn mindkt fl kezben ott lesz egy eljrskteg. Melyek azok az eljrsok, melyeket mindkt fl ugyangy ismer. Az IPSec SA kialaktsakor ezek kzl vlasztjk ki azokat, amelyeket immr hasznlni is fognak. (Gyakorlatilag az IPSec SA kialaktsakor mindkt irnyra klnkln megllapodsok jnnek ltre.) Mivel itt mr tnyleg a konkrt eljrsokrl van sz, ennek a kommunikcinak muszj titkosnak lennie. Brmilyen meglep, formailag ebben a fzisban is ISAKMP csomagokat hasznlnak a felek. A kommunikci ngy lpsbl ll, ezek sorn a kvetkez tipus payload-ok kzlekednek: SA, Identification, Nonce, Hash s Notification.
3. 4 .3 . 3 IKE
RFC 2409 Elrkeztnk ahhoz a rszhez, ahol az egybknt boszorknyosan gyes versenytncosnak is sszegubancoldik a lba. Az Internet Key Exchange ugyanis megint egy szabvnygyjtemny, mely radsul tfedsben van az eddigiekkel. Egsz pontosan az IKE az kt halmaz egybegyrsa: Egyfell az ISAKMP, mint SA ltrehozsra szolgl protokoll, Msfell az Oakley Key Determination Protocol, mely a Diffie-Hellman algoritmust hasznlja kulcsok cserjre. Ha visszaemlkszel, akkor az ISAKMP SA ltrehozsakor rtam, hogy van egy lps, amikor mg plain textben kulcsokat cserlnek a felek. Nos, az IKE azt tudja, hogy ez a kulcscsere trtnhet a Diffie-Hellman algoritmussal. (Mert extrm esetben lehet preshared key is.) Termszetesen az IKE clja is SA ltrehozsa - mghozz mindkett. Van neki Main mdja s van Quick mdja. Ugyangy ISAKMP csomagokat hasznl, st, a Main md utn az SA-t ugyangy IPSEC SA-nak nevezik. rtelemszeren az ISAKMP csomagok itt is az 500-as UDP portot hasznljk.
~ 128 ~
3. 4 .3 . 4 IK E V 2
RFC 4306, 4301, 4309 Az eredeti IKE - br egsz j cucc volt - de azrt brt nhny hinyossggal. Tbb kisrlet is szletett a jobbtsra, vgl ezeket 2005-ben az IETF sszefogta egy RFCbe, a 4306-osba. Ez lett az IKEv2. Mit tud?
3.4 .3 .4 .1 R F C
Eleve kevesebb RFC-t jelent. Mint rtam, az IKE-t nekilltak toldozgatni, foldozgatni. Ez mind-mind RFC-ket jelentett. Ezzel szemben a 4306 egybefogta az egszet. (Azta persze ezt is toldozgatjk.)
3.4 .3 .4 .2 M OB IK E
Ez egy ksbbi kiegszts az IKEv2-hz, melynek segtsgvel a bolyong - mobil felhasznlk is tudnak SA-t ltrehozni.
3.4 .3 .4 .3 N AT T R A V E R S A L
Ez nmagban is egy rdekes trtnet. Gondoljunk bele, mi van akkor, ha egy natol router mgtt lve akarunk IPSec csatornt kipteni? A router a NAT sorn kapsbl kicserli az IP fejlcben a felad IP cmt. Ha a portokkal is jtszik, akkor mg a TCP/UDP fejlcben is cserli a felad port szmt. Mrpedig akr az AH, akr az ESP csatornzst nzzk, az alrs elksztsben benne van mind az IP fejlc, mind az IP payload, azaz az UDP csomag vagy TCP szegmens. Akkor ezt most hogy? Ugyangy, ahogy az IPv6-ot csatornztuk bele IPv4-be, natol router esetn. Ott Teredo-nak hvtk a mdszert, itt NAT-T-nek. A lnyeg ugyanaz: a teljes forgalmat UDP csomagokba rakjuk (portszm: 4500), s ez mr knyelmesen tmegy a NAT/PAT routerrel megerstett hlzaton.
~ 129 ~
3.24. BRA NAT-T MKDS KZBEN
3.4 .3 .4 .4 SC TP
Az IKEv2 mr tmogatja a VOIP-nl hasznlt SCTP protokollt.

3.4 .3 .4 .5 M E G B Z H A T S G S L L A P O T M E N E D Z S M E N T
Az IKEv2-ben bevezettek egy, a TCP-hez hasonl technikt: sequence s acknowledge number prok segtsgvel gondoskodnak a megbzhat csomagszlltsrl. Ennek segtsgvel felderthet az impotencia is. Ez alatt azt rtem, amikor a kommunikci gy akad el, hogy mindkt fl a msikra vr, mert azt hiszik, az van soron. Feloldsukra mg nincs szabvny, de thidal megoldsok Dead-Peer-Detection - mr lteznek.
3.4 .3 .4 .6 DO S E L L E N I V D E L E M
Az IKEv2 mr hamar meg tudja llaptani, hogy a msik fl - a requester - ltezik-e s tnyleg komolyan gondolja-e a csatornzst. A Windows Server 2008 R2, illetve Windows 7 termkek mr ismerik: az IKEv2 a ksbbiekben rszletezett VPN Reconnect fantzianev funkci rsze.
~ 130 ~
3. 4 .3 . 5 A U T H IP
Azaz Authenticated Internet Protocol. Egy olyan kiterjesztse az IKE -nek, mely kifejezetten az autentikcira megy r: Ismeri a felhasznli szint autentikcit. (Kerberos vagy tanstvny) Tud kezelni multiple credential autentikcit. Van benne asszimetrikus autentikci. s gy ltalban, az IKE-nl fejlettebb autentikcis mdszereket hasznl. Van a mdszernek egy htultje is: szigoran csak Microsoft krnyezetben mkdik, ott is csak a Vista, illetve az azutni opercis rendszerekben. Ergo nem IETF RFC, hanem bels Microsoft megolds. Fontos ltni, hogy az AuthIP egyltaln nem kompatibilis az IKEv2-vel. Olyannyira nem, hogy az AuthIP, habr ISAKMP protokollt hasznl, de teljesen ms egyszerstett - csomagtipussal.
~ 131 ~
A TCP/IP PROTOKOLL MKDSE 3.4.4 S S Z EF O G L A L S Nem nagyon szoktam fejezeteket sszefoglalsokkal zrni, de most kivtelt teszek. Egyrszt ez az IPsec tma nmagban elg kaotikus, nem rt rviden ttekinteni. Msrszt a ksbbiekben ptnk erre a tudsra, teht j, ha van egy vilgos kp egy vz - arrl, mi is ez tulajdonkppen. Teht az IPSec az egy szabvnygyjtemny. A clja az, hogy biztonsgos csatornt pthessnk ki kt kommunikl fl kztt. A biztonsg azt jelenti, hogy vagy alrjuk a csomagokat, garantlva ezzel az eredetisgket, vagy az egsz kommunikcit tikostjuk. Az elst hvjuk AH-nak, a msodikat ESP-nek. A kettt kombinlhatjuk. Mindkt mdszernek ltezik Transport, illetve Tunnel mdja. Az els inkbb a host ok kztti kommunikcira jellemz, a msodik pedig inkbb a routerek kzttire. Ahhoz, hogy akr az AH, akr az ESP mkdni tudjon, a feleknek meg kell egyeznik a kzsen ismert eljrsokat illeten. Ezt a megllapodst nevezzk SA-nak. Az IPSec kommunikcihoz kt SA-t kell ltrehozni. Az els clja a biztonsgos csatorna ltrehozsa, a msodik mr ezen a csatornn a konkrt egyeztets. Az els SA-t nevezik ISAKMP SA-nak, illetve IKE SA-nak. Mindkt esetben az ISAKMP protokollt hasznljuk, annak a csomagtipusval. Az IKE SA annyival tbb az ISAKMP SA-nl, hogy kulcscserre az Oakland Key Determination protokollt hasznlja. Az IKE szabvnycsomagnak ltezik jabb, ersen feljavtott vltozata, az IKEv2. Emellett lteznek alternatv kiterjesztett IKE megoldsok is, ilyen Windows krnyezetben az AuthIP. A msodik SA-t IPSec SA-nak nevezik. A kommunikci itt is ISAKMP csomagok segtsgvel trtnik, de mr titkostott csatornn. Windows krnyezetben az IPSec mkdst IPSec hzirendekkel szablyozhatjuk.
~ 132 ~
3.5 VPN
S TRS AI
El sem hiszed, de megint csatornzni fogunk. Azrt ejtsnk eltte pr szt arrl, hogy mit is rtnk Virtual Private Network, azaz VPN alatt. Ht, alapveten azt, amit az angol nv is sugall. Van egy vdett (private) hlzatunk s van ezen kvl a vad kls vilg. A vdett hlzatunkban mindenki bart, a social engineering mvelit mr a ports fbelvi a bejratnl, szval itt tnyleg magunk kztt vagyunk, sokkal lazbbak lehetnk. De jaj, embereink idnknt knytelenek kimerszkedni a nagyvilgba. termszetesen a laptopjaikkal meg a mindenfle ktyikkel egytt. Mondtam mr, hogy neknk borzaszt perverz embereink vannak? Kpesek arra, hogy egy fraszt nap utn a tvoli szllodbl is szeretnnek a bels hlzat lmelegben lubickolni egy cseppet. Nem is beszlve azokrl az embereinkrl, akik akr munkaidn kvl, akr azon bell a knyelmes otthonukbl szeretnnek dolgozni. Nyilvn felmerl az igny, hogyan lehetne a bels biztonsgos hlzat hatrait gy kihzni, hogy tvoli pontokra is elrjen. gy, hogy a kt pont kztt a kiszmthatatlan kzeg, az internet jelenti az tviteli kzeget. Az eddigi fejezetek alapjn nyilvn senki nem huppan fldre a meglepetstl, ha azt mondom, hogy igen, itt is valamifle csatornzsok lesznek.
3.25. BRA LTALNOS VPN SMA
Ez egy teljesen ltalnos sma. Van az eredeti IP csomagunk, ezt valamilyen varzslattal betitkostjuk. Aztn elkpzelhet, hogy rkldnk mg egy varzslatot, majd tesznk el egy jabb IP fejlcet - s ksz az j IP datagram. Mieltt belemennnk a rszletekbe, vizsgljuk meg, felptsk alapjn milyen VPN struktrkat ismernk.
~ 133 ~
3.26. BRA VPN R EMOTE A CCESS
Az els a client-server tipus, ms nven Remote Access VPN. Errl beszltnk eddig. Bolyong a kliens a klvilgban, majd egy benzinkt bfjbl megprbl a helyi wifin keresztl rcsatlakozni cgnek VPN szerverre. Ha ez sikerl neki, akkor utna gy fogja rezni magt, mintha bent lne a munkahelyn. El tud rni brmilyen bels erforrst, pldul a kpen lthat webszervert is. Az brrl nem csak a struktra olvashat le, hanem az IP cmek viszonyai is. Az eredeti IP datagramban a webszerver IP cme szerepel megclzott cmknt s a kliens IP cme feladknt. A VPN varzslat utn viszont a kls IP fejlcben a megclzott cm a VPN router cme lesz. Az fogja levenni a csomagrl a rkldtt varzslatot s tovbbtja az immr teljesen htkznapi csomagot a webszervernek. Visszafel ugyanez pepitban, csak ppen ekkor a VPN szerver varzsol s a VPN kliens tvoltja el a rontst.
~ 134 ~
3.27. BRA S ITE - TO -S ITE VPN
De nem csak ez az egy forgatknyv ltezhet. Mi van akkor, ha neknk van egy kzponti telephelynk s mellette szanaszt az orszgban 30-40 kicsi telephely? Mindegyikhez brelt vonali kapcsolatot kipteni meglehets pazarls, klnsen akkor, ha nem ltfontossg a kapcsolat minsge. Ilyenkor jhet szba az, hogy letesznk a telephelyekre egy-egy VPN szervert s gynevezett site-to-site VPN-eket ptnk ki. Ebben az esetben nem kell a kliens gpekre VPN kliens szoftvert telepteni, viszont loklis alhlzat szinten gondoskodni kell a routolsrl: ugyanis ekkor a kzpont fel nem a helyi router lesz a gateway, hanem a VPN szerver. Nzzk meg, hogyan alakulnak ilyenkor az IP cmek. Amikor a kliens feladja a csomagot, akkor a bels felad IP cm tovbbra is a sajt IP cme lesz, a bels cl IP cm pedig a webszerver. De a kls felad IP cm mr a helyi VPN szerver IP cme lesz, a kls cl IP cm pedig a tloldali VPN szerver IP cme. Nem is lehetne mskppen, hiszen a varzslst nem a kliens, hanem a VPN szerver vgzi, teszi hozz a kls IP fejlcet is a csomaghoz. A varzslst a tloldali VPN szerver szedi le, a csomag onnantl htkznapi csomagknt viselkedik. Amennyiben sajt cgnk telephelyeit ktjk ssze ilyen mdon, a kkor Intranet VPN-rl beszlnk. Ha klnbz cgek ktik ssze ilyen mdon a hlzataikat (pldul full IT outsourcing), akkor pedig Extranet VPN-rl. s akkor nzzk meg konkrtan is a varzslsokat.
~ 135 ~
A TCP/IP PROTOKOLL MKDSE 3.5.1 PPTP RFC 2637 Point-to-Point Tunelling Protocol. Akinek elkezd halvnyan derengeni, hogy de hasonlt mr ez a nv a korbban megismert PPP-hez (Point-toPoint Protocol), az nem jr messze a valsgtl.
A PPP-rl a korbban mr tbbszr is ajnlott knyvben rtam rszletesen.
Nos, a PPTP valahogy gy nz ki: A kldend cuccot PPP keretbe csomagoljuk. Ezt a PPP keretet bekapszulzzuk. A mdszer neve GRE. Az gy keletkez csomag lesz egy j IP datagram payloadja. Egy bra szz sznl is szebben beszl.
3.28. BRA PPTP CSOMAG SZERKEZETE
Induljunk ki legbellrl. Van az eredeti IP datagram. (Ez ugye ll egy IP fejlcbl s egy IP payloadbl, mely lehet ICMP csomag, UDP datagram vagy TCP szegmens.) Ezt a csomagot szeretnnk tjuttani a vad s szeszlyes interneten. Elszr belecsomagoljuk egy PPP keretbe. Emlksznk, ez egyszerre jelent tmrtst/titkostst (MPPC/MPPE), illetve egy PPP autentikcit, mely meglehetsen sokfle lehet, az egyszer PAP autentikcitl az EAP/TLS-ig. A PPP keretet mg el kell kldennk szablyos csomagknt. Ez a csomag gy fog kinzni, hogy kap egy j IP fejlcet, ahol az IP cmek a VPN struktrjnak megfelelen alakulnak ki. Az IP payload pedig egy GRE csomag. Figyelem, a GRE protokollknt kezelend, ugyanolyan kdja van, mint a TCP-nek (6), az UDP-nek (17), az ICMP-nek (1) vagy a nemrg megismert AH-nak (51). A GRE
~ 136 ~
A BIZTONSG KRDSE A TCP/IP-BEN protokoll kdja konkrtan 47 - s tnyleg protokollknt mkdik. Hogy mst ne mondjak, neki is vannak sequence illetve acknowledgment number rtkei. A PPTP-nek - az FTP-hez hasonlan - van egy control csatornja, a Control Connection. Ez sima TCP protokollon keresztl megy, a PPTP szerver az 1723-as portot hasznlja. A PPTP volt a legels VPN protokoll. A maga idejn kifejezetten jnak szmtott. Aztn jttek a bajok. A technika fejldsvel meggyenglt az MPPE titkosts. A PPP autentikcik kzl is sorra dltek ki az egyszerbbek. Vgl megjelent a kihvja, az L2TP/IPsec VPN protokoll. (Br az igazi ttrst a NAT-T bevezetse jelentette, addig ugyanis a PPTP - ha egy kis trkkzssel is ugyan - de tment a natol routereken, ezzel szemben az L2TP/IPsec nem.) 3.5.2 L2TP RFC 2661 Az L2TP az nmagban egy tunneling protokol - vagy ha gy jobban tetszik, akkor egy csatornz, avagy egy kapszulz. Ilyen rtelemben a GRE protokollal esik egy kategriba. (Az L2TP protokoll kdja 115.) s ennyi.
3.29. BRA L2TP CSOMAG SZERKEZETE
~ 137 ~
A TCP/IP PROTOKOLL MKDSE Ha sszehasonltod a korbbi brval (3.28. bra PPTP csomag szerkezete), lthatod, hogy olyan risi nagy klnbsg nincs. GRE helyett L2TP kapszulzst hasznlunk, plusz az egszet mg beletesszk egy UDP datagramba. gy ll ssze a csomag. Emltsk meg, hogy az L2TP nem csak IP protokollon keresztl mkdik, az RFC szerint rtelmezve van Frame Relay s X.25 protokollokon keresztl is. Mivel jobb ez, mint a PPTP? Biztonsg tern nem sokkal. Sem az UDP, sem az L2TP nem ad semmilyen biztonsgi pluszt a PPTP-hez kpest. Az autentikcit s a titkostst mindkt esetben a PPP vgzi. Knyelemben viszont annl inkbb van klnbsg. Itt most ne arra gondoljunk, hogy a PPP csomag Pullman kocsiban utazik. Magt a csatornt knnyebb neknk kezelni. Mind az adat, mind a control zenetek ugyanazt az UDP stream-et hasznljk, nem kell kln control TCP csatorna. Mind az L2TP kliens, mind az L2TP szerver az 1701-es UDP portot hasznlja. 3.5.3 L2TP / IPS E C J. Mi van akkor, ha mi nem csak knyelmesebbek akarunk lenni, hanem szeretnnk biztonsgosabb VPN csatornt pteni? Ekkor jn az, hogy kombinljuk az L2TP csatornt az IPSec csatornatitkost vltozatval. Ebbl lesz az L2TP/IPSec. Alaprtelmezsben a Windows Server 2008-ban nem ltezik L2TP IPSec nlkl - azaz nincs olyan vlasztsi lehetsgnk, hogy csak L2TP csatornzst szeretnnk. Ellenben olyat viszont csinlhatunk, hogy L2TP/IPSec csatornt vlasztunk, majd ksbb a registryben letiltjuk rajta az IPSec komponenst. De a szakirodalom szerint ilyet csak tesztelsi, illetve hibakeressi okokbl cselekedjnk.
3.30. BRA L2TP/IPS EC CSOMAG SZERKEZETE
~ 138 ~
A BIZTONSG KRDSE A TCP/IP-BEN Egyre bonyolultabb, mi? Annyira azrt nem kell megijedni, egyszeren csak elkezdtk egymsba cssztatni az brkat. Lthat kzpen a korbbi brrl (3.29. bra L2TP csomag szerkezete) ismers L2TP csomag. Ha gy nzzk, hogy ez egy egysg, akkor az is lthat, hogy tulajdonkppen erre az egysgre nzve itt egy IPSec ESP transzformcit hajtunk vgre, mghozz Tunnel mdban (3.20. bra ESP Tunnel md). Ezzel gyakorlatilag - az ESP Tunnelhez hasonlan - kellkppen titkostottuk s al is rtuk a csomagot. A NAT Traversal-nak ksznheten pedig manapsg mr a NAT sem akadly. Esetleg felmerlhet a krds, hogy nem rt-e meg a jbol is a sok? De bizony. L2TP/IPSec VPN csatorna esetn a PPP szint MPPE titkosts ki van kapcsolva. Gyengbb, mint az IPSec ESP, ergo felesleges. 3.5.4 SSTP Azt mondtam volna, hogy a NAT nem akadly? Nos, a helyzet azrt nem ennyire egyszer. A NAT igenis akadly. Csak ppen mr megugorhat. A gond igazbl az, hogy nem egyknnyen. PPTP esetben pldul a NAT -ba kell egy erre a clra felingerelt NAT editor. IPSec-nl meg a NAT-T. s akkor mi van a tzfalakkal? A proxy szerverekkel? A tzfalaknak engednik kell mind a GRE, mind az ESP protokollokat. Biztos, hogy egy tlagos szllodai szobban ez engedlyezve van? Ht.. A proxyk pedig nemes egyszersggel nem tmogatjk sem a PPTP-t, sem az L2TP/IPSec forgalmat. Anya, baj van. Marha biztonsgos szeretnk lenni, de ez a zord vilg nem hagyja. Pedig itt van a keznkben a helyzet kulcsa. Annyit beszltnk mr rla... ht mirt nem zavarjuk t azt a szerencstlen VPN forgalmat egy SSL/TLS csatornn? Biztonsgos? A kulcsmrettl fgg. Azaz ha nem bkjk el, akkor igen. Tzfalak, NAT routerek, proxyk? Mit kekeckednnek egy teljesen tlagos 443-as porton men forgalommal? Simn tengedik.
~ 139 ~
3.31. BRA SSTP CSOMAG SZERKEZETE
Lthat, hogy a PPP-be csomagolst most sem sszuk meg. De legalbb tudjuk, hogy becsletes VPN protokollal llunk szemben. Aztn ezt a PPP keretet dobjuk bele egy SSL titkostott HTTP csomagba. (A PPP MPPE itt is ki lett kapcsolva.) Tudni kell, hogy az SSTP abszolt nem tmogatja a site-to-site VPN-eket, azaz a csatorna mindig az SSTP kliens s az SSTP szerver kztt pl ki. Az egyetlen ismeretlen szerepl az brn az SSTP kapszulzs, illetve az ahhoz tartoz fejlc. (Hiszen a HTTPS-t mr ismerjk elg jl, a PPP-t meg szintn.)
3.32. BRA SSTP HEADER
VERSION: Az alkalmazott SSTP verziszma. RESERVED: Majd kitalljuk, mire lesz j. CONTROL: Az SSTP-nek is van Control, illetve Data zemmdja. Ez a flag jelzi, hogy az aktulis csomag melyik tipusba tartozik. LENGTH: Az els ngy bit szintn foglalt, csak mg nem tudjuk, mire. A maradk 12 bit a csomag teljes hosszt mutatja. (Header+payload)
~ 140 ~
A BIZTONSG KRDSE A TCP/IP-BEN DATA: Ha a control flag magas, akkor itt utazik a vezrlzenet. Ellenkez esetben pedig a PPP keret.
3.33. BRA SSTP C ONTROL ZENET
A PPP szerkezetet nyilvn nem fogom itt bemutatni, az mr mshol megtrtnt. A Control csomag viszont nem. MESSAGE TYPE: A Control zenet tipusa. ATTRIBUTES COUNT: A Control zenethez mennyi rtk tartozik. ATTRIBUTES: Maguk a konkrt rtkek, listaszeren. Nzzk meg egy kicsit rszletesebben is, hogyan jn ltre egy SSTP kapcsolat.
3.34. BRA SSTP KAPCSOLAT KIALAKULS A
~ 141 ~
A TCP/IP PROTOKOLL MKDSE 1. A kliens a 195.68.12.41-es IP cmrl felkeresi a szerver 86.24.15.41-es IP cmt, a 443-as porton. Ltrehoz egy TCP sessiont. 2. Ezen a session-on bell elindul egy SSL csatorna kiptse. A kliens elkri a szerver tanstvnyt a session key titkostshoz. Leellenrzi. A szerver nem ellenrzi vissza a klienst. 3. A kliens kld egy HTTPS Request-et, immr a titkostott SSL csatornban. 4. A kliens kld egy SSTP control zenetet. Ha sszeftyltek, akkor kezddhet a PPP kapcsolat kialaktsa. 5. A HTTPS feletti SSTP-ben megtrtnik a PPP kapcsolat felptse. Tudjuk, hogy MPPE titkosts itt mr nincs, autentikciban viszont a teljes PPP sklt hasznlhatjuk, belertve az EAP verzikat is (SSL-ben EAP-TLS... finom). A PPP autentikcin keresztl a szerver autentiklja a kliens felhasznlt. 6. Amint a PPP is felllt, a szmtgpeken megjelenik egy j IP cm. Az brn ezek a 10.10.100.2 a kliensnl s 10.10.100.1 a szervernl. Finito. 3.5.5 VPN R E CO N N EC T rdekes jtk ez a security. Idnknt olyan, mint egy nagy doboz Lego: elveszem a darabokat s ha gy rakom ssze, akkor kvdarl, ha mskppen, akkor meg tank lesz belle. A VPN Reconnect is ilyen legs-sszedugdoss VPN protokoll. Megfogtuk az L2TP/IPSec modellt, leszedtk rla az L2TP kockt, flretettk az UDP kockt, a megmaradt IPSec blokkban meg kicserltk az IKE SA-t IKEv2-re. Ami keletkezett, azt elneveztk VPN Reconnect-nek. Most az egyszer az tnevezsnek tnyleg volt rtelme is. Ha emlksznk, rtam, hogy az IKEv2-hez kijtt ksbb egy kiegszts MOBIKE nven. Nos, ez pont a mobil kliensek kiszolglsra hivatott. Azaz olyan kliensekre, akik nagy sebessggel mozognak, mikzben toljk az iwiw-et, VPN-en keresztl belpve a cges hlzatukba. Aztn ha mozgs kzben megszakad a kapcsolatuk, tvltanak egy msik cellra - s borzasztan nem szeretnk, ha errl brmilyen mdon is tudomst szereznnek. Azaz a VPN legyen olyan kedves, oldja meg az jracsatlakozst magtl.
~ 142 ~
A BIZTONSG KRDSE A TCP/IP-BEN Csak, hogy ne legyen egyszer az let, MS berkekben a VPN Reconnect s az IKEv2 teljesen szinonim kifejezsek. De mi tudjunk rla, hogy az egyik egy VPN protokoll, a msik pedig egy SA.
3.35. BRA IPS EC ESP T UNNEL
A csomagszerkezet bemutatsval nagyon knny dolgom volt, egyszeren idemsoltam a korbbi brt. (3.20. bra ESP Tunnel md.) Hiszen ez gyakorlatilag nem ms, mint egy mezei IPSec ESP Tunnel, ahol az els SA-t az IKEv2 hozza ltre. De azrt ne becsljk le ennyire. Nem csak a mobil kliensek kiszolglsa a nagy erssge a protokollnak, hanem az autentikis eljrsok bvlse (full EAP), illetve rncfelvarrsa is. Hogy mst ne mondjak, a VPN Reconnect esetben mr nincs szksg a VPN kliensen tanstvnyra, elg, ha a szerveren van. Nzznk nhny forgatknyvet. Mind a kliensnek, mind a VPN szervernek egyarnt van IPv4 s IPv6 cme. Ebben az esetben a VPN kapcsolat elszr az IPv6-os cmek kztt jn ltre - de ez ksbb brmikor megvltoztathat, mghozz gy, hogy a VPN megszakadst a kliens nem fogja szlelni. Ha a VPN Reconnect gy van konfigurlva, hogy szerepel benne clknt a cges VPN szervernek mind a kls, mind a bels lba, akkor simn elfordulhat, hogy Keresked Bla ppen stl be a cghez, kzben vadul gyzkdve az egyik gyfelt egy OCS alap mobil kliensrl - s nem veszi szre, hogy ahogy belpett az ajtn, a kliense immr a VPN szerver bels lbra kapcsolt t.
~ 143 ~
A TCP/IP PROTOKOLL MKDSE A cg informatikusa ppen a Teched-en koptatja a szkeket. Jrkl egyik pletbl a msikba, laptopja termszetesen a helyi wifin keresztl folyamatosan rkapcsolva a cges VPN hlzatra. Hiba stl ki az egyik Access Point hatkrbl s stl be egy msikba, hiba vltozik meg az IP cme - a VPN Reconnect csak kitart s kitart. s ez igaz akkor is, ha olyan termekbe tved a szerencstlen, ahol mr igen gyenge a wifi, ahol llandan szakadozik. A kliens nem fog neki visszaszmols reconnect ablakot feldobni, megoldja minden patlia nlkl az jrakapcsolst. Mindez nem csak a MOBIKE kvetkezmnye. Nem rszleteztem, mert ehhez egy kzel 100 oldalas RFC-t kellett volna feldolgoznom, de az IKEv2-ban - az IKEv1-hez kpest - mind koreogrfiban, mind a felhasznlhat eszkzkszletben nagyon komoly vltozsok trtntek. Pldul nem lehetne ilyen rugalmasan kezelni a hlzati vltozsokat, ha az egyes tnclpseket - autentikci, kulcscsere, csatornapts - nem gondoltk volna ennyire t, nem egyszerstettk volna le a vgtelensgig.
~ 144 ~
A BIZTONSG KRDSE A TCP/IP-BEN 3.5.6 S S Z EF O G L A L S Mg egy sszefoglals. De nem azrt, mert tlthatatlanul bonyolult lett volna a fejezet. Sokkal inkbb azrt, hogy egyms mellett lssuk, melyik VPN protokoll mit tud, hol hasznlhat optimlisan.
3.2. TBLZAT Opercis rendszer Elforduls NAT Tzfal Web Proxy Mobil tmogats Autentikci PPTP XP, 2003, Vista, WS08, W7, WS08 R2 Remote Access Site-to-site NAT editor Engedlyezs utn Non passarant Nincs User autentikci a PPP-ben L2TP/IPSec XP, 2003, Vista, WS08, W7, WS08 R2 Remote Access Site-to-site NAT-T Engedlyezs utn Non passarant Nincs Gp autentikci az IPSecben, utna user autentikci a PPP-ben SSTP Vista, WS08, W7, WS08 R2 Remote Access No problemo Legtbbszr simn Autentikci nlkl Nincs User autentikci PPP-ben a VPN Reconnect W7, WS08 R2 Remote Access NAT-T Engedlyezs utn Non passarant Van Gp vagy autentikci IKEv2-ben user az
A Microsoft ajnlsok a kvetkez klszablyokat javasoljk arra az esetre, ha olyan VPN szervernk van, mely az sszes VPN protokollt ismeri (Hall, mi is a cme a knyv msodik rsznek?), s a klienseink is leginkbb Windows7-bl llnak. A legmagasabb priorits a VPN Reconnect legyen. A kliensek mindenkppen ezt prbljk meg legelszr kialaktani. Ha mkdik, akkor sokkal jobb a tbbinl. De nem minden helyzetben mkdik. Egy webes proxy, egy tl szigor tzfal, egy NAT-T-t nem ismer natol router hamar elgzoljk a karriert. Ilyenkor prblkozzunk az SSTP-vel, az mg a falon is tmegy. (Kivve, ha felhasznli autentikcit alkalmaz WEB Proxy-val tallkozik. Az mg neki is sok.) Amennyiben pedig felttlenl site-to-site VPN kialaktsra kell adnunk a fejnket, akkor jhet az L2TP/IPSec. PPTP-t ma mr egyltaln nem ajnlott telepteni. Elmletileg elkpzelhet olyan szituci, hogy site-to-site VPN-t kell kialaktanunk, de van tkzben egy natol router, mely a NAT-T-t nem ismeri, ellenben NAT Editorral le tudja kezelni a PPTP-t... de ilyenkor rdemesebb inkbb a natol eszkzt cserlni.
~ 145 ~
3.6 A UTENTIKCI
gy vgiggondolva, elgg mostohn szoktunk bnni ezzel az autentikcival. Felbukkan itt, runk rla ott, egyik helyen ilyen mdszerekkel csinljk, msik helyen olyannal - de nll tmaknt nem nagyon szoktunk vele foglalkozni. Nem vletlenl. Az autentikci ugyanis legfkppen viszony. Valaki meg akar bizonyosodni msvalakinek/msvalaminek a valdisgrl. Jnapotkvnokjogostvnytforgalmiengedlytkrem. Vagy a diszkban az UV csuklszalag. Informatikban is nagyjbl errl van sz, de nagyon nem mindegy, ki kr, kitl kr s leginkbb mikor kr. Akr egy egyszer folyamatban is elfordulhat, hogy a csatorna kiptshez a gpek autentikljk egymst, de a gpen fut alkalmazs elrshez maga az alkalmazs is autentiklja a felhasznlt. (Pl. OWA.) Habr ugyanazt a szt hasznljuk mindkt lpsre, de a kett kztt g s fldnyi klnbsg is lehet. Msik j plda erre egy L2TP/IPSec csatorna: a csatorna kiptshez a kt host autentiklja egymst, de a VPN mgtti belps autentikcijhoz mr a PPP protokoll autentikcis mdszerei kzl valamelyikkel vizsgljuk meg a felhasznlt. s akkor nem beszltnk mg azokrl az eszkzkrl, kliens-szerver alap alkalmazsokrl, melyek kifejezetten arra lettek kinemestve, hogy egyfajta autentikcis motorknt - Authentication Provider - levegyk az autentikci feladatnak terht az gynevezett Network Access13 szerverekrl. Tbb ilyen rendszer ltezik, a Windows vilgban a RADIUS terjedt el, IAS, illetve a Windows Server 2008-ban mr NPS nven.
Tipikus NAS pldul az eddig VPN szerverknt emlegetett eszkz. Figyelem, nem keverend ssze a teljesen azonos rvidtssel br Network Attached Storage eszkzkkel.
13
~ 146 ~
A BIZTONSG KRDSE A TCP/IP-BEN 3.6.1 RADIUS RFC 2865 - s egy csom egyb
3.36. BRA RADIUS SZERVER MKDS KZB EN
1. Az odakint bolyong laptopos ember be akar lpni a munkahelyi hlzat ba. Felveszi a kapcsolatot a NAS-sal, mely jelen esetben egy VPN szerver. (De lehet RAS szerver, illetve ms szituciban egy port szint azonostst hasznl switch is.) 2. Mivel az autentikci outsourcolva lett, a VPN szerver - mint Radius kliens felveszi a kapcsolatot a Radius szerverrel. tadja neki a szksges paramtereket. (Valjban ez a lps egy kicsit bonyolultabb, a Radius szerver bizonyos esetekben mg visszakrdez, ilyenkor a NAS szerver is visszakrdez... szval maradjunk annyiban, hogy ezek itt addig varilnak, amg sszell a kldend csomag.) A Radius szerver els krben leellenrzi, hogy a Radius kliensnek egyltaln van-e joga hozz fordulni? 3. A Radius szerver sajt adatbzisbl keresi ki a felhasznlt. 4.Leellenrzi, hogy sikeres volt-e az autentikci.
~ 147 ~
A TCP/IP PROTOKOLL MKDSE Alternatv vltozat: 3.Egy kls cmtrszerverben keres r a felhasznlra. Ilyen lehet egy LDAP szerver, egy Active Directory tartomnyvezrl, de akr egy SQL szerver is. 4. A kls szerver visszajelez a Radius szervernek, hogy sikeres volt-e az autentikci. 5. A Radius szerver visszajelez a Radius kliensnek, hogy sikerlt-e, vagy sem az autentikci. 6. A NAS szerver vagy beengedi, vagy kpen trli a laptopos embert. Nos, krem, nagyjbl errl lenne sz. Tnyleg nagyjbl, mert hamarosan rszleteiben is vgig fogunk menni a folyamaton. Beszljnk egy kicsit az extrkrl. A Radius ugyanis nem csak autentiklni tud, hanem teljes rtk AAA szerver. Azaz ismeri a kvetkez funkcikat: AUTENTIKCI : Errl beszltnk eddig. Bejhetsz, vagy sem? AUTORIZCI : Ha mr bejttl, mihez van jogod? Milyen erforrs van hozzd rendelve, ezek kzl melyeket kell helybl megkapnod? ACCOUNTING : Adatokat gyjtnk: mennyi ideig hasznltad a hozzfrst? Ezen adatok alapjn az ISP pldul szmlzni tud neked. (Vagy ha van bels szmlzs a cgnl, akkor az IT a tbbi rszlegnek.) A Radius kliens s Radius szerver kztti kommunikci sorn hat klnbz csomag jelenhet meg: ACCESS-REQUEST A Radius kliens kldi a Radius szervernek. Jelzi, hogy autentikcis s autorizcis ignye van. Ebben az zenetben utazik a NAS ltal sszelltott autentikcis csomag. ACCESS-CHALLENGE Amennyiben olyan az autentikci tipusa, hogy a Radius szervernek plusz informcikra van szksge, akkor ebben a csomagban jelez vissza a Radius kliensnek. (Tipikusan ilyesmi trtnik a challange-response tipus autentikcik esetn.)
~ 148 ~
A BIZTONSG KRDSE A TCP/IP-BEN ACCESS-ACCEPT A Radius szerver visszajelez a kliensnek, hogy az autentikci sikeres volt. ACCESS-REJECT A Radius szerver visszajelez a kliensnek, hogy az autentikci sikertelen volt. ACCOUNTING-REQUEST A Radius kliens jelez a szervernek, hogy accounting informcikat ad meg. ACCOUNTING-RESPONSE A Radius szerver jelez vissza a kliensnek, hogy tudomsul vette a jelzst s fel is dolgozta. Ejtsnk mg pr mondatot errl az accounting folyamatrl. Amikor ltrejtt a kapcsolat, azaz a laptopos ember belpst nyert a bels hlzatba, a Radius kliens kld egy ACCOUNTING-REQUEST zenetet a Radius szervernek. Ez az zenet jelzi, hogy el kell indtani egy accounting folyamatot, megadja, milyen szolgltats lett ignybevve s kicsoda ltal. Erre jelez vissza a Radius szerver egy ACCOUNTING-RESPONSE zenettel, miszerint az accounting folyamat rgztse megtrtnt. Amikor vget rt egy kapcsolat, a Radius kliens kld egy jabb ACCOUNTING-REQUEST csomagot, benne egy Accounting Stop zenettel. Ebben az zenetben van benne minden lnyeges informci: ki volt, milyen szolgltatsokat vett ignybe, mennyi ideig hasznlta, mindenfle statisztikk, letlttt/feltlttt bjtok... meg ilyesmik. A Radius szerver mindezeket befogadja, lelltja az accounting folyamatot s minderrl rtesti a klienst egy jabb ACCOUNTING-RESPONSE csomaggal. Mind a hat csomag UDP-ben utazik. A Radius szerver tipikusan a 1812-es porton figyel az autentikcis zenetekre s a 1813-ason az accounting zenetekre.
3.37. BRA R ADIUS CSOMAG
~ 149 ~
A TCP/IP PROTOKOLL MKDSE CODE: A Radius zenet tipusa. IDENTIFIER: Egy azonost, mely az egymshoz tartoz zeneteket kapcsolja ssze. ltalban igaz, hogy a Response zenetben ebbe a mezbe a request zenetben lv kdot msoljk t. LENGTH: A teljes Radius zenet hossza. AUTHENTICATOR: Egy olyan mez, melyben egy titkostott jelsz (kzs titok) utazik. A Radius kliens szokta visszaellenrizni ezzel a Radius szervert. ATTRIBUTES: Minden, mi szem-szjnak ingere. Minden lnyeges, az autentikcit, az autorizcit s accountingot rint informci ebben a mezben utazik.
3.38. BRA R ADIUS A TTRIBUTES
Minden attribtumnak van egy tpusa, mivel az attribtumok hossza nem rgztett, gy nyilvn fontos paramter a hossz is, az rtk mezben pedig mr a konkrt informcik utaznak. A felsorolsuktl eltekintek, hihetetlenl sok van bellk.
Akit rdekel: http://www.iana.org/assignments/radius-types
Annyi van bellk, hogy mr csak vgiggrgetni a kpernyn is pp elg fraszt. Pedig ez mg nem is az sszes, ezek csak az ltalnos attribtumok. Kln kategrikba esnek az gynevezett vendor-specifikus attribtumok. Ezek a 26-os tipus attribtum alatt jelennek meg, gyakorlatilag al-attribtumknt. Ezeknek a felsorolst is kihagyom.
A vendorok listjt itt tallhatjuk: http://www.iana.org/assignments/enterprise-numbers
RFC 2548 Vgl a fenti RFC-ben talljuk a Microsoft, mint vendor ltal hasznlt plusz Radius attribtumokat.
~ 150 ~
A BIZTONSG KRDSE A TCP/IP-BEN 3.6.2 K T F AK T O R O S

A UT EN T I K CI
A fenti brn (3.36. bra RADIUS szerver mkds kzben) az a Stt L nev szmtgp nem csak gy viccbl kerlt oda. Ugyanis nem csak egyszeres autentikcit nyjt Authentication Provider szerverek (Radius, Takacs) lteznek a vilgban. Vannak olyanok is, amelyek kpesek a ktfaktoros autentikcira. Jogos lehet a krds, hogy mi is ez a ktfaktoros autentikci s miben klnbzik mondjuk a Ktfark Kutya prttl? Mint lthat, a Radius csak egyszeres autentikcit nyjt. Azaz ellenrzi a felhasznl nevt, jelszavt... oszt jl van. A ktfaktoros autentikcihoz ez kevs. Oda kell mg egy olyan elem, egy fizikailag is megfoghat elem, mely az egyszeres autentikcival egytt adja meg a belps lehetsgt. Ahogy az angol mondja, "something you have, something you know", azaz van valamid s tudsz valamit. Ilyenekre gondolok: Kliens tanstvny smartcard-on. Valami OTP. Az els esetben a felhasznl betolja smartcardot a gpbe, megprbl rcsatlakozni a szupertitkos weblapra, beti a usernevt, jelszavt, az autentikcis eljrs felolvassa a tanstvnyt - s ezek egyttes autentikcija adja meg a hn htott belpst. A msik mr jval cifrbb. RFC 2289 Elszr is, nem, nem a nagy magyar bankrl van sz. Az OTP a One -Time Password rvidtse. Az elv lnyege, hogy a felhasznl egy jelszt csak egyszer hasznl. Hogy lesz ebbl ktfaktor autentikci? Nzzk a legegyszerbb OTP rendszert. A felhasznl kap egy nyomtatott, szmozott listt, rajta sorban egy csom jelsz. Mindegyikkel csak egyszer lehet belpni, s csak a megadott sorrendben lehet felhasznlni a jelszavakat. Ekkor a felhasznl berja a usernevt, a hagyomnyos jelszavt (eddig tartott a 'valamit tudsz' komponens), majd elveszi a paprlapot s kikeresi a legels, mg nem thzott jelszt, majd azt is berja egy msik rubrikba. (Maga a papr a 'valamid van' komponens.)
~ 151 ~
A TCP/IP PROTOKOLL MKDSE Habr ezt a mdszert mg manapsg is hasznljk webes banki elrsekre, de azrt ennl mr lteznek elegnsabb mdszerek. Ezek mind valamilyen kls hardver komponensen alapulnak. De mieltt belemennnk a ktyk ismertetsbe, beszljnk arrl, hogyan is keletkeznek ezek a jelszavak. Mert ezek keletkeznek, nem pedig a kzponti IT tlti fel a listt az eszkzre, mieltt kiadja. (Mellesleg ezeket a generlt kdokat mr nem jelszavaknak hvjk, hanem passcode-nak.) A passcode generlsa a pontos idn alapul. Ehhez nyilvn kell egy pontos ra is az eszkzben. Innentl kezdve csak az algoritmus krdse, hogy a szerveren is ugyanaz a passcode generldjon, mint a ktyben. A mdszer elnye, hogy a kd csak rvid ideig hasznlhat. A passcode generlsa a matekon alapul. Ekkor a ktybe az els kdot mg a rendszergazda fik tltik be, a kvetkezk pedig mindig az elzekbl keletkeznek egy jl definilt algoritmus alapjn. Nzzk akkor az eszkzparkot. A nyomtatott paprrl mr beszltem. A msik leginkbb kzenfekv eszkz a mobiltelefon. Ez az eszkz radsul ktflekppen is hasznlhat. Az egyik szerint teleptnk r egy clszoftvert, mely kpes legenerlni az ppen aktulis kdot. A msik szerint nem teleptnk semmilyen szoftvert, hanem amikor a felhasznl begpeli a usernevt s a jelszavt, akkor kldnk neki egy kdot SMS-ben a hozz regisztrlt mobiltelefonra. Vgl itt van a tokenhadsereg. Tucatnl is tbb gyrt gyrt ma mr egymssal nyilvn nem kompatibilis rendszereket, mindegyik a maga tokenjt hasznlva. A token egy kis hardverkty, mely gombnyomsra kiadja a kvetkez kdot. Ha id alap, akkor pontos ra kell bele, ha matekozs, akkor indul passcode. Trjnk vissza arra a Stt Lra s a Windows vilgba. A ktfaktor autentikcit ktflekppen tudjuk megvalstani: A Radius szerver felturbzsval. Ezt nevezzk Radius-OTP megoldsnak. A kls gyrt OTP Manager szervervel. Na, ez a Stt L.
~ 152 ~
A BIZTONSG KRDSE A TCP/IP-BEN Ha megnzzk pldul az ISA2006 szerver esetben a vlaszthat ktfaktor autentikcikat, akkor ezeket ltjuk: Tanstvny alap Radius OTP RSA SecureID A Radius-OTP esetben nincs nagy vltozs az brn, egyszeren a Radius szervert kicserljk egy Radius-OTP szerverre s minden megy tovbb a maga tjn. Az RSA SecureID esetben viszont mr ms egy kicsit a helyzet.
3.39. BRA RSA S ECURE ID
1. A kliens kld egy krst az RSA Agent fel. Legyen ez egy ISA2006 szerver, ahol form-based autentikci van belltva, azaz a Form-Based Authentication Filter aktivizlja magt. 2. A filter visszatol egy formot a kliensnek. Tcsdki - mondja. Ez a form hromfle is lehet, attl fggen, hogy mit krnk: USERNV, JELSZ: Ez speciel nem a mi esetnk, ekkor ugyanis nincs OTP autentikci. USERNV, PASSCODE: Ez mr OTP, de csak egyfaktor. USERNV, JELSZ, PASSCODE: Igen, ez az igazi ktfaktor autentikci. 3. A kliens kitlti a formot s egy HTTP POST paranccsal visszakldi.
~ 153 ~
A TCP/IP PROTOKOLL MKDSE 4. Az RSA Agent tovbbtja az autentikcis csomagot az RSA Authentication Manager szereplnek. 5. Az RSA Authentication Manager molyol rajta egy sort. 6. Visszakldi az eredmnyt az RSA gynknek. 7. Ha nem sikerlt az autentikci, akkor az gynk kld egy HTTP COKI zenetet a kliensnek. Amennyiben sikerlt az autentikci, akkor viszont egy HTTP COOKIE -t kld. Azaz ekkor mg nincs direkt beengeds. Ez a sti tartalmazza a kliens autentikcis adatait, mghozz gy betitkostva, hogy csak az RSA Agent tudja elolvasni. Emellett a sti mg gy van paramterezve, hogy tilos a merevlemezen trolni. Csak a kliensgp memrijban lesz jelen. De ezzel mg nincs vge. Az RSA Agent kld a csomagban egy REFRESH fejlcet is, ezzel knyszertve a klienst, hogy prblja meg jra a behatolst. 8. A kliens meg is prblja. s igen... mivel most mr van egy csodakukija, az RSA Agent beengedi. Azt krdezed, mi volt ez a matyhmzs itt a vgn a stivel? OTP, krem szpen, OTP. A kliens csak egyszer adhat meg egy passcode-ot, tbbszr nem. Mi van akkor, ha akrmirt is jra kell autentiklni? Mondjuk, egy jabb krsnl? (Aztn Single-Sign-On, hogy mst ne mondjak.) Ilyenkor igazbl az RSA gynkt nem az rdekli, hogy van-e mg jabb passcode-ja a kliensnek, hanem megelgszik azzal az informcival, hogy egyszer mr volt egy rvnyes. (Ezrt kell a stit csak a memriban trolni. Hogy annyira sokig azrt ne ljen ez a sttusz.) Egy utols gondolat. Van a kpen egy webszerver. Most lett a stt l. Mit keres ez egyltaln itt? Ht, egyelre csak errefel llkodik. De ebbl az adok-kapokbl leeshet neki is. Ezt gy hvjk, hogy Authentication Delegation. Vagy ms kifejezssel gy, hogy Publishing Rules. Ugye, ismers? De ez mr egy msik knyv tmja.
~ 154 ~
KIVEZETS
4 K IVEZETS
Minden normlis knyvben arra szokta buzdtani a szerz a kedves olvast, hogy ha krdse van, akkor ne hezitljon, tegye fl btran. Ez ilyen szempontbl is rendhagy knyv. n azt mondom, hogy eszed gban se legyen tlem brmit is krdezni. Nem azrt, mert n egy undok vadmalac vagyok... hanem azrt, mert ez egy alulrl korltos knyv. Elmagyarzom. Aki van annyira btor, hogy knyvet r, annak nagyon kell tudnia. Ezt a tudst legtbbszr nem is tudja teljesen kirni magbl. Mr nyomdban van a knyv, amikor eszbe jut, hogy ez is kimaradt, meg az se lett teljesen kibontva. Azaz ha brki krdez valamit, ami nem kerlt bele a knyvbe, a szerz magtl rtetden el tudja magyarzni. Ez a fellrl korltos knyv. Ilyen volt az Exchange 2007-rl szl knyvem. Ennek a mostani knyvnek mr a legelejn jeleztem, hogy rendhagy kisrletre kszlk. Olyan terletrl rok, amelyhez nem rtek. Pontosabban rtek valamennyire, de messze nem annyira, mint amilyen mlyen el akarok merlni a tmban. Menetkzben tanulok... s a megrtett dolgokat gyermeki rmmel adom t, mint megannyi jdonsgot. Lertam mindent, amit tudok... st valjban tbbet is rtam le, mint amit tnylegesen tudok. Hiszen a keretek s datagramok szerkezett, a szabvnyok lnyegt n is kziknyvekbl, weblapokrl szedtem ssze. Ergo ez egy alulrl korltos knyv. Krdezni krdezhetsz, persze... de n is csak annyit tudok tenni, amennyi neke d is rendelkezsedre ll: gugli vagy bing. Ellenben ha te a tma szakrtje vagy s csak a viccek miatt olvastad vgig a knyvet, aztn gy talltl benne ordt hibkat - nos, te ne ttovzz, rd meg ezeket egybl a jpetrenyi@gmail.com cmre. Az online megjelensnek ugyanis pont az az risi elnye, hogy a tartalom mdosthat, aktualizlhat. A vgre egy j hr: a knyv mkdik. Amikor gyjtttem az anyagot, szp lassan kezdett rthet lenni a TCP/IP mkdse. Amikor rtam a knyvet, mr azt hittem, hogy rtem - csak ekkor mg darabokban lttam mindent, hiszen ebben a fzisban a rszletek kidolgozsa volt a jellemz. s amikor lektorlskor olvastam el egyben az egszet, akkor llt csak ssze a teljes kp. De sszellt.
~ 155 ~
5 F ORRSOK , LINKEK
Ez a knyv gy kszlt, hogy elolvastam hozz RFC-ket, izmos kziratokat - majd ahol gy reztem, hozzolvastam a netrl is. Rengeteg link gylt ssze a vgre. Ezeket a linkeket talljtok meg a ebben a fejezetben, minimlisan strukturlva. SZAKKNYVEK: Alapveten ezekre az rott forrsokra tmaszkodtam: Joseph Davies: Windows Server 2003 TCP/IP Fundamentals for Microsoft Windows Joseph Davies: Windows Server 2008 TCP/IP Fundamentals for Microsoft Windows Joseph Davies, Tony Northrup with the Microsoft Networking Team: Windows Server 2008 Networking and Network Access Protection (NAP) Joseph Davies: Windows Server 2008 TCP/IP Protocols and Services Stephen Thomas: HTTP Essentials RFC A tiszta forrs, ahol minden megvan:
http://tools.ietf.org/html/ http://www.rfc-editor.org/rfc.html http://www.networksorcery.com/enp/ http://en.wikipedia.org/wiki/Request_for_Comments
KIEMELT LINKEK: mICK publikcii:

http://inetcom.hu/mick/publikaciok/aktivpasszivftp.htm http://inetcom.hu/mick/publikaciok/ipsecnat.htm http://inetcom.hu/mick/publikaciok/https.htm http://inetcom.hu/mick/publikaciok/vpn1.htm http://inetcom.hu/mick/publikaciok/vpn2.htm http://inetcom.hu/mick/publikaciok/ipsec1.htm http://inetcom.hu/mick/publikaciok/ipsec2.htm http://inetcom.hu/mick/publikaciok/ipsec3.htm http://inetcom.hu/mick/publikaciok/ipsecports.htm http://inetcom.hu/mick/publikaciok/mime1.htm http://inetcom.hu/mick/publikaciok/mime2.htm http://inetcom.hu/mick/publikaciok/mime3.htm
TCP/IP Guide:
http://www.tcpipguide.com
~ 156 ~
FORRSOK, LINKEK Internetworking Technology Handbook:

http://www.cisco.com/en/US/docs/internetworking/technology/handbook/ito_doc.html
TCP/IP Networks:
http://www.citap.com/documents/tcp-ip/tcpip001.htm
Protocols Directory:
http://www.protocols.com/protocols.htm
Internetworking Guide:
http://technet.microsoft.com/en-us/library/cc951210.aspx
WINDOWS SERVER 2008 S VISTA New Networking Features in Windows Server 2008 and Windows Vista
http://technet.microsoft.com/en-us/library/bb726965.aspx
Windows Server 2008 Networking:

http://technet.microsoft.com/en-us/library/cc753940(WS.10).aspx
Windows Vista Networking Tecnologies:

http://en.wikipedia.org/wiki/Windows_Vista_networking_technologies
MLESZTETT LINKEK Vgl mlesztve egy csom link abbl a segdfjlbl, ahov menetkzben szrtam a hasznos infkat tartalmaz tallatokat.
http://en.wikipedia.org/wiki/Http http://www.w3.org/Protocols/ http://www.ietf.org/rfc/rfc2616.txt http://en.wikipedia.org/wiki/List_of_HTTP_status_codes http://en.wikipedia.org/wiki/List_of_HTTP_headers http://en.wikipedia.org/wiki/Ftp http://en.wikipedia.org/wiki/SSH_file_transfer_protocol http://en.wikipedia.org/wiki/FTPS http://www.eventhelix.com/RealtimeMantra/Networking/FTP.pdf http://en.wikipedia.org/wiki/Smtp http://en.wikipedia.org/wiki/Extended_SMTP http://www.vanemery.com/Protocols/SMTP/smtp.html http://en.wikipedia.org/wiki/E-mail http://www.xs4all.nl/~ace/X-Faces/ http://content.hccfl.edu/pollock/Unix/EmailNotes.htm http://www.opinionatedgeek.com/dotnet/tools/Base64Decode/Default.aspx http://technet.microsoft.com/en-us/library/cc959828.aspx http://technet.microsoft.com/en-us/library/cc959829.aspx http://technet.microsoft.com/en-us/library/cc959833.aspx http://technet.microsoft.com/en-us/library/cc959827.aspx http://technet.microsoft.com/en-us/library/cc958813.aspx http://www.iana.org/assignments/message-headers/perm-headers.html http://209.85.135.132/search?q=cache:vcwrTogaB9UJ:www.avolio.com/columns/Emailheaders.html+x+header+smtp&cd=1&hl=en&ct=clnk&gl=hu
~ 157 ~

http://gsexdev.blogspot.com/2004/08/using-x-headers-with-exchange.html http://en.wikipedia.org/wiki/Ftp http://en.wikipedia.org/wiki/Telnet http://en.wikipedia.org/wiki/Secure_Shell http://en.wikipedia.org/wiki/Pop3 http://de.wikipedia.org/wiki/SMTPS http://technet.microsoft.com/en-us/library/cc754104(WS.10).aspx http://technet.microsoft.com/en-us/library/bb430764.aspx http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/809552a33473-48a7-9683-c6df0cdfda21.mspx?mfr=true http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/be0529236022-4007-833f-587c2fa33e78.mspx?mfr=true http://msdn.microsoft.com/en-us/library/cc251568(PROT.13).aspx http://technet.microsoft.com/en-us/library/cc730981(WS.10).aspx http://technet.microsoft.com/en-us/library/cc733010(WS.10).aspx http://www.javvin.com/protocolHTTPS.html http://en.wikipedia.org/wiki/Ftps http://en.wikipedia.org/wiki/E-mail_encryption http://en.wikipedia.org/wiki/Pretty_Good_Privacy http://en.wikipedia.org/wiki/S/MIME http://en.wikipedia.org/wiki/STARTTLS http://www.windowsecurity.com/articles/Securing_Data_in_Transit_with_IPSec.html http://en.wikipedia.org/wiki/IPsec http://en.wikipedia.org/wiki/Internet_Key_Exchange http://en.wikipedia.org/wiki/AuthIP http://en.wikipedia.org/wiki/ISAKMP http://www.iana.org/assignments/protocol-numbers/ http://blogs.technet.com/rrasblog/archive/tags/IKEv2/default.aspx http://blogs.technet.com/rrasblog/archive/tags/SSTP/default.aspx http://www.microsoft.com/downloads/details.aspx?familyid=7E973087-3D2D-4CAC-ABDFCC7BDE298847&displaylang=en http://en.wikipedia.org/wiki/Sstp http://technet.microsoft.com/en-us/library/cc771298(WS.10).aspx http://www.isaserver.org/tutorials/Configuring-TMG-Beta-3-SSTP-VPN-Connections-Part1.html http://blogs.technet.com/rrasblog/archive/2007/01/10/how-sstp-based-vpn-connectionworks.aspx http://en.wikipedia.org/wiki/RADIUS http://en.wikipedia.org/wiki/One-time_password http://blogs.isaserver.org/pouseele/2006/12/26/playing-with-radius-authentication-and-isaserver-2006/ http://en.wikipedia.org/wiki/Base64 http://en.wikipedia.org/wiki/MIME http://technet.microsoft.com/en-gb/magazine/2009.07.cableguy.aspx
~ 158 ~
JAVTSOK
6 J AVTSOK
Hah... milyen szp tiszta fehr mg ez az oldal.
~ 159 ~
7 A SZERZ
Itt szeretnk adni az rzsnek. Mrmint az exhibicionizmus nevnek. Valamikor vegyszmrnknek kszltem, st, meglep mdon mg diplomt is kaptam belle. Pr vnek kellett csak eltelnie s trsasgban mr azt bizonygattam, hogy a kn-monoxid sokkal veszlyesebb, mint a kn-dioxid. Ha jt akarsz magadnak, nem engem krdezel meg arrl, mely anyagok mrgezek. Valjban soha nem is tekintettem magamat vegysznek: az utols kt vet a veszprmi egyetem kibernetika tanszkn tltttem - s aki ismeri a helyet, tudja, hogy akkoriban arrafel tanyztak az gszemek, az elhivatott rendszeresek... azaz a Rendszermrnk szakos hallgatk. Gyakorlatilag neknk csak a testnevels s a nyelvi rinkon nem volt matek - az sszes tbbin tisztn. Modelleztnk (matek), optimalizltunk (lineris/nemlineris algebra), mindezeket szmtgpre vittk (numerikus matek), elemeztk (statisztika, valsznsgszmts)... kikapcsoldskppen ipari/ltalnos szmtstechnikt, ipari/kisgpes/nagygpes programozsi nyelveket tanultunk. A hab a tortn a fizikai kmia volt, melyet gondolom az egyetem vegyipari jellege miatt csempsztek bele lczskppen a tanrendbe, de nlunk azt is statisztikus alapon oktattk. Ehhez kpest az els munkahelyemen, a veszprmi IKV tvftsi rszlegn mindsszesen egy darab C128-as szmtgp volt. Arra kellett gyviteli szoftvereket. fejlesztenem. Mondjuk, mg j, hogy nem a fnk Casio menedzserkalkultorra14.
A geek vonal egybknt mr korn kitkztt. Az els programozhat zsebszmolgpem Stylandia, egy szgyentelen tajvani koppints - 48 lpst ismert. Erre gyrtottam klnbz programokat, gy, hogy a gombnyomsokat cetlikre rtam fel. Klnsen bszke voltam a msodfok egyenlet megoldkpletre - h, mondtam mr, hogy 48 lps? - s a Stirling formulval megvalstott faktorilis szmolsra. Ez utbbi ugyanis kpes volt a 69-nl nagyobb szmok esetben is faktorilist szmolni.
14
~ 160 ~
A SZERZ Aztn jtt a rendszervltozs, a tancsi rendszer felbomlott, az IKV szintn - s ahogy a tvfts nll cg lett, megszabadultunk az sszes kontraszelektlt idittl. Innentl kezdve tnyleg informatikval foglalkoztam, rendszerpts, gyvitelszervezs, zemeltets, programozs (Clipper/Pascal), hlzat. Ahogy egy kis cgnl szoks az ilyesmi. Az OOP mr az zemeltetsi oldalon tallt15. Nem szndkosan lltam t, egyszeren a kvetkez munkahelyemen erre a tudsra volt szksg. Ha fejlesztt kerestek volna, akkor ma fejlesztenk. A szakmai karrierem 2002-ben indult be igazn, amikor egy csoportos lepts eljtkaknt kirgtak a munkahelyemrl. J tz hnapig kerestem j munkahelyet. Ekkor fogadtam meg, hogy ilyesmit tbbszr nem engedlyezek a sorsnak. Rgyrtam a szakmra, tanultam, mint az rlt, sorra nyomtam a - valdi - vizsgkat, a cgemnl is szpen haladtam elre, kaptam az egyre izgalmasabb feladatokat. 2005 krl vgtam bele egy szakmai/civil blogba, az itteni szakmai rsok keltettk fel ksbb a Microsoft figyelmt. gy lettem a Technet Magazin egyik rendszeres szerzje. Innentl szpen aprnknt pltek egymsra a dolgok: cikkek, blogbejegyzsek, oktatsi anyagok... kzben egy MVP cm... majd egy Exchange 2007 knyv, mely eredetileg Netacademia produkcinak indult, de a kzirat vgl a Microsoft Magyarorszgnl landolt. Erre a mostani knyvre mr a Microsofttl kaptam a megbzst - s ahogy most kinznek a dolgok, valsznleg nem ez lesz az utols. Vgl lljanak itt az elrhetsgek: Szakmai blog: EMAIL S A DETEKTVEK : MICROSOFT TECHNET PORTL : Privt blog MI VAN VELEM? Email: jpetrenyi@gmail.com
http://emaildetektiv.hu http://tinyurl.com/ydmbgdk
http://mivanvelem.hu
15
Ha csak nem szmtjuk a kicsit bncska objektumorientlt Clippert, a CA -VO-t.
~ 161 ~

Tcpipalapok 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tcpipalapok 2

Uploaded by

Copyright:

Available Formats

Windows Server 2008

Microsoft Magyarorszg 2010

HTTP Response ____________________________________________________________ 23

2.2.3.1 2.2.3.2 2.2.3.3 2.3 2.3.1

2.3.2 2.3.3 2.4 2.5

Az elektronikus levelek szerkezete, azaz IMF ___________________________ 48 Levelezznk mr vgre! ___________________________________________________ 68

2.5.1 2.5.2 3 3.1 3.2

A biztonsg krdse a TCP/IP-ben_________________________________________________ 90 SSL, TLS __________________________________________________________________________ 90 SSH _______________________________________________________________________________ 95

FTP _________________________________________________________________________ 111

3.3.2.1 3.3.2.2 3.3.2.3 3.3.3 3.4 3.4.1

IPSec ____________________________________________________________________________ 116 3.4.1.1 3.4.1.2

Encapsulating Security Payload _________________________________________ 120

Security Associations _____________________________________________________ 124

VPN s trsai ___________________________________________________________________ 133

Autentikci ____________________________________________________________________ 146

RADIUS ____________________________________________________________________ 147 Ktfaktoros autentikci _________________________________________________ 151

A TCP/IP PROTOKOLL MKDSE

AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI

2 A Z ALKALMAZS RTEG W EBES PROTOKOLLJAI

2.1. BRA E GY GOPHER OLDAL http://en.wikipedia.org/wiki/Gopher_(protocol)

2.2. BR A A HTTP CSOMAGOK HELYE

AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI

2.3. BRA L EKRTEM AZ INDEX NYITLAPJT

2.4. BRA HTTP KLIENS - SZERVER KOMMUNIKCI

AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI

2.5. BRA F OLYAMATOS KAPCSOLAT

A TCP/IP PROTOKOLL MKDSE

2.6. BRA P IPELINE

AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI

2.7. BRA J AVASCRIPT AZ INDEXEN

2.8. BRA A WEBLAP FORRSA KONTR A CAPTURE

Aki szeret bogarszgatni, az innentl el lesz egy darabig az j jtkkal.

2.9. BRA HTTP TSVLTS

AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI

2.10. BRA M EGJELENIK A COOKIE

2.11. BRA S TI A MIVANVELEM OLD ALHOZ

2.12. BRA S TITR

2.13. BRA HTTP REQUEST

Hivatalosan a HTTP Request ngy rszre oszthat.

2.14. BRA A HTTP R EQUEST ELEMEI

A TCP/IP PROTOKOLL MKDSE

AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI 2.1.2 HTTP R E SP O N S E

2.15. BRA HTTP R ESPONSE

A HTTP Response felptse nagyon hasonl a krs felptshez.

2.16. BRA A HTTP VLASZ SZERKEZETE

A TCP/IP PROTOKOLL MKDSE

Alapveten t nagy kategria ltezik.

Minden klnsebb magyarzat nlkl lljanak itt az egyes kdok:

AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI

A TCP/IP PROTOKOLL MKDSE

Milyen autentikcis mdszert kell hasznlni a krt tartalom elrshez.

A TCP/IP PROTOKOLL MKDSE

AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI 2.2.1 FTP

2.17. BRA FTP PARANCSSORBL

2.18. BRA FTP GRAFIKUS KLIENSBL

A TCP/IP PROTOKOLL MKDSE 2.2.2 FTP

AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI

A TCP/IP PROTOKOLL MKDSE

2.19. BRA A KTV FTP KLIENS

AZ ALKALMAZS RTEG WEBES PROTOKOLLJAI

2.20. BRA PORT R EQUEST

2.21. BRA D ATA FORGALOM

A TCP/IP PROTOKOLL MKDSE

Az elektronikus levelek szerkezete, azaz IMF _ 48 Levelezznk mr vgre! _________________________ 68

A biztonsg krdse a TCP/IP-ben_ 90 SSL, TLS 90 SSH _________________________________ 95

RADIUS ____________________ 147 Ktfaktoros autentikci _ 151

X-Face: Xw|'+}IE3RcO/4u;MCw_rVT6OB<-PgDq{'[qF%;xVX;,S9g9:c#LRRtVhOl'+uZ&Ial.?6]1IjF^vvo:T<D+:[(_Z+Cp};:9Zotv Or<(#4RP7aF[JT?p9MjTCGa3kP'2C;?ILRb+QYx~WO6{Ala1;v9^2_.BDdnY/.^8PeD3SKJY=',t2vXpx7m;Z>xr@C*,<ND6W?uokQW ;.QsPuk>WaFwl7'ig[9

X-Face: K?^RDm#'Ec,&g%3z!blP\np<Az>B]y~Y!(oHZmR7#Jf4{r(s&5@ dKAm5G4'6U'p[id6U$z<0+)=LMn^2J+yohN"Pk@7zd;0I8V~AB ynvf5xL|B9r<cFfBxFpWjP+fQTwv5rd'A+HE%pH(k'F9T~6Srp U7Ifl+;eGh6|}