From: xf0r3m Date: Wed, 23 Aug 2023 12:20:03 +0000 (+0200) Subject: Tworzenie rozdziału 10. Ukończono podrozdział 10.1 X-Git-Url: https://gitweb.morketsmerke.org/?a=commitdiff_plain;h=20cdc7625844d28440bd1c228f824eb5a260cb71;p=mmdev.git Tworzenie rozdziału 10. Ukończono podrozdział 10.1 --- diff --git a/articles/terminallog/Linux.Podstawy.html b/articles/terminallog/Linux.Podstawy.html index 9b0d34d..37cea90 100644 --- a/articles/terminallog/Linux.Podstawy.html +++ b/articles/terminallog/Linux.Podstawy.html @@ -8057,6 +8057,261 @@ xf0r3m@immudex:~$ sudo wpa_cli konfiguracji sieci w Linuks. Jednak to nie koniec tematów sieciowych ponieważ następne dwa rozdziały będą na niej bazować.

+

10. Warstwa aplikacji - usługi sieciowe

+

+ W poprzednim rozdziale dowiedzieliśmy się czym są sieci komputerowe + i jak wygląda ich konfiguracja w dystrybucjach Linuksa. Sieci służą + do przesyłania danych, a te musimy dostsować za pomocą uzupełnienia + formularza na stronie internetowej lub w postaci zwykłego pliku + tekstowego. Za obie te formy odpowiadają różne ustandaryzowane zbiory + programów składające się na jeden konkrent protokół. + Protokołów nie należy stawiać obok programów, które możemy kojarzyć + z daną formą sposóbu przesyłania informacji przez sieć. Te programy + najczęściej zajmują się ich obsługą, zawierają tym samym ich + implementacje oraz dostosowanie aby korzystanie z protokołu było + najcześciej niezauważalne a końcowy użytkownik utrzymał tylko + i wyłącznie żądaną stronę internetową lub dostęp do zasobu dyskowego + udostępnionego gdzieś na serwerze. +

+

+ Aby pomiędzy dwoma stronami mogła zajść komunikacji + potrzebny jest nadawca i odbiorca. Z punktu widzenia sieci + komputerowej, każdy host jest jednocześnie jednym i drugim. Jednak + patrząc na to ze strony obecnie omiawianego tematu, różnica między + stronami jest już dużo bardziej podkreślona. Mamy sztywny podział + między aplikacji klienckimi danego protokołu, które żądają dostępu + do konkretnego zasobu a serwera, które te dane udostępniają. + Wiele serwerów określa się mianem usług sieciowych. + Często mówiąc o jakiś serwerze do słowa serwer dodaje się + protokół, który obsługuje. Jak możemy pamiętać np. z rozdziału 7, + nie które serwery domyślnie nie są usługami sieciowymi (chociaż mogą, + wystarczy odpowienio jes skonfigurować). +

+

+ Usługi sieciowe mają za zadanie udostępniać dane poprzez wybrane + protokoły. Na przykład coś co nazywamy przeglądarką internetową + opiera swoje działanie na protokole HTTP bądź jego bezpieczeniejszej + wersji w postacji protokołu HTTPS. Programy pocztowe wykorzystują + protokoły SMTPS oraz POP3S lub IMAPS. Wiele różnych aplikacji + sieciowych może wykorzystywać różne protokoły lub samodzielnie + implementować format danych przesyłanych przez sieć. Nie mniej jednak + wszystkie te protokoły rezydują w warstwie aplikacji + czwartej warstwie modelu TCP/IP. +

+

+ W tym rozdziale nadal pozostaniemy w sieciach. Przeanalizujemy + działanie protokołu HTTP. Omówimy sobie usługę sieciową na podstawie + SSH. Dowiemy się jak uruchamiane były, nie które specyficzne usługi + i jak są uruchamiane teraz. Sprawdzimy sobie narzędzia diagnostyczne, + które pozwolą nam na sprawdzenie dostępności usługi ale również + monitorowanie przesłanych przez nia i do niej danych. Na koniec + zajmiemy się zdalnym wywołaniem procedur (RPC) oraz omówimy sobie + podstawowe zagadnienia związane z bezpieczeństwem. + Tematem zaawansowamym będą gniazda. +

+

10.1. Analiza HTTP

+

+ Na wstępie omówilśmy sobie co tak naprawdę znajduje się w warstwie + aplikacji. Aby była możliwość zapewnienia bezbłędnego działania + wielu znanych protokołów, które no men omen są podstawą komunikacji + w internecie, zespoły odpowiedzialne za implementacje tych standardów + często umieszczają w swoich programach klienckich możliwośc analizy + przesyłanych danych. W tym podrozdziale skupimy się głównie na jednym + protokole i jednym narzędziu umożliwiającym śledzenie danych + przesyłanych za pomocą protokołu. Jednak w podrozdziale poświęconym + narzędziom dianostycznym dowiemy się, że możemy sprawdzić większość + usług, za pomocą kilku narzędzi. +

+

+ W większości dystrybucji dostępne jest narzędzie + curl jest ono nagminnie wykorzystywane do pobierania + plików za pomocą protokołu HTTP w terminalu. Program ten jako, że + wykorzystuje protokół HTTP/S posiada również możliwość prześledzenia + transmisji. Jako przykład wykorzystamy serwis pogodowy, który + przesyła obecną sytuację pogodową (lub dwu-dniową prognozę) za ASCII. + Dla przykładu: +

+
+xf0r3m@immudex:~$ curl wttr.in/Warszawa?0\&lang=pl
+Pogoda w: Warszawa
+
+      \   /     Słonecznie
+       .-.      21 °C
+    ― (   ) ―   → 9 km/h
+       `-’      10 km
+      /   \     0.0 mm
+
+

+ Na podstawie wyścia tego polecenia, ciężko jest na prierwszy rzzut + oka dostrzec, że jest to strona internetowa, ale tak właśnie jest. + Chcąc przeanalizować jak wygląda komunikacja za pomocą protokołu + HTTP należy wydać następujące polecenie: +

+
+xf0r3m@immudex:~$ curl --trace-ascii curl.log wttr.in/Warszawa?0\&lang=pl
+
+

+ Opcja --trace-ascii mówi programowi + curl aby zapisywał on komunikaty diagnostyczne. Dodatkowo + ta opcja wymaga podania pliku przeznaczonego na dane wyjściowe. W + moim przypadku jest curl.log. Poniżej znajduje się jego + zawartość, pominąłem na poniższym przykładzie dane zwracane przez + polecenie (są one normalnie dostępne w terminalu po wydaniu + polecenia). +

+
+== Info:   Trying 5.9.243.187:80...
+== Info: Connected to wttr.in (5.9.243.187) port 80 (#0)
+=> Send header, 89 bytes (0x59)
+0000: GET /Warszawa?0&lang=pl HTTP/1.1
+0022: Host: wttr.in
+0031: User-Agent: curl/7.74.0
+004a: Accept: */*
+0057:
+== Info: Mark bundle as not supporting multiuse
+<= Recv header, 17 bytes (0x11)
+0000: HTTP/1.1 200 OK
+<= Recv header, 32 bytes (0x20)
+0000: Access-Control-Allow-Origin: *
+<= Recv header, 21 bytes (0x15)
+0000: Content-Length: 314
+<= Recv header, 41 bytes (0x29)
+0000: Content-Type: text/plain; charset=utf-8
+<= Recv header, 37 bytes (0x25)
+0000: Date: Wed, 23 Aug 2023 08:23:51 GMT
+<= Recv header, 2 bytes (0x2)
+0000:
+<= Recv data, 314 bytes (0x13a)
+0080:  .  .[38;5;226m  ... (   ) ...  .[0m .[1m....[0m .[38;5;154m9.[0
+00c0: m km/h.[0m       .  .[38;5;226m     `-...     .[0m 10 km.[0m
+0100:       .  .[38;5;226m    /   \    .[0m 0.0 mm.[0m         .
+== Info: Connection #0 to host wttr.in left intact
+
+

+ Pierwsze dwie linie, są to linie informujące nas o uzyskanym adresie + IP oraz o tym czy połącznie powiodło się. Jeśli tak jest, to wówczas + wysyłany jest nagłówek, - w nagłówkach HTTP + przeważnie znajdują się informacje kontrolne dla programów, które + będą zajmować się interpretowaniem treści przesłanej przez serwer. + No właśnie. Można by na logikę rzecz ująć, że to przeglądarka powinna + pobrać żądaną stronę WWW. W rzeczywistości to klient przesyła + jedynie nagłówek z żądaniem. Przyglądając się pierwszej linii + nagłówka + rozpoczynajcego się liczbą: 0000 + (Ta liczba to bajt rozpoczęcią tych danych w ładunku/bloku danych + przesyłanych w pakietach sieciowych). Zawiera ona słowo kluczowe + GET Następnie występuje wartość + żądania (czego sobie życzysz), na podstawie tych informacji skrypt + jest wstanie zwrócić odpowiedni stan pogodowy, w przypadku kiedy + poprostu odwiedzamy jakąś witrynę to najczęściej po słowie + GET występuje ukośnik (/). Serwery wówczas + interpretują to, że żądanie dotyczy głównie pliku index.html + zapisanego w katalogu przypisanym na serwerze do danej witryny. +

+

+ Uwaga! Jeden serwer WWW, może utrzymać kilka jak nie kilkanaście lub + kilkadziesiąt różnych stron internetowych. Wszystko zależy od jego + ustawień oraz wydajności sprzętowej, która go utrzymuje. Dlatego też + wiele stron może kierowanych pod jeden adres IP. Taka funkcjonalność + nazywa się hostingiem. +

+

+ W naszym przypadku również żądamy głównego pliku tego hostingu, w + nagłówku natomiast przekazujemy dane, które pomogą w uzyskaniu + żądanych przez nas danych. Jest to jedna z cech protokołu HTTP. Dane + (głównie do aplikacji, ponieważ statyczne strony rzadko interpretują + jakieś dane) mogą być przekazywane jako rozwinięcie adresów jest to + tak zwana metoda GET lub w postaci odrębnego pakietu danych + poza widocznością dla zwykłego użytkownika - metoda POST. + Przy użyciu metody POST najczęściej przesyłane są dane + uzupełnionych formularzy na stronach WWW. Po danych przekazywanych + aplikacji (w tym przypadku) wstepują już informacje kontrolne dla + samego protokołu HTTP w linii 0022 (będę używał takich + oznaczeń) występuje pole nagłówka + Host: zawiera ono nazwę hosta do, + którego kierujemy nasze żądanie. Następne pole nagłówka to + User Agent:, to pole zawiera + informacje jakiego programu klienckiego WWW używamy. Ta informacja + jest zapisywana w plikach dziennika serwera wraz z adresem IP. + Narzędzia takie jak curl lub podobny mu i bardziej + powszechny wget pozwalają na zmianę tej wartości, za pomocą + jednej opcji możemy podać się za np. program indeksujący jednej z + wyszukiwarek. Trzecim polem jest rodzaje danych jakie może + zinterpretować, polecenie to służy głównie pobieraniu treści więc + rzadko kiedy je interpretuje. Wyjątkiem może być omawiany przez nas + przykład. Ostatnim pole jest znak nowego wiersza, który kończy + nagłówek żądania. Teraz następuje jego przesłanie i oczekiwnaie na + odpowiedź serwera. +

+

+ W przypadku odpowiedzi jak możemy zauważyć przesyłanych jest wiele + nagłówków przedstawiających pojedyńcze pola. Nie będe ich tutaj + wszystkich opisywał, jednak na uwagę zasługuję jedna informacja, + która została wcześniej pominięta. Otóż, w polu metody żądania lub + w pierwszym naglówku odpowiedzi znajduje się wykorzystywana w + transmisjii wersja protokołu HTTP. Wersja 1.1 jest obecnie + standardem, jednak obecnie w stanie proponowanych standardów są + wersje 2 i 3. Seria nagłówków odpowiedzi kończy się w taki sam + sposób jak w przypadku nagłówka żądania, znakiem nowego wiersza. + Następnie odebrany zostaje pakiet danych a dane w nim zawarte + trafiają do użytkownika. +

+

+ Tak moglibyś to wywnioskować na podstawie danych diagnostycznych + zwróconych przez program curl. Wygląda to nieco inaczej, ale + różnice występują tylko w przedstawieniu danych. Otóż otrzymując + pakiet protokołu HTTP, nie ma w nim podziału na sekcje nagłówka i + danych. Nie ma także dwóch odrębnych pakietów. Wszystko spakowane + jest w jednej paczce, a curl na podstawie znaku nowego + wiersza jest jedynie oddzielić te dane. +

+

+ Innym sposobem na wejście interakcje np. z protokołem HTTP jest + wykorzystanie zapomnianego już programu Telnet. + Telnet kiedyś służył do tego do czego służy teraz + protokół SSH. Do zdalnego połączenia się z powłoką. + Telnet sam w sobie również jest protokołem. Obecnie telnet rzadko + jest spotykany w swojej pierwotnej formie, chyba że w postaci + lokalnej konsoli w systemach wbudowanych. +

+
+xf0r3m@immudex:~$ telnet example.org 80 > telnet.log
+Trying 93.184.216.34...
+Connected to example.org.
+Escape character is '^]'
+GET / HTTP/1.1
+Host: example.org
+
+HTTP/1.1 200 OK
+Age: 126394
+Cache-Control: max-age=604800
+Content-Type: text/html; charset=UTF-8
+Date: Wed, 23 Aug 2023 11:28:50 GMT
+Etag: "3147526947+ident"
+Expires: Wed, 30 Aug 2023 11:28:50 GMT
+Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
+Server: ECS (dcb/7F7F)
+Vary: Accept-Encoding
+X-Cache: HIT
+Content-Length: 1256
+...
+
+

+ Po wielokropku występuje już tylko kod HTML strony. Polecenie + telnet wymaga aby port, pod który + należy się podłączyć. Aby otrzymać odpowiedź musimy metodę + (GET), ewentualne dane/żądany plik + (/), wersje protokołu + (HTTP/1.1) w drugiej lini nagłówka + należy podać nazwę hosta + (Host: example.org), ze względu na + to aby serwer WWW wiedział z jakiej witry przesłać odpowiedź. +

+

+ Protokół jest może trochę mało interaktwny przy takim połączeniu, ale + np. usługi pocztowe są już bardziej skore do rozmowy. +

+

10.2. Serwery sieciowe

2022; COPYLEFT; ALL RIGHTS REVERSED;