From 262b6e24c83387388c1ab811c8b0f430d2f4fed0 Mon Sep 17 00:00:00 2001 From: xf0r3m Date: Tue, 29 Aug 2023 14:08:37 +0200 Subject: [PATCH] =?utf8?q?Tworzenie=20rozdzia=C5=82u=2010.=20Rozpocz=C4=99?= =?utf8?q?cia=20pisania=20podrozdzia=C5=82u=2010.5/10.5.2.tcpdump?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit --- articles/terminallog/Linux.Podstawy.html | 162 ++++++++++++++++++++++- 1 file changed, 161 insertions(+), 1 deletion(-) diff --git a/articles/terminallog/Linux.Podstawy.html b/articles/terminallog/Linux.Podstawy.html index 596ac6a..fd722bc 100644 --- a/articles/terminallog/Linux.Podstawy.html +++ b/articles/terminallog/Linux.Podstawy.html @@ -8746,7 +8746,167 @@ sftp> SSH.

10.4. Demony internetowe - inetd, xinetd

- +

+ Niektóre małe usługi sieciowe takie jak np. telnetd - + demon usługi telnet czy klasyczna usługa FTP oraz wiele + innych posiadają te same lub podobne wymagania dotyczące obsługi + sieci, zatem żeby nie implementować tego samego kodu. Twórcy tych + usług stworzyli superdemona on nazwie inetd i + najprościej rzecz ujmując jego zadaniem jest obsługa połączeń: + otwieranie portów oraz przekierowywanie połączeń już do właściwych + usług. +

+

+ Na przestrzenii lat działania tego rozwiązania powstała nowsza + implementacja xinetd posiadająca lepsze mechanizmy + obsługi oraz kontroli połączeń. +

+

+ Obecnie rzadko spotyka się działający demon inet lub + xinetd, został on wyparty przez demona systemctl, + a demony które obsługiwał obecnie posiadają własne implementacje + obsługi połączeń, z biegiem lat rozszerzały swoje możliwości i + finalnie stały się bardziej samodzielne. Wiele życzenia pozostawiaja + również kwestie bezpieczeństwa, chociaż wiele rzeczy zostało + poprawionych między oryginalną implementacją a xinetd. +

+

+ Inną równie archaiczną rzeczą jest wraper TCP w postaci + demona tcpd. Jego działanie przypomina nieco + działanie filtra sieciowego. Był on wykorzystywany jeszcze zanim + takie rozwiązania jak iptables zostały na stałe wdrożone + jako swoisty standard i podstawowy poziom ochrony. Zanim ruch z + inetd trafił do właściwego demona przechodził przez ten + wraper. tcpd rejestrował połączenie następnie konfrontował + je z listami dostępu /etc/hosts.allow lub + /etc/hosts.deny, na podstawie informacji ustalonych przez + wraper był dopuszczany do właściwego procesu lub nie. +

+

+ Plikowe listy kontroli dostępu mogą być wykorzystywane w + dystrybucjach klasy enterprise, do ustalenia dostępu do wybranych + komponentów systemu. Takim przykładem może być dostęp do cron + (harmonogramu zadań). Więcej informacji znajduje się pod tym adresem: + https://morketsmerke.github.io/articles/terminallog/RedHat_-_RHCSA.html#8.2.1.scheduleaccesscontrol +

+

10.5. Narzędzia diagnostyczne

+

+ Podczas analizownia działania protokołu HTTP, na samym końcu + wspomniałem o innym sposobie połączenia się z serwerem WWW przy + użyciu programu telnet. Program ten może być programem + diagnostycznym w podczas sprawdzania uruchomienia i dostępności + usługi. W większości dystrybucji program telnet trzeba + będzie zainstalować z repozytorium. Jednak możemy w systemie + naleźć co najmniej jedno narzędzie, które jest nam wstanie zwrócić + jakieś informacje na temat usług sieciowych takim program jest + już omawiany ss. +

+

+ Wynik działania programu ss, był już omawiany podczas + omawiania transmisji TCP w warstwie transportowej. Ale poniżej + znajdują się najważniejsze (dla celów diagnostycznych) opcje. +

+ +

10.5.1. Polecenie lsof

+

+ Jesli pamiętamy z rozdziału 8, polecenie lsof służy + do wyświetlania otwartych plików w systemie. Z jego pomocą możemy + również wyświetlić połączenia realizowane w systemie. Rola tego + polecenia może przypominać ss, jednak polecenie lsof + do działania w obrębie całego systemu wymagają uprawnień + administratora, w przeciwnym razie polecenie wyświetli tylko i + wyłącznie połączenia utworzne przez użytkownika, który wydał to + polecenie. Aby móc wyświetlić połączenia sieciowe przy użyciu + polecenia lsof należy użyć opcji -i, tak + jak przedstawiono to na poniższym poleceniu. +

+
+xf0r3m@vm-3d6b184:/media/xf0r3m/immudex_crypt0$ sudo lsof -i
+COMMAND     PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
+systemd       1    root   35u  IPv4  11469      0t0  TCP *:sunrpc (LISTEN)
+systemd       1    root   36u  IPv4  11472      0t0  UDP *:sunrpc 
+systemd       1    root   37u  IPv6  11475      0t0  TCP *:sunrpc (LISTEN)
+systemd       1    root   38u  IPv6  11478      0t0  UDP *:sunrpc 
+rpcbind     427    _rpc    4u  IPv4  11469      0t0  TCP *:sunrpc (LISTEN)
+rpcbind     427    _rpc    5u  IPv4  11472      0t0  UDP *:sunrpc 
+rpcbind     427    _rpc    6u  IPv6  11475      0t0  TCP *:sunrpc (LISTEN)
+rpcbind     427    _rpc    7u  IPv6  11478      0t0  UDP *:sunrpc 
+avahi-dae   476   avahi   12u  IPv4  13560      0t0  UDP *:mdns 
+avahi-dae   476   avahi   13u  IPv6  13561      0t0  UDP *:mdns 
+avahi-dae   476   avahi   14u  IPv4  13562      0t0  UDP *:33600 
+avahi-dae   476   avahi   15u  IPv6  13563      0t0  UDP *:34773 
+NetworkMa   675    root   26u  IPv4  14371      0t0  UDP vm-3d6b184.morketsmerke.org:bootpc->DDI1184JS.mshome.net:bootps 
+cupsd       790    root    6u  IPv6  14463      0t0  TCP localhost:ipp (LISTEN)
+cupsd       790    root    7u  IPv4  14464      0t0  TCP localhost:ipp (LISTEN)
+cups-brow   860    root    7u  IPv4  15147      0t0  UDP *:631 
+chronyd     883 _chrony    5u  IPv4  14538      0t0  UDP localhost:323 
+chronyd     883 _chrony    6u  IPv6  14539      0t0  UDP localhost:323 
+ssh       60722  xf0r3m    3u  IPv4 187934      0t0  TCP vm-3d6b184.morketsmerke.org:36440->ip82-117-231-222.static.awhost.cloud:2022 (ESTABLISHED)
+
+

+ Na powyższym przykładzie możemy zauważyć, że wyjście tego polecenia + jest trochę bardziej podrasowanym wyjściem polecenia ss. + Poza tym lsof daje nam możliwość przefiltrowania listy + dostępnych połączeń. Ogólny format filtru wygląda następująco: +

+
+$ sudo lsof -i[wersja_IP][protokół]@[komputer]:[port]
+
+

+ Oczywiście istnieje pełna dowolność w stosowaniu tych elementów, aby + to pokazać przedstawię kilka użytecznych filtrów: +

+
+xf0r3m@vm-3d6b184:/media/xf0r3m/immudex_crypt0$ sudo lsof -i4 -s TCP:LISTEN
+COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
+systemd   1 root   35u  IPv4  11469      0t0  TCP *:sunrpc (LISTEN)
+rpcbind 427 _rpc    4u  IPv4  11469      0t0  TCP *:sunrpc (LISTEN)
+cupsd   790 root    7u  IPv4  14464      0t0  TCP localhost:ipp (LISTEN)
+
+

+ Powyższy przykład przestawia wyłącznie otwarte porty dla transmisji + TCP. W tym przypadku uzyskanie stanu połączenia + (LISTEN) wymaga podania dodatkowe + opcji (-s) a ona ma swoją składnię + dla wartości: PROTOKOŁ:STAN. +

+
+xf0r3m@vm-3d6b184:/media/xf0r3m/immudex_crypt0$ sudo lsof -iTCP@searx.morketsmerke.org
+COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
+ssh     60722 xf0r3m    3u  IPv4 187934      0t0  TCP vm-3d6b184.mshome.net:36440->ip82-117-231-222.static.awhost.cloud:2022 (ESTABLISHED)
+
+

+ Ciekawy przypadek mamy tutaj. Ponieważ wśród połączeń TCP wyszukujemy + hosta o konkretnej nazwie. Nie dostajemy informacji zwrotnej, że coś + jest nie tak, wręcz przeciwnie uzyskujemy odpowiedź i to prawidłową. + Adres searx.morketsmerke.org jest + odwzrowywany do 82.117.231.222, ale jeśli skorzystamy z zamiany + adresu IP na nazwę domenową wówczas otrzymamy taki oto wynik: + ip82-117-231-222.static.awhost.cloud + Więc jeśli adres searx.morketsmerke.org + jest tożsamy z + ip82-117-231-222.static.awhost.cloud, + co oznacza, że filtr jest jak najbardziej poprawny. Poniżej znajduje + się ostatni już przykład: +

+
+xf0r3m@vm-3d6b184:/media/xf0r3m/immudex_crypt0$ sudo lsof -i6UDP:323
+COMMAND PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
+chronyd 883 _chrony    6u  IPv6  14539      0t0  UDP localhost:323 
+
+

10.5.2. tcpdump

+

2022; COPYLEFT; ALL RIGHTS REVERSED;

-- 2.39.5