Przy pierwszym połączeniu się z serwerem jest kilka rzeczy, które warto lub nawet trzeba zrobić. Postanowiłem wybrać pięć, które według mnie są najistotniejsze, i pokrótce je opisać. Proszę nie traktujcie tego co napiszę w tym wpisie jako widzę absolutną. Ja jedynie pokażę kilka, z mojej perspektywy, prostych i niezbędnych zabiegów, które wykonuję na swoich serwerach. Nie jestem ekspertem od cyberbezpieczeństwa czy też doświadczonym bezpiecznikiem/pentesterem, więc nie przedstawię tutaj przepisu na w pełni zabezpieczony serwer. W tym aspekcie odsyłam Was do bardziej wykwalifikowanych kolegów, których poradników jest mnóstwo w internecie. Każdy admin jest odpowiedzialny za bezpieczeństwo serwera, którym zarządza.

Zmiana hasła administratora

Po instalacji świeżego systemu na naszym ODROIDzie zawsze mamy nas start utworzonych dwóch użytkowników – root i odroid. Domyślnie dla obu tych kont hasło to „odroid”. Jest to hasło, które należy traktować jako tymczasowe do natychmiastowej zmiany. A więc nie przedłużając, zróbmy to!

Najpierw logujemy się na użytkownika odroid i wpisujemy polecenie:
passwd
Zostaniemy poproszeni o podanie aktualnego hasła do tego konta, a więc wpisujemy „odroid”. Następnie należy podać dwukrotnie nowe hasło, którym chcemy zabezpieczyć tego użytkownika.
$ passwd
Changing password for odroid.
Current password:
New password:
Retype new password:
passwd: password updated successfully
Powinnyśmy uzyskać taki rezultat. Po zmianie hasła dobrze jest się wylogować i kontrolnie połączyć się jeszcze raz przy użyciu nowego hasła. Jeżeli coś na tym etapie byłoby nie tak to możemy się jeszcze ratować kontem root. Jeżeli jest OK to teraz rzecz, o której wiele osób zapomina.

Zabezpieczyliśmy tylko jedno z dwóch kont! Na koncie roota dalej mamy fabryczne, banalnie proste hasło „odroid”. Nie możemy tego tak zostawić, dlatego wykonujemy bliźniacze do powyższych działania. Będąc zalogowanym na użytkownika odroid musimy przejść na roota, a więc wydajemy polecenie:
su
Jest to skrót od Super User. Podajemy hasło do użytkownika root, a więc (jeszcze) „odroid”. Następnie „passwd” i tak jak ostatnio podajemy dwa razy nowe hasło. Po potwierdzeniu wykonania zmiany hasła, możemy opuścić konto roota poleceniem:
exit
Tam samo jak wcześniej proponuję kontrolnie jeszcze raz zalogować się na roota i sprawdzić czy nowe hasło działa prawidłowo.

Zmiany haseł użytkowników już od pewnego czasu nie są uznawane za wystarczającą formę zabezpieczenia swojego serwera przed atakami po SSH. Znacznie bezpieczniejszym rozwiązaniem jest stosowanie kluczy SSH, ale o tym będzie oddzielny wpis, bo jest to ważne zagadnienie. W tym wpisie skupimy się tylko na podstawach, które należy zaaplikować zaraz po pierwszym połączeniu się z serwerem i na krótką metę wystarczą.

---

Adres IP serwera jako statyczny

We wpisie, w którym opisywałem jak po raz pierwszy połączyć się z serwerem, ustaliliśmy aktualny adres IP serwera. Warto jednak pamiętać, że jeżeli nie zmienimy tego ręcznie to dla routera ten adres będzie dynamiczny, a więc taki który może ulec zmianie np. gdy odepniemy od routera lub wyłączymy nasze urządzenie, a adres ten zostanie przypisany do innego urządzenia. Dlatego rozsądnym jest wskazanie w ustawieniach routera tego adresu jako statyczny, przypisany na stałe do naszego serwera. Nie będę pokazywał jak to się robi, bo dla każdego routera wygląda to inaczej. Na pewno można to zmienić w ustawieniach dotyczących serwera DHCP.

---

Ustawiamy prawidłową strefę czasową

Do kontroli poprawnego działania serwera niejednokrotnie będziemy używać wszelkiego rodzaju logów, czyli pewnego rodzaju dzienników zdarzeń. Aby było to możliwe musimy zadbać, aby prawidłowo ustawić tak trywialną rzecz jak godzina i data, które są istotne, aby ustalić dokładnie, w którym momencie nastąpiło zdarzenie nas interesujące. Ustawienia strefy czasowej sprawdza się poleceniem:
timedatectl
Sprawdźmy zatem jakie ustawienia ma nasz serwer:
Local time: Sun 2022-06-05 08:02:12 UTC
Universal time: Sun 2022-06-05 08:02:12 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Jak widać strefa czasowa jest nieprawidłowa, gdyż zamiast +0000 powinna wynosić dla Polski +0200 w okresie czasu letniego. Zatem czas pokazywany na serwerze jest o 2 godziny spóźniony względem naszego czasu lokalnego. Winne jest błędne ustawienie parametru „Time zone”, a więc zmieńmy je poleceniem:
sudo timedatectl set-timezone Europe/Warsaw
Zmieniliśmy strefę czasową na tą odpowiadającą naszemu miastu stołecznemu – Warszawie. Sprawdźmy teraz czy już jest w porządku:
$ timedatectl
Local time: Sun 2022-06-05 10:03:04 CEST
Universal time: Sun 2022-06-05 08:03:04 UTC
RTC time: n/a
Time zone: Europe/Warsaw (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

---

Zmiana domyślnego portu SSH z 22 na inny

Domyślnym portem do łączenia przez SSH jest port 22. Wpisując standardowe polecenie wywołujące połączenie nie musimy podawać tego portu, bo system od razu wie, że to właśnie z portem 22 musi się połączyć. Jest to takie samo ułatwienie dla osób trzecich próbujących przeprowadzać zautomatyzowane ataki na port 22. Dlatego też dobrą praktyką jest zmiana domyślnego portu SSH z 22 na jakikolwiek inny z przedziału 1024 – 65535 (0-1023 są zarezerwowane dla usług systemowych).

Zmiana portu jest banalnie prosta, realizuje się ją poprzez edycję pliku konfiguracyjnego usługi „sshd”:
sudo nano /etc/ssh/sshd_config
W pliku odszukujemy linijkę „#Port 22”, usuwamy znak komentarza i zmieniamy 22 na wybrany przez nas numer (przyjmijmy, że wybraliśmy 1234):
Port 1234
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
Zapisujemy edytowany plik i wychodzimy z niego.
Konieczne będzie jeszcze zrestartowanie procesu ssh, aby nowa konfiguracja została załadowana:
sudo service ssh restart
Mimo zmiany portu powinniśmy dalej pozostać normalnie zalogowani, jednak po rozłączeniu z serwerem i próbie ponownego połączenia standardowym poleceniem uzyskamy błąd:
% ssh odroid@192.168.88.7
ssh: connect to host 192.168.88.7 port 22: Connection refused
Taki sam komunikat dostanie potencjalny włamywacz, co po pierwsze powinno go zniechęcić, natomiast jeżeli się tak nie stanie to musi sprawdzić 65535 możliwych kombinacji, co nie jest karkołomnym zadaniem, ale na pewno utrudniającym pracę. Zawsze mówi się, że włamywacze, szczególnie tacy którzy masowo atakują serwery, są leniwi i jak tylko napotkają jakiś problem to atakują następny cel, zamiast dalej tracić czas na atakowanie tego, który sprawia problemy.

Skoro zmieniliśmy domyślny port SSH to od teraz musimy łączyć się z serwerem przy użyciu zmodyfikowanego polecenia:
ssh -p 1234 odroid@192.168.88.7

---

Firewall – zapora sieciowa

Mimo tego, że na razie serwera nie wystawiamy poza sieć lokalną, to i tak warto pochylić się na chwilę nad uszczelnieniem serwera pod kątem sieciowym. Wykorzystamy do tego narzędzie „ufw”, które jest domyślnie zaimplementowane w naszym systemie. Rozwinięciem skrótu jest Uncomplicated Firewall (nieskomplikowana zapora sieciowa), czyli jak sama nazwa wskazuje jest to bardzo przyjazny interfejs do modyfikacji ustawień zapory. Zaprezentuję tutaj jedynie podstawową konfigurację, którą później będzie można modyfikować.

W pierwszej kolejności musimy się upewnić, że zaporę mamy nieaktywną w momencie zmieniania jej konfiguracji:
sudo ufw status verbose
Porządany jest dla nas status „inactive”:
Status: inactive
Jeżeli jest tam cokolwiek innego to po pierwsze powinniśmy zastosować polecenie, które wyłączy nam tą usługę:
sudo ufw disable
A następnie dobrze jest zresetować konfigurację do wartości domyślnej:
sudo ufw reset

Rozpoczynamy konfigurację. Najpierw blokujemy cały ruch przychodzący:
sudo ufw default deny incoming
Następnie pozwalamy na cały ruch wychodzący:
sudo ufw default allow outgoing
Skoro zablokowaliśmy cały ruch przychodzący to po włączeniu firewalla w takiej formie nie będziemy mogli się połączyć nawet przez SSH. Tego byśmy nie chcieli, więc musimy otworzyć port 1234 (to nasz zmieniony port do komunikacji SSH – patrz rozdział wyżej tego wpisu):
sudo ufw allow 1234
Na razie to wszystko, jeżeli chodzi o podstawową konfigurację. Później jak będziemy uruchamiać jakieś dodatkowe usługi na innych portach to musimy pamiętać, aby otworzyć te porty w firewallu.
Jeżeli ktoś chce być ultrauszczelniony to może się jeszcze pobawić z otwieraniem portu 22 jedynie dla konkretnego adresu IP, ale to już dla bardzo ambitnych, którzy mogą sobie o tym doczytać. Podpowiem tylko, że realizuje się to poleceniem w formie:
sudo ufw allow from [adres_IP] to any port [port]

Konfiguracja zakończona, możemy zatem uruchomić nasz firewall:
sudo ufw enable
Otrzymujemy ostrzeżenie, że jeżeli coś zepsuliśmy to możemy stracić dostęp, jesteśmy tego świadomi, więc potwierdzamy „y”:
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
W rezultacie powinnyśmy otrzymać następujący komunikat potwierdzający:
Firewall is active and enabled on system startup

Teraz upewnijmy się, że usługa ufw będzie uruchamiana wraz ze startem systemu (np. po restarcie). Ta opcja powinna się włączyć sama, ale zawsze dobrze sprawdzić to we własnym zakresie. Wchodzimy do pliku konfiguracyjnego ufw:
sudo nano /etc/ufw/ufw.conf
Interesuje nas tutaj, aby wartość „ENABLED” była ustawiona na „yes”:
# Set to yes to start on boot. If setting this remotely, be sure to add a rule
# to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
ENABLED=yes

Na koniec sprawdźmy status firewalla:
sudo ufw status verbose
Odpowiedź serwera powinna wyglądać następująco:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
1234 ALLOW IN Anywhere
1234 (v6) ALLOW IN Anywhere (v6)

Jeżeli materiał zawarty w tym wpisie jest dla Ciebie wartościowy i masz ochotę wesprzeć moją pracę to zapraszam na mój profil na >Patronite<. Zachęcam także do odwiedzenia mojej strony >tomaszdunia.pl<. Możesz także zagadać do mnie na Twitterze >@theto3k<.

---

Kategorie: Dla początkujących,Poradniki - @ 2022-06-05 22:00

Tagi: DHCP, firewall, ODROID, passwd, porty, RaspberryPi, root, SSH, strefa czasowa, timedatectl, ufw, zapora sieciowa, zmiana hasła