24 03.2015

Standard bezpieczeństwa Linux

Gdy powierzamy komuś zarządzanie serwerami naszej firmy, pierwszą obawą, która przychodzi nam na myśl, jest obawa o bezpieczeństwo. Bezpieczeństwo rozumiane głównie jako możliwość utraty bądź wycieku danych, zatrzymania pracy przedsiębiorstwa, czy choćby nieautoryzowanego wykorzystania naszych serwerów do wysyłania spamu, kopania Bitcoinów itp. Wybierając dostawcę outsourcingu powinieneś wziąć pod uwagę m.in. oferowany poziom bezpieczeństwa. Poziom, który wynika zarówno z kompetencji poszczególnych pracowników dostawcy, jak i ze stosowanych przez dostawcę praktyk.

Poniżej znajdziesz nasze wewnętrzne wytyczne w zakresie bezpiecznego konfigurowania serwerów i usług w ramach systemu Linux. Wytyczne te możesz porównać z ofertą naszej konkurencji, jak również możesz je samodzielnie wdrożyć w swojej firmie (nawet jeśli prowadzisz działalność konkurencyjną).

Zarządzanie systemem i sprzętem
1. Wymagania podstawowe:
  • instalacja od zera przez naszych pracowników lub pod naszym bezpośrednim nadzorem, albo przeprowadzenie przy rozpoczęciu współpracy osobno płatnego audytu bezpieczeństwa i ewentualnego dostosowania konfiguracji serwera
  • dostęp dla naszych pracowników do warstwy powyżej systemu operacyjnego (fizycznie do pojedynczej maszyny, bądź do konsoli KVM, iLO, BladeCenter, ESXi itp.)
  • jeśli system jest maszyną wirtualną, dostęp z prawami administratora dla naszych pracowników do systemu hosta, brak działających innych usług na hoście poza wirtualizacją, oraz zgoda na przegląd bezpieczeństwa hosta (bezpłatny)
2. Konta użytkowników i administratorów:
  • klient posiada hasło użytkownika root tylko na wszelki wypadek; użytkownicy ze strony klienta nie wykonują żadnych działań administracyjnych bez konsultacji
  • wszyscy użytkownicy mają założone konta imienne, bez uprawnień administratora; nie ma możliwości logowania na konta wspólne (np. www-data)
  • wszyscy użytkownicy mają założone hasła, co najmniej jedną dużą literę i cyfrę w haśle, maksymalny okres ważności hasła 6 tygodni (dopuszczalne użycie kluczy ssh na zasadach określonych poniżej)
  • administracja za pomocą su/sudo, wyłączone bezpośrednie logowanie na konto root (dostęp bezpośredni tylko dla skryptów przez klucze ssh na zasadach określonych poniżej)
System operacyjny i źródła oprogramowania
1. Wybór systemu na nowy serwer:
  • Debian stable (najnowsze wydanie stabilne) - wersja zalecana
  • Ubuntu Server LTS (najnowsze wydanie stabilne) - jeśli nie można zastosować Debiana, albo w danym zastosowaniu wymagane są świeższe wersje oprogramowania
  • Oracle Linux (płatny) - dla instalacji Oracle Database
  • Red Hat Enterprise Linux (płatny) / CentOS (bezpłatny odpowiednik) - jeśli do danego zastosowania wymagany jest system typu Red Hat, albo specyficzne sterowniki do sprzętu
  • inny system operacyjny tylko po udokumentowaniu konkretnych potrzeb i akceptacji
  • dystrybucje SuSE, Slackware, Gentoo, Arch i inne, a także systemy BSD, Solaris itp. są na chwilę obecną obsługiwane tylko w ramach oferty pełnopłatnej
2. Polityka migracji serwerów i oprogramowania:
  • poprzednie wydanie stabilne Debiana należy zmigrować w ciągu 9 miesięcy od wydania nowej wersji
  • poprzednie wydanie LTS Ubuntu Server należy zmigrować w ciągu 2 lat od wydania nowej wersji
  • poprzednią wersję główną Red Hat Enterprise Linux / Oracle Linux / CentOS należy zmigrować w ciągu 3 lat od wydania nowej wersji głównej
3. Oprogramowanie spoza repozytoriów systemu operacyjnego:
  • w miarę możliwości wszelkie oprogramowanie instalowane na maszynach powinno pochodzić z pakietów w ramach domyślnych repozytoriów dla danego systemu
  • znane i zaakceptowane wyjątki wymagające dodatkowych repozytoriów:
    • Oracle Database i Oracle Grid Infrastructure
    • Percona Server (zamiennik MySQL)
    • New Relic (monitoring serwera i aplikacji na nim)
    • Proxmox Kernel (jądro ze wsparciem dla OpenVZ)
    • Google Chrome (dla stacji roboczych Ubuntu LTS ze środowiskiem graficznym)
  • dodatkowe repozytoria należy dodawać tylko po udokumentowaniu potrzeb i akceptacji; jeśli nie ma konieczności instalacji za pomocą repozytorium, to dodatkowe oprogramowanie instalujemy ręcznie (w szczególności dotyczy to oprogramowania specyficznego dla pojedynczych maszyn)
  • oprogramowanie spoza repozytorium należy instalować:
    • jeśli to oprogramowanie to pojedynczy skrypt w języku interpretowanym + ew. pliki konfiguracyjne, w ramach katalogu /etc (jako podkatalog)
    • jeśli to coś większego, w katalogu /opt
Backup danych
1. Organizacja backupu:
  • każda maszyna fizyczna i wirtualna (nie dotyczy kontenerów OpenVZ/LXC) jest indywidualnie odpowiedzialna za codzienne przygotowywanie backupu swojej konfiguracji i innych ważnych danych
  • backup kontenerów OpenVZ/LXC powinien być wykonywany z poziomu hosta, jako backup jego zasobów
  • backup przygotowywany przez maszynę dzieli się na:
    • codzienny - gotowe pliki wrzucane do katalogu /backup/daily
    • cotygodniowy - gotowe pliki wrzucane do katalogu /backup/weekly
  • backup danych szybko zmiennych i/lub szczególnie wrażliwych (np. katalogi /etc i /var/log) należy wykonywać codziennie
  • pliki trafiające do katalogu /backup i jego podkatalogów muszą być już lokalnie zaszyfrowane kluczem publicznym GPG - klucz prywatny nie powinien być wgrany na stałe na żadnym hoście, powinien znajdować się tylko i wyłącznie w kontenerze KeePass i być wgrywany tymczasowo w razie konieczności odtworzenia danych z backupu, po czym niezwłocznie usuwany
  • używany przez nas Server Farmer instaluje gotowe skrypty realizujące backup, na maszynach z tym frameworkiem nie trzeba nic więcej konfigurować
  • gotowe pliki z katalogów /backup/daily i /backup/weekly są odbierane przez centralny serwer backupu (przez scp i klucz ssh), zbierane w komplety wg określonego algorytmu i kopiowane na dysk zewnętrzny
Podstawowe usługi sieciowe
1. Firewall:
  • na wszystkich maszynach fizycznych i wirtualnych powinien być włączony lokalny firewall (na maszynach produkcyjnych musi być włączony):
    • dla systemów Debian / Ubuntu w katalogu /opt/firewall jest standardowo instalowany nasz autorski skrypt do sterowania firewallem systemowym
    • dla systemów bazujących na Red Hat z plikiem /etc/sysconfig/iptables i bez systemd/firewalld można dokonywać konfiguracji bezpośrednio w tym pliku
    • w przypadku konkretnych potrzeb dopuszczalne jest stosowanie innego oprogramowania do sterowania firewallem, np. Shorewall
  • na kontenerach OpenVZ/LXC rolę firewalla pełni host, niezależnie od tego na kontenerach należy w miarę możliwości ograniczać dostęp do usług do określonych pul adresowych (np. za pomocą zmiennej "mynetworks" w konfiguracji Postfixa lub analogicznie dla innych usług, zalecane jest także odpowiednie skonfigurowanie TCP Wrapper)
  • niezależnie od firewalli lokalnych, zalecane jest stosowanie zewnętrznego firewalla i/lub NAT na routerze
2. Usługa DHCP:
  • role serwerów DHCP pełnią routery Mikrotik
  • uruchamianie serwera DHCP na Linuksie tylko po udokumentowaniu konkretnych potrzeb i akceptacji
  • na serwerach fizycznych i wirtualnych rolę klienta DHCP pełni dhclient
  • na kontenerach OpenVZ/LXC adresy są przyznawane statycznie na hoście VZ/LXC
3. Usługa DNS:
  • role serwerów DNS dla sieci wewnętrznych pełnią routery Mikrotik
  • uruchamianie serwera DNS na Linuksie tylko po udokumentowaniu konkretnych potrzeb i akceptacji
  • każda maszyna fizyczna, wirtualna lub kontener powinny mieć wpisaną swoją natywną nazwę hosta do DNS
  • dla każdego dodatkowego adresu IP powinien być stworzony alias w DNS
  • sufiks powinien być zgodny z lokalizacją - np. "biuro", "dc1" itd.
4. Usługa MTA:
  • w każdej domenie zaufania powinien działać tylko 1 lokalny serwer MTA z otwartym na wybrane podsieci portem 25 (SMTP), przyjmujący pocztę od innych serwerów i przesyłający ją dalej, w miarę możliwości powinien to być serwer fizyczny
  • na pozostałych serwerach w ramach tej samej domeny zaufania powinien być zainstalowany program ssmtp, przesyłający lokalną pocztę do MTA
  • jeśli w danej dystrybucji program ssmtp nie jest dostępny w ramach standardowych repozytoriów, dopuszczalne jest zastosowanie serwera Postfix
  • lokalny serwer MTA jest relayem odbierającym pocztę od innych serwerów, kolejkującym i przesyłającym ją dalej do publicznego serwera SMTP przez dedykowane konto (każdy MTA powinien mieć swój odrębny login i hasło)
  • zalecanym oprogramowaniem MTA jest Postfix
  • aplikacje samodzielnie wysyłające pocztę bezpośrednio na publiczne serwery SMTP (np. JIRA) powinny mieć skonfigurowane swoje unikalne loginy i hasła
5. Usługa syslog:
  • w każdej domenie zaufania powinien działać tylko 1 lokalny serwer syslog z otwartym na wybrane podsieci portem 514, przyjmujący logi od innych serwerów i co godzinę obrabiający je programem logcheck; koniecznie musi to być serwer fizyczny, w miarę możliwości serwer nie powinien pełnić innych ról poza centralnym syslog i lokalnym MTA
  • na pozostałych serwerach w ramach tej samej domeny zaufania powinien być zainstalowany syslog w trybie przekazywania komunikatów do centralnego serwera
  • zalecanym oprogramowaniem jest domyślny typ serwera syslog dla danego systemu operacyjnego - np. rsyslog dla Debiana i Ubuntu
Sieciowe systemy plików i serwery urządzeń blokowych
1. Usługa NFS:
  • generalnie unikamy używania NFS, w przypadku potrzeby punktowego transferu plików zalecanym rozwiązaniem jest scp (klucz prywatny u klienta, rssh na serwerze), w przypadku potrzeby udostępnienia powierzchni dyskowej zalecanym rozwiązaniem jest iSCSI
  • zalecanym oprogramowaniem serwera NFS jest nfs-kernel-server i system operacyjny Debian stable / Ubuntu Server LTS
  • w przypadku appliance'ów klasy SOHO/SMB z własnym systemem operacyjnym, nie należy z nich wystawiać udziałów NFS, a jedynie targety iSCSI
2. Usługa iSCSI:
  • oprogramowanie: iscsitarget po stronie targetu, open-iscsi po stronie inicjatora; dopuszczalne wystawianie targetów dla systemów Windows
  • pojedyncze dyski łączymy w targety zgodnie z architekturą fizyczną - czyli jeśli mamy 5 dysków w 1 fizycznym urządzeniu na 1 kablu, to target też zawiera 5 dysków - wyjątek to gdy te dyski chcemy rozdzielić na kilka inicjatorów, ale wtedy też robimy jak największe pule
  • zawsze używamy identyfikatorów dysków /dev/disk/by-id/*, nigdy /dev/sda1 itd.
  • zawsze wystawiamy dla każdego dysku fizycznego numer seryjny zgodny z prawdziwym (dla plikowego - numer opisujący system plików, z którego wystawiony jest target)
3. Samba:
  • skrypty autorskie do konfiguracji Samby, specyficzne dla pojedynczych maszyn, należy wrzucać do katalogu /etc/samba
  • dla Samby 3.x działającej jako niezależny serwer plików (bez integracji z LDAP, Kerberosem, AD itp., z lokalnym uwierzytelnianiem użytkowników) jako passwd backend wybieramy metodę smbpasswd zamiast domyślnego tdbsam
Klucze prywatne i certyfikaty
1. Autoryzacja ssh za pomocą kluczy:
  • niezaszyfrowane klucze prywatne powinny być przechowywane tylko i wyłącznie na hostach i kontach, które mają mieć dostęp do zewnętrznego zasobu, tylko i wyłącznie na hostach z zaszyfrowanym dyskiem rozruchowym
  • niezaszyfrowane klucze powinny być stosowane tylko na potrzeby automatycznego dostępu przez skrypty
  • jeśli możliwa ma być autoryzacja ręczna, klucze powinny być szyfrowane (stosowane powinny być klucze odrębne od kluczy nieszyfrowanych, w miarę możliwości osobne klucze iminne dla każdego administratora)
  • wszystkie klucze prywatne składowane w systemach Windows (PuTTY, Cygwin, inne klienty ssh) muszą koniecznie być szyfrowane
2. Certyfikaty SSL dla serwerów https:
  • certyfikaty self-signed powinny być używane tylko na potrzeby deweloperskie
  • do celów produkcyjnych mogą być używane wyłącznie certyfikaty podpisane przez zewnętrzne CA klasy II (dla systemów z dostępem publicznym i kluczowych systemów własnych), bądź wewnętrzne CA (dla pozostałych systemów)
  • pliki certyfikatów i kluczy prywatnych (w szczególności niezaszyfrowane klucze) powinny być przechowywane tylko i wyłącznie na maszynach, które faktycznie potrzebują dostępu do takich plików
3. Klucze licencyjne do oprogramowania komercyjnego:
  • pliki kluczy licencyjnych powinny być przechowywane tylko i wyłącznie na maszynach, które faktycznie potrzebują dostępu do takich plików
  • wszelkie klucze sprzętowe (np. HASP) używane w systemach produkcyjnych muszą być wpisane do ewidencji kluczy sprzętowych wraz z nazwą serwera i opisem celu stosowania klucza
  • klucze sprzętowe ze złączem innym niż USB (np. LPT 25-pin) nie mogą być używane ani podłączane do systemów będących hostami LXC ani hiperwizorami - aplikacja korzystająca z klucza innego niż USB powinna być zainstalowana bezpośrednio na maszynie fizycznej, jako jedyna aplikacja/usługa
Bazy danych i serwery aplikacji
1. Bazy danych MySQL i inne (również nosql):
  • generalnie unikamy stawiania dużych, zbiorczych serwerów baz danych, chyba że po udokumentowaniu wymogów i akceptacji - zamiast tego stawiamy małe instancje per zastosowanie (nie dotyczy to komercyjnych baz danych, licencjonowanych per procesor)
  • w miarę możliwości bazujemy na domyślnej konfiguracji dla bieżącego systemu operacyjnego
  • w miarę możliwości łączność aplikacji z bazą powinna się odbywać przez sockety plikowe, nie należy włączać dostępu TCP jeśli nie jest to konieczne
  • Server Farmer w systemach Debian i Ubuntu wykonuje cotygodniowy backup lokalnej bazy danych MySQL (pod warunkiem instalacji z repozytorium) - backup pozostałych baz danych należy oprogramować samodzielnie
2. Java:
  • wersje Javy spoza repozytorium powinny być instalowane jako /opt/jre1.7.0_X, /opt/jdk1.7.0_X itd.
  • domyślna wersja Javy powinna albo pochodzić z repozytorium, albo należy zrobić linki symboliczne:
    • /usr/local/bin/java -> /opt/java/bin/java
    • /opt/java -> /opt/jre1.7.0_X
  • jeśli domyślną wersją Javy ma być wersja spoza repozytorium, należy:
    • odinstalować z maszyny wszelkie inne wersje Javy (w szczególności inne niż Sun Java)
    • dodać ścieżkę /opt/java/lib/amd64 do katalogu /etc/ld.so.conf.d
    • wykonać polecenie "ldconfig" jako root (polecenie to ponawiać przy każdej zmianie miejsca docelowego dla linka /opt/java)


Tomasz Klim
Administrator serwerów i baz danych, specjalista w zakresie bezpieczeństwa, architekt IT, przedsiębiorca. Ponad 20 lat w branży IT. Pracował dla największych i najbardziej wymagających firm, jak Grupa Allegro czy Wikia. Obecnie zajmuje się bezpieczeństwem projektów blockchainowych w Espeo Software. Chętnie podejmuje się ciekawych zleceń.


Wzbudziliśmy Twoje zainteresowanie?

Szukasz pomocy? formularz kontaktowy