bezpieczeństwo

Zabezpieczenia serwerów

68

sierpień 2007

bezpieczeństwo

Zabezpieczenia serwerów

69

www.lpmagazine.org

lin

ux

@

so

ftw

ar

e.

co

m

.p

l

M

am nadzieję tym artykułem przybliżyć
nieco aspekty często pomijane przez po-
czątkujących użytkowników Linuksa, mło-
dych administratorów i wielu innych,

którzy chcą postawić daną usługę na swojej maszynie, ale
obawiają się ataków na nią. Zaproponuję tutaj kilkanaście
rozwiązań, które w łatwy sposób można będzie wdrożyć
na własnym podwórku.

Linux, jak żaden inny system operacyjny, daje nam

ogromne możliwości konfiguracyjne pozwalające zwięk-
szyć bezpieczeństwo. Artykuł ten skupi się na podstawo-
wych jego aspektach, ponieważ kwestia bezpieczeństwa
jest tak rozległa, że można by było napisać o niej kilka-
naście książek, które i tak nie wyczerpałyby tematu. Pa-
miętajmy jednak o bumie technologicznym oraz softwa-
rowym, które ciągle ewoluują, a z nimi również sposo-
by ataków i chęci łamania coraz wymyślniejszych zabez-
pieczeń.

Zakładam, że każdy z czytających ma już zainstalowa-

nego Linuksa z kernelem co najmniej 2.6.x. Na starszych
wersjach jądra również sprawdzają się porady i sztuczki
opisywane tutaj, ale nowsza wersja ma sama w sobie dużo

poprawionych luk i niedociągnięć, dlatego osobiście dora-
dzam korzystanie z takowej wersji.

Krok pierwszy prawdopodobnie najważniejszy. Silne

hasło. Mocne hasło musi należeć nie tylko do administra-
tora, ale również każdy użytkownik systemu powinien
zadbać o to, by jego hasło było odpowiednio skompliko-
wane.

Silne hasło zapewni nam początkową ochronę przed

nieautoryzowanym dostępem do serwera przez niepowo-
łane osoby. Poza tym nie zostanie ono tak szybko rozpra-
cowane przez działające w sieci systemy łamiące hasła,
które to korzystają z potężnych słowników bardzo często
udostępnianych za darmo w sieci.

Mocne hasło to takie, które jest długie. Posiada co naj-

mniej 8 znaków liter małych i dużych, cyfr oraz znaków
specjalnych typu: & * ( @ itp. Najlepiej jednak jeśli będzie
miało co najmniej piętnaście znaków. Takie hasło 15–zna-
kowe ułożone z losowo wybranych elementów z całej kla-
wiatury jest w porządku. 33 tysiące razy trudniejsze do
złamania niż hasło 8znakowe. Warto również pamiętać,
żeby nie wybierać haseł oczywistych, związanych bez-
pośrednio z posiadaczem, nie stosować imion, nazw wła-

Podstawy

zabezpieczenia

serwerów

Każdy z nas chciał kiedyś o własnych siłach postawić sobie swój własny serwer linuksowy. Udostępniać
pliki, móc sprawdzać pocztę, zdalnie zarządzać usługami. Ale czy każdy z nas wie jak bardzo serwer na
defaultowych ustawieniach, które dostarcza nam producent danej dystrybucji, jest narażony na ataki?

Grzegorz Walocha

bezpieczeństwo

Zabezpieczenia serwerów

68

sierpień 2007

bezpieczeństwo

Zabezpieczenia serwerów

69

www.lpmagazine.org

snych itp. Takie hasła znajdują się często
w słownikach i narzędzia do łamania pora-
dzą sobie z nimi bezproblemowo.

Dla przykładu: złamanie 3znakowego ha-

sła zawierającego jedynie litery alfabetu ułożo-
ne bez jakiegokolwiek sensu trwa ok. 1 sekun-
dy. Czas ten diametralnie się zwiększa, jeśli za-
stosujemy dłuższe hasło.

Jeśli nie mamy pomysłu, jakie hasło jest

bezpieczne, możemy skorzystać z gotowego
oprogramowania, które pomoże nam w wyge-
nerowaniu takiego hasła.

Do wygenerowania bezpiecznego hasła

użyjemy programu

openssl

(zawartego w każ-

dej dystrybucji). Komenda:

# openssl rand 10 | hexdump e '10/1
"%02x"' > plikzhaslem.

W ten sposób mamy w pliku

plikzhaslem

za-

szyte hasło. Fakt, iż to trochę niepraktyczne, ale
mamy pewność, że jest na pewno skompliko-
wane. Parametr

10/1

określa nam długość

w znakach hasła.

Zaczynajmy. Po uruchomieniu systemu

logujemy się na SUPERUŻYTKOWNIKA,
czyli

roota

. Pamiętajmy, by użyć po polece-

niu su znaku specjalnego w celu przejęcia ca-
łej powłoki, w której pracujemy. Jeśli zaś lo-
gujemy się bezpośrednio na maszynie, wy-
starczy, że użyjemy loginu

root

.

Zmieniamy stare hasło poleceniem

passwd

(po spacji nazwa usera, któremu chcemy zmie-

nić hasło w tym przypadku zmieniamy ha-
sło administratorowi, możemy więc wykonać
jedynie polecenie passwd i wcisnąć ENTER,
by zmienić hasło obecnie zalogowanemu use-
rowi). Jeśli już jesteśmy przy zmienianiu haseł
i ustawianiu odpowiedniej trudności hasła,
nie wolno nam pominąć problemu, z którym
możemy się spotkać, przejmując po kimś ma-
szynę.

W celu wyszukania takiej luki warto użyć

programu, który jest w każdej dystrybucji, czy-
li AWK. Komendą wyszukamy konta z pusty-
mi hasłami:

# awk F: '$2 == "" {print $1, "puste
hasło!"}' /etc/shadow.

Jeśli już mamy sprawdzony system pod
względem silnych haseł i braku kont z pusty-
mi hasłami, możemy zabrać się do weryfikacji
kont, które powinny mieć dostęp do powłoki
systemu. W tym celu należy zweryfikować plik
z kontami

/etc/passwd

.

Dostęp regulujemy w prosty sposób, do-

dając lub usuwając parametr określający po-
włokę, w której będziemy pracować.

Aby zabrać użytkownikowi prawa do lo-

gowania się do powłoki, edytujemy plik

pas-

swd

, zastępując

/bin/bash

, na przykład

/bin/

nologin

lub

/bin/false

.

Tak edytowany plik zapisujemy. Od tej

pory tylko te konta, którym określiliśmy po-
włokę mogą zalogować się do systemu.

Kolejnym krokiem, jaki powinniśmy

przedsięwziąć jest zabezpieczenie najczę-
ściej atakowanej usługi, jaką jest ssh. Wiele
razy w logach można zauważyć wzmiankę
typu.

Świadczy to o tym, że ktoś (osoba lub pro-

gram) próbuje się dostać na konto

recruit

. Je-

śli nie wie czy istnieje konto o takiej nazwie, bę-
dzie próbować logować się na inne z uprzed-
nio przygotowanej listy. Na takiej liście pierw-
szą pozycją jest konto o nazwie

root

. Następ-

nymi są zwykle

squid

,

apache

,

postfix

i wie-

le innych, które mogą być związane z branżą,
z zainteresowaniami, preferencjami itp. W za-
leżności od tego, jakie pojęcie w swoim fachu
ma włamywacz, taką listę loginów i słowni-
ków zastosuje.

Podstawowe zabezpieczenie usługi ssh

polega na edytowaniu pliku:

/etc/ssh/sshd_config.

Edytujemy linię: Pierwsza linia odpowiada za
nasłuchiwanie usługi na danym porcie. Do-
myślnie opcja jest wyłączona, odhaszowujemy
linię i dodajemy port, na który chcemy prze-
nieść nasłuch. W podanym przykładzie jest to
port

12345.

Druga linia odpowiada za rodzaj

protokołu używanego podczas pracy. Domyśl-
nie opcje zahaszowane odhaszowywujemy
i zostawiamy jedynie wersję 2. protokołu ssh.

Linia ListenAdress odpowiada adresowi,

który będzie miał dostęp do serwisu ssh. Mo-
żemy dodać kilka adresów lub cały zakres
z danej puli adresowej. Domyślnie

deamon

ssh

nasłuchuje na wszystkich adresach, czy-

li na

0.0.0.0.

PermitRotLogin no

opcja ta zabrania lo-

gowania się roota bezpośrednio przez ssh.
Czyli początkowo loguje się zwykły użyt-
kownik, a dopiero potem root.

Te podstawowe funkcje dla deamona ssh

pozwolą na wzmocnienie obrony przed nie-
chcianymi intruzami próbującymi wykorzy-
stać słabości naszego systemu. Istnieją odpo-
wiednie aplikacje, które pozwalają nam na we-
ryfikowanie kilkukrotnych prób nieudanego
logowania, ale to opiszę w dalszej części arty-
kułu. Następną rzeczą, o której powinniśmy
pamiętać jest wyłączenie tak wspaniałego na-
rzędzia, jakim jest telnet. Fakt jeśli korzysta-
my z niego często, możemy go zostawić, ale
lepiej dmuchać na zimne, jeśli maszyna stoi z
publicznym adresem VLAN.

Odszukujemy plik z telnetem i poddaje-

my go edycji w vi, nano czy pico.

# pico w /etc/xinetd.d/telnet.

Po wylistowaniu pliku musimy odszukać li-
nie o budowie:

disable = no.

Analogicznie chcąc wyłączyć, wpisujemy za-
miast NO YES.

Na samym końcu trzeba pamiętać, że-

by zrestartować usługę. Wykonujemy to po-
leceniem:

# /etc/init.d/xinetd restart

lub

service xinetd restart.

To tyle na temat telnetu.

Fajną rzeczą, która jest prosta w użyciu,

a przydaje się w codziennej administracji jest
po prostu wysłanie ostrzeżenia, że ktoś zalo-
gował się na roota.

Rysunek 1.

Logowanie na superużytkownika

Listing 1.

Określa konta, które mają dostęp do

powłoki basha

grey:x:500:500::/home/grey:/bin/
bash
rayos:x:501:501::/home/rayos:
/bin/bash
jols:x:502:502::/home/jols:/bin/
bash
kon.szt:x:503:503::/home/konsz:
/bin/bash

Listing 2.

Widok na Log Systemowy, określający

błędne logowanie usera recruit.

May 30 23:26:59 testowy
sshd[27984]: §
Failed password

for

invalid user

recruit from §
TU_ADRES_IP port 53101 ssh2.

70

bezpieczeństwo

Zabezpieczenia serwerów

sierpień 2007

71

bezpieczeństwo

Zabezpieczenia serwerów

www.lpmagazine.org

Wykonujemy prostą czynność edytuje-

my plik

./bash_profile

jako root (pamiętaj-

my, że logujemy się zawsze su ).

#nano ./bash_profile.

Przechodzimy na sam dół i dopisujemy:

# echo 'ALERT
Ktoś zalogował się na roota'
`date` `who` | mail s "Alert:
Zalogowany `who | awk '{print $6}'` "
[e-mail].

Oczywiście zapisujemy i wychodzimy.

Po takim zabiegu każde logowanie się ro-

ota spowoduje wysłanie maila z informacją
do właściciela maszyny.

Jeśli udostępniamy serwer komuś innemu,

chcielibyśmy zawrzeć jakieś informacje, które
byłyby przekazywane po udanej próbie zalo-
gowania na ekran. Można zawrzeć ostrzeżenia,
można zawrzeć adresy kontaktowe itp.

Służy do tego plik:

# /etc/motd.

Po prostu go edytujemy i wpisujemy wszystko
to, co chcemy przekazać na konsolę osobie lo-
gującej się. Pozostając przy temacie logowania i
logów systemowych, możemy się bliżej zatrzy-
mać przy programie, który jest bardzo pomoc-
ny w codziennej pracy z systemem. Mowa tu-
taj o LogWatch.

Plik

logwatch.conf

, który odpowiada za

sposób, dokładność logowania tego, co w sys-
temie się dzieje, znajduje się w katalogu

/etc/

log.d/conf/logwatch.conf

lub po prostu

/etc/logwatch/conf/logwatch.conf.

Edytujemy ten plik ulubionym przez nas

edytorem ja preferuję nano :). Szukamy linii
MailTo = root i zmieniamy ją na MailTo = twoje-
[e-mail]. Oczywiście nie musisz tego ro-
bić, jeśli używasz aliasów w swoim MTA (wte-
dy wszystko, co przychodzi dla roota może
być przekazywane na wybrany przez nas ad-
res). Ale to nie artykuł o aliasach, więc nie bę-
dziemy się tutaj rozwodzić nad tym (powsta-
nie na pewno artykuł o zabezpieczaniu MTA,
ale to podstawy, więc nie będę się rozpisywał
na temat MTA).

Następnie możemy zmieniać dokładność

naszego LogWatcha. Odnajdujemy linię

Deta-

il = Low

i zmieniamy na

Detail = 5

lub

De-

tail = 10

, gdzie liczba określa nam stopień

logowania. Im większa, tym więcej informa-
cji zbieramy o systemie, ale tym samym nasz
plik logu może urosnąć do niebotycznych roz-
miarów. Jeśli plik logwatch.conf jest pusty, po
prostu dopisujemy na końcu powyższe funkcje
wraz z argumentami, każdy w oddzielnej linii.
Nie można zapomnieć o pustej linii na końcu
każdego pliku konfiguracyjnego, także i tego.
Dajemy ENTER i zapisujemy.

Myślę, że te podstawy w dużym stopniu

utrudnią, a nawet uniemożliwią łatwe przeję-
cie naszej maszyny. Pomogą również zwięk-
szyć wiedzę o tym, co się na niej dzieje.

W dalszej części przedstawię bardzo przy-

jemne i proste w konfiguracji darmowe opro-
gramowania wspomagające kontrolę i zbie-
ranie informacji o systemie oraz skuteczną jego
obronę. Pierwszym z proponowanych przeze
mnie programów jest fail2ban. Strona projek-
tu znajduje się pod adresem: http://www.fail
2ban.org/wiki/index.php/Main_Page.

Program służy do weryfikacji nieudanych

prób ataku i odpowiedniej reakcji na nie. Jed-

nym słowem blokuje IP, których weryfikacja
nie powiodła się określoną przez nas ilość razy.

Któż z nas nie zauważył w logach. Kilka-

set lub kilkanaście tysięcy nieudanych prób
logowania się przez ssh, ftp i apacha.

Fail2ban jednoznacznie weryfikuje takie

próby i odpowiednio blokuje (na określony
przez nas czas) dany adres.

Program pobieramy ze strony : http://www.

fail2ban.org/wiki/index.php/Downloads.

Wybieramy dystrybucję, pod którą obec-

nie pracujemy i zabieramy się za instalację.

Jeśli wybraliśmy rpma, to po prostu in-

stalujemy go jako roota. Poleceniem:

# rpm ivh fail2banX.X.X.rpm,

gdzie XXX określają wersję, którą wybraliśmy.

Wybierając instalację ze źródeł, postępu-

jemy następująco (w przypadku

src.rpm

)

:

# rpm rebuild fail2banX.X.X.src.rpm.

Po wykonaniu znajdziemy instalacyjne pliki
w

/usr/src/RPM/RPMS/ix86 :

# rpm Uhv /usr/src/RPM/RPMS/ix86/
fail2banX.X.X.rpm.

Jeśli instalujemy na distro debianowym, to:

dpkg i fail2banX.X.X.deb.

A na Gentoo:

emerge fail2ban.

Po zainstalowaniu przechodzimy do pliku
konfiguracyjnego i ustawiamy poszczególne

Listing 3.

Plik sshd_config określający opcje kon-

figuracyjne SSH.

Port 12345
Protocol 2
ListenAddress 123.456.789.10
PermitRootLogin no.

Listing 4.

Widok na nieudaną próbę zalogowania

się do systemu przez usera andrea. Określający
kto, kiedy, z jakiego adresu i na jaki port.

May 10 16:39:08 testowy sshd[2953]:
§
Failed password

for

invalid §

user andrea from §
83.*.220.* port
55329 ssh2.

Rysunek 2.

przedstawia mniej więcej budowę podstawowego pliku

70

bezpieczeństwo

Zabezpieczenia serwerów

sierpień 2007

71

bezpieczeństwo

Zabezpieczenia serwerów

www.lpmagazine.org

parametry programu. Najważniejszym jest
atrybut określający język, w jakim pracuje
powłoka. Musimy wybrać język angielski.
Nie potrafiłem zmusić fail2bana do pracy
w innym języku. Nawet próby modyfikacji
kodu nie pomagały. Tak więc przechodzimy
do zmiennej określającej język.

Jako root wykonujemy:

# export LANG= C lub export LANG=EN.

Tym sposobem zmieniliśmy język powłoki.
Możemy przejść do pliku konfiguracyjnego,
który znajduje się w

/etc/fail2ban.conf.

Jest kilkanaście zmiennych, na które war-

to zwrócić uwagę:

• maxfailures = 5

– określa liczbę błęd-

nych prób w haśle lub loginie,

• Bantime = 600

określa czas, na jaki zo-

staje zablokowany dane IP,i

• gnoreip = 192.168.1.0/24

określa sieć

lub adresy, które nie będą weryfikowane
przez próg.

Program w dalszej części pliku konfiguracyj-
nego jest podzielony na sekcje, które określa-
ją usługi, jakie będziemy monitorować. Są to:
MAIL pozwala na wysyłanie emaila w posta-
ci monitu, o zablokowanym IP; Apache dostęp
do serwera www; Vsftpd dostęp do serwera
FTP; Ssh monitorowanie błędnych logowań
przez ssh. Opcje w tych sekcjach są tak trywial-
ne, że każdy w szybki sposób zorientuje się,

o co chodzi. Najważniejszą rzeczą jest zwróce-
nie uwagi na umiejscowienie plików logów da-
nych usług i dostosowanie ich pod własne śro-
dowisko. Żeby zadziałał nam program, teore-
tycznie musimy zmienić dwie rzeczy. Pierw-
szą z nich jest określenie, które usługi będzie-
my monitorować. Czyli jeśli chcemy monitoro-
wać ssh, szukamy sekcji [SSH] i argument

ena-

bled = false

zmieniamy na

true.

Postępuje-

my podobnie z innymi usługami, które ma ob-
jąć

fail2ban.

Kolejnym przydatnym progra-

mem jest rkhunter oraz bardzo podobny do
niego chkrootkit.

Strona projektu: http://www.rootkit.nl/ oraz

http://www.chkrootkit.org/.

Chkrootkit oraz rkhunter to programy

skanujące najważniejsze pliki systemowe pod
kątem obecności rootkitów, czyli programów
pisanych, aby ukryć obecność włamywacza
i pozwolić mu na dostęp do komputera. Pro-
gramy te skanują również system w poszuki-
waniu śladów loggerów klawiszy i innych nie-
pożądanych programów, które mogą zostać
wykorzystane w celu zostawienia sobie tzw. tyl-
nej furtki. Obydwa narzędzia są bardzo uży-
teczne. Rkhunter wydaje mi się bardziej roz-
budowany, dając tym samym większy ogląd
sytuacji niż chkrootkit, dlatego też opiszę tyl-
ko ten pierwszy. Informacje o instalacji, moż-
liwościach chkrootkita znajdziecie na stronie:
http://www.chkrootkit.org/faq/.

Pozyskanie oraz instalacja rkhuntera jest

bardzo prosta:

Ściągamy program ze strony poleceniem:

# wget http://downloads.rootkit.nl/
rkhunter<version>.tar.gz.

Nie jest ważne, do jakiego katalogu go ściąga-
my. Następnie należy rozpakować paczkę:

# tar zxf rkhunter<versja>.tar.gz

.

W tym momencie możemy przejść do in-

stalowania.

Wykonujemy kolejno:

• # cd rkhunter
• # ./installer.sh

.

Od tej chwili mamy już drugą linię obrony.
Możemy uruchamiać rkhuntera w każdej
chwili z linii poleceń, ale prościej jest zaim-
plementować prosty skrypt w bashu, który
uruchamiać będziemy z crona.

Ja skorzystałem z gotowego zastosowa-

nia, które zaprezentowane jest na stronie pro-
jektu, odsyłam do niego, gdyż jest ono nie
tylko dobrze przemyślane, ale również bar-
dzo proste do wykonania dla początkujące-
go użytkownika.

Tworzymy plik w katalogu roota pole-

ceniem:

• # touch rkhunter

.

•

Nadajemy mu uprawnienia do wykony-
wania przez roota:

# chmod 700 rkhunter

.

•

Edytujemy go:

#nano rkhunter

Teraz wystarczy dodać zadanie do crona.
W tym celu edytujemy tablice poleceniem:

# crontab e

,

dopisując na końcu poniższy przykład (ja
skorzystałem z przykładu zawartego na stro-
nie projektu):

30 5 * * * root /root/rkhunter c
–cronjob.

Zapisujemy i wychodzimy z naszego ulubio-
nego edytora tekstów. Jeśli komuś otworzy-
ło się w

vi

i ma problem z zapisaniem, niech

spróbuje wcisnąć jeden raz Esc, a następnie
CTRL+ZZ.

Druga linia obrony skonfigurowana oraz

gotowa do użycia.

W taki oto prosty sposób dotarliśmy do

końca tego artykułu. Wszystkie przedstawione
przeze mnie metody sam testowałem i wdra-
żałem we własnym środowisku serwerowym.
Oczywiście są to podstawowe aspekty bezpie-
czeństwa, lecz często zdarza się, że pomijamy
je albo po prostu o nich zapominamy. Mam na-
dzieję, że nie tylko początkujący użytkownicy
zajrzą do tego artykułu, ale również doświad-
czeni fani Linuksa przejrzą moje propozycje
i znajdą coś dla siebie.

Rysunek 3.

Przykład z informacjami wyświetlającymi się na ekranie przy udanej próbie logowania

Listing 5.

Skrypt wymuszający uruchomienie

rkhunter-a przez crona z wybranymi przez nas
opcjami

#!/bin/sh
/usr/local/bin/rkhunter
versioncheck
/usr/local/bin/rkhunter update
/usr/local/bin/rkhunter cronjob
reportwarningsonly
) | /bin/mail s 'rkhunter Daily
Run' root

Admin RedHat5/Fedora/Debian. W branży
od 4 lat. Zawodowo nieugięty administrator,
właściciel kilku serwerów.
Kontakt z autorem: [e-mail]

O autorze