SSH.
</p>
<h2 id="10.4.inetd">10.4. Demony internetowe - inetd, xinetd</h2>
- </div>
+ <p>
+ Niektóre małe usługi sieciowe takie jak np. <em>telnetd</em> -
+ demon usługi <em>telnet</em> 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 <strong>inetd</strong> 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.
+ </p>
+ <p>
+ Na przestrzenii lat działania tego rozwiązania powstała nowsza
+ implementacja <strong>xinetd</strong> posiadająca lepsze mechanizmy
+ obsługi oraz kontroli połączeń.
+ </p>
+ <p>
+ Obecnie rzadko spotyka się działający demon <em>inet</em> lub
+ <em>xinetd</em>, został on wyparty przez demona <em>systemctl</em>,
+ 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 <em>xinetd</em>.
+ </p>
+ <p>
+ Inną równie archaiczną rzeczą jest <em>wraper</em> TCP w postaci
+ demona <strong>tcpd</strong>. Jego działanie przypomina nieco
+ działanie filtra sieciowego. Był on wykorzystywany jeszcze zanim
+ takie rozwiązania jak <em>iptables</em> zostały na stałe wdrożone
+ jako swoisty standard i podstawowy poziom ochrony. Zanim ruch z
+ <em>inetd</em> trafił do właściwego demona przechodził przez ten
+ wraper. <em>tcpd</em> rejestrował połączenie następnie konfrontował
+ je z listami dostępu <em>/etc/hosts.allow</em> lub
+ <em>/etc/hosts.deny</em>, na podstawie informacji ustalonych przez
+ wraper był dopuszczany do właściwego procesu lub nie.
+ </p>
+ <p>
+ 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 <em>cron</em>
+ (harmonogramu zadań). Więcej informacji znajduje się pod tym adresem:
+ <a href="https://morketsmerke.github.io/articles/terminallog/RedHat_-_RHCSA.html#8.2.1.scheduleaccesscontrol">https://morketsmerke.github.io/articles/terminallog/RedHat_-_RHCSA.html#8.2.1.scheduleaccesscontrol</a>
+ </p>
+ <h2 id="10.5.diagnostictools">10.5. Narzędzia diagnostyczne</h2>
+ <p>
+ 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 <em>telnet</em>. Program ten może być programem
+ diagnostycznym w podczas sprawdzania uruchomienia i dostępności
+ usługi. W większości dystrybucji program <em>telnet</em> 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 <strong>ss</strong>.
+ </p>
+ <p>
+ Wynik działania programu <em>ss</em>, był już omawiany podczas
+ omawiania transmisji TCP w warstwie transportowej. Ale poniżej
+ znajdują się najważniejsze (dla celów diagnostycznych) opcje.
+ </p>
+ <ul>
+ <li><strong>-t</strong> - informacje o połączeniach TCP</li>
+ <li><strong>-u</strong> - informacje o połączeniach UDP</li>
+ <li><strong>-l</strong> - wyświetla informacje o portach oczekujących
+ na połączenie (nasłuchujących).</li>
+ <li><strong>-a</strong> - wyświetla wszystkie dostępne połączenia w
+ systemie</li>
+ <li><strong>-n</strong> - wyłącza rozwiązywanie nazw (przyspiesza to
+ wynik działania programu jeśli serwery DNS nie odpowiadają).</li>
+ <li><strong>-4, -6</strong> - wyświetlenie informacji dotyczących
+ protokołu IPv4 lub IPv6.</li>
+ </ul>
+ <h3 id="10.5.1.lsofcommand">10.5.1. Polecenie lsof</h3>
+ <p>
+ Jesli pamiętamy z rozdziału 8, polecenie <strong>lsof</strong> 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ć <em>ss</em>, jednak polecenie <em>lsof</em>
+ 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 <em>lsof</em> należy użyć opcji <strong>-i</strong>, tak
+ jak przedstawiono to na poniższym poleceniu.
+ </p>
+<pre class="code-block">
+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)
+</pre>
+ <p>
+ Na powyższym przykładzie możemy zauważyć, że wyjście tego polecenia
+ jest trochę bardziej podrasowanym wyjściem polecenia <em>ss</em>.
+ Poza tym <em>lsof</em> daje nam możliwość przefiltrowania listy
+ dostępnych połączeń. Ogólny format filtru wygląda następująco:
+ </p>
+<pre class="code-inline">
+$ sudo lsof -i[wersja_IP][protokół]@[komputer]:[port]
+</pre>
+ <p>
+ Oczywiście istnieje pełna dowolność w stosowaniu tych elementów, aby
+ to pokazać przedstawię kilka użytecznych filtrów:
+ </p>
+<pre class="code-block">
+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)
+</pre>
+ <p>
+ Powyższy przykład przestawia wyłącznie otwarte porty dla transmisji
+ TCP. W tym przypadku uzyskanie stanu połączenia
+ (<code class="code-inline">LISTEN</code>) wymaga podania dodatkowe
+ opcji (<code class="code-inline">-s</code>) a ona ma swoją składnię
+ dla wartości: <em>PROTOKOŁ:STAN</em>.
+ </p>
+<pre class="code-block">
+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)
+</pre>
+ <p>
+ 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 <code class="code-inline">searx.morketsmerke.org</code> jest
+ odwzrowywany do 82.117.231.222, ale jeśli skorzystamy z zamiany
+ adresu IP na nazwę domenową wówczas otrzymamy taki oto wynik:
+ <code class="code-inline">ip82-117-231-222.static.awhost.cloud</code>
+ Więc jeśli adres <code class="code-inline">searx.morketsmerke.org</code>
+ jest tożsamy z
+ <code class="code-inline">ip82-117-231-222.static.awhost.cloud</code>,
+ co oznacza, że filtr jest jak najbardziej poprawny. Poniżej znajduje
+ się ostatni już przykład:
+ </p>
+<pre class="code-block">
+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
+</pre>
+ <h3 id="10.5.2.tcpdump">10.5.2. tcpdump</h3>
+ </div>
<p style="margin: 15px; padding: 0; outline: 0;">
2022; COPYLEFT; ALL RIGHTS REVERSED;
</p>
projects / mmdev.git / commitdiff