2007.08_Podstawy zabezpieczenia serwerów_[Bezpieczenstwo].pdf

bezpieczeństwo

Zabezpieczenia serwerów

zabezpieczenia

serwerów

Grzegorz Walocha

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?

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 koniguracyjne 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-

sierpień 2007

Podstawy

M am nadzieję tym artykułem przybliżyć

bezpieczeństwo

Zabezpieczenia serwerów

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

powłoki basha

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:

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-

ryikowanie 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.

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.

# 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 weryikacji

kont, które powinny mieć dostęp do powłoki

systemu. W tym celu należy zweryikować 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 , postix 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:

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:

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

# openssl rand 10 | hexdump e '10/1

"%02x"' > plikzhaslem.

Po wylistowaniu pliku musimy odszukać li-

nie o budowie:

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-

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.

/etc/ssh/sshd_conig.

Rysunek 1. Logowanie na superużytkownika

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.

www.lpmagazine.org

bezpieczeństwo

Zabezpieczenia serwerów

Wykonujemy prostą czynność edytuje-

my plik ./bash_proile jako root (pamiętaj-

my, że logujemy się zawsze su ).

#nano ./bash_proile.

Przechodzimy na sam dół i dopisujemy:

# echo 'ALERT

Ktoś zalogował się na roota'

`date` `who` | mail s "Alert:

Zalogowany `who | awk '{print $6}'` "

wlasciciel_maszyny@email.pl.

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:

Rysunek 2. przedstawia mniej więcej budowę podstawowego pliku

Edytujemy ten plik ulubionym przez nas

edytorem ja preferuję nano :). Szukamy linii

MailTo = root i zmieniamy ją na MailTo = twoje-

mail@email.com . 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 koniguracyjnego, 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 koniguracji 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 weryikacji nieudanych

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

nym słowem blokuje IP, których weryikacja

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 weryikuje 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:

# /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.

# 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 ) :

Listing 3. Plik sshd_conig określający opcje kon-

iguracyjne SSH.

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

Port 12345

Protocol 2

ListenAddress 123.456.789.10

PermitRootLogin no.

Po wykonaniu znajdziemy instalacyjne pliki

w /usr/src/RPM/RPMS/ix86 :

# rpm Uhv /usr/src/RPM/RPMS/ix86/

fail2banX.X.X.rpm.

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.

Jeśli instalujemy na distro debianowym, to:

dpkg i fail2banX.X.X.deb.

May 10 16:39:08 testowy sshd[2953]:

Failed password for invalid §

user andrea from §

83.*.220.* port

55329 ssh2.

A na Gentoo:

emerge fail2ban.

Po zainstalowaniu przechodzimy do pliku

koniguracyjnego i ustawiamy poszczególne

sierpień 2007

bezpieczeństwo

Zabezpieczenia serwerów

Listing 5. Skrypt wymuszający uruchomienie

rkhunter-a przez crona z wybranymi przez nas

opcjami

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:

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:

#!/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

parametry programu. Najważniejszym jest

atrybut określający język, w jakim pracuje

powłoka. Musimy wybrać język angielski.

Nie potraiłem zmusić fail2bana do pracy

w innym języku. Nawet próby modyikacji

kodu nie pomagały. Tak więc przechodzimy

do zmiennej określającej język.

Jako root wykonujemy:

• # touch rkhunter .

• Nadajemy mu uprawnienia do wykony-

wania przez roota:

# chmod 700 rkhunter .

• Edytujemy go:

#nano rkhunter

# export LANG= C lub export LANG=EN.

Teraz wystarczy dodać zadanie do crona.

W tym celu edytujemy tablice poleceniem:

Tym sposobem zmieniliśmy język powłoki.

Możemy przejść do pliku koniguracyjnego,

który znajduje się w /etc/fail2ban.conf.

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

to zwrócić uwagę:

# crontab e ,

dopisując na końcu poniższy przykład (ja

skorzystałem z przykładu zawartego na stro-

nie projektu):

• 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ą weryikowane

przez próg.

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 skonigurowana 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.

# wget http://downloads.rootkit.nl/

rkhunter<version>.tar.gz.

Program w dalszej części pliku koniguracyj-

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ę,

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 .

O autorze

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

Admin RedHat5/Fedora/Debian. W branży

od 4 lat. Zawodowo nieugięty administrator,

właściciel kilku serwerów.

Kontakt z autorem: zatara@poczta.fm

www.lpmagazine.org

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: