r04.pdf

(110 KB) Pobierz
QPrint
PROTOKOýY TRANSPORTU
PORTY Î krtki przeglĢd
Copyright ¨: JaRo
1. Standardowe protokoþy internetowe
1.1. TCP Î Transmission Control Protocol
Aplikacje, dla ktrych istotne jest, Ňeby dane niezawodnie dotarþy do celu,
wykorzystujĢ protokþ TCP. Zapewnia on prawidþowe przesyþanie danych we
wþaĻciwej kolejnoĻci. Nie zastħpuje on protokoþu IP, lecz wykorzystuje jego
wþaĻciwoĻci do nadawania i odbioru.
TCP jest niezawodnym protokoþem transmisyjnym, zorientowanym poþĢczeniowo.
Komputer po upþywie okreĻlonego czasu wysyþa dane ponownie aŇ do chwili, gdy
otrzyma od odbiorcy potwierdzenie, Ňe zostaþy poprawnie odebrane.
Jednostka czasu, ktrĢ posþugujĢ siħ we wzajemnej komunikacji moduþy TCP, nosi
nazwħ segmentu. KaŇdy segment zawiera przy tym automatycznie sumħ kontrolnĢ,
ktra podlega weryfikacji po stronie odbiorcy. W ten sposb sprawdza siħ, czy dane
zostaþy odebrane poprawnie.
TCP jest zorientowany na poþĢczenia. Protokþ tworzy zatem poþĢczenie logiczne
komputer-komputer. W tym celu wysyþa przed rozpoczħciem wþaĻciwej transmisji
danych uŇytecznych pewnĢ iloĻę informacji kontrolnych, nazywanych handshake.
Handshake wykorzystywany w TCP to 3-Way-Handshake, poniewaŇ w jego trakcie
wymieniane sĢ trzy bloki informacji. NawiĢzywanie poþĢczenia rozpoczyna siħ od
tego, Ňe oba komputery ustalajĢ wartoĻę poczĢtkowĢ sekwencji numerycznej Î Initial
Sequence Number (ISN). Oba systemy TCP wymieniajĢ miħdzy sobĢ i potwierdzajĢ te
wartoĻci.
1.1.1. 3-Way-Handshake
NawiĢzywanie poþĢczenia za pomocĢ 3-Way-Handshake moŇna przedstawię
w postaci diagramu. Za pomocĢ odpowiedniego polecenia poþĢczenie przechodzi
w tryb Listen, w ktrym moŇna nawiĢzaę kontakt z innym systemem TCP.
151793785.102.png 151793785.113.png 151793785.124.png 151793785.135.png 151793785.001.png 151793785.012.png 151793785.023.png 151793785.034.png 151793785.045.png 151793785.056.png 151793785.058.png 151793785.059.png 151793785.060.png 151793785.061.png 151793785.062.png 151793785.063.png 151793785.064.png 151793785.065.png 151793785.066.png 151793785.067.png 151793785.068.png 151793785.069.png 151793785.070.png 151793785.071.png 151793785.072.png 151793785.073.png 151793785.074.png 151793785.075.png 151793785.076.png 151793785.077.png 151793785.078.png 151793785.079.png 151793785.080.png 151793785.081.png 151793785.082.png 151793785.083.png 151793785.084.png 151793785.085.png 151793785.086.png 151793785.087.png 151793785.088.png 151793785.089.png 151793785.090.png 151793785.091.png 151793785.092.png 151793785.093.png 151793785.094.png 151793785.095.png 151793785.096.png 151793785.097.png 151793785.098.png 151793785.099.png 151793785.100.png 151793785.101.png 151793785.103.png 151793785.104.png 151793785.105.png 151793785.106.png 151793785.107.png 151793785.108.png 151793785.109.png 151793785.110.png 151793785.111.png 151793785.112.png 151793785.114.png 151793785.115.png 151793785.116.png 151793785.117.png 151793785.118.png 151793785.119.png 151793785.120.png 151793785.121.png 151793785.122.png 151793785.123.png 151793785.125.png 151793785.126.png 151793785.127.png 151793785.128.png 151793785.129.png 151793785.130.png 151793785.131.png 151793785.132.png 151793785.133.png 151793785.134.png 151793785.136.png 151793785.137.png 151793785.138.png 151793785.139.png 151793785.140.png 151793785.141.png 151793785.142.png 151793785.143.png 151793785.144.png 151793785.145.png 151793785.002.png 151793785.003.png 151793785.004.png 151793785.005.png 151793785.006.png 151793785.007.png 151793785.008.png 151793785.009.png 151793785.010.png 151793785.011.png 151793785.013.png 151793785.014.png 151793785.015.png 151793785.016.png 151793785.017.png 151793785.018.png 151793785.019.png 151793785.020.png 151793785.021.png 151793785.022.png 151793785.024.png 151793785.025.png 151793785.026.png 151793785.027.png 151793785.028.png 151793785.029.png 151793785.030.png 151793785.031.png 151793785.032.png 151793785.033.png 151793785.035.png 151793785.036.png 151793785.037.png 151793785.038.png 151793785.039.png 151793785.040.png 151793785.041.png 151793785.042.png 151793785.043.png 151793785.044.png 151793785.046.png 151793785.047.png 151793785.048.png 151793785.049.png 151793785.050.png 151793785.051.png 151793785.052.png 151793785.053.png 151793785.054.png 151793785.055.png 151793785.057.png
JeŇeli system znajduje siħ w trybie Listen, czeka na nadejĻcie znaku SYN, aby
odpowiedzieę kolejnym znakiem SYN, a nastħpnie przejĻę w tryb SYN
Received. JeŇeli znak SYN zostaþ wysþany, poþĢczenie przechodzi w tryb SYN
Send. System TCP pozostaje w tym trybie aŇ do otrzymania od drugiego
systemu znaku SYN w odpowiedzi. JeŇeli nadejdzie pozytywna odpowiedŅ na
ten znak SYN, system TCP przechodzi w tryb SYN Received. Po pozytywnym
potwierdzeniu znaku SYN (ACK w odpowiedzi na SYN) nadajnik i odbiornik
przechodzĢ w tryb Established Î moŇe siħ rozpoczĢę transmisja danych miħdzy
obydwoma komputerami. Po przesþaniu wszystkich danych komputery biorĢce
udziaþ w komunikacji kontynuujĢ procedurħ 3-Way-Handshake. W celu
zakoıczenia poþĢczenia wymieniane sĢ segmenty z bitem No more data from
sender.
1.2. UDP Î User Datagram Protocol
Protokþ UDP zapewnia protokoþom wyŇszego rzħdu zdefiniowanĢ usþugħ transmisji
pakietw danych, zorientowanej transakcyjnie. Dysponuje minimalnymi
mechanizmami transmisji danych i opiera siħ bezpoĻrednio na protokole IP.
W przeciwieıstwie do TCP nie gwarantuje kompleksowej kontroli skutecznoĻci
transmisji, a zatem nie ma pewnoĻci dostarczenia pakietu danych do odbiorcy, nie da
siħ rozpoznaę duplikatw, ani nie moŇna zapewnię przekazu pakietw we wþaĻciwej
kolejnoĻci.
Mimo to jest wiele istotnych powodw stosowania UDP jako protokoþu
transportowego. Gdy trzeba przesþaę niewiele danych, nakþady administracyjne na
nawiĢzanie poþĢczenia i zapewnienie prawidþowej transmisji mogĢ byę wiħksze od
nakþadw niezbħdnych do ponownej transmisji wszystkich danych.
2. Protokoþy, porty i gniazda
Gdyby nie byþo portw, komunikacja za poĻrednictwem standardowych protokoþw
internetowych TCP i UDP byþaby niemoŇliwa. To dziħki portom wiele aplikacji moŇe
jednoczeĻnie wymieniaę dane, wykorzystujĢc jedno þĢcze internetowe.
2.1. Numery portw
Numery portw stanowiĢ jeden z podstawowych elementw stosowania protokoþw
TCP i UDP. Gdy dane docierajĢ do komputera docelowego, muszĢ jeszcze zostaę
dostarczone do wþaĻciwej aplikacji. Podczas transportu informacji przez warstwy sieci
potrzebny jest mechanizm, ktry najpierw gwarantuje przekazanie danych do
wþaĻciwego w danym wypadku protokoþu.
ýĢczenie danych z wielu Ņrdeþ w jeden strumieı danych nosi nazwħ
multipleksowania. Protokþ internetowy (IP) musi zatem poddaę dane nadchodzĢce
z sieci procesowi demultipleksowania. W tym celu IP oznacza protokoþy transportowe
numerami protokoþw. Same protokoþy transportowe wykorzystujĢ z kolei numery
porw do identyfikacji aplikacji.
Numer protokoþu IP zawarty jest w jednym bajcie w trzecim sþowie nagþwka
datagramu. WartoĻę ta determinuje przekazanie do odnoĻnego protokoþu w warstwie
transportowej; przykþadowo 6 to TCP, 17 to UDP. Protokþ transportowy musi
przekazaę otrzymane dane do wþaĻciwego procesu aplikacji.
Aplikacje identyfikowane sĢ na podstawie numerw portw o dþugoĻci 16 bitw, do
ktrych dane kierowane sĢ po nadejĻciu do komputera docelowego. W pierwszym
sþowie kaŇdego nagþwka TCP czy UDP zapisany jest teŇ numer portu Ņrdþowego
i numer portu docelowego. JeŇeli aplikacja ma byę dostħpna pod okreĻlonym
numerem portu, musi przekazaę tħ informacjħ do stosu protokþu TCP/IP.
2.2. Gniazda
Kombinacjħ adresu IP i numeru portu okreĻla siħ jako gniazdo. To poþĢczenie
umoŇliwia jednoznacznĢ identyfikacjħ poszczeglnych procesw sieciowych
w ramach caþego Internetu.
Zapis ma nastħpujĢcĢ postaę: adres IP:port, np. 62.96.227.70:80. Dwa gniazda
definiujĢ poþĢczenie: jedno okreĻla komputer Ņrdþowy, drugie Î docelowy.
TCP i UDP mogĢ nadawaę te same numery portw. Dopiero poþĢczenie protokoþu
i numeru portu jest jednoznaczne. Numer portu 53 w TCP nie jest identyczny
z numerem portu 53 w UDP.
3. Porty Î krtki przeglĢd
Microsoft Windows wykorzystuje kilka portw do realizacji swoich funkcji sieciowych.
W starszych wersjach, do Windows Me/NT, byþy to porty 137, 138 i 139. Od Windows
2000 Server message lock wysyþane sĢ przez port 445. OczywiĻcie, wersje Windows od
2000 sĢ zgodne w dþ, a wiħc obie procedury mogĢ funkcjonowaę rwnolegle.
Port 137
Obsþuguje tzw. NetBIOS Name Service. Za jego pomocĢ Windows przyporzĢdkowuje
wzajemnie Î podobnie jak w DNS Î nazwy komputerw i adresy IP. W okreĻlonych
wypadkach moŇe to powodowaę nastħpujĢcĢ sytuacjħ Î jeŇeli uŇytkownik surfuje na
windowsowym serwerze WWW, ten ostatni wysyþa zapytanie do portu 137 komputera
uŇytkownika. Dzieje siħ tak, poniewaŇ serwer windowsowy wykorzystuje funkcjħ
winsock gethostbyaddr() do odczytania nazwy odlegþego komputera. Funkcja ta jest
jednak tak zaimplementowana w Windows, Ňe najpierw nastħpuje prba odczytu przez
NetBIOS, a dopiero w razie niepowodzenia wykorzystywany jest odczyt przez DNS.
Tego rodzaju ruch powinien byę generalnie zabroniony, zarwno wchodzĢcy, jak
i wychodzĢcy. JeŇeli dwie sieci windowsowe majĢ wymieniaę dane przez Internet,
generalnie naleŇy zastosowaę VPN.
Port 138
Kryje siħ za nim usþuga NetBIOS datagram service. Za jej pomocĢ Windows rozsyþa
gþwnie informacje o sieci Windows, najczħĻciej w formie rozgþaszania. Na przykþad
usþuga Windows computerbrowser wykorzystuje informacje NetBIOS do
sporzĢdzenia aktualnej listy komputerw w sieci Windows, wyĻwietlanej w oknie
Otoczenie sieciowe.
Najwiħksze niebezpieczeıstwo zwiĢzane z usþugĢ datagram service polega na tym, Ňe
haker moŇe przekonaę Windows za pomocĢ sfaþszowanych pakietw, iŇ jego
komputer naleŇy do lokalnej sieci, a wiħc moŇe w ten sposb obejĻę rŇnice
zabezpieczeı odnoszĢcych siħ do komputerw lokalnych i internetowych. RwnieŇ
i tu obowiĢzuje zasada, Ňe port ten naleŇy zamknĢę w obu kierunkach
Zgłoś jeśli naruszono regulamin