Będę sysadminem! – Konfiguracja VPS. Część 3.

Albert Tomaszewski/ Marzec 9, 2015/ Debian, IT, Linux/ 0 comments

Poziom trudności    

Nadszedł czas na kolejny etap konfiguracji serwera. Zabezpieczenia. Znowu nie będzie łatwo.

 

Aby dobrze się zabezpieczyć wczuj się w rolę atakującego

Zabezpieczając swój serwer (tudzież sieć LAN) musisz przyjąć strategię myślenia atakującego. Wiedz o tym, że będzie on szukał słabych punktów w zabezpieczeniach, a potem bezlitośnie je wykorzysta do włamania.

W swoim krótkim doświadczeniu z serwerami spotkałem się z dwoma atakami na serwery linux. Obie maszyny posłużyły do automatycznego i masowego wysyłania spamu mejlowego (widać musi być to opłacalne na czarnym rynku). Mimo podobnego osiągniętego celu ataków, same w sobie przebiegły zupełnie inaczej.

Pierwszą maszyną był mój pierwszy serwer VPS, który posiadałem niegdyś. Postawiłem tam apache’a, PHPa i bazę MySQL – wszystko to za czasów gdy jeszcze nie znałem linuxa – z tutoriali znalezionych w sieci, metodą kopiuj-wklej. Widząc słynne apaczowe „It works!”, potem PHP Info a jeszcze potem komunikat o poprawnym połączeniu do bazy danych cieszyłem się konfiguracją i na tym ją zakończyłem. Wtedy jeszcze nie wiedziałem, że serwery w centrach danych (VPSy i dedyki) nie mają ustawionych żadnych zabezpieczeń! Routery w centrach danych zajmują się routingiem i load balancingiem, ewentualnie wychwytują ataki DDoS i je odbijają. W tych routerach nie ma włączonego NATa – wszystkie porty są otwarte. Wiedz, że teraz czytając ten post w pracy czy w domu jesteś bardziej chroniony przez router i system operacyjny niż każdy serwer od dostawcy. Oczywiście nie dotyczy to właścicieli hostingu, gdzie administracja spoczywa na barkach sprzedawcy. Wracając do ataku – po skonfigurowaniu LAMPa wystawiłem na publiczny dostęp porty usług, które zostały uruchomione na serwerze. Port 22 (ssh), 80 (apache), 443 (apache po SSL) oraz 3306 (mysql) były otwarte i nasłuchiwane przez usługi – tym samym narażone na ataki z sieci. Tak jak nie możemy zablokować portów webowych, tak też pozostałe powinniśmy, o ile oczywiście taka jest nasza wola. Powszechnie stosowaną praktyką jest restrykcyjne blokowanie wszystkich portów na serwerze i ewentualne odblokowywanie poszczególnych w razie potrzeby. Do tego służy narzędzie iptables w linuxie – będzie o nim troszkę dalej. W ten sposób możemy wyłączyć dostęp do bazy danych (zablokować port 3306) – skoro na serwerze mam strony www, które łączą mi się do baz danych na tym samym serwerze to po co mi dostęp do baz z innych miejsc (komputerów)? Kolejną dobrą praktyką jest silne zabezpieczenie połączenia przez SSH. Tutaj tak na prawdę stosuje się 4 rozwiązania – zmiana domyślnego portu nasłuchującego ssh na niestandardowy, użycie narzędzia fail2ban (blacklistowanie adresów IP próbujących ataku metodą Brute Force), wyłączenie logowania po haśle i dopuszczenie jedynie logowań z użyciem pary kluczy publicznego i prywatnego oraz w końcu graniczenie dostępu do ssh jedynie dla konkretnych źródłowych adresów IP. Użycie każdego kolejnego rozwiązania z tych, które wymieniłem sprawi, że zmniejszysz ryzyko włamu na swój serwer. Pamiętaj jednak, że jeśli będziesz korzystał z logowania kluczem publicznym, metoda ta będzie na tyle bezpieczna na ile bezpiecznie będziesz przechowywał swój klucz prywatny. Mam nadzieję, że nie zapomnę kiedyś poruszyć tego tematu. Ważnym kolejnym aspektem bezpieczeństwa Twojego serwera jest aktualizowanie pakietów oprogramowania. Kolejne wersje programów często wnoszą poprawki bezpieczeństwa. Na moim serwerze nie zastosowałem żadnego zabezpieczenia, przez co po zaledwie kilku godzinach ataku (w nocy) wstrzykiwania exploitów w port 3306 moja baza danych padła a włamywacz uzyskał dostęp do shella i zmienił hasło do konta root na swoje własne. Dodam jeszcze tylko, że o tym wszystkim dowiedziałem się następnego dnia, kiedy było już za późno na interwencję – obciążenie zainfekowanego serwera było tak wysokie, że ledwie udało mi się odczytać logi.

Drugi serwer, o którym wspomniałem to świeższy przypadek. Wybaczcie, ale nie mogę zdradzić wszystkich szczegółów, jednak postaram się jak najwięcej. Serwer bazodanowy działał w pewnym miejscu całkowicie poprawnie i z wdrożonymi różnymi mechanizmami bezpieczeństwa. Pan X, będący informatykiem w firmie będącej właścicielem serwera, lubił go monitorować (mając do niego pełny dostęp przez konto root). Jego lenistwo jednak zaprowadziło go do skorzystania ze skryptu, który znalazł w sieci – miał on zainstalować automatycznie system do kontrolowania serwera. Świetne ułatwienie, prawda? Tak. Dla autora skryptu – w pozyskaniu nowych spambotów. Skrypt zaciągnął z sieci kolejne, które rozpoczęły wysyłkę mejli. Jako ciekawostkę dodam, że wygenerowały one obciążenie na serwerze przekraczające 40.0 loadu. Niczego nieświadomy Pan X chwycił za słuchawkę i poskarżył się do mnie, że baza danych wolno pracuje a program z niej korzystający niemal nie reaguje na kliknięcia.

 

Wróćmy do meritum

Tymi dwiema historyjkami chciałem Ci tylko pokazać z czym możesz się spotkać administrując serwerami. Zagrożeń w sieci jest znacznie więcej, jednak rozwiązania, które chcę Ci zaproponować pomogą Ci się ustrzec przed znaczną większością z nich.

1. Firewall – iptables

iptables to proste i potężne narzędzie, które zarządza ruchem sieciowym. Potrafi zablokować ruch na konkretne porty tudzież protokoły, tworzyć maskarady. Tak jak wcześniej wspomniałem – powszechnie stosowaną praktyką jest zablokowywanie całego ruchu sieciowego i odblokowanie jedynie tego, na którym nam zależy.

Instalujemy iptables:

[email protected]:$ apt-get update ; apt-get install -y iptables

Tworzymy skrypt z konfiguracją:

[email protected]:$ touch /root/iptablesy.sh
[email protected]:$ chmod +x /root/iptablesy.sh
[email protected]:$ vim /root/iptablesy.sh

I wprowadzamy mu reguły:

#!/bin/sh

PATH='/sbin'

#Oczyszczamy tablice z poprzednio wpisanych reguł
iptables -F
iptables -X

#Ustawiamy politykę domyślną - akceptujemy pakiety generowane przez maszynę, resztę odrzucamy
iptables -P FORWARD DROP
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT

#Następnie ustalamy reguły, które będą wyjątkami od ustalonych polityk

#Zezwalamy na nawiązane połączenia
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#Zezwalamy na korzystanie z pętli zwrotnej (loopback)
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT

#Zezwolenie na ping bo kimsufi krzyczy, że serwer nie odpowiada
iptables -A INPUT -p ICMP --icmp-type 8 -s 0.0.0.0/0 -j ACCEPT
iptables -A INPUT -p ICMP --icmp-type 11 -s 0.0.0.0/0 -j ACCEPT

#Otwieranie portów
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Jest to prosta konfiguracja, są jednak możliwe do stworzenia bardziej zaawansowane reguły. Mogą one przekierowywać porty, otwierać je dla konkretnych adresów lub zamykać jedynie wybrane porty. W sieci jest wiele tutoriali, które opisują iptables – zachęcam do lektury.

2. Fail2ban

Fail2ban to proste w działaniu narzędzie chroniące nas przez atakami Brute Force na hasło do dostępu do serwera (i innych usług). Po kilku próbach nieudanego zalogowania się fail2ban dodaje podejrzany adres IP do firewalla (jako zablokowany). Można skonfigurować czy blokada ma być stałą czy czasowa, po ilu próbach logowania ma nastąpić. Ja używam konfiguracji standardowej, która jest dobrze napisana, dlatego też ograniczam się jedynie do samej instalacji:

[email protected]:$ apt-get install -y fail2ban

3. Zmiana portu SSH

Zdecydowana większość botów grasujących w sieci sprawdza jedynie podstawowe (1-1024) porty. Niestety SSH w konfiguracji poinstalacyjnej nasłuchuje na porcie 22, który mieści się w tych, które są narażone na ataki – dlatego też wprowadzimy prostą zmianę.
Na początku edytujemy plik konfiguracyjny demona SSH:

[email protected]:$ vim/etc/ssh/sshd_config

I zamieniamy wartość zmiennej Port na wybraną przez nas wartość:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22002
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0

Pamiętaj jednak, że sama zmiana portu to jedynie utrudnienie dla atakujących, nie stanowi pełnego zabezpieczenia serwera.

Podsumowanie

Zabezpieczenie serwera w zasadzie nigdy nie daje 100% gwarancji na to, że zamieszczone dane będą bezpieczne a dostęp nie zostanie udzielony osobom niepożądanym. Można jednak znacznie utrudnić ich działanie, a ryzyko włamania zminimalizować. W razie pytań lub sugestii jestem do dyspozycji w komentarzach.

Leave a Comment

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre user="" computer="" escaped="">
*
*