Checklista systemu cz.1
Oddając serwer do produkcji administrator często boryka się z przeświadczeniem, że o czymś zapomniał. Można oczywiście oddać serwer i czekać na zgłoszenia od użytkowników, że coś nie działa lub czegoś brakuje, ale nie tędy droga. Doświadczeni administratorzy często korzystają z gotowych procedur wdrożeniowych i sprawdzających. Najprostszym podejściem realizującym ten model jest lista zadań, które muszą zostać wykonane lub zweryfikowane. Zadanie te oczywiście odnoszą się do nowego systemu lub już istniejącego nad którym opiekę przejmujemy.
1. Usuwanie zbędnych pakietów
Przy instalowaniu nowego serwera bardzo ważnym elementem jest określenie jego głównej roli. Na tej podstawie można określić pakiety jakie muszą być zainstalowane w systemie. Trudno jest określić zakres implementacji zabezpieczeń na serwerze, na którym zainstalowanych jest mnóstwo niepotrzebnych komponentów. Prostym przykładem jest serwer Webowy, na którym raczej nie powinien się znaleźć pakiet Samby.
Dobrą praktyką jest instalacja minimalna i w miarę uruchamiania poszczególnych funkcji serwera, instalowanie potrzebnych pakietów.
2. Aktualizacja systemu
Przy uruchamianiu środowiska produkcyjnego bardzo ważnym elementem jest procedura wprowadzania i testowania aktualizacji systemu. Należy określić przedziały czasowe w jakich aktualizacje są wprowadzane do systemów. W procedurze tej trzeba określić sposób testowania i wycofywania poprawek. Jako pierwsze z reguły aktualizuje się środowisko deweloperskie i testowe. W przypadku poprawek krytycznych w obszarze sieciowym czas testowania powinien być jak najkrótszy, aby zapewnić szybkie łatanie podatnych, wystawionych na świat systemów.
3. Detekcja otwartych portów
Jeśli dokładnie znamy rolę serwera, powinniśmy bez trudu określić listę otwartych portów komunikacyjnych. Bardzo często nieskonfigurowane w pełni serwery mają otwarte porty, które nie służą oficjalnie do niczego. Należy upewnić się, że otwarte porty TCP/UDP są rzeczywiście wymagane. Czasem usługa potrzebuje nasłuchiwać jedynie na adresie 127.0.0.1, dobrą praktyką jest potwierdzenie tego poprzez przeskanowanie serwera zewnętrznym skanerem portów. Należy się przy tym upewnić czy w danym środowisku wolno nam przeprowadzić skanowanie portów, czasem trzeba uzyskać zgodę administratora sieci i/lub zmodyfikować odpowiednio systemy IPS/IDS dla skanowanej maszyny.
4. Wyłączanie niepotrzebnych usług
Wyłączenie niepotrzebnych usług systemu może istotnie wpłynąć zarówno na wydajność systemu jak i jego bezpieczeństwo. Często nie zdajemy sobie sprawy z tego, że podczas startu systemu uruchamiane są procesy mogące istotnie obniżyć bezpieczeństwo systemu, a nie służą one niczemu. Jednym z takich procesów może być np. atd w systemie, w którym wybrano crond jako demona zarządzającego harmonogramem systemowym. Inne bardzo często zbędne usługi to: kudzu, apmd, gpm, pcmcia, cups. Przed oddaniem serwera do produkcji należy dokładnie zweryfikować listę uruchamianych przy starcie usług i skryptów.
5. Wyłączanie usług xinetd
Część usług systemowych uruchamiana jest na żądanie za pomocą xinetd. Bardzo często konfiguracja tej usługi jest pomijana a przecież to właśnie xinetd uruchamia telnet a czasem ftp. Niektóre usługi (np. telnet) najlepiej usunąć z systemu całkowicie.
6. Ograniczanie dostępu do usług
Znaczna część usług serwera wykorzystuje systemowe access listy (TCP Wrapper). Konfiguruje się je bardzo prosto za pomocą dwóch plików /etc/hosts.allow i /etc/hosts.deny. Dobrze jest dostęp skonfigurować według polityki „zabroń wszystkim – zezwalaj wybranym”. Podejście takie pozwala uniknąć błędów konfiguracji, a także domyślnie nie zezwala nieskonfigurowanym usługom na odbieranie połączeń, to na wypadek, gdyby administrator zapomniał dajmy na to wyłączyć ftp. Konfiguracja TCP Wrappers zezwala na selektywne (per usługa) wybieranie dozwolonych (lub zabronionych) hostów i sieci. W listach hostów i sieci zaleca się użycie numeracji IP niż nazw domenowych ze względu na podatność na ataki DNS Spoofing.
7. Zabezpieczanie sshd
W przypadku usługi sshd należy bardzo ostrożnie i z pełną świadomością konfigurować jej parametry. Po pierwsze należy uniemożliwić dostęp bezpośredni dla użytkonika root (PermitRootLogin no). Następnie warto zastosować protoków SSH w wersji 2 (Protocol 2) i separację upranień na poziomie procesu (UsePrivilegeSeparation yes). Warto włączyć sprawdzanie uprawnień do istotnych plików użytkownika (StrictModes yes), a także zastosować konkretną listę kont, na które może nastąpić próba logowania (AllowUsers).
8. Synchronizacja czasu serwera
Z punktu widzenia bezpieczeństwa na pierwszy rzut oka czas nie powinien mieć większego znaczenia, ale w przypadku utrzymywania farmy współpracujących ze sobą serwerów czas odgrywa istotną rolę. W celu poprawnej analizy logów systemowych także warto utrzymywać poprawny czas. W systemach zwirtualizowanych czas należy synchronizować do hosta, natomiast czas hosta do dobrego źródła czasu. Dość powszechne jest zjawisko dryfowania czasu dla systemów zwirtualizowanych dlatego dla nich powinno się zwrócić szczególną uwagę na poprawność czasu i w miarę potrzeby zwiększyć częstotliwość jego synchronizacji.
9. Ustawianie limitów na zasoby
Każdy serwer ma ograniczoną liczbę zasobów, które może zutylizować system operacyjny. Domyślna konfiguracja większości dystrybucji Linuxa nie posiada skonfigurowanych limitów dla zasobów. Administrator systemów, do których logują się użytkownicy np. za pomocą ssh, powinien szczególnie dokładnie ustalić ilość procesów i maksymalne zużycie procesora i pamięci. Dodatkowym krokiem jest ustalenie limitów przestrzeni dyskowej. Nie skonfigurowanie limitów na zasobach umożliwia praktycznie każdemu użytkownikowi wykonanie, świadomego lub nie, ataku typu DoS.
10. Parametry jądra systemu związane z bezpieczeństwem sieciowym
W większości dystrybucji Linuxa podane niżej parametry są już ustawiane domyślnie przy starcie systemu. Konfiguracja najczęściej przechowywana jest w pliku /etc/sysctl.conf. Można te parametry zmieniać podczas pracy systemu.
net.ipv4.tcp_syncookies = 1 – zabezpieczenie przed atakiem typu TCP SYN
net.ipv4.conf.all.accept_source_route = 0 – włączenie weryfikacji ścieżki źródłowej
net.ipv4.conf.all.accept_redirects = 0 – nie pozwalamy na modyfikację trasy
net.ipv4.conf.all.rp_filter = 1 – weryfikacja adresu źródłowego zapewnia zabezpieczenie przed atakiem typu IP Spoofing.
net.ipv4.conf.all.log_martians = 1 – włączamy logowanie wykrytych nieprawidłowych pakietów (Spoofed, Source Routed, Redirected)