Tym o to, tak jak obiecywałem przedstawiam kolejną część poradnika, który ukazuje się regularnie co tydzień.

W tej części opiszę „Zabezpieczenia systemu”. Nie są to jedyne zabezpieczenia jakie należy wprowadzić (choćby pominięty firewall/iptables), ale do takiego podstawowego użytkowania serwera są one wystarczające. Mam nadzieję, że w niczym nie popełniłem gafy, choć zawsze jakiś chochlik drukarski mógł się wkraść. W razie czego poprawcie mnie zostawiając komentarz. Konstruktywna pochwała i krytyka jest dla mnie bardzo cenna!

Mimo że poradnik ten zaadresowany jest do osób, które uruchamiają serwer tylko do swoich prywatnych potrzeb i nie będą współdzielić go ze znajomymi to jednak trzeba dokonać podstawowych zabezpieczeń w zainstalowanym systemie. Głównie chodzi tutaj o odparcie ataków z zewnątrz, aby potencjalny intruz nie narobił szkód w systemie.
Wiele osób instaluje także firewall (iptables), ale ja jakoś nie przekonałem się do niego i nie był mi nigdy potrzebny, dlatego nie instaluję go. Nie natrafiłem także na odpowiedni artykuł/tutorał o nim, który w klarowny sposób przekonałby mnie do tego, że takie oprogramowanie jest mi potrzebne i łatwo go zainstalować.

SSH

W ścisłym znaczeniu SSH to tylko następca protokołu Telnet, służącego do terminalowego łączenia się ze zdalnymi komputerami. SSH różni się od Telnetu tym, że transfer wszelkich danych jest zaszyfrowany oraz możliwe jest rozpoznawanie użytkownika na wiele różnych sposobów. W szerszym znaczeniu SSH to wspólna nazwa dla całej rodziny protokołów, nie tylko terminalowych, lecz także służących do przesyłania plików (SCP, SFTP), zdalnej kontroli zasobów, tunelowania i wielu innych zastosowań. Wspólną cechą wszystkich tych protokołów jest identyczna z SSH technika szyfrowania danych i rozpoznawania użytkownika. Obecnie protokoły z rodziny SSH praktycznie wyparły wszystkie inne „bezpieczne” protokoły, takie, jak np. rlogin czy RSH.

Głównym zagrożeniem są boty, które próbują złamać hasło root w konsoli, aby zainfekować kolejną maszynę do rozsyłania spamu i włamań na inne serwery. Aby tego uniknąć należy zmienić domyślny port SSH i wyłączyć możliwość logowania się głównego użytkownika (root) bezpośrednio na konsole.

W pliku /etc/ssh/sshd_config musimy zmienić kilka wpisów:

Port 5022
Protocol 2
LoginGraceTime 45
MaxAuthTries 5
PermitRootLogin no
PermitEmptyPasswords no

• Port – numer portu przez który będziemy się logować. Domyślna wartość to 22. Sugeruję ustawiać wysokie numery portów – powyżej 5000.
• Protocol – nr 2 protokołu jest znacznie bardziej bezpieczniejszy, niż nr 1. Teraz w Ubuntu i Debianie domyślnie jest już ustawiony nr 2, ale mimo wszystko warto dla pewności zwrócić na to uwagę.
• LoginGraceTime – czas w sekundach na zalogowanie. Domyślna wartość to 600. A chyba nie zajmie ci 10 min wpisanie loginu i hasła?
• MaxAuthTries – ilość błędnych prób logowania się na konto. Po tych próbach zostaniesz „wyrzucony” z serwera i trzeba łączyć się ponownie. Nie oznacza to, że twoje konto zostanie zablokowane!
• LoginGraceTime i MaxAuthTries utrudnia życie botom, które metodą brutalforce próbują dostać się do serwera.
• PermitRootLogin – zabraniamy logowania się na konto root bezpośrednio przez SSH
• PermitEmptyPasswords – Zabrania logowania się na konto bez podania hasła.

Dodatkowym zabezpieczeniem może być umożliwienie logowania się na serwer tylko z określonych adresów IP. W ten sposób jesteśmy niemal w 100% zabezpieczeni przed próbami ataków.
Edytujemy w tym celu plik /etc/hosts.allow

sshd : 127.0.0.1 : allow
sshd : TwojAdresIP : allow
sshd : TwojInnyAdresIP : allow
sshd : ALL : deny

Niestety może to być miecz obusieczny – kiedy będziemy na wakacjach i chcąc „pogrzebać” coś w serwerze nie będziemy mieć takiej możliwości. Chyba, że na czas urlopy przestawimy uprawnienia. No i w dzisiejszych czasach większość z nas nawet w domu ma zmienny adres IP, a więc ta opcja będzie mało przydatna… .

Uniknąć ForkBomb

Fork-bomba (ang. fork bomb) jest rodzajem ataku Denial of Service na systemy komputerowe.

Atak opiera się na założeniu, że w środowisku wieloprocesowym tylko pewna ilość procesów może być efektywnie wykonywana naraz. Atak polega na bardzo szybkim „rozmnożeniu” kopii programu (fork to nazwa funkcji systemowej służącej do tworzenia nowych procesów) w celu wypełnienia tablicy procesów systemu operacyjnego. W takiej sytuacji wywołanie nowego procesu (mającego na celu np. zabicie procesów bomby) jest wstrzymane do czasu zwolnienia choćby jednego wpisu, co jednak jest mało prawdopodobne, ponieważ każdy proces bomby jest gotów w tym momencie się rozmnożyć.

Ponieważ każdy z procesów bomby wykonuje jakiś kod (nie usypia się) planista systemowy każdemu z nich przydziela czas procesora, co praktycznie zatrzymuje działanie systemu. Jedną z technik obrony przed fork-bombami jest ustalenie górnego limitu procesów, jakie może utworzyć dany proces lub użytkownik (dotyczy to również jego dalszych potomków). I właśnie ten typ obrony zostanie przedstawiony, ponieważ jest najprostszy do zaimplementowania.

:(){ :|:& }; :

UWAGA!! To polecenie w niezabezpieczonym systemie zrobi spustoszenie. Pomoże tylko i wyłącznie restart maszyny! Wykonując je robicie to na własną odpowiedzialność !!

Aby uniknąć tego typu przykrych rzeczy, należy w systemie stworzyć nową grupę użytkowników, którzy będą mieć ograniczoną ilość uruchomionych procesów. Takich grup można stworzyć więcej – w zależności od tego jak bardzo zaufane osoby będziemy chcieli wpuszczać do systemu.

# addgroup TwojaNazwaGrupy

Dodajemy nową grupę do systemu, po czym w pliku /etc/security/limits.conf Dodajemy poniższe linijki

@TwojaNazwaGrupy soft nproc 100
@TwojaNazwaGrupy hard nproc 150

W ten sposób ograniczymy ilość maksymalnie uruchomionych procesów dla danej grupy do 150, a przy 100 użytkownik ten zostanie poinformowany o zbliżającej się granicy „wytrzymałości” jego grupy.

Prawa dostępu

Mimo wszystko – jeśli chcemy udostępnić serwer znajomym, to warto zabezpieczyć się, aby znajomy Kowalski nie patrzył w pliki Nowakowi.

Możemy tego dokonać na kilka sposobów: chmod plików, chroot’owane środowisko, jail.
Te dwa ostatnie sposoby są dość ciężkie do wytłumaczenia i są po prostu trudne, ale dzięki nim mamy większe bezpieczeństwo w systemie. Ja uważam, że jeśli serwer jest głównie jednej osoby, a dodatkowe konto FTP dla znajomego jest udostępniane naprawdę sporadycznie to wystarczy zastosowanie sposobu nr 1.

Najpierw powiem o tym, jak zabronić użytkownikowi korzystać z konsoli. Tworząc przecież nowego użytkownika, jego domyślne wartości umożliwiają mu przecież korzystanie z SSH i wykonywanie skryptów basha. Trzeba to zmienić.

/etc/adduser.conf
/etc/default/useradd

W różnych systemach w różnym miejscu domyślne wartości tworzonego użytkownika się znajdują. Sami musicie drogą empiryczną dojść do tego z którego pliku wasz system korzysta.

W każdym bądź razie znajdziecie w tych plikach kilka podstawowych opcji jakie są „doklejane” do polecania adduser. Możecie sobie poeksperymentować z rożnymi ustawieniami – pozwalam ;)
Nas interesuje pierwszy odhashowany zapis. Domyślnie wygląda on:

SHELL=/bin/sh
#lub
SHELL=/bin/bash

A musimy go zmienić na:

SHELL=/bin/false

Dzięki czemu użytkownik nie będzie mógł logować się na konsole.

Drugim zabezpieczeniem są odpowiednie prawa zapisu/odczytu do plików i folderów.
Chodzi tutaj o to, aby użytkownik pnowak, który należy do grupy pnowak nie mógł podglądać prywatnych plików użytkownika mkowalski (grupa mkowalski).

Istnieje kilka sposobów zapisu praw do danego pliku. Najpopularniejszymi są: system numeryczny, oraz literowy. Numerycznie chmod przyjmuje odpowiednią wartość potęgi dwójki dla każdego typu akcji (zapisu, odczytu, uruchomienia).

Typ zapisu	Prawo odczytu	Prawo zapisu	Prawo uruchomienia
Potęga dwójki	22	21	20
Numer dziesiętny	4	2	1
Znak	r (ang. read)	w (ang. write)	x (ang. execute)

Ja od początku byłem wychowywany w nomenklaturze numerycznej i tylko taką stosuję. Inne są dla mnie mało zrozumiałe, no ale to na pewno kwestia przyzwyczajenia… co do tej pory nie było mi potrzebne, więc zostałem przy swoich nawykach :)

Przykłady zastosowań:

Prawa dostępu	Wartość liczbowa	Opis
-rw-------	600	Tylko właściciel ma prawo do odczytu i zapisu.
-rw-r--r--	644	Właściciel ma prawo do zapisu i odczytu, a reszta tylko prawo odczytu.
-rw-rw-rw-	666	Wszyscy mają prawo do odczytu i zapisu.
-rwx------	700	Tylko właściciel ma prawo do odczytu, zapisu, uruchomienia.
-rwxr-xr-x	755	Właściciel ma wszystkie prawa do pliku, reszta tylko prawo do odczytu i uruchomienia.
-rwxrwxrwx	777	Wszyscy mają pełne prawa (nie zalecane).
-rwx--x--x	711	Wszystkie prawa ma właściciel, reszta tylko prawo uruchomienia.
drwx------	700	Właściciel katalogu ma pełne prawa do niego (katalogi mają literkę 'd’ na początku zamiast ’-’)
drwx--r--r	744	Właściciel ma pełne prawa do katalogu, reszta ma prawo do odczytu.

Najbezpieczniejsze prawa dostępu do plików to 641, a dla folderów 751. Aby zmienić domyślne ustawienia (które są odpowiednio 644 i 755), należy w konsoli wpisać:

umask 0026

Dostęp do konta root

root to tradycyjna nazwa uniksowego konta, które ma pełną kontrolę nad systemem. Z założenia konto root nie powinno być używane do pracy, do której wystarczyłoby zwykłe konto z ograniczonymi uprawnieniami. Istotną sprawą jest zabezpieczenie tego konta silnym hasłem i zabezpieczenie przed nieautoryzowanym dostępem.

Dlatego zalecam wyłączyć w ogóle możliwość logowania się na konto roota. Nawet jeśli jakiś robak dostanie się do wnętrza systemu poprzez nasze normalne konto użytkownika i będzie próbował zalogować się na konto root’a to nie uda mu się to. Mimo że robactwo jest coraz bardziej inteligentne i na pewno istnieją już robaki, które będą próbować złamać hasła do wszystkich kont systemowych, to pozostaje być przy nadziei, że intruz skup się tylko na koncie root.

Oczywiście nie możemy zrezygnować z dostępu do superadministratora systemu, czy męczyć się każdorazowym włączeniem dostępu do roota. W tym celu stworzymy nowego użytkownika, który będzie mieć wszystkie prawa w systemie.

# adduser blueroot

Pamiętajcie, aby podać długie i ciężkie hasło do złamania! Najlepiej z mieszanymi dużymi, małymi literami, cyframi oraz znakami specjalnymi.

/etc/passwd
W tym pliku zmienimy domyślne prawa użytkownika aby był rootem, a także domyślny katalog.

blueroot:x:1005:1005:,,,:/home/blueroot:/bin/false

• 1005 – jest to UID i GID użytkownika. Zmieńmy te wartości na 0 (czyt. zero)
• /home/blueroot – katalog domowy. Ja podaję tutaj zawsze swój domyślny katalog użytkownika, ponieważ tam trzymam wszystkie swoje pliki.
• /bin/false – jeśli zastosowaliśmy wcześniej praktyki zabezpieczenia systemu, to oznacza to, że użytkownik blueroot nie może korzystać z terminala. Trzeba to zmienić na /bin/bash

Po zmianach linijka ta powinna wyglądać mniej więcej tak:

blueroot:x:0:0:,,,:/home/blueman:/bin/bash

Plik zapisujemy i wychodzimy z niego.
Możemy także usunąć utworzony katalog domowy użytkownika blueroot (/home/blueroot), skoro korzystać będzie z innego.

/etc/shadow
W tym pliku zapisane są m.in. hasła wszystkich użytkowników w systemie. Aby wyłączyć logowanie na konto root’a wystarczy zmodyfikować ręcznie hasło.

root:$1$w7dOW/oV$GeA.WPpb/CqScsqYbPxxTenTekstDodalemSam:13971:0:99999:7:::

Można też wpisać jedną literkę/znak na początku/końcu, ale bardziej bezpieczne jest zastosowanie jakiegoś ciągu znaków po którym będziemy mogli się domyśleć, że w razie konieczności włączenia konta root należy ten string usunąć.

I tyle. Teraz nie będzie można już logować się na konto roota, ponieważ jego hasło zostało zmienione na niestandardowy system zapisu hasła.

Aby zalogować się na swojego nowego root’a (blueroot) należy w konsoli wpisać:

$ su blueroot

Uzupełnić o monitorowane hasło… i cieszyć się nowym kontem root.

PS.

# whoami

Dzięki tej komendzie sprawdzimy kim tak naprawdę jesteśmy w systemie. Po zalogowaniu na blueroot powinien wyskoczyć napis root.

Kolejna część poradnika będzie zawierać opis „Instalacja i konfiguracja LAMP„.

Od tej części udostępniam także wersję w formacie PDF do ściągnięcia. Jest ona znacznie bardziej wygodniejsza, niż czytanie takiego kursu na blogu, a także w dokumencie PDF mogę umieścić czytelniejsze formatowanie tekstów.

Podstawowa konfiguracja serwera dedykowanego/VPS