Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00081 004941 18972978 na godz. na dobę w sumie
Hartowanie Linuksa we wrogich środowiskach sieciowych. Ochrona serwera od TLS po Tor - książka
Hartowanie Linuksa we wrogich środowiskach sieciowych. Ochrona serwera od TLS po Tor - książka
Autor: Liczba stron: 280
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-4216-3 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> webmasterstwo >> inne
Porównaj ceny (książka, ebook (-35%), audiobook).

Bezpieczeństwo serwerów - od TLS do TOR

W dzisiejszym świecie, w którym wiele codziennych aktywności odbywa się przez internet, bardzo dużo zależy od bezpieczeństwa serwerów. Kiedy zwykli ludzie tworzą społeczności, komunikują się i robią zakupy online, hakerzy niestrudzenie przeglądają sieć, poszukując słabych punktów. Atakują różne obiekty: mogą to być agencje rządowe, elektrownie i banki, ale równie dobrze ich celem może się stać jakakolwiek sieć komputerów. Chodzi o uzyskanie wrażliwych informacji, zbiorów danych osobowych czy wreszcie przejęcie kontroli nad systemem. Co gorsza, agresorzy odnoszą sukcesy nawet w przypadku sieci, w których wdrożono złożone i kosztowne zabezpieczenia.

Dzięki tej książce poznasz sprawdzone i niezbyt skomplikowane procedury, które pozwolą Ci na zahartowanie swoich danych. Zawarte tu treści przedstawiono w sposób bardzo praktyczny, z uwzględnieniem najnowszych osiągnięć w dziedzinie zabezpieczania systemów. Najpierw zapoznasz się z ogólnym ujęciem tematyki bezpieczeństwa systemów, w tym stacji roboczych, serwerów i sieci. Następnie dowiesz się, w jaki sposób zahartować specyficzne usługi, takie jak serwery WWW, pocztę elektroniczną, systemy DNS i bazy danych. Na końcu książki znalazł się rozdział poświęcony reagowaniu na incydenty - to również jest wiedza potrzebna każdemu administratorowi.

Najciekawsze zagadnienia:

Po pierwsze: zabezpiecz swoją sieć i zahartuj swój system!


Kyle Rankin od wielu lat zajmuje się administrowaniem systemów informatycznych. Jest uznanym ekspertem w dziedzinie zabezpieczania infrastruktury, architektury, automatyzacji i rozwiązywania problemów z tym związanych. Rankin jest nagradzanym felietonistą magazynu 'Linux Journal' i przewodniczącym rady doradczej Purism. Często wygłasza referaty na konferencjach poświęconych oprogramowaniu open source i bezpieczeństwu, takich jak O'Reilly Security Conference, CactusCon, SCALE, OSCON, LinuxWorld Expo, Penguicon.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Linux Hardening in Hostile Networks: Server Security from TLS to Tor (Pearson Open Source Software Development Series) Tłumaczenie: Radosław Meryk ISBN: 978-83-283-4216-3 Authorized translation from the English language edition, entitled: LINUX HARDENING IN HOSTILE NETWORKS: SERVER SECURITY FROM TLS TO TOR; ISBN 0134173260; by Kyle Rankin; published by Pearson Education, Inc., publishing as Addison-Wesley Professional. Copyright © 2018 by Pearson Education, Inc. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. Polish language edition published by HELION S.A. Copyright © 2018. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/hartli Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treści O autorze .................................................................................9 Podzi(cid:246)kowania ........................................................................10 S(cid:228)owo wst(cid:246)pne .......................................................................11 Przedmowa .............................................................................13 Rozdzia(cid:228) 1. Ogólne poj(cid:246)cia dotycz(cid:241)ce bezpiecze(cid:254)stwa ...............................21 Cz(cid:246)(cid:264)(cid:232) 1. Podstawy zabezpiecze(cid:254) .........................................................21 Podstawowe zasady bezpiecze(cid:254)stwa ..............................................22 Podstawy bezpiecze(cid:254)stwa hase(cid:228) .....................................................25 Cz(cid:246)(cid:264)(cid:232) 2. Metody zabezpiecze(cid:254) przed do(cid:264)wiadczonymi napastnikami ......31 Najlepsze praktyki dotycz(cid:241)ce zabezpiecze(cid:254) .....................................31 Techniki (cid:228)amania hase(cid:228) ..................................................................34 Utrudnianie (cid:228)amania hase(cid:228) .............................................................38 Cz(cid:246)(cid:264)(cid:232) 3. Metody ochrony przed zaawansowanymi napastnikami .............42 Zaawansowane techniki (cid:228)amania hase(cid:228) ...........................................42 (cid:263)rodki zaradcze przeciwko zaawansowanym technikom (cid:228)amania hase(cid:228) .............................................................44 Podsumowanie ...................................................................................46 Rozdzia(cid:228) 2. Bezpiecze(cid:254)stwo stacji roboczych .............................................47 Cz(cid:246)(cid:264)(cid:232) 1. Podstawy zabezpiecze(cid:254) .........................................................48 Podstawy bezpiecze(cid:254)stwa stacji roboczych ......................................48 Podstawy bezpiecze(cid:254)stwa sieci ......................................................50 Wprowadzenie do dystrybucji Tails ..................................................52 Pobieranie, weryfikowanie i instalowanie dystrybucji Tails .................52 Pos(cid:228)ugiwanie si(cid:246) dystrybucj(cid:241) Tails ..................................................54 Cz(cid:246)(cid:264)(cid:232) 2. Dodatkowe hartowanie stacji roboczej ....................................56 Szyfrowanie dysków stacji roboczych ...............................................56 Has(cid:228)a BIOS ...................................................................................57 Utrwalanie i szyfrowanie w Tails .....................................................57 Poleć książkęKup książkę 6 Hartowanie Linuksa we wrogich (cid:264)rodowiskach sieciowych Cz(cid:246)(cid:264)(cid:232) 3. Qubes ................................................................................. 61 Wprowadzenie do Qubes ............................................................... 61 Pobieranie Qubes i instalacja ......................................................... 66 Pulpit Qubes ................................................................................. 68 Przyk(cid:228)ad kompartmentalizacji maszyn appVM .................................. 72 Split GPG ..................................................................................... 75 USB VM ....................................................................................... 76 Podsumowanie .................................................................................. 78 Rozdzia(cid:228) 3. Bezpiecze(cid:254)stwo serwerów ...................................................... 79 Cz(cid:246)(cid:264)(cid:232) 1. Podstawy bezpiecze(cid:254)stwa serwerów ....................................... 79 Podstawowe praktyki w zakresie zabezpieczania serwerów ............... 79 Konfiguracja SSH .......................................................................... 81 Sudo ............................................................................................ 82 Cz(cid:246)(cid:264)(cid:232) 2. (cid:263)rednio zaawansowane techniki hartowania serwerów ............. 85 Uwierzytelnianie za pomoc(cid:241) klucza SSH .......................................... 86 AppArmor ..................................................................................... 90 Zdalne logi ................................................................................... 94 Cz(cid:246)(cid:264)(cid:232) 3. Zaawansowane techniki hartowania serwerów ........................ 96 Szyfrowanie dysku serwera ............................................................ 97 Bezpieczne alternatywy serwera NTP .............................................. 99 Uwierzytelnianie dwusk(cid:228)adnikowe za pomoc(cid:241) SSH ......................... 100 Podsumowanie ................................................................................ 103 Rozdzia(cid:228) 4. Sie(cid:232) .................................................................................... 105 Cz(cid:246)(cid:264)(cid:232) 1. Podstawowe hartowanie sieci .............................................. 106 Podstawy bezpiecze(cid:254)stwa sieci .................................................... 106 Ataki man-in-the-middle ............................................................... 108 Ustawienia firewall serwera ......................................................... 110 Cz(cid:246)(cid:264)(cid:232) 2. Sieci szyfrowane ................................................................. 118 Konfiguracja OpenVPN ................................................................. 118 Tunele SSH ................................................................................ 125 Równowa(cid:276)enie obci(cid:241)(cid:276)enia z wykorzystaniem protoko(cid:228)u SSL/TLS ..... 127 Cz(cid:246)(cid:264)(cid:232) 3. Sieci anonimowe ................................................................ 132 Konfiguracja sieci Tor .................................................................. 133 Ukryte us(cid:228)ugi Tor ......................................................................... 138 Podsumowanie ................................................................................ 140 Rozdzia(cid:228) 5. Serwery WWW ..................................................................... 141 Cz(cid:246)(cid:264)(cid:232) 1. Podstawy bezpiecze(cid:254)stwa serwerów WWW ........................... 141 Uprawnienia ............................................................................... 141 Podstawowe uwierzytelnianie HTTP ............................................... 142 Cz(cid:246)(cid:264)(cid:232) 2. HTTPS ............................................................................... 145 W(cid:228)(cid:241)czanie HTTPS ........................................................................ 146 Przekierowanie HTTP na HTTPS .................................................... 148 Poleć książkęKup książkę Spis tre(cid:264)ci 7 Odwrócone proxy HTTPS ..............................................................149 Uwierzytelnianie klienta za pomoc(cid:241) protoko(cid:228)u HTTPS .....................150 Cz(cid:246)(cid:264)(cid:232) 3. Zaawansowana konfiguracja HTTPS ......................................151 HSTS .........................................................................................151 Utajnienie przekazywania HTTPS ...................................................152 Zapory WAF ................................................................................154 Podsumowanie .................................................................................164 Rozdzia(cid:228) 6. E-mail ...................................................................................167 Cz(cid:246)(cid:264)(cid:232) 1. Podstawowe hartowanie serwerów e-mail ..............................168 Podstawy bezpiecze(cid:254)stwa poczty e-mail ........................................168 Podstawowe hartowanie serwerów e-mail ......................................170 Cz(cid:246)(cid:264)(cid:232) 2. Uwierzytelnianie i szyfrowanie ..............................................172 Uwierzytelnianie SMTP .................................................................173 SMTPS .......................................................................................175 Cz(cid:246)(cid:264)(cid:232) 3. Hartowanie zaawansowane ..................................................176 SPF ............................................................................................177 DKIM .........................................................................................182 DMARC ......................................................................................189 Podsumowanie .................................................................................193 Rozdzia(cid:228) 7. DNS .....................................................................................195 Cz(cid:246)(cid:264)(cid:232) 1. Podstawy bezpiecze(cid:254)stwa DNS ............................................196 Hartowanie autorytatywnych serwerów DNS ...................................197 Hartowanie rekursywnych serwerów DNS ......................................199 Cz(cid:246)(cid:264)(cid:232) 2. Ataki DNS Amplification i mechanizm Rate Limiting ...............200 Rejestrowanie zapyta(cid:254) DNS .........................................................201 Dynamiczne uwierzytelnianie DNS .................................................201 Cz(cid:246)(cid:264)(cid:232) 3. DNSSEC ............................................................................205 Jak dzia(cid:228)a DNS? ..........................................................................205 Bezpiecze(cid:254)stwo DNS ...................................................................206 Jak dzia(cid:228)a DNSSEC? ....................................................................207 Terminologia DNSSEC .................................................................210 Dodawanie obs(cid:228)ugi DNSSEC dla strefy ..........................................212 Podsumowanie .................................................................................215 Rozdzia(cid:228) 8. Baza danych .........................................................................217 Cz(cid:246)(cid:264)(cid:232) 1. Podstawy bezpiecze(cid:254)stwa baz danych ..................................218 Podstawowe zabezpieczenia bazy danych ......................................218 Lokalne administrowanie baz(cid:241) danych ..........................................220 Uprawnienia u(cid:276)ytkowników baz danych ..........................................223 Cz(cid:246)(cid:264)(cid:232) 2. Wzmacnianie zabezpiecze(cid:254) bazy danych ...............................226 Sieciowe mechanizmy kontroli dost(cid:246)pu do baz danych ...................227 W(cid:228)(cid:241)czanie SSL/TLS .....................................................................230 Poleć książkęKup książkę 8 Hartowanie Linuksa we wrogich (cid:264)rodowiskach sieciowych Cz(cid:246)(cid:264)(cid:232) 3. Szyfrowanie bazy danych ..................................................... 233 Szyfrowanie ca(cid:228)ego dysku ............................................................ 233 Szyfrowanie po stronie aplikacji ................................................... 234 Szyfrowanie po stronie klienta ..................................................... 237 Podsumowanie ................................................................................ 237 Rozdzia(cid:228) 9. Reagowanie na incydenty ..................................................... 239 Cz(cid:246)(cid:264)(cid:232) 1. Podstawy reagowania na incydenty ...................................... 239 Kto zajmuje si(cid:246) reagowaniem na incydenty? .................................. 239 Czy b(cid:246)dziesz (cid:264)ciga(cid:232) cyberprzest(cid:246)pc(cid:246)? .......................................... 240 Wyci(cid:241)gnij wtyczk(cid:246) ........................................................................ 240 Wykonaj obraz serwera ................................................................ 241 Przywró(cid:232) serwer do pracy ............................................................. 241 (cid:263)ledztwo .................................................................................... 242 Cz(cid:246)(cid:264)(cid:232) 2. Bezpieczne techniki tworzenia obrazu dysku ......................... 243 Wybór systemu do tworzenia obrazu ............................................. 244 Utworzenie obrazu ...................................................................... 244 Wprowadzenie w tematyk(cid:246) narz(cid:246)dzi Sleuth Kit i Autopsy ................ 244 Cz(cid:246)(cid:264)(cid:232) 3. Przyk(cid:228)adowe (cid:264)ledztwo ......................................................... 252 Reagowanie na incydenty w chmurze ............................................ 256 Podsumowanie ................................................................................ 258 Dodatek A Tor ...................................................................................... 259 Czym jest Tor? ................................................................................. 259 Dlaczego warto korzysta(cid:232) z us(cid:228)ugi Tor? ......................................... 260 Jak dzia(cid:228)a Tor? ................................................................................. 260 Zagro(cid:276)enia dla bezpiecze(cid:254)stwa ......................................................... 262 Przestarza(cid:228)e oprogramowanie us(cid:228)ugi Tor ....................................... 263 Wycieki to(cid:276)samo(cid:264)ci ..................................................................... 263 Dodatek B SSL/TLS .............................................................................. 265 Czym jest TLS? ................................................................................ 265 Dlaczego warto korzysta(cid:232) z TLS? .................................................. 266 Jak dzia(cid:228)a TLS? ................................................................................ 266 Odszyfrowanie nazw szyfrów ........................................................ 268 Polecenia przydatne do rozwi(cid:241)zywania problemów z TLS ...................... 268 Przegl(cid:241)danie zawarto(cid:264)ci certyfikatu .............................................. 268 Przegl(cid:241)danie zawarto(cid:264)ci (cid:276)(cid:241)dania CSR ........................................... 269 Rozwi(cid:241)zywanie problemów w komunikacji z TLS ............................. 269 Zagro(cid:276)enia dla bezpiecze(cid:254)stwa ......................................................... 269 Ataki man-in-the-middle ............................................................... 269 Ataki degradacji protoko(cid:228)u ........................................................... 270 Utajnianie przekazywania ............................................................. 271 Skorowidz ............................................................................ 273 Poleć książkęKup książkę 3 Bezpieczeństwo serwerów eśli ktoś ma zamiar włamać się do serwera, to najbardziej prawdopodobną drogą ataku jest zazwyczaj luka w aplikacji webowej albo innej usłudze bądź hostach serwerów. J Napastnik może również dostać się do systemu przez SSH. Sposoby hartowania popularnych aplikacji, dla których serwer może być hostem, omówimy w innych rozdziałach, dlatego w tym skoncentruję się bardziej na ogólnych technikach zabezpieczania niemal dowolnych serwerów — niezależnie od tego, czy jest to host dla serwisu WWW, poczty e-mail, serwisu DNS, czy też czegoś zupełnie innego. W tym rozdziale omówiono szereg różnych technik hartowania SSH, a także opisano sposób ograniczania szkód, jakie może wyrządzić napastnik lub nawet złośliwy pracownik, jeśli uzyska dostęp do serwera z takimi narzędziami, jak AppArmor i sudo. Opiszemy także zagadnienia związane z szyfrowaniem dysków w celu ochrony danych w stanie spoczynku, a także sposób konfigurowania zdalnego serwera syslog, aby utrudnić napastnikowi zacieranie śladów. Cz(cid:246)(cid:264)(cid:232) 1. Podstawy bezpiecze(cid:254)stwa serwerów Zanim przejdziemy do konkretnych metod hartowania, zaczniemy od pewnych podstawowych zasad zabezpieczania serwerów. Przy próbie zabezpieczenia serwera ważne jest, by podchodzić do niego z odpowiednim nastawieniem. Mając to na uwadze, warto pamiętać o kilku zasadach, którymi należy się kierować, niezależnie od serwera, który zabezpieczamy. Podstawowe praktyki w zakresie zabezpieczania serwerów Do podstawowych zasad zabezpieczania serwerów należą w szczególności zasada najmniejszych uprawnień, zachowania prostoty oraz dbania o utrzymanie aktualności. Zasada najmniejszych uprawnie(cid:254) Zasadę najmniejszych uprawnień będziemy stosowali w całej książce (na przykład w rozdziale 4., „Sieć”, przy okazji omawiania reguł zapór firewall), ale ogólnie rzecz biorąc, powinniśmy dążyć do tego, aby użytkownicy i aplikacje na hoście mieli tylko takie uprawnienia, jakie są konieczne Poleć książkęKup książkę 80 Rozdzia(cid:228) 3. Bezpiecze(cid:254)stwo serwerów do wykonania ich pracy, i nic ponadto. Na przykład, konta na serwerach mogą mieć wszyscy programiści, lecz dostęp dla użytkownika root powinni otrzymać tylko administratorzy systemów. Można też pójść dalej i przydzielić przeciętnemu programiście dostęp do powłoki środowiska deweloperskiego oraz ograniczyć dostęp do serwerów produkcyjnych tylko dla administratorów systemu i członków personelu pomocniczego, dla których taki dostęp jest niezbędny. Stosowanie tej zasady do aplikacji oznacza, że aplikacja powinna działać z uprawnieniami użytkownika root tylko wtedy, jeśli jest to absolutnie konieczne; w przeciwnym razie powinna ona działać z uprawnieniami jakiegoś innego konta w systemie. Jednym z najczęstszych powodów, dla których aplikacje potrzebują dostępu roota, jest otwieranie portu o niskim numerze (otwieranie każdego portu o numerach niższych niż 1025 wymaga uprawnień użytkownika root). Dobrym przykładem stosowania tej zasady są serwery WWW. Otwarcie portów 80 i 443 wymaga dostępu root, jednak gdy te porty już zostaną otwarte, wtedy przeciętny proces roboczy serwera WWW działa z uprawnieniami mniej uprzywilejowanego użytkownika (np. użytkownika www-data). Obecnie powszechnie stosowaną praktyką dla aplikacji webowych jest nasłuchiwanie na portach o wyższych numerach, na przykład 3000 lub 8080. Dzięki temu aplikacje webowe mogą działać z uprawnieniami zwykłego użytkownika. To ma by(cid:232) proste! Przy prostym serwerze łatwiej zapewnić bezpieczeństwo niż w przypadku skomplikowanego. Należy unikać instalowania i uruchamiania dodatkowych usług (zwłaszcza usług sieciowych), które nie są potrzebne. Dzięki temu mamy mniej aplikacji, które mogą mieć luki w zabezpieczeniach i dla których należy śledzić dostępność aktualizacji bezpieczeństwa. Twojemu zespołowi oraz audytorom zewnętrznym będzie łatwiej zweryfikować konfigurację, jeśli będziesz utrzymywał pliki danych i wykonywalne w standardowych miejscach i, o ile to możliwe, starał się zachowywać ustawienia domyślne. Prostota jest również ważna podczas projektowania ogólnej architektury Twojego środowiska. Im bardziej skomplikowana architektura i im więcej „ruchomych części”, tym trudniej ją zrozumieć i zabezpieczyć. Jeśli Twój schemat sieci wygląda jak talerz spaghetti, to być może powinieneś rozważyć uproszczenie sposobu komunikowania się serwerów w środowisku. Kiedy dotrzemy do rozdziału o bezpieczeństwie sieci (rozdział 4.), utrzymanie prostoty również ułatwi nam zadanie. Zachowaj aktualno(cid:264)(cid:232) swoich serwerów Nowe luki w zabezpieczeniach aplikacji lub bibliotek są znajdowane przez cały czas. Prostym sposobem na pozostanie na szczycie bezpieczeństwa serwerów jest subskrypcja listy mailingowej poświęconej bezpieczeństwu Twojej dystrybucji, a następnie obserwowanie ogłaszanych luk w zabezpieczeniach w celu ustalenia priorytetów aktualizacji serwerów. Im bardziej jednorodne środowisko, tym łatwiej utrzymać aktualność różnych wersji oprogramowania. Zatem będzie nam łatwiej, jeśli będziemy trzymać się jednej dystrybucji Linuksa oraz jej określonej wersji. Listy mailingowe dotyczące bezpieczeństwa dystrybucji Linuksa nie obejmują jednak wykorzystywanego oprogramowania firm trzecich. Z tego powodu warto zapisać się do pomocniczych list dostępnych dla tych produktów. Poleć książkęKup książkę Cz(cid:246)(cid:264)(cid:232) 1. Podstawy bezpiecze(cid:254)stwa serwerów 81 Konfiguracja SSH Jedną z najbardziej popularnych usług niemal na każdym serwerze jest SSH. W przeszłości administratorzy używali takich narzędzi, jak telnet, które wysyłały wszystko (w tym hasła!) w formacie zwykłego tekstu, natomiast SSH szyfruje komunikację pomiędzy użytkownikiem a serwerem. Chociaż ta cecha sama w sobie jest usprawnieniem zabezpieczeń, to niestety samo jej stosowanie nie wystarczy. W tej części omówimy kilka podstawowych technik hartowania SSH, które powinniśmy zastosować na wszystkich naszych serwerach. Wy(cid:228)(cid:241)cz logowanie na koncie u(cid:276)ytkownika root Jedną z najprostszych czynności, które można wykonać, aby Twoja konfiguracja SSH stała się bardziej bezpieczna, jest wyłączenie logowania na koncie root. W dalszej części tego rozdziału opowiemy o tym, jak można uniknąć logowania się z hasłem użytkownika root za pomocą narzędzia sudo (w niektórych systemach takie podejście jest domyślne), natomiast w tym przypadku chodzi o ograniczenie możliwości logowania się z tożsamością root za pomocą hasła, kluczy SSH lub dowolnym innym sposobem. Ze względu na możliwości, jakie ma użytkownik root, po prostu bezpieczniej jest wyeliminować możliwość bezpośredniego zalogowania się napastników z uprawnieniami tego użytkownika. Zamiast tego administratorzy powinni logować się jako zwykli użytkownicy, a następnie korzystać z lokalnych narzędzi, takich jak sudo, aby stać się użytkownikiem root. Aby wyłączyć logowanie na koncie root na serwerze, wystarczy wyedytować plik konfiguracyjny serwera SSH (zwykle w pliku /etc/ssh/sshd_config) i zmienić ustawienie PermitRootLogin yes na PermitRootLogin no Następnie należy ponownie uruchomić usługę SSH. W zależności od systemu można to zrobić za pomocą jednego z poniższych poleceń: $ sudo service ssh restart $ sudo service sshd restart Wy(cid:228)(cid:241)czenie protoko(cid:228)u 1 Stary protokół SSH 1 ma szereg znanych luk w zabezpieczeniach, więc jeśli w Twojej dystrybucji jeszcze go nie wyłączono, trzeba to zrobić. Znajdź wiersz Protocol w pliku /etc/ssh/sshd_config i zadbaj o to, aby miał następujący format: Protocol 2 Jeśli byłeś zmuszony do wprowadzenia zmian w pliku, pamiętaj o ponownym uruchomieniu usługi SSH. Poleć książkęKup książkę 82 Rozdzia(cid:228) 3. Bezpiecze(cid:254)stwo serwerów Sudo W dawnych czasach, kiedy administrator musiał wykonać jakieś działania z uprawnieniami użytkownika root, logował się bezpośrednio jako użytkownik root albo zostawał nim dzięki użyciu takiego narzędzia jak su. Z takim podejściem wiązały się jednak pewne problemy. Zachęcało ono użytkowników do tego, aby pozostawali zalogowani w systemie jako root. Ponieważ root może zrobić w systemie praktycznie wszystko, co chce, to błędy popełnione jako root mogą mieć znacznie gorsze skutki niż w przypadku działań wykonanych z tożsamością zwykłego użytkownika. Ponadto, z punktu widzenia kosztów administracyjnych, w przypadku gdy było kilku administratorów i wszyscy mieli dostęp do serwera z uprawnieniami root, trzeba było stworzyć wspólne hasło, znane dla nich wszystkich. Gdy jeden z administratorów opuszczał firmę, pozostali członkowie zespołu musieli zadbać o zmianę haseł dla wszystkich współdzielonych kont. Narzędzie sudo pomaga rozwiązać wiele z tych problemów dotyczących bezpieczeństwa i zapewnia znacznie silniejszy model zabezpieczeń, który pomaga trzymać się zasady najmniejszych uprawnień. Dzięki sudo administrator może zdefiniować grupy użytkowników, którzy mogą wykonywać zadania z tożsamością innych użytkowników, w tym użytkownika root. Narzędzie sudo ma kilka zalet w porównaniu z su: (cid:132) Każdy użytkownik wprowadza własne hasło, a nie hasło uprzywilejowanego konta. To oznacza, że nie trzeba już zarządzać wspólnymi hasłami do uprzywilejowanych kont. Jeśli użytkownik opuszcza firmę, trzeba tylko wyłączyć jego konto. Oznacza to również, że administratorzy w ogóle nie muszą utrzymywać w systemie haseł dla kont związanych z rolami (w tym użytkownika root). Dzięki temu użytkownicy lub cyberprzestępcy w wyniku odgadnięcia hasła nie mogą uzyskać uprawnień, których nie powinni mieć. (cid:132) Narzędzie sudo umożliwia szczegółową kontrolę dostępu. W przypadku narzędzia su dostęp do uprawnień użytkownika jest działaniem w rodzaju „wszystko albo nic”. Jeśli mogę skorzystać z su, aby uzyskać uprawnienia użytkownika root, to mogę w jego imieniu zrobić wszystko, co chcę. Choć oczywiście można utworzyć reguły sudo, które pozwalają na taki sam poziom dostępu, to można również ograniczyć uprawnienia użytkowników tak, aby mogli wykonywać tylko określone polecenia jako root lub jako inny użytkownik. (cid:132) Narzędzie sudo ułatwia ochronę uprzywilejowanych kont. Choć oczywiście można skorzystać z sudo, aby uzyskać kompletny dostęp do powłoki użytkownika root, najprostsze wywołanie polecenia sudo to po prostu sudo oraz nazwa polecenia, które ma być uruchomione w imieniu użytkownika root. Dzięki temu z łatwością możemy uruchamiać uprzywilejowane polecenia, kiedy jest taka potrzeba, a przez pozostały czas pracować jako zwykły użytkownik. (cid:132) Narzędzie sudo zapewnia tzw. ścieżkę audytu (ang. audit trail). Gdy użytkownik systemu używa sudo, mechanizm audytu śledzi, jaki użytkownik korzystał z sudo, jakie polecenia uruchamiał i kiedy. Rejestrowane są również próby użytkowników skorzystania z sudo w przypadku, gdy nie mają takich uprawnień. Poleć książkęKup książkę Cz(cid:246)(cid:264)(cid:232) 1. Podstawy bezpiecze(cid:254)stwa serwerów 83 Dzięki temu generowana jest ścieżka audytu, której administrator może później użyć w celu śledzenia prób nieautoryzowanego dostępu do systemu. Przyk(cid:228)ady u(cid:276)ycia sudo i najlepsze praktyki Narzędzie sudo, podobnie jak większość mechanizmów kontroli dostępu, oferuje szeroki zbiór opcji konfiguracyjnych oraz metod grupowania użytkowników, ról i poleceń. Ta konfiguracja zazwyczaj jest zapisana w pliku /etc/sudoers, chociaż w nowoczesnych systemach często występuje katalog /etc/sudoers.d, dzięki któremu można lepiej zorganizować specyficzne zestawy reguł sudo w osobnych plikach. Strona podręcznika man sudoers (wpisz polecenie man sudoers) zawiera wyczerpujące szczegóły na temat budowania własnych złożonych reguł sudo. Dostępnych jest również wiele innych podręczników. Zamiast cytowania tej dokumentacji w tym miejscu opiszę niektóre najlepsze praktyki dotyczące reguł sudo oraz zaprezentuję kilka użytecznych przykładów z nimi związanych. Jednak na początek przyjrzyjmy się uniwersalnemu poleceniu sudo: root ALL=(ALL) ALL To polecenie pozwala użytkownikowi root uruchamiać w systemie dowolne polecenie w imieniu dowolnego użytkownika. Pierwsza kolumna określa nazwę użytkownika lub grupy, której dotyczy reguła sudo; w tym przypadku to jest użytkownik root. Druga kolumna pozwala określić konkretne hosty, do których ma zastosowanie ta reguła sudo, albo ALL, jeśli odnosi się ona do dowolnego hosta. W następnym wpisie, podanym w nawiasach, znajduje się nazwa użytkownika bądź lista użytkowników (oddzielonych przecinkami w przypadku więcej niż jednego użytkownika) — tutaj są to wszyscy użytkownicy. Ostatnia kolumna to rozdzielona przecinkami lista konkretnych programów wykonywalnych w systemie, które można uruchamiać z tymi podwyższonymi uprawnieniami. W tym przypadku są to wszystkie polecenia. (cid:132) Użyj visudo do edycji pliku /etc/sudoers. Możesz odczuwać pokusę, aby po prostu uruchomić swój ulubiony edytor tekstu i bezpośrednio wyedytować plik /etc/sudoers. Problem jednak w tym, że jeśli przypadkowo popełnisz literówkę w pliku /etc/sudoers, możesz całkowicie zablokować sobie dostęp do konta root! Narzędzie visudo przeprowadza sprawdzanie składni pliku przed jego zapisaniem, dlatego nie ryzykujemy zapisania nieprawidłowego pliku. (cid:132) Przydzielaj dostęp grupom użytkowników, a nie konkretnym użytkownikom. Stosowanie tej zasady ma większe znaczenie dla wygody administratorów niż dla bezpieczeństwa, ale sudo pozwala na dostęp do grupy w systemie zamiast do konkretnego użytkownika. Oto kilka przykładów reguł sudo, które możesz zastosować w swoim systemie w celu zapewnienia administratorom dostępu z uprawnieniami użytkownika root: admin ALL=(ALL:ALL) ALL wheel ALL=(ALL:ALL) ALL sudo ALL=(ALL:ALL) ALL Poleć książkęKup książkę 84 Rozdzia(cid:228) 3. Bezpiecze(cid:254)stwo serwerów Każda z tych reguł jest równoznaczna z dostępem root. Pozwalają one wcielić się w każdego użytkownika w systemie i uruchomić w imieniu tego użytkownika dowolne polecenie. Grupy admin, wheel i sudo to często wykorzystywane grupy w systemie, które mogą być używane w określonej dystrybucji do zdefiniowania tych użytkowników, którzy mogą uzyskać uprawnienia root. Spróbujmy zaprezentować bardziej użyteczny przykład. Załóżmy, że jesteś administratorem pewnej grupy serwerów tomcat, a deweloperzy potrzebują dostępu do lokalnego użytkownika tomcat w środowisku deweloperskim, aby mogli rozwiązywać problemy w swoim kodzie. Gdyby na przykład wszyscy użytkownicy w grupie należeli do grupy developers, moglibyśmy dodać do pliku /etc/sudoers następującą regułę: developers ALL=(tomcat) ALL (cid:132) Maksymalnie ograniczaj dostęp do niektórych poleceń. Choć oczywiście łatwiej jest po prostu pozwolić komuś uruchamiać wszystkie polecenia jako specyficzny użytkownik, to jeśli chcemy przestrzegać zasady najmniejszych uprawnień, powinniśmy zapewnić użytkownikom dostęp tylko do tych uprzywilejowanych poleceń, które są im potrzebne. Jest to szczególnie ważne w przypadku udzielania dostępu root. Na przykład, jeśli administratorzy baz danych (DBA) potrzebują uruchomienia polecenia psql jako użytkownicy postgres, żeby mieć większą kontrolę nad konfiguracją bazy danych na poziomie systemu, to łatwym sposobem rozwiązania tego problemu jest dodanie następującej reguły: dbas ALL=(postgres) ALL Problem w tym, że niekoniecznie chcę lub potrzebuję, aby administratorzy DBA robili coś więcej niż uruchamianie psql, dlatego mógłbym ograniczyć regułę tylko do tego polecenia, którego administratorzy potrzebują: dbas ALL=(postgres) /usr/bin/psql (cid:132) Zawsze używaj pełnej ścieżki do skryptów. Podczas pisania reguł sudo zawsze pamiętaj o podawaniu kompletnej ścieżki do programu wykonywalnego, który użytkownik ma uruchomić. W przeciwnym razie, gdybym po prostu podał psql zamiast /usr/bin/psql, złośliwy użytkownik mógłby utworzyć lokalny skrypt, nazwać go psql i wpisać w nim wszystko, co mu się tylko podoba. (cid:132) Twórz skrypty-wrappery w celu ograniczenia poleceń wysokiego ryzyka do specyficznych argumentów. W wielu przypadkach, gdy piszesz reguły sudo, ostatecznie przydzielasz użytkownikom szersze uprawnienia niż te, których naprawdę potrzebują. Na przykład gdybym chciał umożliwić użytkownikowi zrestartowanie usługi Nginx, mógłbym dać mu dostęp do polecenia service: bob ALL=(root) /usr/sbin/service To oczywiście dałoby mu możliwość zrestartowania Nginx, ale jednocześnie także pozwoliłoby mu uruchamiać i zatrzymywać dowolne inne usługi w systemie. Poleć książkęKup książkę Cz(cid:246)(cid:264)(cid:232) 2. (cid:263)rednio zaawansowane techniki hartowania serwerów 85 W tych okolicznościach lepiej jest stworzyć niewielki skrypt-wrapper o nazwie /usr/local/bin/restart_nginx o następującej treści: #!/bin/bash /usr/sbin/service nginx restart Następnie wystarczy napisać regułę sudo, która daje dostęp tylko do tego skryptu: bob ALL=(root) /usr/local/bin/restart_nginx Gdybym chciał zezwolić użytkownikowi bob także na zatrzymywanie i uruchamianie usługi Nginx, mógłbym tak zmodyfikować istniejący skrypt, aby akceptował argument wejściowy (który należałoby dokładnie sprawdzić), albo stworzyć dwa nowe skrypty dla funkcji stop i start w ten sam sposób, jak dla operacji restart. W tym drugim przypadku należałoby zaktualizować regułę sudo do następującej postaci: bob ALL=(root) /usr/local/bin/restart_nginx, /usr/local/bin/stop_nginx, /usr/local/bin/start_nginx Należy zadbać o to, aby właścicielem skryptów-wrapperów był tylko użytkownik root oraz by tylko root miał do nich prawa zapisu (chmod 775). Ogólnie rzecz biorąc, należy zachować ostrożność podczas uruchamiania wszelkich skryptów, za pomocą których użytkownik może wykonywać polecenia powłoki (np. vi). (cid:132) Powstrzymaj się od pisania reguł sudo NOPASSWD, jeśli nie jest to absolutnie niezbędne. Polecenie sudo dostarcza flagę o nazwie NOPASSWD, która zwalnia użytkownika z obowiązku wprowadzania hasła podczas uruchamiania polecenia sudo. W ten sposób można zaoszczędzić trochę czasu, jednak równocześnie eliminujemy jedno z podstawowych zabezpieczeń, jakie gwarantuje polecenie sudo, mianowicie konieczność przeprowadzenia uwierzytelniania przez użytkownika, zanim sudo pozwoli mu uruchomić polecenie. Niemniej jednak istnieją uzasadnione powody korzystania z flagi NOPASSWD. W szczególności jest to potrzebne w sytuacji, gdy chcemy uruchomić polecenie z konta określonej roli w systemie, która sama nie ma hasła. Na przykład możesz zezwolić użytkownikowi bazy danych postgres na inicjowanie zadania cron, które uruchamia z uprawnieniami użytkownika root specjalny skrypt tworzący kopię zapasową bazy danych, a konto roli postgres nie ma hasła. W takim przypadku należy dodać regułę sudo w następującej postaci: postgres ALL=(root) NOPASSWD: /usr/local/bin/backup_databases Cz(cid:246)(cid:264)(cid:232) 2. (cid:263)rednio zaawansowane techniki hartowania serwerów Średnio zaawansowane techniki hartowania serwerów obejmują uwierzytelnianie za pomocą klucza SSH, mechanizm AppArmor i zdalne logowanie. Poleć książkęKup książkę 86 Rozdzia(cid:228) 3. Bezpiecze(cid:254)stwo serwerów Uwierzytelnianie za pomoc(cid:241) klucza SSH Większość administratorów korzysta ze swoich komputerów przez SSH i, niestety, czasami hakerzy też! Jeśli masz serwer udostępniony w publicznym internecie i kiedykolwiek zadałeś sobie trud, żeby sprawdzić logi uwierzytelniania (w systemach opartych na Debianie można je znaleźć w pliku /var/log/auth.log), możesz się zdziwić, jak wiele prób połączeń przez SSH dociera do Twojej maszyny. Są to ślady ataków siłowych przez SSH. Wielu cyberprzestępców doszło do wniosku, że bardzo często najprostszym sposobem włamania się do serwera Linux jest odgadnięcie hasła użytkownika. Jeśli jeden z użytkowników (lub konto popularnej roli, takie jak oracle lub nagious) używa hasła, które znajduje się w słowniku napastnika, jest tylko kwestią czasu, kiedy skrypt odgadnie prawidłowe hasło. Zatem w jaki sposób możemy się bronić przed siłowymi atakami SSH? Jeden ze sposobów to audyt haseł użytkowników i ścisłe egzekwowanie strategii złożoności haseł. Inny może polegać na wybraniu dla SSH innego portu w nadziei na to, że utajnienie portu nas ochroni. Jeszcze inny obejmuje skonfigurowanie systemów, które parsują próby łączenia się przez SSH i modyfikują reguły zapory firewall w przypadku, gdy zbyt wiele prób pochodzi z jednego adresu IP. Oprócz tego, że w ten sposób ryzykujemy zablokowaniem samych siebie, to napastnicy często się „przeprowadzają” i z jednego adresu IP wykonują tylko kilka prób. Następnie przenoszą się na inny host, należący do zazwyczaj ogromnego botnetu. Każda z wymienionych metod może pomóc zmniejszyć ryzyko przeprowadzenia udanego siłowego ataku SSH, ale nie jest w stanie całkowicie go wyeliminować. Jeśli chcesz całkowicie wykluczyć możliwość przeprowadzania siłowych ataków SSH, to najlepsza metoda jest jednocześnie jedną z najprostszych: należy wyeliminować logowanie do SSH za pomocą haseł. Jeśli usuniesz z równania logowania do SSH za pomocą hasła, to cyberprzestępcy będą mogli odgadywać hasła do woli, a nawet jeśli im się to uda, to i tak nie zdołają się zalogować do SSH. Jeśli wykluczymy logowanie za pomocą haseł, to jak zdołamy zalogować się do SSH? Najbardziej popularnym zamiennikiem logowania do SSH za pomocą haseł jest używanie par kluczy SSH. Dzięki stosowaniu par kluczy SSH klient (laptop lub inny serwer) ma zarówno klucz publiczny, jak i prywatny. Klucz prywatny jest tajny i przechowywany na Twoim komputerze osobistym, natomiast klucz publiczny jest kopiowany do pliku ~/.plik SSH/authorized_keys na zdalnym serwerze, na który chcemy się zalogować. Tworzenie kluczy SSH Pierwszy krok polega na utworzeniu pary kluczy SSH. Robi się to za pomocą narzędzia ssh-keygen. Choć ten program akceptuje wiele różnych opcji i typów kluczy, my skorzystamy z tych, które powinny działać na wielu serwerach: $ ssh-keygen -t rsa -b 4096 Opcja -t określa typ klucza (RSA), natomiast -b definiuje rozmiar klucza w bitach (4096 bitów). Taki 4096-bitowy klucz RSA powinien być obecnie akceptowalny. Po uruchomieniu polecenia wyświetli się pytanie o podanie opcjonalnego hasła wymaganego do odblokowania klucza. Jeśli nie wybierzesz hasła, będziesz mógł łączyć się przez SSH do zdalnych serwerów bez konieczności wprowadzania hasła. Wadą takiego podejścia jest to, że jeśli ktoś uzyska Poleć książkęKup książkę Cz(cid:246)(cid:264)(cid:232) 2. (cid:263)rednio zaawansowane techniki hartowania serwerów 87 dostęp do klucza prywatnego (domyślnie jest zapisany w pliku ~/.ssh/id_rsa), to będzie mógł od razu go użyć w celu nawiązania połączenia przez SSH do Twoich serwerów. Radzę ustawić hasło. W jednym z kolejnych punktów opowiem, jak wykorzystać narzędzie ssh-agent w celu buforowania hasła w pamięci podręcznej przez określony czas (w podobny sposób hasła sudo są często buforowane przez kilka minut, dzięki czemu nie trzeba wpisywać ich wraz z każdym poleceniem). Po zakończeniu działania polecenia powstaną dwa nowe pliki: klucz prywatny w pliku ~/.ssh/id_rsa oraz klucz publiczny w pliku ~/.ssh/id_rsa.pub. Klucz publiczny można bezpieczne współdzielić z innymi osobami. Jest on zapisany w pliku, który będzie skopiowany na zdalne serwery. Z kolei klucz prywatny powinien być chroniony tak samo jak hasła lub inne tajne informacje i nie powinien być współdzielony z innymi. Można rozważyć opcję tworzenia różnych kluczy SSH do różnych celów. Podobnie jak posługiwanie się różnymi hasłami do różnych kont, korzystanie z różnych kluczy SSH dla różnych kont jest zgodne z zasadą kompartmentalizacji i pomaga chronić nasze zasoby w sytuacji, gdy jeden z kluczy zostanie skradziony. Aby przechowywać parę kluczy w pliku z inną nazwą niż domyślna, należy użyć opcji -f, która pozwala wskazać inny plik. Na przykład, jeśli używasz tego samego komputera do użytku osobistego i do pracy, właściwe będzie stworzenie oddzielnej pary kluczy dla każdego środowiska: $ ssh-keygen -t rsa -b 4096 -f ~/.ssh/workkey W wyniku wykonania powyższego polecenia w katalogu ~/.ssh/ zostaną utworzone pliki workkey i workkey.pub. Kopiowanie kluczy SSH na inne hosty Po wygenerowaniu kluczy SSH należy skopiować zawartość klucza publicznego do pliku ~/.ssh/authorized_keys na zdalnym serwerze. Chociaż można połączyć się przez SSH ze zdalnym serwerem i zrobić to ręcznie, łatwiej to zrobić za pomocą narzędzia o nazwie ssh-copy-id. Na przykład, jeśli chcę skopiować klucz publiczny na serwer o nazwie web1.example.com, a mój login to kyle, mogę wpisać następujące polecenie: $ ssh-copy-id kyle@web1.example.com Należy zastąpić nazwę użytkownika i nazwę serwera nazwą użytkownika i serwera, których będziesz używać do zalogowania się na zdalny serwer. W tym momencie wyświetli się pytanie o hasło potrzebne do zalogowania na zdalnym komputerze, ale kiedy polecenie zostanie wykonane, będzie to ostatni raz! Podobnie jak w przypadku zwykłego logowania przez SSH, jeśli Twoja lokalna nazwa użytkownika jest taka sama, jak nazwa użytkownika na zdalnym serwerze, możesz pominąć ją w poleceniu. Polecenie ssh-copy-id domyślnie skopiuje plik id_rsa.pub, ale jeśli para kluczy ma inną nazwę, to możesz użyć argumentu -i, aby podać inny klucz publiczny. Gdybyśmy więc chcieli użyć niestandardowego pliku workkey, który stworzyliśmy wcześniej, napisalibyśmy: $ ssh-copy-id -i ~/.ssh/workkey.pub kyle@web1.example.com Poleć książkęKup książkę 88 Rozdzia(cid:228) 3. Bezpiecze(cid:254)stwo serwerów Przydatną własnością polecenia ssh-copy-id jest to, że dba ono o ustawienie odpowiednich uprawnień do katalogu ~/.ssh, jeśli dotychczas nie zostały ustawione (jego właścicielem powinien być uwierzytelniany użytkownik oraz powinny być do niego ustawione uprawnienia 700). Polecenie tworzy także plik authorized_keys, jeśli zachodzi taka potrzeba. To pomaga uniknąć wielu kłopotów związanych z konfigurowaniem kluczy SSH wynikających z niewłaściwych uprawnień do lokalnego bądź zdalnego katalogu ~/.ssh albo lokalnych plików kluczy. Po zakończeniu działania polecenia ssh-copy-id powinno nam się udać nawiązać połączenie przez SSH ze zdalnym serwerem bez podawania hasła. Jeśli ustawiliśmy hasło do klucza SSH, to teraz zostanie wyświetlony monit o jego podanie. Mam jednak nadzieję, że wybrałeś inne hasło do klucza niż hasło dostępu do zdalnego serwera. Dzięki temu będziesz mógł łatwiej zaobserwować, w jaki sposób działają klucze. Wy(cid:228)(cid:241)czanie uwierzytelniania za pomoc(cid:241) has(cid:228)a Gdy jesteś w stanie zalogować się do komputera przez SSH z wykorzystaniem kluczy, możesz wyłączyć możliwość uwierzytelniania za pomocą hasła. Podczas realizacji tego kroku należy oczywiście zachować ostrożność, ponieważ jeśli z jakiegoś powodu Twoje klucze przestaną działać, a wyłączysz sprawdzanie hasła, to ryzykujesz zablokowaniem dostępu do serwera. Jeśli dokonujesz tranzycji maszyny używanej przez kilka osób z uwierzytelniania za pomocą haseł na klucze, powinieneś zadbać o to, aby przed wyłączeniem uwierzytelniania za pomocą haseł wszyscy użytkownicy przesłali swoje klucze na serwer. W przeciwnym razie ktoś z uprawnieniami użytkownika root będzie musiał ręcznie zaktualizować plik ~/.ssh/authorized_keys kluczem publicznym takich użytkowników. Aby wyłączyć uwierzytelnianie za pomocą haseł, nawiąż połączenie przez SSH ze zdalnym serwerem i zdobądź uprawnienia użytkownika root. Następnie wyedytuj plik /etc/ssh/sshd_config i zmień wiersz PasswordAuthentication yes na PasswordAuthentication no Następnie uruchom ponownie usługę SSH. W zależności od systemu należy w tym celu skorzystać z jednego z następujących poleceń: $ sudo service ssh restart $ sudo service sshd restart Ponieważ nie chcesz dopuścić do zablokowania dostępu do serwera, zachowaj aktywną bieżącą sesję SSH. Zamiast tego otwórz nowy terminal i spróbuj połączyć się przez SSH z serwerem. Jeśli możesz zalogować się przez SSH, to znaczy, że Twoje klucze działają, a tranzycja przebiegła pomyślnie. Jeśli nie, uruchom polecenie ssh z opcją -vvv, aby uzyskać bardziej szczegółowe błędy. Dla bezpieczeństwa należy także cofnąć zmiany w pliku /etc/ssh/sshd_config i uruchomić usługę SSH ponownie. Dzięki temu uzyskasz pewność, że nie zostaniesz całkowicie zablokowany podczas rozwiązywania problemów. Poleć książkęKup książkę Cz(cid:246)(cid:264)(cid:232) 2. (cid:263)rednio zaawansowane techniki hartowania serwerów 89 Praca z kluczami SSH chronionymi has(cid:228)em Niektórym administratorom podoba się wygoda korzystania z kluczy SSH, które zostały stworzone bez hasła. Możesz zalogować się przez SSH natychmiast, bez konieczności wprowadzania hasła. Może to być bardzo wygodne. Jeśli korzystasz z systemu kontroli wersji, takiego jak git, przez SSH, to prawdopodobnie wolałbyś uniknąć konieczności wprowadzania hasła za każdym razem, gdy pobierasz źródła ze zdalnych repozytoriów lub wprowadzasz zmiany. Wadą tego podejścia jest to, że bez klucza SSH zabezpieczonego hasłem bezpieczeństwo Twoich serwerów jest tylko tak dobre, jak bezpieczny jest Twój prywatny klucz SSH. Jeśli ktoś zdobędzie plik ~/.ssh/id_rsa, będzie mógł natychmiast uzyskać dostęp do wszystkich serwerów, do których ma dostęp właściciel tego pliku. W przypadku klucza SSH zabezpieczonego hasłem, nawet jeśli dojdzie do przejęcia klucza prywatnego, napastnik nadal będzie musiał odgadnąć hasło, aby odblokować klucz. W ten sposób co najmniej zyskamy czas na stworzenie i zainstalowanie nowego klucza. W zależności od tego, kim jest napastnik, może to oznaczać, że klucz chroniony hasłem nigdy nie zostanie złamany. Stosowanie kluczy zabezpieczonych hasłem jest szczególnie ważne w przypadku, gdy klucze są przechowywane w systemach, w których konto root jest współdzielone z innymi administratorami. Bez zabezpieczania hasłem każdy administrator z uprawnieniami użytkownika root mógłby posłużyć się Twoimi poświadczeniami w celu zalogowania się na serwerach. W przypadku stosowania kluczy SSH zabezpieczonych hasłem nie musisz rezygnować z wygody. Dostępne są narzędzia, dzięki którym posługiwanie się kluczami SSH chronionymi hasłami jest prawie tak samo wygodne, jak korzystanie z każdej innej metody, a dodatkowo gwarantuje Ci większe bezpieczeństwo. Podstawowym narzędziem, dzięki któremu zarządzanie hasłami zabezpieczającymi klucze SSH staje się łatwiejsze, jest program ssh-add. Program ten jest częścią narzędzia ssh-agent, które pozwala wprowadzić hasło raz, a następnie buforować odblokowany klucz w pamięci RAM z wykorzystaniem agenta SSH. W większości współczesnych komputerów stacjonarnych z systemem Linux agent SSH działa w tle (lub za pośrednictwem wrappera, takiego jak keyring w środowisku Gnome). Domyślnie klucz jest buforowany w pamięci RAM na czas nieokreślony (do chwili wyłączenia systemu). Nie polecam jednak stosowania takiej praktyki. Zamiast tego zwykle stosuję narzędzie ssh-add w podobny sposób do buforowania haseł sudo. Podaję konkretny czas, przez jaki klucz ma być przechowywany w pamięci podręcznej. Po tym czasie ponownie wyświetla się monit o wprowadzenie hasła. Na przykład, gdybym chciał zbuforować klucz przez 15 minut, podobnie jak hasło sudo w niektórych systemach, mógłbym wprowadzić następujące polecenia: $ ssh-add -t 15m Enter passphrase for /home/kyle/.ssh/id_rsa: Identity added: /home/kyle/.ssh/id_rsa (/home/kyle/.ssh/id_rsa) Lifetime set to 900 seconds Zwróćmy uwagę, że podałem czas w minutach, dzięki dodaniu przyrostka „m” na końcu wartości za argumentem -t; w przeciwnym razie wartość zostałaby zinterpretowana jako czas w sekundach. Zazwyczaj klucz buforuje się na nieco dłużej. Dla przykładu, aby zbuforować klucz przez godzinę, można wprowadzić następujące polecenie: $ ssh-add -t 1h Enter passphrase for /home/kyle/.ssh/id_rsa: Poleć książkęKup książkę 90 Rozdzia(cid:228) 3. Bezpiecze(cid:254)stwo serwerów Identity added: /home/kyle/.ssh/id_rsa (/home/kyle/.ssh/id_rsa) Lifetime set to 3600 seconds Od tego momentu aż do chwili, gdy ważność klucza wygaśnie, możesz zalogować się przez SSH do serwerów i skorzystać z takich narzędzi jak Git bez wpisywania hasła. Gdy ten czas upłynie, to następnym razem, gdy skorzystasz z SSH, wyświetli się pytanie o hasło. Wtedy możesz zadecydować, aby uruchomić polecenie ssh-add ponownie. Jeśli klucz, który chcesz dodać, nie znajduje się w domyślnej lokalizacji, po prostu dodaj ścieżkę do klucza na końcu polecenia ssh-add: $ ssh-add -t 1h ~/.ssh/workkey Podoba mi się korzystanie z tego narzędzia tak, jak z osobistego timera. Kiedy rano zaczynam pracę, obliczam liczbę godzin lub minut od chwili obecnej do momentu, kiedy chcę iść na obiad, i ustawiam timer ssh-add na tę liczbę. Następnie pracuję tak jak zwykle, a kiedy następnym razem w efekcie polecenia git push lub ssh wyświetli się pytanie o hasło, to zdaję sobie sprawę, że właśnie nadszedł czas, aby udać się na przekąskę. Gdy wracam z obiadu, robię to samo, aby uzyskać powiadomienie o tym, kiedy będzie pora, by zakończyć pracę tego dnia. Oczywiście, wykorzystywanie takiego narzędzia jak to oznacza, że jeśli napastnikowi uda się złamać zabezpieczenia maszyny podczas jednego z okien czasowych, podczas których klucz SSH jest zbuforowany w pamięci podręcznej, będzie on miał dostęp do wszystkiego tego, do czego ma dostęp właściciel klucza, bez konieczności wprowadzania hasła. Jeśli pracujesz w środowisku, w którym jest to zbyt duże zagrożenie, po prostu stosuj krótkie odcinki czasu ssh-add albo uruchamiaj polecenie ssh-add -D, aby usunąć wszystkie klucze zapisane w pamięci podręcznej za każdym razem, gdy pozostawiasz swoje stanowisko komputerowe bez opieki. Możesz nawet spowodować, aby polecenie ssh-add -D było wywoływane za każdym razem, gdy uruchamiasz polecenie lock lub włączasz wygaszacz ekranu, tak by pamięć podręczna kluczy była czyszczona każdorazowo, gdy chcesz zablokować komputer. AppArmor1 Model uprawnień systemu Unix od dawna jest używany do blokowania dostępu użytkownikom i programom. Chociaż model ten nieźle się sprawdza, nadal istnieją obszary, gdzie dodatkowe mechanizmy kontroli dostępu mogą okazać się przydatne. Na przykład wiele usług nadal działa z tożsamością użytkownika root. Z tego powodu, jeśli zostaną wykorzystane, to potencjalnie napastnik może uruchamiać polecenia w pozostałej części systemu jako użytkownik root. Istnieje kilka sposobów radzenia sobie z tym problemem, w tym piaskownice, „więzienia” chroot i tak dalej. Do dystrybucji Ubuntu dołączono domyślnie instalowany system o nazwie AppArmor, który dodaje mechanizmy kontroli dostępu do specyficznych usług systemowych. AppArmor bazuje na zasadzie najmniejszych uprawnień — czyli podejmuje próbę wprowadzenia przydzielenia programom minimalnego zestawu uprawnień, jakie są niezbędne do ich funkcjonowania. AppArmor działa za pośrednictwem zbioru reguł przypisanych do 1 Rankin, Kyle; Hill, Benjamain Mako, The Official Ubuntu Server Book, wydanie trzecie, © 2014. Przedruk za zgodą Pearson Education, Inc., Nowy Jork. Poleć książkęKup książkę Cz(cid:246)(cid:264)(cid:232) 2. (cid:263)rednio zaawansowane techniki hartowania serwerów 91 konkretnych programów. Reguły te określają na przykład, które pliki lub katalogi program może czytać i zapisywać oraz które może tylko czytać. Kiedy aplikacja, która jest zarządzana przez AppArmor, narusza te mechanizmy kontroli dostępu, AppArmor zaczyna działać, zapobiega naruszeniom i rejestruje zdarzenie w logu. Niektóre usługi uwzględniają domyślnie egzekwowane profile AppArmor. W kolejnych wydaniach dystrybucji Ubuntu dodawanych jest coraz więcej takich profili. Oprócz profili domyślnych w repozytorium universe dostępny jest pakiet apparmor-profile, który możesz zainstalować, aby dodać nowe profile dla innych usług. Jeśli poznasz składnię reguł AppArmor, możesz nawet dodawać własne profile. Prawdopodobnie najprostszym sposobem pokazania, jak działa AppArmor, jest użycie przykładowego programu. Jednym z programów automatycznie zarządzanych przez AppArmor w dystrybucji Ubuntu jest serwer DNS BIND, dlatego najpierw zainstaluję pakiet BIND za pomocą polecenia sudo apt-get install bind9. Po zainstalowaniu pakietu można skorzystać z programu aa-status, aby dowiedzieć się, czy AppArmor już nim zarządza: $ sudo aa-status apparmor module is loaded. 5 profiles are loaded. 5 profiles are in enforce mode. /sbin/dhclient3 /usr/lib/NetworkManager/nm-dhcp-client.action /usr/lib/connman/scripts/dhclient-script /usr/sbin/named /usr/sbin/tcpdump 0 profiles are in complain mode. 2 processes have profiles defined. 1 processes are in enforce mode : /usr/sbin/named (5020) 0 processes are in complain mode. 1 processes are unconfined but have a profile defined. /sbin/dhclient3 (607) Na podstawie wyniku powyższego polecenia możemy się dowiedzieć, że załadowano profil /usr/sbin/named, który działa w trybie enforce, oraz że AppArmor zarządza aktualnie uruchomionym procesem /usr/sbin/named (PID 5020). Profile AppArmor Profile AppArmor są przechowywane w pliku /etc/apparmor.d/, a ich nazwy odpowiadają binariom, którymi te profile zarządzają. Na przykład profil usługi /usr/sbin/named jest zapisany w pliku /etc/apparmor.d/usr.sbin.named. Wystarczy przyjrzeć się zawartości tego pliku, aby zorientować się, jak działają profile AppArmor i jakiego rodzaju ochronę zapewniają: # vim:syntax=apparmor # Last Modified: Fri Jun 1 16:43:22 2007 #include tunables/global /usr/sbin/named { #include abstractions/base #include abstractions/nameservice capability net_bind_service, capability setgid, capability setuid, Poleć książkęKup książkę 92 Rozdzia(cid:228) 3. Bezpiecze(cid:254)stwo serwerów capability sys_chroot, # plik /etc/bind powinien by(cid:252) dost(cid:266)pny dla us(cid:225)ugi bind tylko do odczytu # /var/lib/bind jest potrzebny dla plików aktualizowanej dynamicznie strefy (oraz dziennika). # /var/cache/bind jest u(cid:298)ywany dla danych slave/stub, poniewa(cid:298) nie jeste(cid:286)my ich #(cid:296)ród(cid:225)em. # Patrz /usr/share/doc/bind9/README.Debian.gz /etc/bind/** r, /var/lib/bind/** rw, /var/lib/bind/ rw, /var/cache/bind/** rw, /var/cache/bind/ rw, # niektórzy s(cid:261) zwolennikami umieszczania logów w pliku /var/log/named/ /var/log/named/** rw, # pakiet dnscvsutil /var/lib/dnscvsutil/compiled/** rw, /proc/net/if_inet6 r, /usr/sbin/named mr, /var/run/bind/run/named.pid w, # obs(cid:225)uga dla resolvconf /var/run/bind/named.options r, } Dla przykładu przyjrzyjmy się poniższemu fragmentowi z tego pliku: /etc/bind/** r, /var/lib/bind/** rw, /var/lib/bind/ rw, /var/cache/bind/** rw, /var/cache/bind/ rw, Składnia tych plików jest dość prosta. Najpierw podana jest ścieżka do pliku lub katalogu, a za nią dozwolone uprawnienia. Dozwolone są także symbole wieloznaczne. W związku z tym na przykład zapis /etc/bind/** dotyczy rekurencyjnie wszystkich plików z katalogu /etc/bind. Pojedynczy symbol * miałby zastosowanie wyłącznie do plików w bieżącym katalogu. W przypadku tej reguły można zauważyć, że usługa /usr/sbin/named może jedynie czytać pliki w tym katalogu, natomiast nie może ich zapisywać. To ma sens, ponieważ ten katalog zawiera same pliki konfiguracyjne BIND — program named nigdy nie powinien ich nadpisywać. Drugi wiersz fragmentu zezwala programowi named na odczyt i zapis do plików lub folderów w katalogu /var/lib/bind/. To też ma sens — BIND może (między innymi) zapisywać tutaj pliki stref pomocniczych, a ponieważ informacje do tych plików są zapisywane każdorazowo przy zmianie strefy, usługa named potrzebuje tam uprawnień zapisu. Tryby enforce i complain Prawdopodobnie zauważyłeś, że w wyniku działania polecenia aa-status są informacje na temat dwóch trybów: enforce i complain. W trybie enforce AppArmor aktywnie blokuje wszelkie próby naruszenia jego profilu przez programy. W trybie complain AppArmor po prostu rejestruje próby, ale ich nie blokuje. Programy aa-enforce i aa-complain pozwalają Poleć książkęKup książkę Cz(cid:246)(cid:264)(cid:232) 2. (cid:263)rednio zaawansowane techniki hartowania serwerów 93 zmienić profil tak, by działał w trybie enforce lub complain. Jeśli zatem mój program /usr/sbin/named miał potrzebę zapisu do pliku w katalogu /etc/bind lub jakimś innym katalogu, w którym nie miał zezwolenia zapisu, to albo mogłem zmodyfikować profil AppArmor, aby na to pozwolić, albo ustawić go na tryb complain: $ sudo aa-complain /usr/sbin/named Setting /usr/sbin/named to complain mode Jeśli później zechcę ustawić tryb enforced ponownie, mogę skorzystać z polecenia aa-enforce w ten sam sposób: $ sudo aa-enforce /usr/sbin/named Setting /usr/sbin/named to enforce mode Gdybym zdecydował się zmienić domyślny zestaw w pliku /etc/apparmor.d/usr.sbin.named, musiałbym zadbać o ponowne załadowanie AppArmor, tak aby zmiany stały się widoczne. Aby to osiągnąć, możesz uruchomić skrypt inicjalizacji systemu AppArmor i przekazać do niego opcję reload: $ sudo /etc/init.d/apparmor reload Podczas modyfikowania reguł AppArmor należy zachować ostrożność. Kiedy po raz pierwszy rozpoczniesz modyfikowanie reguł, możesz ustawić określoną regułę na tryb complain, a następnie monitorować wszelkie nieprawidłowości w pliku /var/log/syslog. Gdyby na przykład usługa /usr/sbin/named była w trybie enforce i ująłbym w komentarz wiersz w pliku profilu /usr/sbin/named, który gwarantował dostęp do odczytu do /etc/bind/**, a następnie ponownie załadował AppArmor i zrestartował BIND, to nie tylko BIND nie wystartowałby (ponieważ nie mógłby odczytać swoich plików konfiguracyjnych), ale także jądro wygenerowałoby czytelny wpis w dzienniku /var/log/syslog informujący o zablokowanej próbie: Jan 7 19:03:02 kickseed kernel: [ 2311.120236] audit(1231383782.081:3): type=1503 operation= inode_permission requested_mask= ::r denied_mask= ::r name= /etc/bind/named.conf pid=5225 profile= /usr/sbin/named namespace= default Konwencje AppArmor w Ubuntu Na poniższej liście wyszczególniono popularne katalogi i pliki używane przez AppArmor, włącznie z tymi, w których ten program przechowuje pliki konfiguracyjne i zapisuje logi: (cid:132) /etc/apparmor/: ten katalog zawiera podstawowe pliki konfiguracyjne dla programu AppArmor. Należy jednak zwrócić uwagę, że nie zawiera on reguł AppArmor. (cid:132) /etc/apparmor.d/: w tym katalogu są zapisane wszystkie reguły AppArmor, włącznie z podkatalogami zawierającymi różne zbiory plików nagłówkowych (ang. include files), do których odnoszą się określone zestawy reguł. (cid:132) /etc/init.d/apparmor: w tym pliku jest zapisany skrypt inicjalizacji AppArmor. Domyślnie AppArmor jest włączony. (cid:132) /var/log/apparmor/: w tym katalogu AppArmor przechowuje swoje logi. (cid:132) /var/log/syslog/: kiedy reguła AppArmor zostanie naruszona w trybie enforce lub complain, wtedy jądro wygeneruje wpis w standardowym logu systemowym. Poleć książkęKup książkę 94 Rozdzia(cid:228) 3. Bezpiecze(cid:254)stwo serwerów Zdalne logi Dzienniki systemu (zwane popularnie logami) są ważnym mechanizmem rozwiązywania problemów na serwerze, ale najbardziej przydają się w sytuacji, gdy napastnikowi uda się włamać na serwer. Logi systemowe zawierają dane o wszystkich próbach logowania, zarówno lokalnych, jak i przez SSH, wszystkich próbach użycia programu sudo, załadowanych modułach jądra, zamontowanych dodatkowych systemach plików, a jeśli używamy programowej zapory firewall z włączonym mechanizmem logowania, to w logu można znaleźć interesujące informacje dotyczące ruchu sieciowego od intruza. W przypadku serwerów WWW, bazy danych lub aplikacji w logach pojawiają się również dodatkowe informacje dotyczące prób dostępu do tych systemów. Problem w tym, że cyberprzestępcy wiedzą, jak przydatne są dzienniki i jak wiele informacji mogą ujawnić, dlatego każdy przeciętnie inteligentny stara się zmodyfikować wszystkie logi systemowe, które mogłyby ujawnić jego ślady. Z tego względu jednym z pierwszych działań wykonywanych przez wiele rootkitów oraz innych skryptów do przeprowadzania ataków jest usunięcie lokalnych logów i zadbanie o to, aby ich skrypty nie generowały nowych logów. Administrator dbający o bezpieczeństwo powinien pamiętać, aby wszystkie logi systemowe, które mogą być przydatne po ataku, były dodatkowo przechowywane na oddzielnym komputerze. Scentralizowane logi są przydatne do ogólnych zadań dotyczących rozwiązywania problemów, ale również znacznie utrudniają napastnikom zacieranie śladów, ponieważ aby ukryć swoje działania, napastnik musiałby nie tylko włamać się na oryginalny serwer, ale także znaleźć sposób na włamanie na zdalny serwer logowania. W niektórych firmach obowiązują również przepisy, zgodnie z którymi niektóre kluczowe logi (np. zawierające próby logowania) muszą być przechowywane przez długi czas na oddzielnym serwerze. Dostępnych jest wiele systemów, takich jak między innymi Splunk i Logstash, które nie tylko zbierają logi z serwerów, ale również potrafią je indeksować i udostępniają interfejs, który administratorzy mogą wykorzystać do szybkiego ich przeszukiwania. Wiele z tych usług dostarcza własnego agenta, który może być zainstalowany w systemie w celu ułatwienia zbierania logów, jednak prawie wszystkie obsługują zbieranie logów za pośrednictwem standardowego protokołu sieciowego syslog. Zamiast opisywania w tym miejscu wszystkich dostępnych systemów zbierania logów omówię, jak należy skon
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Hartowanie Linuksa we wrogich środowiskach sieciowych. Ochrona serwera od TLS po Tor
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: