Naucz się jak zabezpieczyć swój serwer, cześć 1: podstawy

dodał 10 października 2016 o 07:15 w kategorii HowTo  z tagami: • • • •
Naucz się jak zabezpieczyć swój serwer, cześć 1: podstawy

W ostatnich miesiącach namawialiśmy Was do postawienia swoich własnych serwerów pełniących rolę usługi kopii bezpieczeństwa lub VPN. Przedstawione przez nas konfiguracje były bezpieczne, ale nadszedł czas, by je jeszcze trochę ulepszyć.

We współpracy z firmą ArubaCloud pokazaliśmy Wam, jak postawić swój serwer backupów, jak skonfigurować własny serwer VPN i podłączyć do niego komputer, telefony komórkowe oraz domowy ruter a także jak schować się przed cenzurą sieci. Dzisiaj zaczynamy cykl artykułów, w których pokażemy Wam, jak podnieść bezpieczeństwo Waszych serwerów w Arubie. Zaczniemy od podstaw, a w kolejnych odcinkach dodamy kolejne elementy zabezpieczeń.

Jeśli nie macie jeszcze swojego własnego serwera, to jest to dobra okazja by się w taki wyposażyć. Aruba oferuje dwa miesiące korzystania ze swojego podstawowego serwera gratis – a po zakończeniu promocji będzie on Was kosztował zaledwie 4 złote miesięcznie. Instrukcję jak krok po kroku skorzystać z promocji i uruchomić swój serwer znajdziecie w tym artykule. Jeśli macie już swój serwer – to zapraszamy do lektury kolejnych akapitów.

SSH bezpieczniej

Wszystkie poniższe instrukcje powinny działać na systemie CentOS7, który wykorzystywaliśmy przy poprzednich instrukcjach. Ćwiczenie zaczniemy od poprawy bezpieczeństwa usługi SSH. Co prawda jeśli wybraliście silne hasło roota to Wasz serwer raczej jest w większości przypadków bezpieczny, ale bez dodatkowej konfiguracji daleko mu do modelowego wdrożenia. Trochę go zatem podrasujemy.

Jeśli nie zmienialiście naszej domyślnej konfiguracji, to logujecie się za pomocą swojego hasła bezpośrednio na konto roota na porcie 22. Wszystkie elementy tej układanki poskładamy od nowa. Po pierwsze stworzymy nowego użytkownika, by nie logować się bezpośrednio zdalnie na roota. Dużo bezpieczniej jest konta roota używać tylko do czynności które go naprawdę wymagają, na co dzień korzystając z konta o niższych uprawnieniach. Dodamy zatem w naszym systemie nowego użytkownika i ustawimy mu nowe hasło.

useradd adam
passwd adam

Dodamy też użytkownika do grupy WHEEL by w razie potrzeby mógł wykonywać polecenia jako root.

usermod -aG wheel adam

Mamy teraz nowego użytkownika – możemy od razu się na jego konto zalogować. Gdy się zalogujemy (nowa sesja w PuTTy), to od razu utworzymy mu klucz SSH. I to klucz bardzo bezpieczny, używający kryptografii krzywych eliptycznych – a konkretnie lubianej i szanowanej krzywej Ed25519. Użyjemy także zabezpieczenia przed atakami typu bruteforce na hasło naszego klucza – na wypadek gdyby ktoś go nam ukradł i próbował nasze hasło do niego złamać. Wykorzystamy w tym celu funkcję bcrypt i na przykład 100 rund, by zniechęcić potencjalnego atakującego.

[adam@serwer ~]$ ssh-keygen -o -a 100 -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/adam/.ssh/id_ed25519):
Created directory '/home/adam/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/adam/.ssh/id_ed25519.
Your public key has been saved in /home/adam/.ssh/id_ed25519.pub.

Pobierzemy klucz na nasz komputer, by zalogować się nim zdalnie zanim wyłączymy możliwość logowania się hasłem.

[adam@serwer ~]$ cd .ssh
[adam@serwer .ssh]$ cat id_ed25519
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNsaC1rZXltdjEAAAAACmFlczI1Ni1jYmMAAAAGYmNyeXB0AAAAGAAAABCpbVco+k
SRaMh/ndLs15daAAAAZAAAAAEAAAAzAAAAC3NzaC4lZDI1NTE5AAAAIBlV2rHO4axH8Otm
7lU7yTveIWWlt8Yy0vKGQnEhzwJ4AAAAoN5YkWL55KoygRRXFEkqG1Jho0VFYRKvC8npY+
q5oSRuTZvsk6t77mxvUJWatljIN70Zhtn5UxqoH3+RQ1sVvLUwhvafvGaXCkawylUUoKkO
je1QiI31Fj3wt2pMehyjFtVPsYMA5DYIOW0CVhLlehADFyxtw0Z61r+zU5VIl4UgI7KZme
/UMC+6UNR/dzDj1JgvT1pMS7RDYqhBDuuI1v0=
-----END OPENSSH PRIVATE KEY-----

Zwartość klucza prywatnego możemy skopiować z ekranu PuTTy i wkleić do pliku tekstowego który zapiszemy w bezpiecznym miejscu na naszym dysku. Aby użyć nowego formatu klucza potrzebujemy jednak nowej wersji PuTTy oraz narzędzia PuTTygen. Na stronie PuTTy znajdujemy sekcję „The latest development snapshot” (różowe tło) i pobieramy PuTTy.exe oraz PuTTygen.exe. Uruchamiamy nowe PuTTygen.exe i wybieramy menu „Conversions” oraz „Import key” a następnie wskazujemy zapisany przed chwilą klucz prywatny. Podajemy hasło klucza i gdy po chwili zostanie prawidłowo zaimportowany wybieramy „Save private key” i zapisujemy plik z rozszerzeniem .PPK w bezpiecznej lokalizacji. Pozostaje nam już tylko na serwerze skopiować nasz klucz publiczny do pliku o odpowiedniej nazwie:

cd .ssh
cp id_ed25519.pub authorized_keys

a w PuTTy w sekcji „Connection” w menu „Data” wypełnić pole „Auto-login username” oraz w menu SSH/Auth wskazać plik .PPK (i zapisać ustawienia by nie musieć powtarzać całej operacji). Po udanym logowaniu za pomocą klucza możemy wrócić do dalszego zabezpieczenia usługi SSH na serwerze.

Aby móc edytować konfigurację serwera SSH najpierw nadamy sobie moc roota poprzez polecenie

su

a następnie podanie hasła roota. Dla wygody możemy teraz uruchomić Midnight Commandera

mc

i poszukać pliku

/etc/ssh/sshd_config

W nim około wiersza 17 zmienimy numer portu na np. 5000

Port 5000

W wierszu 23 wymusimy korzystanie z najnowszej wersji protokołu:

Protocol 2

W wierszu 44 ustawimy dokładniejsze logowanie informacji, na przykład odcisków kluczy używanych do logowania:

LogLevel VERBOSE

W okolicy wiersza 49 zablokujemy możliwość logowania się bezpośrednio na konto roota:

PermitRootLogin no

a około wiersza 79 wyłączymy możliwość logowania się za pomocą hasła:

PasswordAuthentication no

Zmodyfikowany plik zapiszemy (F2) i zrestartujemy usługę:

systemctl reload sshd.service

Nie zamykając okienka w którym pracowaliśmy (na wszelki wypadek, by w razie katastrofy móc jeszcze wprowadzić poprawki) możemy przetestować logowanie z osobnej sesji PuTTy (nie zapomnijcie zmienić numeru portu na nowy). Jeśli wszystko działa to możemy przejść do kolejnych zadań, czyli blokowania adresów, które dobijają się do naszej usługi.

fail2ban

Aby zabezpieczyć serwer przed uporczywymi próbami odgadywania haseł wdrożymy tez blokowanie niegrzecznych użytkowników po adresie IP. W tym celu użyjemy narzędzia fail2ban. Najpierw musimy je zainstalować:

yum install fail2ban fail2ban-systemd

Następnie stworzymy odpowiednią konfigurację – będziemy blokować adres IP na dobę za 3 nieudane próby logowania. W edytorze Midnight Commander (sudo mc) wchodzimy do katalogu

/etc/fail2ban/jail.d/

tworzymy plik (Shift+F4) o treści:

[sshd]
enabled = true
port = 5000
logpath = %(sshd_log)s
maxretry = 3
bantime = 86400

i zapisujemy go (F2) pod nazwą sshd.local. Wystarczy już tylko uruchomić usługę i zapewnić jej uruchamianie przy każdym restarcie:

systemctl enable fail2ban
systemctl start fail2ban

iptables

Jako ostatni z podstawowych kroków konfiguracji bezpieczeństwa serwera włączymy firewalla. Co prawda udostępniamy naprawdę niewiele usług, ale dobrze skonfigurowany firewall jeszcze nikomu nie zaszkodził, a tu konfiguracja będzie dość prosta. Jako narzędzia do określenia zasad przepuszczania i blokowania ruchu użyjemy polecenia iptables.

Zaczniemy od zatrzymania usługi firewalld oraz maskujemy ją aby nie uruchamiała się podczas uruchomienia systemu:

systemctl stop firewalld
systemctl mask firewalld

Następnie instalujemy pakiet iptables-services:

yum install iptables-services

Ustawiamy automatyczne uruchamianie usługi iptables podczas startu systemu:

systemctl enable iptables

Następnie usuwamy przypadkowe lub stare reguły:

iptables -F

Zaakceptujemy połączenia na interfejsie lokalnym:

iptables -A INPUT -i lo -j ACCEPT

Wpuścimy ruch do naszego serwera SSH (na porcie 5000) oraz serwera VPN (na porcie 11194)

iptables -A INPUT -p tcp -m tcp --dport 5000 -j ACCEPT
iptables -A INPUT -p udp --dport 11194 -j ACCEPT

Pozwolimy na ruch wychodzący z serwera (np. pobieranie aktualizacji)

iptables -P OUTPUT ACCEPT
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

A całą resztę ruchu zablokujemy

iptables -P INPUT DROP

Możemy teraz sprawdzić czy o czymś nie zapomnieliśmy

iptables -L -n

Następnie zapisujemy konfigurację

iptables-save > /etc/sysconfig/iptables

i restartujemy usługę

systemctl restart iptables

Automatyczne aktualizacje

Jeśli w poprzednich artykułach ominęliście konfigurację automatycznych aktualizacji bezpieczeństwa, to najwyższy czas je uruchomić na serwerze. Instalujemy pakiet yum-cron:

yum install yum-cron

W pliku /etc/yum/yum-cron.conf zmieniamy w wierszu 8

update_cmd = default

na

update_cmd = security

a w wierszu 19

apply_updates = no

na

apply_updates = yes

Pozostaje uruchomić usługę:

systemctl start yum-cron.service

Dzięki temu nie będziecie musieli co parę dni aktualizować ręcznie pakietów oprogramowania w obawie przed nowymi błędami – aktualizacje bezpieczeństwa zainstalują się same.

Odzyskiwanie dostępu do serwera

W trakcie eksperymentów z podnoszeniem poziomu bezpieczeństwa może się zdarzyć, że zabezpieczenia okażą się zbyt skuteczne nawet dla właściciela serwera i zostaniecie odcięci od swojej maszyny (szczególnie zdarza się przy zabawach z iptables). Na szczęście ArubaCloud dysponuje rozwiązaniem awaryjnym, które pozwoli w łatwy sposób do serwera wrócić. Wystarczy, że zalogujecie się na swoje konto, na liście serwerów wybierzecie obok nazwy swojej maszyny opcję „Zaloguj się” a następnie w prawym dolnym rogu wybierzecie opcję „Uruchom proces startowania konsoli”.

aruba01

Traficie wtedy do ekranu logowania gdzie wystarczy że podacie login roota oraz hasło by dostać się do swojej maszyny. Metoda ta pozwoli Wam np. poprawić reguły iptables lub błędnie skonfigurowany dostęp SSH i przywrócić dostęp do serwera.

Podsumowanie

Powyżej przedstawiliśmy jedynie kilka podstawowych kroków mających podnieść poziom bezpieczeństwa usługi SSH oraz samego serwera. Staraliśmy się nie popadać w paranoję i wybrać metody, które pozwalają bezpieczeństwo poprawić, nie zabijając użyteczności. To oczywiście dopiero wstęp do tematu, który będziemy rozwijać w kolejnych odcinkach. Zapraszamy też do zgłaszania uwag i pomysłów – poradnik może dzięki Wam stać się dużo lepszy w kolejnej edycji.

Poradnik oraz swoje własne pomysły możecie testować na serwerach ArubaCloud przez dwa miesiące za darmo, a potem za zaledwie 4 PLN miesięcznie. Zapraszamy do zabawy :)

Dla pełnej przejrzystości – za przygotowanie oraz opublikowanie powyższego artykułu otrzymujemy wynagrodzenie.

Podobne wpisy