2007.03_Stawiamy bezpieczny serwer plików_[Bezpieczenstwo].pdf

Bezpieczeństwo

Stawiamy bezpieczny serwer plików

Stawiamy bezpieczny

Michał Miszewski

Tradycyjnie do przesyłania plików między serwerami stosuje się protokół FTP. Niestety ma on

istotną wadę - zarówno hasło, jak i pliki przesyłane są w postaci jawnej, bez jakiegokolwiek

szyfrowania. Z tego powodu lepiej nie stosować protokołu FTP do łączenia się przez nie budzące

zaufania sieci, takie jak Internet.

tokół o szyfrowanie SSL. My jednak postawimy bez-

pieczny serwer plików korzystając z innego rozwią-

zania - użyjemy SSH i podsystemu przesyłania pli-

ków SFTP.

W domyślnej koniguracji OpenSSH zawiera obsłu-

gę SFTP. Odpowiada za nią program /usr/lib/sftp-server .

Otwarcie sesji SFTP polega na zestawieniu połączenia

SSH ze zdalnym hostem. Następnie uruchamiany jest prog-

ram sftp-server po zdalnej stronie. Interpretuje on polece-

nia wydawane przez klienta, m in. żądania operacji na

plikach.

Załóżmy, że nasz serwer będzie platformą do hostingu

stron WWW. Użytkownicy muszą mieć możliwość bezpiecz-

nego przesyłania plików do swojego katalogu domowego.

Dostęp do konta powinien jednak podlegać następującym

ograniczeniom:

• brak dostępu do pozostałej części systemu plików

(katalogi /proc, /tmp, /etc itp .)

O ile postawienie SFTP jest proste, ograniczenie go w po-

wyższy sposób wymaga więcej pracy. Program sftp-server

dostarczany wraz z pakietem OpenSSH nie zapewnia taki-

ej możliwości. Na szczęście istnieje patch chrootssh rozwi-

jany przez Jamesa Dennisa. Wykorzystuje on mechanizm

chroot systemu operacyjnego do zamknięcia użytkownika

w „klatce“. Więcej na temat jego działania znajdziesz w ram-

ce „jak działa chroot“. Źródła OpenSSH z nałożonym pa-

tchem znajdują się na stronie projektu chrootssh.

SSH w klatce

Zacznijmy od skompilowania zmodyikowanej wersji

OpenSSH. Procedura jest standardowa - rozpakowujemy

archiwum i konigurujemy źródła skryptem ./conigure .

Należy zwrócić uwagę na opcje, które mogą różnić się

w zależności od rodzaju wykorzystywanej dystrybucji

systemu. W moim przypadku (system Debian GNU/Li-

nux ) należało wywołać skrypt z parametrami --with-pam

--sysconfdir=/etc/ssh --without-zlib-version-check (włączenie

• użytkownicy nie mają dostępu do shella

• nie jest dostępny forwarding portów oferowany przez

SSH

• dostęp tylko do własnego katalogu domowego

marzec 2007

serwer plików

I stnieją serwery i klienty FTP rozszerzające ten pro-

Bezpieczeństwo

Stawiamy bezpieczny serwer plików

Listing 1. Kopiowanie bibliotek

$ ldd sftp-server

libresolv.so.2 => /lib/tls/libresolv.so.2 (0x40026000)

libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0x40038000)

libutil.so.1 => /lib/tls/libutil.so.1 (0x40138000)

libz.so.1 => /usr/lib/libz.so.1 (0x4013b000)

libnsl.so.1 => /lib/tls/libnsl.so.1 (0x4014d000)

libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0x40161000)

libc.so.6 => /lib/tls/libc.so.6 (0x4018e000)

libdl.so.2 => /lib/tls/libdl.so.2 (0x402c3000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

$ cp /lib/tls/libresolv.so.2 lib/tls/

$ cp /lib/tls/libutil.so.1 lib/tls/

$ cp /usr/lib/libz.so.1 usr/lib/

$ cp /lib/tls/libnsl.so.1 lib/tls/

$ cp /lib/tls/libcrypt.so.1 lib/tls/

$ cp /lib/tls/libc.so.6 lib/tls/

$ cp /lib/tls/libdl.so.2 lib/tls/

$ cp /lib/ld-linux.so.2 lib/

$ cp /usr/lib/i686/cmov/libcrypto.so.0.9.7 usr/lib/i686/cmov/

Rysunek 1. Drzewo katalogów w środowisku chroot

Potrzebny jest jeszcze plik urządzenia

/dev/null - możemy zwyczajnie skopiować go

z systemu: cp -p /dev/null /home/chroot/dev/

Konta użytkowników

Pozostaje utworzyć konto użytkownika (tutaj

przykładowo o nazwie jan). Jako katalog do-

mowy użytkownika powinna zostać ustawio-

na ścieżka /home/chroot/./home/jan. Jako shell

ustawiamy /usr/lib/sftp-server – pozwoli to jedy-

nie na połączenia SFTP, odbierając dostęp do

interaktywnej powłoki. Ostatecznie wpis w /etc/

passwd powinien wyglądać następująco:

mechanizmu PAM, wskazanie katalogu z pli-

kami koniguracyjnymi oraz pominięcie spra-

wdzania wersji biblioteki zlib). Następnie

wykonujemy polecenia make i make install.

Podczas logowania przez SSH kod doda-

ny przez chrootssh sprawdza w /etc/passwd , czy

katalog domowy użytkownika zawiera ciąg

znaków /./. Jeśli tak jest, następuje wywołanie

funkcji chroot() dla katalogu przed kropką. Dru-

ga część ścieżki (po kropce) to katalog domo-

wy użytkownika względem nowego katalogu

głównego.

Utwórzmy zamknięte środowisko, w któ-

rym będzie działał nasz serwer SFTP. Zakła-

damy katalog dla chroot: mkdir /home/chroot .

Muszą się tam znaleźć wszystkie pliki binarne

i biblioteki potrzebne do działania SFTP. Two-

rzymy katalogi bin, etc, home, lib, lib/tls, usr, usr/

lib i usr/lib/i686/cmov . Do katalogu bin kopiu-

jemy podstawowe pliki binarne potrzebne do

działania SFTP: ls, mkdir, mv, rm, rmdir i chmod .

Potrzebujemy też samego serwera sftp - kopiu-

jemy /usr/lib/sftp-server do /home/chroot/usr/lib/ .

Należy jeszcze dodać wymagane bibli-

oteki dynamiczne. Korzystamy w tym celu

z narzędzia ldd. Sprawdzamy, jakich biblio-

tek wymaga każdy z programów i kopiujemy

je do odpowiednich katalogów. Przykład, jak

należy to zrobić, znajduje się na Listingu 1.

Czynności powtarzamy dla wszystkich pli-

ków wykonywalnych w chroot.

Program sftp-server wymaga jeszcze jed-

nej biblioteki: libnss_iles. Biblioteka ta jest łado-

wana później i ldd nie pokazuje jej na liście.

Bez niej sftp-server zakończy działanie nie zwra-

cając żadnego komunikatu o błędzie. Tego ro-

dzaju brakujące pliki można odnaleźć np. tym-

czasowo umieszczając w chroocie shell (np.

/bin/bash ) i program strace. Następnie wpisuje-

my polecenie chroot /home/chroot /bin/bash

(uzyskamy ograniczoną interaktywną powło-

kę), a następnie używamy narzędzia strace do

przeanalizowania, jakie pliki otwiera dany pro-

gram.

Sftp-server wymaga dostępu do sysloga po-

przez socket /dev/log . Ze względu na ograni-

czone środowisko standardowa lokalizacja

gniazdka nie jest dostępna. Musimy więc do-

dać socket w naszym chroocie - można to zrobić

uruchamiając syslogd z parametrem -a /home/

chroot/dev/log . Plik specjalny zostanie utworzo-

ny automatycznie przez program syslogd .

jan:x:1003:100::/home/chroot/./home/

jan:/usr/lib/sftp-server

Plik /etc/passwd jest potrzebny do działania

także programowi sftp-server . Jako, że jest on

wywoływany już w zamkniętym środowisku,

potrzebuje drugiej kopii pliku passwd z od-

powiednim wpisem. Odpowiednie wpisy dla

Listing 2. Przykładowa sesja sftp

jkowalski@galaxy:tmp$ sftp jan@box

Connecting to box...

jan@box's password:

sftp> pwd

Remote working directory: /home/jan

sftp> put info.txt

Uploading info.txt to /home/jan/info.txt

info.txt 100% 153 0.2KB/s 00:00

sftp> ls -l

drwxr-xr-x 0 1003 100 4096 Dec 26 23:28 .

drwxr-xr-x 0 0 0 4096 Dec 26 19:38 ..

-rw-r--r-- 0 1003 100 153 Dec 26 23:28 info.txt

sftp> cd /

sftp> ls

. .. bin dev etc home lib usr

sftp> ls etc

etc/. etc/.. etc/passwd

sftp> exit

www.lpmagazine.org

Bezpieczeństwo

Stawiamy bezpieczny serwer plików

Przykład koniguracji Apache

dla kont w chroocie

Użycie poniższej dyrektywy w pliku koni-

guracyjnym httpd.conf umożliwi dostęp do

stron WWW znajdujących się na ogranic-

zonych kontach.

UserDir /home/chroot/home

</IfModule>

Taka koniguracja spowoduje, że przy pró-

bie wczytania adresu URL http://serwer.pl/

~jan/strona.html Apache wyświetli plik /ho-

me/chroot/home/jan/strona.html. Możemy

także dodać wirtualny host odpowiadający

katalogowi użytkownika:

Rysunek 2. Sesja SFTP w programie WinSCP

ServerAdmin jan@serwer.pl

DocumentRoot /home/chroot/home/jan

ServerName jan.serwer.pl

ErrorLog /var/log/apache/jan-

error.log

CustomLog /var/log/apache/jan-

access.log common

</VirtualHost>

wszystkich użytkowników trzeba więc dodać

do / home/chroot/etc/passwd np. poleceniem:

getent passwd jan >> /home/chroot/etc/passwd . Jest

to jedyny plik w /etc w chroot wymagany do

działania naszego serwera plików. Oczywiście

tworzymy także katalog /home/chroot/home/jan

i ustawiamy właściciela „jan“.

Należy upewnić się, że w pliku konigura-

cyjnym demona SSH (w tym przypadku /etc/

ssh/sshd_conig ) znajduje się linijka:

Port forwarding

potencjalna luka

Każde konto należy zabezpieczyć przed uży-

ciem mechanizmów, takich jak port forwar-

ding. Można to zrobić umieszczając następu-

jące linie w pliku koniguracyjnym sshd:

• Match User jan

• AllowTcpForwarding no

Spowoduje to, że ta sama strona będzie

dostępna pod adresem http://jan.serwer.pl/

strona.html (oczywiście domena jan.ser-

wer.pl musi wskazywać na adres IP nasze-

go serwera).

Subsystem sftp /usr/lib/sftp-server

Należy pamiętać o dopisywaniu po przecinku

wszystkich dodawanych użytkowników. Jeśli

tego nie zrobimy, właściciel konta będzie mógł

otworzyć szyfrowany tunel TCP i połączyć się

od wewnątrz na dowolny port naszego serwe-

ra lub dowolnego innego hosta dostępnego

z naszej maszyny.

Po uruchomieniu demona sshd powinna ist-

nieć możliwość zalogowania na ograniczone

konto. Przykładowa sesja SFTP znajduje się

na listingu 2.

Ograniczenie port forwardingu można

rozwiązać także w inny sposób – wyłączając

je całkowicie (opcja AllowTcpForwarding no )

i ewentualnie włączając dla wybranych użyt-

kowników z pełnym dostępem do shella. Kon-

ta dla pozostałych użytkowników zakładamy

analogicznie.

W tym momencie bezpieczny serwer pli-

ków można uznać za skonigurowany. Sesje

SFTP powinny działać w ograniczonym śro-

dowisku, a dostęp do shella i forwardowania

portów został zablokowany. Ewentualne pro-

blemy możemy zdiagnozować na podstawie

komunikatów sysloga. Należy jeszcze ws-

zystko dokładnie sprawdzić i można wpuścić

użytkowników.

Jak działa chroot?

Chroot to mechanizm służący do ogranic-

zania procesom dostępu do części syste-

mu plików. Proces, którego katalog główny

(root directory) został zmieniony, nie może

odwoływać się do plików znajdujących się

poza tym katalogiem. Zamknięte w chroo-

cie procesy mogą jednak tworzyć nowe de-

skryptory plików, połączenia sieciowe itp.

Mogą też czytać i modyikować wszystkie

pliki, które otworzyły jeszcze przed wywo-

łaniem funkcji chroot() . Uruchamianie prog-

ramu w środowisku chroot jest dość kłopot-

liwe, ponieważ wybrany katalog musi za-

wierać wszystkie wymagane do jego dzi-

ałania pliki. Trzeba więc utworzyć strukturę

katalogów podobną do '/' i skopiować tam

potrzebne binarki, pliki urządzeń i biblioteki.

Aby sprawdzić, jakich bibliotek wymaga da-

ny program, korzystamy z narzędzia ldd(1).

Jeśli zamknięty w chroot program nie działa

poprawnie, możemy skorzystać z narzędzia

strace w celu sprawdzenia, czy nie próbuje

on otwierać jakichś brakujących plików.

Mechanizm chroot ma swoje słabe strony

- jedną z nich jest możliwość "wydostania

się" z zamkniętego środowiska procesów

działających z prawami użytkownika root.

Z tego powodu należy unikać umieszcza-

nia w chroocie plików wykonywalnych z usta-

wionym bitem SUID i właścicielem root.

Chroot nie ogranicza listy wywołań syste-

mowych, jakie mogą uruchamiać działające

procesy. Nie chroni także przed nadmier-

nym wykorzystaniem CPU, pamięci, miej-

sca na dysku i innych zasobów.

W Sieci

• Strona projektu OpenSSH:

http://openssh.org/

• Strona projektu chrootssh:

http://chrootssh.sourceforge.net/ -

marzec 2007

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: