Kilka pomysłów na bezpieczny serwer linuksowy

Konfigurując nowy serwer linuksowy, warto podjąć kilka dodatkowych kroków, aby mieć pewność naprawdę bezpiecznego systemu.

Niedawno zrezygnowałem z fizycznego serwera na rzecz systemu opartego na chmurze. Proces rejestracji przebiegł bezboleśnie – może poza koniecznością podania danych karty kredytowej – i po chwili mogłem się cieszyć nowym serwerem z Debianem 8.1 Jessie ze statycznym adresem IPv4.

Niezwykle rzadko zdarza mi się ręcznie budować serwery od podstaw. Ponieważ jednak opisywany w przykładzie system ma służyć jako serwer roboczy, warto przyjrzeć się czynnościom, jakie wykonałem, aby go zabezpieczyć. Przedstawione kroki w dużej mierze wynikają z osobistych upodobań, ale stanowią dobry punkt wyjścia przy budowie własnego systemu bezpieczeństwa. Lista z pewnością nie wyczerpuje wszystkich możliwości (jest ich po prostu zbyt dużo, aby dokładnie je omówić), ale może zasugerować nam rozwiązania niebrane wcześniej pod uwagę.

Opisane w artykule instrukcje pokazują, jak skonfigurować od podstaw serwer z Debianem Jessie. Jak zawsze chodzi o zminimalizowanie liczby pakietów, aby zredukować potencjalne luki w zabezpieczeniach i ograniczyć ilość aktualizacji. Przykład pokazuje, jak wzmocnić zabezpieczenia pojedynczego serwera z Debianem – zapewnienie ochrony całej sieci wymaga wielu dodatkowych czynności, w tym zadbania o bezpieczeństwo routerów, zapór sieciowych, systemów zapobiegania włamaniom i wielu innych.

Usługi

Do uzyskania zdalnego dostępu do serwerów zwykle sprawdzają się klucze SSH. Po zmianie adresu DNS na statyczny IP oferowany przez dostawcę chmury, logujemy się do systemu przez SSH i od razu zmieniamy hasło root na takie, które spełnia nasze wymagania (i nie jest przesyłane drogą mailową). Warto sugerować dostawcom chmur, by dostarczali hasła root za pośrednictwem interfejsu webowego (używającego HTTPS); e-mail jest niezwykle niebezpieczny, a przecież chodzi o nową instalację serwerową, która ma być godna zaufania przez długi czas. Zaleta polega na tym, że dostawca przynajmniej zachęca do utworzenia klucza SSH.

Zalogowawszy się przez SSH jako root, przystępujemy do pracy. Pod żadnym pozorem nie powinniśmy logować się przez SSH jako superużytkownik, jeśli wcześniej nie utworzyliśmy użytkownika z mniejszymi uprawnieniami, który w razie potrzeby wpuści nas do systemu.

Wzmacnianie zabezpieczeń maszyny zaczynamy od wyłączenia wszystkich usług otwierających porty z wyjątkiem serwera SSH, uruchamiając polecenie:

# lsof -i | grep LISTEN

Wynik wyświetla dwie kolumny: w lewej są nazwy usług (przeważnie związane z nazwami plików start/stop z katalogu /etc/init.d), a w prawej – otwarte przez nie porty sieciowe widniejące zwykle na liście jako nazwy usług przetłumaczone z liczb przez plik /etc/services.

Uwagę przykuwają w przykładzie dwie niepożądane usługi mogące zagrażać bezpieczeństwu. Za uruchomienie pierwszej odpowiada pewnie /etc/init.d/rpcbind; szybko ją wyłączamy:

# systemctl stop rpcbind

dodając polecenie zakazujące rpcbind ponownego uruchamiania się po restarcie:

# systemctl disable rpcbind

Kolejny otwarty port sugeruje w końcu, że winna jest uruchamiana podczas startu usługa Systemd o nazwie nfs-common. Wyłączamy ją jak poprzednio, zastępując rpcbind jej nazwą.

W razie kłopotów (jeśli nie używamy wersji polecenia lsof z Debiana Jessie, ale z innej dystrybucji) możemy spróbować zmodyfikować polecenie:

lsof -i | grep LISTEN | awk '{print $1,$3}'

rpcbind rpc
master root
sshd root
httpd root
httpd apache

Działa ono w przykładzie z Debianem Jessie. Wyszukuje wszystkie nasłuchujące usługi i wyświetla ich nazwy wraz z kontami użytkowników odpowiedzialnymi za jej uruchomienie. Polecenie lsof z wyjątkiem wyłączania usług może służyć do eksperymentów z przenoszeniem usług do bezpieczniejszych kont użytkowników. Metodą prób i błędów możemy skutecznie przełączyć niektóre usługi na inne konta, podnosząc bezpieczeństwo.

Ssshhhh

Kolejny krok polega na przeniesieniu demona SSH sshd ze zbyt przewidywalnego portu 22 na inny. W tym celu ostrożnie edytujemy plik /etc/ssh/sshd_config, odkomentowując początkowy wiersz (Rysunek 2) i zmieniając 22 na wybrany numer portu – na przykład 2222, co zapobiega zautomatyzowanym atakom na port 22.

Dodatkowo blokujemy logowanie użytkownika root parametrem PermitRootLogin z wartością no:

PermitRootLogin no

Przechodzimy do utworzenia mniej uprzywilejowanego użytkownika. Wcześniej jednak upewniamy się, że logować się zdalnie mogą tylko wybrani użytkownicy – dodajemy do pliku konfiguracyjnego SSH (na początku, by pamiętać o zmianach przy następnym otwarciu pliku) polecenie:

AllowUsers lionel, luis, neymar

Teraz przez SSH mogą się logować tylko trzej użytkownicy – tworzymy ich konta, zanim się wylogujemy lub zrestartujemy serwer OpenSSH; inaczej ryzykujemy utratę dostępu do systemu:

# adduser lionel

Dalsze zabezpieczanie pliku SSH to temat na osobny artykuł; zdecydowanie jednak warto je wykonać i zrozumieć wprowadzane zmiany. Aby zatwierdzić zmiany, restartujemy sshd:

# systemctl restart ssh

Możemy przeprowadzić szybki test, aby się upewnić, że SSH nadal pozwala nam się logować, i otworzyć dziennik systemowy (w tym wypadku plik /var/log/messages). Wciąż powinniśmy zapoznać się z błędami Systemd, ale nie widać w pliku nic powiązanego z wprowadzonymi zmianami, więc na razie nie ma powodu do zmartwień.

Otwieramy plik /etc/hosts.allow, by usunąć wszystko, co niewykomentowane, i dodać swój adres IP:

sshd: 11.22.33.44, 123.123.123.123, 9.8.7.6

Od teraz przez SSH mogą się logować tylko trzy adresy IP, a nazwa użytkownika powinna być jedną z wcześniej utworzonych – na przykład lionel. Dodajemy wiersz do hosts:deny:

sshd: ALL

I gotowe. Pamiętajmy, aby nie zamykać okna logowania, nie przetestowawszy logowania się przez SSH.

Historia poleceń

Przewijanie historii poleceń znacznie przyspiesza użycie klawiszy [PageUp] i [PageDown]. Wprawdzie nie jest to związane z bezpieczeństwem, ale pozwala nam sprawniej się poruszać po wierszu poleceń.

Na Rysunku 3 znajdują się dwa wiersze pliku /etc/inputrc, które odkomentowujemy. Zmiany zostają wprowadzone przy kolejnym rozruchu.

Home, sweet home

Nie wszystkie dystrybucje domyślnie zaostrzają ograniczenia w dostępie do katalogów domowych. Zakładamy, że nasza nazwa użytkownika to lionel, luis i neymar mają nie widzieć plików z naszego katalogu domowego. Aby zablokować innym użytkownikom dostęp do katalogu domowego, możemy uruchomić z uprawieniami root polecenie:

# chmod -R 750 /home/lionel

Chcąc z kolei zablokować dostęp do wszystkich katalogów domowych, wystarczy użyć symbolu gwiazdki zamiast nazwy użytkownika.

Hej, panie listonoszu!

Następny krok to instalacja i skonfigurowanie narzędzia Logwatch [1], abyśmy codziennie otrzymywali podsumowanie najważniejszych zdarzeń. Wykonanie tych kilku prostych czynności da nam również w pełni funkcjonalny serwer SMTP. Oczywiście, z powodu ram artykułu, polecenia omówione są w dużym skrócie; jeśli jednak nie mamy pewności, co robić, lepiej, przyjrzeć im się bliżej.

Instalujemy Postfiksa:

# apt-get install postfix

Podczas procesu konfiguracji wybieramy Internet Site i dodajemy pełną nazwę hosta (w tym FQDN). Możemy wprowadzić szybką zmianę w pliku /etc/aliases, aby na prywatny adres e-mail otrzymywać wiadomości wysyłane do użytkownika root – edytujemy plik aliases i dodajemy adres zewnętrzny:

# pico -w /etc/aliases

Upewniamy się, że wiersz zaczynający się od root: wygląda analogicznie:

root: chris@binnie.tld

Aktualizujemy plik aliasów, wywołując polecenie newaliases:

# newaliases

Na koniec instalujemy pakiet Logwatch:

# apt-get install logwatch

Logwatcha najłatwiej wywołać, tworząc zadanie crona uruchamiane codziennie o tej samej porze (cron.daily); czas możemy określić w pliku /etc/crontab. Alternatywnie możemy przenieść plik /etc/cron.daily/00logwatch w inne miejsce i uruchomić go w innym czasie ustawionym pliku /etc/crontab.

Uruchamiamy Logwatcha i sprawdzamy skrzynkę:

# /etc/cron.daily/00logwatch

Wyniki są bardzo przydatne. Więcej na temat monitorowania plików dziennika przy użyciu Logwatcha [2].

Logwatch dostarcza użyteczne informacje na temat systemu (w tym wykorzystania miejsca na dysku, logowania się przez SSH, nowych użytkowników i grup, restartowanych usług i podejrzanych wpisów w plikach dziennika). Dodatkowo tworzy listę pakietów zainstalowanych od instalacji minimalnej, dzieląc je w praktyczny sposób na Zainstalowane, Zaktualizowane i Usunięte. Listy archiwizowane w skrzynce e-mail z tematem wiadomości Logwatch dla <nazwa_hosta> (Linux) to doskonały punkt odniesienia na przyszłość. W razie rozbieżności między dwoma serwerami spowodowanymi różnymi wersjami pakietów lub funkcjami sprawdzenie, w jaki sposób są skompilowane, zajmuje najwyżej dwie minuty.

Nie chcąc, aby użytkownik root bezpośrednio otrzymywał pocztę za pośrednictwem naszego pliku aliases, w pliku konfiguracyjnym /etc/logwatch/conf/logwatch.conf możemy dodać MailTo = adres e-mail. Jeżeli plik nie istnieje, tworzymy go.

Warto przy okazji wspomnieć, jak zabezpieczyć nowy serwer SMTP. Nawet gdy domyślnie włączone jest przekazywanie (ang. relaying), wciąż powinniśmy podjąć pewne kroki, aby zapewnić bezpieczeństwo serwera poczty. Interesujący post znajduje się na stronie Ask Ubuntu [3].

Hasła

Jeśli na serwer mają się logować inni użytkownicy, powinniśmy zadbać o bezpieczeństwo haseł. Jeżeli mieliśmy styczność z listą najpopularniejszych haseł, wiemy, dlaczego administratorzy tak bardzo obawiają się dopuszczać do systemów serwerowych zwykłych użytkowników [4].

Skala stosowania słabych haseł nie wróży dobrze, zwłaszcza jeśli dostępu do serwera nie blokujemy po adresach IP lub przy użyciu innej metody. Gdy użytkownicy mogą się logować przez SSH z dowolnego adresu, a nie zablokowaliśmy serwera lub nie wprowadziliśmy zasad tworzenia haseł, istnieje ryzyko zautomatyzowanych ataków słownikowych. Na szczęście Linux pozwala wzmocnić reguły haseł przy użyciu zaawansowanego pakietu libpam-cracklib.

Konfiguracja sprawdza się na systemie Debian Wheezy. Instalujemy libpam-cracklib:

# apt-get install libpam-cracklib

Edytujemy plik:

# pico -w /etc/pam.d/common-password

Zmieniamy wiersz:

password requisite pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=2 ocredit=2

przy użyciu wymaganych ustawień (lepiej go odkomentować, zamiast usuwać, aby w razie potrzeby móc go przywrócić). Konfiguracja ogranicza do dwóch liczbę prób zalogowania się i wymaga hasła złożonego z przynajmniej dziesięciu znaków. Ustawienie difok=6 (denerwujące kolegów) umożliwia ponowne wykorzystanie w bieżącym haśle tylko sześciu znaków występujących w poprzednim, dwa ostatnie powinny być przynajmniej dwoma cyframi i dwoma symbolami (lub znakami specjalnymi).

Aby włączyć te ustawienia (na Wheezy), piszemy:

# pam-auth-update

Teraz możemy wypróbować kilka testów – ostrożnie, abyśmy mogli zalogować się na konto z powrotem. W razie problemów możemy sprawdzić, czy plik /etc/ssh/sshd_config zawiera UsePAM yes. Po zmianie konfiguracji uruchamiamy ponownie serwer OpenSSH poleceniem systemctl restart ssh.

Tabela 1 zawiera podsumowanie opcji wymuszających stosowanie silniejszych haseł zaczerpnięte z instrukcji pam_cracklib. Możemy eksperymentować z ustawieniami do woli.

Tabela 1: Opcje wymuszania haseł Crackliba

Opcja	Opis
retry=N	Informuje użytkownika najwyżej N razy przed zwróceniem błędu. Wartość domyślna N wynosi 1.
difok=N	Liczba znaków, które muszą być zmienione w stosunku do poprzedniego hasła (domyślnie 5).
minlen=N	Minimalna akceptowalna długość nowego hasła; więcej informacji zawiera instrukcja.
dcredit=N	(N ≥ 0) Maksymalna liczba punktów za użycie cyfr w nowym haśle. Jeśli hasło ma N lub mniej znaków, każdy znak to +1 punkt do bieżącej wartości minlen. Domyślna wartość dcredit wynosi 1; zalecana wartość minlen – mniej niż 10. (N < 0) Minimalna liczba cyfr w nowym haśle.
ucredit=N	(N ≥ 0) Maksymalna liczba punktów za użycie w nowym haśle wielkich liter. Jeśli hasło zawiera N lub mniej wielkich liter, każdy znak to +1 punkt do bieżącej wartości minlen. Domyślna wartość ucredit to 1 – zalecana przy minlen mniej niż 10. (N < 0) Minimalna liczba wielkich liter w nowym haśle.
lcredit=N	(N ≥ 0) Maksymalna liczba punktów za użycie małych liter w nowym haśle. Jeśli w haśle jest N lub mniej małych liter, każda litera to +1 punkt do wartości minlen. Domyślna wartość lcredit to 1, zalecana wartość minlen – mniej niż 10. (N < 0) Minimalna liczba małych liter w nowym haśle.
ocredit=N	(N ≥ 0) Maksymalna liczba punktów za użycie w nowym haśle innych znaków. Jeśli hasło ma N lub mniej innych znaków, każdy znak to +1 punkt do bieżącej wartości minlen. Domyślna wartość ocredit to 1, zalecana przy minlen mniej niż 10. (N < 0) Minimalna liczba innych znaków w nowym haśle.
minclass=N	Minimalna liczba wymaganych klas znaków dla nowego hasła, domyślnie 0. Są cztery rodzaje klas: cyfry, duże i małe litery oraz inne znaki.
maxrepeat=N	Odrzuca hasła zawierające więcej niż N jednakowych występujących po sobie znaków, domyślnie 0 (wyłączony test).
maxsequence=N	Odrzuca hasła z monotonicznymi sekwencjami znaków (na przykład 12345 lub fedcb) dłuższymi niż N, domyślnie 0 (czyli test jest wyłączony).
maxclassrepeat=N	Odrzuca hasła zawierające więcej niż N występujących po sobie znaków tej samej klasy, domyślnie 0 (czyli test jest wyłączony).
reject_username	Odrzuca hasło, które zawiera nazwę użytkownika w zwykłej lub odwróconej kolejności.
gecoscheck	Odrzuca hasło, które zawiera ciągi z pola GECOS (zwykle pełna nazwa użytkownika) dłuższe niż 3 znaki w zwykłej lub odwróconej kolejności.
enforce_for_root	Komunikat o błędzie lub nieudanej próbie testu uniemożliwia użytkownikowi root zmianę hasła. Opcja domyślnie wyłączona: komunikat o nieudanej próbie przeprowadzenia testu jest generowany, ale root i tak może zmienić hasło.
authtok	Argument zakazuje modułowi prosić użytkownika o nowe hasło, by użyć hasła dostarczonego przez wcześniejszy moduł haseł.

Chcąc pójść krok dalej, możemy wprowadzić własne słowniki dla Crackliba. W Sieci znajdziemy dość stary, ale dobrze napisany artykuł na temat używania Crackliba w połączeniu z Django [5].

Inne pomysły

Dalsze kroki mogą obejmować monitorowanie systemu plików. Dla najważniejszych plików możemy utworzyć sumy kontrolne MD5, z którymi będziemy porównywać pliki w razie podejrzenia ataku. Możemy też zainstalować narzędzie sprawdzające integralność systemu plików – na przykład AIDE (ang. Advanced Intrusion Detection Environment), by monitorowało za nas zmiany.

Do wykrywania niepożądanych usług możemy też skonfigurować IPTables sprawdzające, czy na systemie są uruchomione usługi wyzwolone na skutek ataku lub błędnej konfiguracji.

Bronić się przed atakami pozwala również pukanie w porty (ang. Port Knocking) [6]

• technika umożliwiająca zablokowanie portu serwera SSH dla świata zewnętrznego
• wyłącza pingi, czyniąc serwer całkowicie niewidocznym; jedynym sposobem obudzenia serwera SSH jest połączenie się z określoną sekwencją portów.

Jeśli użytkownicy mają zdalny dostęp przez sFTP, możemy im go ograniczyć poprzez zmuszenie ich do pracy wewnątrz katalogu domowego i zablokowanie możliwości wykonywania innych poleceń systemowych. W tym celu wystarczy skonfigurować środowisko sFTP chroot [7].

Możemy też skorzystać z narzędzia, które automatycznie analizuje i blokuje system, raportując o problemach związanych z bezpieczeństwem, jak rozwiązania do audytu bezpieczeństwa pokroju Bastille Linuksa czy Lynisa.

Zaleta narzędzi takich, jak Bastille Linux i Lynis, polega na tym, że przyspieszają proces wzmacniania zabezpieczeń i nie wymagają szczegółowej wiedzy na ten temat. Z drugiej jednak strony sprawia to, że administratorzy tracą zainteresowanie bezpieczeństwem systemu, a tym samym korzyści samodzielnego wzmacniania bezpieczeństwa systemu, pomijając już, jak łatwo wpisać Y i przypadkowo uczynić system bezużytecznym, nie rozumiejąc, o co pyta nas aplikacja.

Niekończąca się historia

Bezpieczeństwo zależy nie tylko od konfiguracji serwera. Naszej uwagi wymagają również inne komponenty sieci. Na przykład powinniśmy sprawdzić obecność na systemie niebezpiecznych plików z uprawnieniami SETUID, z pewnością chcąc ograniczyć ich liczbę.

Jeśli mamy obawy, możemy poeksperymentować z poleceniem:

find / -xdev \( -perm -4000 \) -type f -print0 | xargs -0 ls -hal

Nieprzyjemne niespodzianki z bitem s możemy usunąć:

# chmod -s /home/chrisbinnie/nasty_file

Aby jeszcze bardziej wzmocnić bezpieczeństwo systemu plików, możemy rozważyć instalację SELinuksa. Warto też rzucić okiem na zalecenia amerykańskiej Narodowej Agencji Bezpieczeństwa [10].

Instalując na serwerze Apacheʼa, możemy zacząć od ukrycia katalogu cgi-bin i zmiany ustawień ServerTokens na Prod. Świetny artykuł na temat podnoszenia bezpieczeństwa Apacheʼa znajduje się na stronie Geekflare [11].

Testowanie zabezpieczeń to niekończąca się historia. Jeśli chcemy dowiedzieć się więcej, możemy poczytać na temat stworzonego przez National Institute of Standards and Technology skanera OpenSCAP [12], którego działanie polega na „automatycznej weryfikacji obecności łatek, sprawdzaniu konfiguracji zabezpieczeń i analizowaniu systemów pod kątem występowania śladów włamań”.

Oby artykuł zachęcał do dalszego eksplorowania tematu bezpieczeństwa systemu. Warto budować i konfigurować systemy serwerowe, mając na uwadze bezpieczeństwo, szczególnie jeśli – wracając do nich później – chcemy je zastać działające tak samo w chwili pozostawienia.

Linki

1. Logwatch: http://www.logwatch.org/ 
2. Chris Binnie, Logwatch, „Admin Magazine” 25/2015: http://www.admin-magazine.com/Archive/2015/25/Lean-on-Logwatch/%28language%29/eng-US
3. Zabezpieczanie Postfiksa na serwerze Ubuntu: http://askubuntu.com/questions/418340/how-to-secure-postfix-on-ubuntu-server
4. 5 najczęstszych haseł ujawnionych: http://news.sky.com/story/1412124/revealed-the-top-25-most-common-passwords
5. Wymuszanie silniejszych haseł przy użyciu Crackliba: http://thegarywilson.com/blog/2006/using-cracklib-to-require-stronger-passwords/
6. Chris Binnie, Ochrona sieci przy użyciu Port Knockingu, „Admin Magazine” 23/2014: http://www.admin-magazine.com/Archive/2014/23/Port-Knocking
7. Ograniczanie dostępu za pomocą więzień SFTP na Debianie i Ubuntu: https://www.linode.com/docs/tools-reference/tools/limiting-access-with-sftp-jails-on-debian-and-ubuntu
8. Bastille Linux: http://bastille-linux.sourceforge.net/
9. Lynis: https://cisofy.com/lynis/
10.  Wytyczne NSA dotyczące bezpiecznej konfiguracji systemu operacyjnego: https://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/operating_systems.shtml
11. Wzmacnianie zabezpieczeń serwera Apache: http://geekflare.com/apache-web-server-hardening-security/
12. Portal OpenSCAP: http://www.open-scap.org/page/Main_Page 

— Chris Binnie