np. usługi pocztowe są już bardziej skore do <em>rozmowy</em>.
</p>
<h2 id="10.2.networkservers">10.2. Serwery sieciowe</h2>
+ <p>
+ W dystrybucjach Linuksa możemy napodkać wiele serwerów, nie które z
+ nich działają w oparciu o sieć i oczekują zdarzeń pochodzących od
+ zdalnych użytkowników. Serwery wewnątrzsystemowe to dość niszowa
+ grupa do których zalicza się tylko kilka demonów np. <em>cron</em>.
+ Dlatego w mowie potocznej przyjęło się, że mówiąc o serwerach mamy
+ na myśli serwery sieciowe. Poniżej znajduje się lista rodzajów
+ wraz kilkoma przykładmi oprogramowania.
+ </p>
+ <ul>
+ <li><strong>Serwery WWW:</strong> - <em>Apache</em>, <em>Nginx</em></li>
+ <li><strong>Serwery pocztowe:</strong> - SMTP: <em>Postfix</em>,
+ <em>Sendmail</em>; POP3/IMAP: <em>dovecot</em></li>
+ <li><strong>Serwery plików:</strong> - CIFS (udziały Windows):
+ <em>Samba</em>; FTP: <em>vsftpd</em>;
+ NFS: <em>nfs-kernel-server</em></li>
+ <li><strong>Serwery zdalnego dostępu:</strong> - SSH:
+ <em>openssh</em>; RDP: <em>xrdp</em>.</li>
+ <li><strong>Serwery wewnątrzsieciowe:</strong> - DHCP:
+ <em>isc-dhcp-server</em>, <em>dnsmasq</em>; DNS:
+ <em>bind9</em>, <em>dnsmasq</em></li>
+ <li><strong>Usługa zdalnego wywołania procedury (RPC)</strong><li>
+ </ul>
+ <p>
+ Aby bardziej zaznajomić się z serwerami sieciowymi, omówimy sobie
+ po krótce jeden z znich. Z powyższej listy najciekawszym z nich
+ jest implementacja protokołu SSH od twórców innego Unix-a jakim jest
+ OpenBSD - <strong>openssh</strong>. Implementacji protokołu SSH jest
+ kilka, jednak ta jest w najpowszechniejszym użytku obecna jest nawet
+ w najnowszych wersjach MS Windows 10.
+ </p>
+ <h2 id="10.3.openssh">10.3. Serwer bezpiecznej powłoki - implementacja openssh</h2>
+ <p>
+ Demony sieciowe zawyczaj skupiają się na czynnościach wokół protokołu,
+ który obsługują. Implementacja <em>openssh</em> ma za zadanie
+ zapewnienie solidnego poziomu bezpieczeństwa zarówno dla zdalnej
+ powłoki, transferu plików jak i innych połączeń za pomocą
+ <em>proxy</em> czy <strong>tunelowania</strong>.
+ </p>
+ <h3 id="10.3.1.sshcommand">10.3.1. Aplikacja klienta - polecenie ssh</h3>
+ <p>
+ Za pomocą polecenia <em>ssh</em> mamy dostęp do większości cudów
+ jakie oferuje ta implementacja. Najprostszym jej wywołaniem jest
+ podanie nazwy użytkownika następnie adresu zdalnego hosta, z którym
+ chcemy się połączyć. Obie te wartości połączone są ze sobą za pomocą
+ <em>małpy</em> (<strong>@</strong>). Po poprawnym znalezieniu hosta
+ i połączeniu z jego demon SSH (będzie o nim za chwile), zostaniemy
+ poproszeni o hasło. Jeśli łączymy się z serwerem po raz pierwszy,
+ Zostanie nam wyświetlona informacja na temat, że nie można
+ zweryfikować autentyczności hosta.
+ </p>
+<pre class="code-block">
+1184JS:~$ ssh -p 2022 searx.morketsmerke.org
+The authenticity of host '[searx.morketsmerke.org]:2022 ([82.117.231.222]:2022)' can't be established.
+ECDSA key fingerprint is SHA256:ghhvjaz6T/qcsX9TiWN4UEV4fuiv6oqHxsD1bGB+40c.
+Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
+Warning: Permanently added '[searx.morketsmerke.org]:2022,[82.117.231.222]:2022' (ECDSA) to the list of known hosts.
+</pre>
+ <p>
+ W przypadku protokołu SSH, serwer musi się przedstawić za każdym
+ razem gdy nawiązujemy z nim połączenie. Jeśli jest pierwsze
+ połączenie z tym serwerem, to na komputerze klienta nie ma jeszcze
+ danych autentykacji serwera (bez wdawania sie w zawiłe,
+ kryptograficzne szczegóły) wówczas musimy się upewnić we własnym
+ zakresie czy jest rzeczywiście ten serwer z którym chcemy się
+ połączyć, a nie np. próba wyłudzenia hasła. Po wyświetleniu się tego
+ komunikatu zostaniemy zapytaniu czy chcemy kontynuować, jeśli
+ odpowiedź jest twierdząca to dane autentykacyjne serwera zostaną
+ zapisane w plikach na naszym komputerze i przy kolejnej próbie
+ logowania poproszeni zostaniem wyłącznie o hasło.
+ </p>
+<pre class="code-block">
+xf0r3m@immudex:~$ ssh -p 2022 searx.morketsmerke.org
+xf0r3m@searx.morketsmerke.org's password:
+</pre>
+ <p>
+ Na powyższym przykładzie podałem opcję
+ <code class="code-inline">-p</code>, która pozwala na wkazanie
+ nie stanadardowego portu (standardowy port to 22/TCP).
+ Na tym przykładzie pominąłem, użytkownika. Jeśli go pominiemy
+ <em>ssh</em> jako użytkownika przyjmie tego, który wydał polecenie.
+ </p>
+ <p>
+ Domyślnie podczas logowania używa się haseł, ale jeśli mamy pod sobą
+ kilka maszyn i wpisywanie do każdej hasła może być męczące. SSH daje
+ nam możliwość uwierzytelnienia za pomocą kluczy kryptograficznych.
+ Nie będę zagłębiał się charkterystykę kluczy kryptograficznych, ale
+ istnieje możliwość wygenerowania pary plików (klucz publiczne oraz
+ prywatnego), następnie załadowanie jednego z nich do maszyn, którymi
+ administrujemy. Podczas generowanie pary kluczy, będzie można podać
+ hasło chroniące klucz prywatny. Najlepiej, aby dodać to hasło.
+ Wówczas będziemy mieć jedno hasło do wielu maszyn (niezależne, bo
+ nawet jeśli główny administrator serwera zmieni nam hasło, to jeśli
+ klucz nadal będzie w systemie, to nadal będziemy mieli możliwość
+ zalogowania się do systemu.).
+ </p>
+ <p>
+ Aby wygenerować klucze wydajemy następujące polecenie. Dodam tylko,
+ że obecnie będziemy generować klucz algorytmu kryptograficznego
+ <strong>RSA</strong>, są one domyślne dla SSH. Choć, nie które z
+ systemów mogą ich nie przyjmować i wymagać innych rozdzajów. Więcej
+ na temat znajduje się na stronie podręcznika polecenia
+ <strong>ssh-keygen</strong>.
+ </p>
+<pre class="code-block">
+xf0r3m@immudex:~$ ssh-keygen
+Generating public/private rsa key pair.
+Enter file in which to save the key (/home/xf0r3m/.ssh/id_rsa):
+Enter passphrase (empty for no passphrase):
+Enter same passphrase again:
+Your identification has been saved in /home/xf0r3m/.ssh/id_rsa
+Your public key has been saved in /home/xf0r3m/.ssh/id_rsa.pub
+The key fingerprint is:
+SHA256:7N+WSF5OuOXiGh0hWr3hjMClfssGrn7Ofh8igPYpqcw xf0r3m@immudex
+The key's randomart image is:
++---[RSA 3072]----+
+| . |
+| . o . |
+| + o + |
+| . . = = + |
+| o . + S =. |
+| . o + = oo.+ |
+| o o o BooO . |
+|o. . o.o.+=o= |
+|.E .o++..++o. |
++----[SHA256]-----+
+</pre>
+ <p>
+ Polecenie wydajemy bez żadnych opcji chcąc wygenerować parę kluczy
+ RSA. Ścieżkę zapisu klucza równięż pozostawiamy bez zmian, oczywiście
+ jeśli mamy w planach ustawienie hasła klucz prywatnego. Jeśli nie
+ to może warto było by wskażać jakie bezpieczne miejsce np.
+ szyfrowaną partycję lub dysk. Posiadając parę kluczy możemy je
+ załadować do docelowych systemów.
+ </p>
+<pre class="code-block">
+xf0r3m@immudex:~$ ssh-copy-id xf0r3m@172.26.38.226
+/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/xf0r3m/.ssh/id_rsa.pub"
+/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
+/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
+xf0r3m@172.26.38.226's password:
+
+Number of key(s) added: 1
+
+Now try logging into the machine, with: "ssh 'xf0r3m@172.26.38.226'"
+and check to make sure that only the key(s) you wanted were added
+</pre>
+ <p>
+ Klucze możemy załadować do systemu za pomocą polecenia
+ <code class="code-block">ssh-copy-id</code>. Działanie tego polecenia
+ widzimy na powyższym przykładzie. To polecenie przyjmuje również
+ te same opcje jak w przypadku polecenia <em>ssh</em>. Jeśli podaliśmy
+ inną ścieżkę podczas generowania klucza to za pomoca opcji
+ <em>-i</em> możemy skazać plik klucza publicznego
+ (plik z rozszerzeniem .pub). Natomiast jeśli chcemy się uwierzytelnić
+ za pomocą klucza to przy opcji <em>-i</em> polecenia <em>ssh</em>
+ podajemy plik klucza bez rozszerzenia.
+ </p>
+ <h3 id="10.3.2.sshd">10.3.2. Demon serwera - sshd</h3>
+ <p>
+ Jak możemy zdawać sobie z tego sprawę z demona nie korzysta się jak
+ z aplikacji klienckiej. Nie wydajemy poleceń, żeby go uruchomić.
+ Oczywiście możemy to zrobić, ale normalnie tego się nie robi. Demony
+ uruchamiane są za pomocą plików jednostek. Dlatego, że obsługa demona
+ różni się od obsługi klienta, w tym podrozdziale skupimy się głównie
+ zmianie konfiguracji demona <em>openssh</em>, jednak nie będziemy się
+ skupiać na wszystkich możliwych opcjach poniżej przedstawię tylko
+ te, które mogą nam się przydać na obecnym poziomie
+ <em>wtajemniczenia</em>
+ </p>
+ <p>
+ Konfiguracja demona <em>openssh</em> znajduje się w pliku:
+ <em>/etc/ssh/sshd_config</em>. W tym pliku poza instrukcją
+ <em>Include</em>, wszysktie opcje są ujęte w komentarz. Wartości
+ tych opcji zawierają rzeczywiste domyślne wartości. Jeśli więc
+ chcemy coś zmienić w konfiguracji daemona SSH, musimy usunąć
+ początkowy symbol komentarz i zmienić wartość opcji.
+ </p>
+ <ul>
+ <li><strong>Port</strong> - Czasami, aby nieco ukryć przed wścibstwem
+ zmienia się domyślny port, aby nie każdy wiedział, że można się
+ do tego systemu za pomocą SSH podłączyć. Obcnie nie przynosi to
+ rezultatów. Bezpieczeniej jest wyłączyć logowanie za pomocą
+ haseł.</li>
+ <li><strong>PermitRootLogin</strong> - Zezwolenie na logowanie się
+ jako superużytkownik. Jeśli dostęp do tego konta nie jest jakos
+ bardzo potrzebny to możemy ustawić wartość tego pola na
+ <em>no</em>. Ze względu na to, że znana jest jego potoczna nazwa
+ często jego konto pada ofiarą ataków siłowych, skupionych na
+ probach odgadnięcia hasła (Przeciwdziałanie tego typu atakom,
+ zostanie przedstawione w tym rozdziale).</li>
+ <li><strong>X11Forwarding</strong> - dość ciekawa opcja pozwala
+ uruchomić program okienkowy na serwerze, kontrolując go z
+ poziomu klienta. Proces programu uruchomiany jest na serwerze,
+ okno (np. przeglądarki, uruchamiane jest na komputerze klienta).
+ Pozwala to na konfiguracje, aplikacji wymagającej połączenia z
+ tej samej sieci co serwer lub z poziomu pętli zwrotnej, co nie
+ zawsze jest fizycznie możliwe (serwery VPS). Uruchomienie takiego
+ programu wymaga podania użycia przez klient opcji <em>-Y</em> lub
+ <em>-X</em>.</li>
+ </ul>
</div>
<p style="margin: 15px; padding: 0; outline: 0;">
2022; COPYLEFT; ALL RIGHTS REVERSED;
projects / mmdev.git / commitdiff