Chroot w praktyce

Czym jest chroot

Chroot to polecenie uniksowe, pozwalające uruchomić dany program ze zmienionym korzeniem (root) – katalogiem głównym systemu plików. Wykorzystanie tego typu mechanizmu w konfiguracji domowego serwera ma wiele zalet. Nie jest to raczej metoda, która mogłaby być z powodzeniem użyta na serwerach dużych korporacji – w takich przypadkach znacznie lepiej sprawdzają się techniki wirtualizacyjne. Wirtualizowaniem zasobów na pewno nie będą się jednak zajmować osoby, które korzystają z jednego domowego serwera średniej klasy, często komputera zabytkowego. W przypadku wirtualizacji najważniejszym punktem, od którego trzeba zacząć, to konieczność posiadania odpowiednich zasobów do wirtualizowania. Serwery na zabytkowych komputerach klasy Pentium III lub podobne nie są stworzone dla tak nowoczesnych metod, ale jednocześnie ich los nie jest przekreślony. Odpowiedni system operacyjny bez zbędnych dodatków takich jak środowisko graficzne, jest w stanie umożliwić nie tylko uruchomienie na tego typu komputerze serwera www, serwera ftp czy dostępu przez powłokę secure shell, ale także zwiększyć bezpieczeństwo całej konfiguracji poprzez zastosowanie wcale zasobożernego środowiska chroot.

Stosując środowisko chroot, wydzielamy użytkownikom specjalną przestrzeń dyskową, najczęściej w podfolderze folderu /home. W zależności od zasobów sprzętowych, możemy wykorzystać ten fakt w różny sposób. Jednym z ciekawszych pomysłów jest odseparowanie danych użytkowników i środowiska chroot od danych właściwego systemu. W moim przypadku wykorzystane zostały dwa dyski twarde. Jeden z nich, o pojemności dziesięciu gigabajtów, posłużył za magazyn dla plików właściwego sytemu oraz strony głównej serwera. Drugi, czterdziestogigabajtowy dysk twardy, został w całości przeznaczony na dane środowiska chroot. W zależności od naszej konfiguracji, folder ze środowiskiem chroot może mieć różną nazwę, dla przykładu /home/jail. Folder ten możemy zamontować na osobny dysk twardy. Jeśli posiadamy już zainstalowany system operacyjny, nie musimy go przeinstalowywać, by osiągnąć wyżej wymieniony efekt. Wszystko co należy w tym momencie zrobić, to podpiąć dysk twardy do płyty głównej, po czym utworzyć na nim partycję, a następnie dopisać ją do pliku /etc/fstab. Nową partycję najlepiej utworzyć za pomocą takich narzędzi jak cfdisk. O konfiguracji partycji przy pomocy pliku fstab można przeczytać w internecie.

cfdisk z widokiem na pierwszy dysk twardy

cfdisk z widokiem na drugi dysk twardy

To, na co należy się przygotować, przystępując do konfiguracji serwera do pracy w środowisku chroot, to potencjalne problemy. Aplikacje uruchamiane w środowisku chroot są odseparowane od prawdziwego systemu. O ile korzystamy z prostych, podstawowych poleceń systemu Linux, problemy nie powinny się pojawiać. Kłopoty sprawiają natomiast bardziej zaawansowane aplikacje takie jak nano, dla których trzeba wyszukiwać odpowiednie biblioteki, które następnie ręcznie należy przekopiowywać do folderów środowiska chroot. Nie jest to takie łatwe, nie zawsze wiadomo, który plik trzeba skopiować, jednak takie działające środowisko ma ogromną zaletę – użytkownik teoretycznie nie może wydostać się poza środowisko chroot. W dodatku, przy konfiguracji dyskowej opisywanej przeze mnie powyżej, dane systemu właściwego są jeszcze lepiej odseparowane od danych użytkowników w środowisku chroot. Nawet gdyby udało się użytkownikom zapełnić plikami cały dysk twardy, dysk prawdziwego systemu pozostanie nieruszony. Nawet gdyby użytkownikom udało się usunąć jakieś pliki systemowe środowiska chroot, nie wpłynie to w żaden sposób na funkcjonowanie właściwego systemu. Najciekawsze jest jednak to, iż przy odpowiednim podejściu do sprawy, można środowisko chroot uczynić tak podobne do prawdziwego, iż użytkownik nie będzie w stanie stwierdzić czy pracuje na prawdziwym systemie.

Domyślny układ folderów w środowisku chroot

Przygotowanie środowiska

Z naszego domowego serwera ma się nam korzystać wygodnie. Z racji trybu, w którym pracuje system operacyjny naszego serwera – trybu tekstowego – nie jest potrzebne posiadanie do niego monitora. Można nim zarządzać zdalnie i, w przeciwieństwie do zarządzania zdalnego Pulpitem, jest banalne. Wystarczy, że zainstalujemy w systemie usługę ssh i nie będziemy musieli posiadać osobnej klawiatury i osobnego monitora dla naszego serwera, gdyż będziemy mogli zarządzać nim z naszego domowego komputera, z poziomu terminala. Wystarczy, że przydzielimy naszemu serwerowi statyczny adres (nie jest to konieczne, ale znacznie ułatwi nam pracę w przyszłości), czego dokonuje się poprzez edycję pliku /etc/network/interfaces:

Widok pliku /etc/network/interfaces po zamianie domyślnych ustawień adresu IP pobieranego z DHCP na adres statyczny

ssh -l [nazwa użytkownika] [adres serwera]

Gdyby zdażyło się nam zapomnieć adresu serwera – korzystamy z komendy nmap, by przeskanować sieć lokalną w celu znalezienia podłączonych do sieci urządzeń – nmap -sP 192.168.1.0/24 lub inny adres odpowiedni dla naszej sieci lokalnej:

Wyszukiwanie serwera przy pomocy komendy nmap

Make Chroot Jail

Istnieją różne metody tworzenia środowiska chroot w systemie. Jedną z nich, która najbardziej przypadła mi do gustu, polega na wykorzystaniu skryptu autorstwa Wolfganga Fuschlbergera o nazwie make_chroot_jail.sh. Jest to jednocześnie najłatwiejsza moim zdaniem metoda. Przed wdrożeniem jakiegoś rozwiązania, warto zastanowić się w jaki sposób nam pomoże, w jaki sposób działa, jakie wady i zalety posiada. Postaram się zatem pokrótce to wszystko omówić.

Skrypt Make Chroot Jail jest dostosowany do czterech dystrybucji systemu operacyjnego GNU/Linux: Debianie, Suse, Fedorze i RedHacie. W skrypcie istnieje odpowiedni mechanizm wykrywający uruchomiony system operacyjny i stosujący odpowiednie czynności dla niego. W przypadku kiedy posiadamy system nie zaliczany do tego grona – podejmowane są domyślne czynności. Mowa jest tutaj głównie o bibliotekach kopiowanych do środowiska chroot, specyficznych dla danego systemu. W przypadku, gdy skrypt nie obsługuje danej dystrybucji i ustawienia domyślne się nie sprawdzają – można go edytować, dodając odpowiednie parametry, specyficzne dla tej dystrybucji systemu.

Wycinek kodu źródłowego skryptu makre_chroot_jail.sh

Skryptu można używać tylko posiadając prawa roota. Sugeruję pobranie go i wrzucenie do jednego z folderów ze ścieżki PATH

mv make_chrot_jail.sh /usr/bin/mk_jail

aby móc uruchamiać go jednym poleceniem, wraz z wykorzystaniem funkcji bash polegającej na dopełnianiu nazwy polecenia po naciśnięciu klawisza TAB. Oprócz tego należy nadać skryptowi uprawnienia wykonywania, ale tylko dla roota, czyli rwx—— (700):

chmod 700 /usr/bin/mk_jail

Domyślna konfiguracja skryptu make_chroot_jail.sh tworzy jedynie folder dla użytkownika z prawami rwx——. My, chcąc umożliwić użytkownikom publikowanie swoich własnych stron internetowych i plików, musimy zmienić tę konfigurację. Ręczna zmiana atrybutów folderu za każdym razem z pewnością nie jest wygodna, dlatego lepiej wyedytować skrypt tak, by robił to za nas. Dla leniwych lub niezaawansowanych użytkowników udostępniam zmodyfikowaną przeze mnie wersję skryptu, która tworzy folder dla użytkownika z prawami rwxr-xr-x, a w nim dwa podfoldery: public_html o atrybutach takich jak folder powyższy, z przeznaczeniem dla stron internetowych oraz folder private o uprawnieniach rwx——, w którym użytkownicy będą mogli umieszczać swoje prywatne dokumenty bez obaw, że zobaczy je ktoś inny.

Dodawanie nowych aplikacji

1. Standardowy proces dodawania nowych aplikacji

Przed rozpoczęciem procesu dodawania nowych użytkowników, bądź też migrowania obecnych do środowiska chroot, warto zadbać by już na starcie posiadali odpowiednie aplikacje, potrzebne do codziennej pracy. W domyślnej konfiguracji skryptu w naszym systemie pojawią się jedynie takie programy jak: bash, cp, dircolors, ls, mkdir, mv, rm, rmdir, sh, su, groups, id, netcat, rsync, ssh, scp, unix_chkpwd. Jak można zatem zauważyć – jest to niesamowicie minimalistyczny zestaw oprogramowania, przy pomocy którego zdziałać nie można zbyt wiele. W tym zestawie nie ma nawet programu touch, umożliwiającego tworzenie plików. Warto zatem zastanowić się jakie programy chcemy udostępnić naszym użytkownikom. Osobiście proponuję udostępnić całą zawartość folderu /bin. Zdawałoby się, że możliwość zmiany hasła w systemie jest oczywistością, jednak jak widać po powyższym zestawie podstawowych aplikacji – wcale nie musi tak być. Nie musimy umożliwiać użytkownikom zmiany hasła, jednak to co najmniej szaleństwo. Program odpowiedzialny za zmianę hasła to /usr/bin/passwd.

Programy, które mają zostać skopiowane do środowiska chroot, wpisujemy do skryptu. Ważne, by pamiętać, iż należy podawać pełne ścieżki do programów. Skąd jednak wiedzieć gdzie znajduje się dany program? Do tego celu stosujemy polecenie wbudowane w powłokę bash – type:

Działanie komendy type przedstawione na przykładach

Oprogramowanie mające pojawić się w chroocie wpisujemy do zmiennej APPS do odpowiedniego punktu instrukcji warunkowej if. Jeśli korzystamy ze skryptu na Debianie – ścieżki programów wpisujemy przy warunku “$DISTRO” = DEBIAN:

Zmienna APPS w kodzie źródłowym make_chroot_jail.sh

Po dodaniu programów, komendą:

mk_jail update

dokonujemy aktualizacji zawartości środowiska chroot.

2. Dodawanie specyficznych aplikacji

Większość podstawowych programów, na przykład te z /bin działają na standardowych bibliotekach Linuksa, które skrypt make_chroot_jail.sh kopiuje do chroota automatycznie.

Wycinek kodu źródłowego skryptu make_chroot_jail.sh

Dzięki takiej konfiguracji skryptu, podczas pracy ze standardowymi programami nie pojawiają się problemy wynikające z natury zależności aplikacji od bibliotek. Cuda zaczynają się jednak dziać w przypadku specyficznych aplikacji takich jak nano – konsolowy edytor tekstu. Nawet po jego zainstalowaniu w chroocie, nie jest możliwe uruchomienie go na domyślnej konfiguracji:

zosia@byisk-server:~$ nano
Error opening terminal: xterm.

Ta aplikacja wymaga do działania m.in. bibliotek, które nie są domyślne, dlatego należy je skopiować własnoręcznie. Po raz kolejny pojawia się pytanie – skąd wiedzieć które? Do wykrywania zależności programów od bibliotek stosujemy komendę ldd. Tym poleceniem wskazujemy na plik w danym miejscu na dysku – należy podawać całą ścieżkę jako parametr polecenia, bądź, oczywiście, po prostu przejść do danego folderu i wskazać na konkretny plik z aplikacją. W przypadku nano, polecenie ldd zwraca taki wynik:

Wyszukiwanie potrzebnych bibliotek przy pomocy komendy ldd

Jak zatem widzimy – komenda ldd dokładnie wypunktowuje nam biblioteki, które musimy skopiować do środowiska chroot.

byisk-server:~# cp /lib/libncursesw.so.5 /home/jail/lib/libncursesw.so.5
byisk-server:~# cp /lib/i686/cmov/libc.so.6 /home/jail/lib/i686/cmov/libc.so.6
byisk-server:~# cp /lib/i686/cmov/libdl.so.2 /home/jail/lib/i686/cmov/libdl.so.2
byisk-server:~# cp /lib/ld-linux.so.2 /home/jail/lib/ld-linux.so.2
cp: cannot create regular file `/home/jail/lib/ld-linux.so.2': Text file busy

W kwestii nano i innych edytorów – to jeszcze nie wszystko. Warto zawczasu dodać sobie biblioteki terminfo. Mimo, że komenda ldd nie wykazała takiej konieczności, nie da się bez tego uruchomić takich aplikacji jak nano. Terminfo przyda się nam z pewnością także dla innych aplikacji, chyba, że szczytem wymagań naszych użytkowników jest możliwość tworzenia i kasowania nowych plików i folderów

byisk-server:/etc/terminfo# mkdir -p /home/jail/usr/share/terminfo
byisk-server:/etc/terminfo# cp -R /usr/share/terminfo/ /home/jail/usr/share/terminfo/
byisk-server:/etc/terminfo# mkdir -p /home/jail/lib/terminfo
byisk-server:/etc/terminfo# cp -R /lib/terminfo /home/jail/lib/terminfo/
cp -R /lib/terminfo /home/jail/lib/terminfo
byisk-server:/etc/terminfo# cd !$
cd /home/jail/lib/terminfo
byisk-server:/home/jail/lib/terminfo/terminfo# ls
a c d E h l m p r s v w  x
byisk-server:/home/jail/lib/terminfo/terminfo# mv * ..
byisk-server:/home/jail/lib/terminfo# cd /usr/share/terminfo/
byisk-server:/usr/share/terminfo# ls
1 2 3 4 5 6 7 8 9 a  A b c d e E f g h i  j k l L m M n N o p P q Q r s t u  v w  x X z

Po tych wszystkich czynnościach, nano powinno uruchamiać się i działać bez problemu.

Program nano uruchomiony w środowisku chrootowanym

3. Dodawanie programu passwd i automatyzacja zmiany haseł.

W taki sam sposób, jaki opisałem w punkcie 3.1, dodajemy do listy dostępnych dla użytkownika programów program passwd, służący zmianie hasła. Z racji tego, iż system główny, jak i ten chrootowany, pracują na osobnych wersjach plików, pojawiają się problemy. Po zainstalowaniu passwd, chrootowany użytkownik ma możliwość zmiany hasła, jednak zmiana następuje jedynie w obrębie środowiska chrootowanego, które to nie ma wpływu na pliki systemu głównego, na czym nam przecież zależy. Użytkownik zmienia zatem hasło jedynie w pliku /home/jail/etc/passwd i /home/jail/etc/shadow, a do logowania do systemu używane są pliki /etc/passwd i /etc/shadow. Należy zatem poinstruować system, by automatycznie co jakiś czas porównywał pliki z systemu głównego do tych z systemu chrootowanego i, w razie konieczności, wprowadzał potrzebne zmiany. Zasadniczo, ze względów bezpieczeństwa nie pozwalamy sobie na trzymanie haseł w pliku /etc/passwd, dlatego nawet po zmianie hasła, wpis w tym pliku pozostanie taki sam – x sygnalizuje, iż hasło zawiera się w pliku /etc/shadow. Z tego powodu porównywać będziemy jedynie pliki /etc/shadow i /home/jail/etc/shadow. Standardowy cron dostępny w wielu systemach często sprawia problemy, w moim przypadku w ogóle nie chce uruchamiać poleceń, nawet tak prostych jak tworzenie plików. Proponuję wykorzystać do automatyzacji program bcron, który nastawiony jest głównie na bezpieczeństwo, zastępuje system drop-in z vixie-cron, posiada natywne wsparcie dla czasu letniego i potrafi wiele innych ciekawych rzeczy. W zależnościach pakietu wpisane jest, iż nie może on współgrać z cronem, dlatego pakiet cron zostanie usunięty. Po instalacji bcrona możemy przejść do edycji crontab. W tym celu otwieramy w dowolnym edytorze tekstu, np. nano, plik /etc/crontab i dodajemy do niego wpisy

* * * * * diff -u /etc/shadow /home/jail/etc/shadow > /etc/shadow.patch
* * * * * patch -b /etc/shadow /etc/shadow.patch

lub podobne, w zależności od tego, jak często funkcja synchronizacji plików z hasłami powinna być uruchamiana. Ogrom informacji na temat konfiguracji pliku crontab można znaleźć przy pomocy Google.

Po wykonaniu tych operacji użytkownicy nie będą mieli problemów ze zmianą hasła w środowisku chroot.

Zarządzanie użytkownikami

Skrypt jest banalny w użyciu. Najczęściej uruchamiamy go tylko z jednym parametrem. W przypadku tworzenia nowego i przenoszenia obecnego użytkownika do środowiska chroot – przy uruchomieniu skryptu podajemy tylko jego nazwę. W przypadku gdy użytkownik już istnieje – przed rozpoczęciem migrowania jego folderu i ustawień do środowiska chroot – zostaniemy poproszeni o potwierdzenie operacji.

Działanie skryptu w przypadku migracji użytkownika do środowiska chroot

Zatem za pomocą komendy mk_jail jakilinux utworzymy w systemie użytkownika jakilinux. Istnieje jeszcze opcja zastosowania trzech parametrów, w tym przypadku wywołujemy skrypt w taki sposób: mk_jail [nazwa użytkownika] [ścieżka do powłoki] [ścieżka do folderu domowego]

Proces usuwania użytkownika nie jest niestety aż tak zautomatyzowany. Użytkownika wymazujemy z systemu poprzez zastosowanie kilku komend. Wpierw wywołujemy program odpowiedzialny za usuwanie użytkowników – userdel <nazwa użytkownika>. Następnie kopiujemy zmodyfikowane wersje plików /etc/shadow i /etc/passwd do folderu /home/jail/etc, zastępując obecne. Na sam koniec usuwamy ręcznie wpisy o danym użytkowniku z pliku /etc/sudoers

Jeśli w przyszłości będziemy chcieli pozbyć się całego mechanizmu jail – oprócz wyżej wymienionych czynności usuwamy plik /usr/bin/mk_jail, folder /home/jail oraz “powłokę” /bin/chroot-shell

Konfiguracja usług

1. SSH

Połączenia przez Secure Shell są domyślnie skonfigurowane tak, by wszystko mogło działać w kooperacji z chrootem. Warto jednak wprowadzić kilka zabezpieczeń. Użytkownik chrootowany nie może wejść nam do głównego systemu, pozmieniać plików, a ewentualne zawalenie partycji przeznaczonej dla /home/jail/ nie spowoduje problemów z działaniem systemu właściwego. Może on jednak ubić nasz serwer w inny sposób. Warto zapoznać się z materiałem, do którego hiperłącze zamieściłem w poprzednim zdaniu, by zyskać świadomość, że to, co jest akceptowalne na komputerze biurkowym, często nie może mieć miejsca na serwerze. W Twojej głowie na pewno nie ma takich pomysłów jak ubijanie swojego własnego systemu, pośród użytkowników spotkasz różnych ludzi, którym psucie Twojej pracy może sprawiać przyjemność. Zobaczmy zatem co możemy zdziałać w kwestii bezpieczeństwa udostępnianej użytkownikom usługi Secure Shell.

Jednym z ważniejszych plików, w którym konfigurujemy limity dla użytkowników jest plik /etc/security/limits.conf. Założenie limitów na maksymalną liczbę uruchomionych na raz procesów jest obowiązkowe, by nie doznać na własnej skórze ataku typu bash fork() bomb. W samym pliku znajduje się zahaszowane wytłumaczenie jego konfiguracji wraz z przykładami.

Widok na plik konfiguracyjny usługi Secure Shell

Jak można wyczytać, wpis limitujący ilość procesów do dziesięciu dla wszystkich użytkowników, powinien wyglądać tak:

* hard nproc 10

Liczba procesów, na jaką możemy przyzwolić, zależy od tego ilu użytkowników spodziewamy się na naszym serwerze oraz od tego, jak wydajny jest serwer. Za konfigurację samego daemona sshd odpowiedzialny jest /etc/ssh/sshd_config. By nie powtarzać raz dobrze wykonanej roboty, po informacje na temat konfiguracji, którą można osiągnąć za pomocą tego pliku odsyłam do źródeł tu i tu. Jeden z podpunktów mówi o możliwości podpięcia pliku tekstowego, którego zawartość będzie wyświetlana użytkownikom podczas łączenia się z naszym serwerem przez usługę Secure Shell. Linia w konfiguracji odpowiedzialna za zdefiniowanie pliku, który ma brać udział w tym przedsięwzięciu to:

Banner /etc/issue.net

Mam ciekawą propozycję, która co prawda nie zwiększy bezpieczeństwa serwera, jednak uprzyjemni korzystanie z usług przez niego udotępnianych. W pliku /etc/issue.net można zamieścić jakiś obrazek wykonany techniką ASCII ART, których to niesamowita kolekcja znajduje się na stronie Christophera Johnsona. Efekt nie powala może na kolana, ale niejednemu z naszych użytkowników z pewnością pojawi się uśmiech na twarzy.

Przykładowy komunikat powitalny usługi SSH, czerpiący motywem z Futuramy

Dodatkowe metody zabezpieczenia zostały niedawno opisane w serwisie Jakilinux.org.

2. ProFTPd

Konfiguracja tej usługi również zależy głównie od naszych upodobań. W celu poszerzenia swojej wiedzy, zachęcam do odwiedzenia rozdziału dotyczącego ProFTPd w polskiej dokumentacji PLD. Koniecznością w przypadku chrootowanego FTP za pomocą opisywanej przeze mnie metody jest dodanie (lub odhaszowanie) w pliku /etc/proftpd/proftpd.conf linii

RequireValidShell off

Ma to ogromne znaczenie ze względu na to w jaki sposób działa skrypt. Make Chroot Jail tworzy specjalną “powłokę”, która nie jest autoryzowana w pliku /etc/shells ze względu na to, że gdyby tak było – chroot nie spełniałby swojej funkcji. Powłoka /bin/chroot-shell to prosty skrypt, w którym zawiera się taka komenda:

/usr/bin/sudo /usr/sbin/chroot /bin/su - $USER "$@"

Jak zatem możemy zauważyć – cała sztuczka polega na tym, iż przy logowaniu się na konto korzystające z chroot-shella, z poziomu roota (przez sudo) uruchamiany jest program chroot, po czym następuje przełączenie się na danego użytkownika. ProFTPd, jak sama nazwa wskazuje, jest profesjonalnym serwerem FTP W program wbudowano mechanizm zabezpieczający przed potencjalnym niebezpieczeństwem związanym z użyciem fałszywej powłoki – właśnie z tego powodu musimy dodać wyżej wymienioną linię do pliku konfiguracyjnego.

3. Apache

Również w dokumentacji PLD można odnaleźć ciekawe informacje na temat podstaw konfiguracji Apache. To, co nas interesuje, to konfiguracja serwera Apache by pozwalał na umieszczanie stron przez wszystkich użytkowników. Jest to banalne, cytując źródło:

Swobodne publikowanie stron internetowych przez użytkowników jest możliwe dzięki pakietowi apache-mod_userdir. Opcja UserDir w pliku 16_mod_userdir.conf definiuje nazwę katalogu przechowującego strony użytkowników wewnątrz ich katalogów domowych.

UserDir public_html

Przykład: Użytkownik Jan Kowalski posiada konto o nazwie: jan. W /home/users/jan jest jego katalog domowy. Swoją stronę internetową umieszcza w katalogu /home/users/jan/public_html, zaś dostęp do niej uzyskuje za pomocą adresu http://example.net/~jan.
Aby strona się wyświetliła należy ustawić odpowiednie prawa dostępu – tak by Apache (domyślnie z prawami użytkownika http) miał prawo do odczytu. Katalog domowy jan powinien mieć ustawione prawa 711. Katalog przechowujący jego stronę czyli public_html powinien mieć 755. Każdy katalog zawierający elementy strony powinien mieć również uprawnienia 755. Pliki strony natomiast 644.

UserDir wskazuje na folder public_html, czyli ten, który jest tworzony przez zmodyfikowaną przeze mnie wersję skryptu.

Czynienie serwera widocznym w sieci Internet

1. Przekierowanie portów

Aby umożliwić pracę naszego domowego serwera w sieci WAN, będziemy musieli skorzystać z mechanizmu przekierowania portów. Tego typu mechanizmy stosuje się w routerach. Jeśli na naszym serwerze będzie działać np. serwer www, musimy ustawić przekierowanie portu 80 na konkretny adres IP w sieci lokalnej.

Domyślna konfiguracja większości routerów bazuje na protokole DHCP, który przydziela adresy dynamicznie. Nie jest to dobre rozwiązanie, gdyż przy każdej zmianie adresu przez DHCP, musielibyśmy zmieniać adres IP, na który przekierowane miałyby być dane porty. By wprowadzić poprawną konfiguracę do pliku interfaces, należy zorientować się jakie adresy IP w sieci lokalnej są wolne, a jakie są zarezerwowane dla działania protokołu DHCP. Całość jest możliwa do skonfigurowania w routerze. Spostrzegawczy użytkownicy zorientowali się już na pewno, iż stosując mechanizm przekierowania portów, można posiadać osobny serwer dla każdej usługi. Można posiadać także kilka serwerów dla jednej usługi, dzięki mechanizmowi klastrowania I równoważenia obciążenia, jednak tematyka ta nie wchodzi w zakres tego artykułu.

Strona konfiguracyjna routera

Strona konfiguracyjna routera

Warto w tym momencie również wspomnieć, z racji popularności urządzenia, że cześć usług oferowanych przez serwer w sieci Internet, np. WWW, wymaga do działania tzw. strefy zdemilitaryzowanej, której z pewnością nie posiadają routery oferowane przez Telekomunikację Polską – liveboksy. DMZ posiada większość routerów dostępnych na rynku.

2. Konfigurowanie DynDNS

Żyjemy w erze domen, wpisywanie adresów IP serwerów jest obecnie uznawane za coś niebywałego i kompletnie niewygodnego. Warto zaopatrzeć się w domenę dla naszego serwera, nawet w darmową. W przypadku gdy korzystamy z sieci, w której zewnętrzny adres IP jest przydzielany dynamicznie – np. z Neostrady – domena to konieczność. W celu współpracy z dynamicznie zmiennymi IP powstała darmowa usługa DDNS (Dynamic Domain Name Server) DynDNS.com. Korzystając z tej usługi możemy ustawić domenę zarówno dla statycznego, jak i dynamicznego adresu. Na dodatek wielu producentów dostrzegło tę możliwość i umożliwiła w swoich routerach automatyczną synchronizację z usługą DynDNS. Wystarczy w panelu administracji routera podać swój login i hasło do usługi DDNS, aby router, przy każdej zmianie adresu IP, wysyłał informację do DynDNS, by ten zaktualizował wpisy na swoich serwerach. Całość działa naprawdę świetnie, a w dodatku za darmo, dlatego warto z tego skorzystać.

W celu założenia konta i usługi w serwisie DynDNS, należy udać się na stronę usługi. Na stronie głównej, w pobliżu panelu logowania, wybieramy opcję Create Account.

W dalszej części wypełniamy kolejne formularze, aż w końcu kończymy rejestrację, logujemy się do serwisu, znajdujemy zakładkę My Services, gdzie w części usług hostingowych (Host Services) wybieramy opcję Add Hostname.

Konfiguracja nazwy domenowej w DynDNS

W następnej części wpisujemy nazwę domenową dla naszego serwera, wybieramy opcję Host with IP Adress, po czym klikamy na “Use auto detected IP Address x.x.x.x”

Konfiguracja nazwy domenowej w DynDNS

Następnie udajemy się do panelu konfiguracyjnego routera, gdzie podajemy nasze dane dostępowe do usługi, zapisujemy ustawienia i od teraz usługi oferowane przez nasz serwer są widoczne spoza naszej sieci lokalnej. Tak, nasz serwer stał się teraz serwerem widocznym w Internecie.

Konfiguracja synchronizacji routera z DynDNS

3. Konfigurowanie /etc/hosts

W pewnych przypadkach możliwość korzystania z domeny w przypadku łączenia się w sieci lokalnej jest przydatna. Taka możliwość przypadnie do gustu osobom, które posiadają nie jeden, lecz kilka domowych serwerów, a spamiętywanie ich adresów IP nie jest rzeczą przyjemną. W obecnych czasach możliwości usługi www znacznie się rozwinęły i w przypadku niektórych skryptów, np. blogowego systemu WordPress, nie możemy pozwolić sobie na korzystanie z adresu IP. WordPress wymaga ustawienia konkretnej nazwy domeny dla bloga. Możemy wpisać tam adres domenowy, jednak w większości przypadków nie będziemy w stanie połączyć się z serwerem przy pomocy domeny, gdyż będziemy przekierowywani na stronę konfiguracyjną routera. Przy próbie łączenia się z serwerem poprzez wpisanie adresu IP, posypie się nam WordPress, gdyż większość elementów skrypt próbował będzie pobierać ze skonfigurowanego wcześniej adresu domenowego, jednak nie otrzyma ich, gdyż jego zapytania zatrzymaja się na routerze. W takich i innych przypadkach wystarczy w swoim komputerze biurkowym zastosować sztuczkę polegającą na dodaniu nazwy domenowej serwera do pliku /etc/hosts:

Widok na plik /etc/hosts

Po wykonaniu tej prostej czynności wszystkie zapytania kierowane na domenowy adres naszego serwera będą zamieniane na zapytania na adres IP w sieci lokalnej.

Zakończenie

Mam nadzieję, iż przedstawiony przeze mnie w tym artykule sposób pomoże początkującym administratorom zwiększyć bezpieczeństwo serwerów przez nich zarządzanych. Jak już mówiłem, w dobie dzisiejszych mocy obliczeniowych bezpieczeństwo znacznie efektywniej zwiększa się przy pomocy wirtualizacji. Znajdzie się jednak nie jeden użytkownik, który z ogromną chęcią weźmie swojego starego peceta i postawi na nim serwer. Mam nadzieję, że dzięki mojemu artykułowi serwer będzie choć odrobinkę bezpieczniejszy.

—Szymon Barczak (b.yisk)
Skład: Swamper / Sekurak