Sekcje

Przejdź na skróty do treści. | Przejdź do nawigacji


Baza wiedzy Publikacje Bezpieczeństwo BSD: Hardening systemu

Bezpieczeństwo BSD: Hardening systemu

— w kategorii: ,

Systemy z rodziny BSD są uważane za bezpieczne systemy operacyjne. Taką opinię zawdzięczają dzięki stabilnej i solidnej bazie kodu. Jest ona ciągle rozwijana, poprawiana oraz ulepszana. Duża ilość deweloperów i niezależnych badaczy bezpieczeństwa bezustannie przegląda i audytuje kod tych systemów operacyjnych. Przyczynia się to do zapewnienia, że tuż po standardowej instalacji, bez żadnej dodatkowej konfiguracji systemy z rodziny BSD są mocno zabezpieczone.

Oczywiście, zawsze można podnieść poziom bezpieczeństwa systemu operacyjnego. W tym artykule postaramy się pokazać co można jeszcze zrobić aby system z rodziny BSD jeszcze bardziej „utwardzić“.

Ze względu na bardzo dużą popularność systemu FreeBSD skupimy się właśnie na tej wersji. Nie oznacza to że wymienione poniżej przykłady nie są adekwatne do pozostałych systemów z rodziny BSD jak również innych systemów operacyjnych. Prezentowane poniżej przykładowe polecenia powłoki mają jedynie nakreślić sposób wykonania pewnego zadania a nie jedyne rozwiązanie.

„Safety First“

Zanim zajmiemy się aspektami związanymi z bezpieczeństwem zewnętrznym (eng. security) postaramy się przybliżyć tematykę związaną z bezpieczeństwem wewnętrznym (eng. safety) - ochroną systemu. Przy okazji chcielibyśmy naświetlić pewną, często pomijaną kwestię związaną z dwoma filarami bezpieczeństwa. Bezpieczeństwo jako takie możemy podzielić na dwie części.

Pierwsza z nich - safety czyli ochrona - polega na zapewnieniu bezpieczeństwa lokalnego. Czyli takiego skonfigurowania sprzętu i oprogramowania aby lokalnie, po uzyskaniu lokalnego dostępu, nie dało się przejąć pełnej kontroli nad systemem albo przynajmniej utrudnić je jak najbardziej. Również uniemożliwienie oraz minimalizacja szkód jakie intruz jest w stanie nam wyrządzić jest też zadaniem ochrony. W tej kategorii znajdują się także rozwiązania zapewniające nieprzerwaną pracę systemu, zmniejszające ryzyko utraty danych itp.

Drugą kategorią jest security czyli bezpieczeństwo z zewnątrz. Ma ono na celu zminimalizowanie wszelkich zdalnych zagrożeń i ataków. Polega ono na filtrowaniu ruchu, zabezpieczaniu usług sieciowych i aplikacji, etc.

Odpowiednie zabezpieczenie systemu plików.

W trakcie podłączania (ang. mount) systemu plików (w naszym przypadku jest to UFS) poszczególnych "slice’ów" możemy skorzystać z opcji regulujących proces mount’owania. Niektóre z nich mogą zostać wykorzystane do zwiększenia poziomu bezpieczeństwa systemu operacyjnego. W naszym przypadku takimi opcjami będą noexec oraz nosuid.

Pierwsza z nich - noexec - uniemożliwia wykonywanie plików binarnych na oznaczonym nią slice. Niestety, nie została ona z góry zaprojektowana jako mechanizm zabezpieczający, dlatego też nie zapewnia całkowitej blokady plików wykonywalnych. Pomimo tego jest to dobry sposób na utrudnienie życia ewentualnemu włamywaczowi.

Z kolei opcja nosuid uniemożliwia poprawne działanie plików z bitem set-user-identifier lub set-group-identifier. Co oznacza, że pliki wykonywalne oznaczone bitami zmieniającymi identyfikator użytkownika lub grupy nie będą efektywnie zmieniać tych identyfikatorów. Może to skutkować tym, że przypadkowo pozostawiony przez użytkownika root plik z takim bitem, który w najgorszym dla nas przypadku mógłby doprowadzić do przejęcia uprawnień root’a. Zostanie uruchomiony jedynie z prawami tego użytkownika, który go uruchamia a nie super-użytkownika - dzięki opcji nosuid systemu plików, na którym ten plik się znajdował.

W zależności od polityki i naszych ustawień system plików mógłby wyglądać następująco. Opcja nosuid jest ustawiona w /home, /var/ oraz /var/tmp. Natomiast noexec został włączony w katalogu z plikami tymczasowymi oraz w katalogu domowym.

   
% cat /etc/fstab
   
# Device	  Mountpoint	FStype	Options	  Dump	 Pass#
   
/dev/sd0s1b	 none	  swap	 sw	   0	 0
   
/dev/sd0s1a	 /	  ufs	 rw	   1	 1
   
/dev/sd0s1i	 /usr	  ufs	 rw	   2	 2
   
/dev/sd0s1g	 /home	 ufs	 rw,nosuid,noexec	2	 2
   
/dev/sd0s1f	 /var	  ufs	 rw,nosuid	  2	 2
   
/dev/sd0s1e	 /var/tmp	 ufs	 rw,nosuid,noexec	2	 2
   
proc	   /proc	 procfs	rw	   0	 0

Przeszukiwanie systemu plików.

Polecenie systemowe find jest jednym z najprzydatniejszych poleceń w arsenale administratora systemu. Dzięki niemu jesteśmy w stanie znaleźć każdy plik, zrobić szybki audyt naszego systemu oraz pozbyć się potencjalnie niebezpiecznych plików. Dlatego warto też z nim się zapoznać.

 

W celu przeszukania naszego systemu pod kontem plików z włączonymi flagami suid/sgid możemy wykonać poniższe polecenia. Pierwsza z nich znajdzie pliki z włączoną flagą sgid a druga z flagą suid.

 

# find / -perm -2000 -ls
# find / -perm -4000 -ls

 

Możemy wykorzystać polecenie find do odnalezienia innych podejrzanych plików. Na przykład pliki, do których mogą zapisywać inni użytkownicy.

 

# find / -perm -002 -ls

 

Kolejnym przykładem wykorzystania polecenia find może być odnalezienie plików, które mają przypisane identyfikatory użytkownika bądź grupy, które nie są zdefiniowane w naszym systemie.

 

# find / -nogroup -ls
# find / -nouser -ls

 

Odnalezienie plików, których właścicielem jest root też nie powinno sprawić problemu.

# find / -user root -ls

 

Warto również sprawdzić gdzie znajdują się katalogi w naszym systemie, do których nie ma ograniczeń co do zapisu. Możemy przyjrzeć się tym katalogom i podjąć odpowiednie akcje w celu zabezpieczenia ich przed niepowołanym dostępem. Poniższa komenda wyświetli wszystkie katalogi z pełnymi uprawnieniami do zapisu i wykonywania dla pozostałych użytkowników.

# find / -perm -003 -type d -ls

Ujednolicenie katalogu plików tymczasowych.

W systemie FreeBSD i w pozostałych systemach z rodziny BSD istnieją i są wykorzystywane dwa katalogi w których przechowywane są pliki tymczasowe. Pierwszy z nich znajduję się w /tmp a drugi w /var/tmp. Ich wykorzystanie zależy od usługi. W zależności od polityki jaką sobie przyjmiemy możemy usunąć jeden z nich a następnie zrobić dowiązanie symboliczne. Poniższy przykład ilustruje usunięcie katalogu /tmp i stworzenie dowiązania symbolicznego z /var/tmp do /tmp.

   
# rm -R /tmp
   
# ln -s /var/tmp /tmp

Zabezpieczenie plików konfiguracyjnych, logów oraz innych.

Bardzo ważnym dla nas szczegółem jest zapewnienie integralności i nienaruszalności plików konfiguracyjnych naszego systemu. Dlatego też dostęp do nich powinien być ściśle ograniczony. Poniższe polecenia ograniczą dostęp do najważniejszych plików systemowych.

   
# chmod o= /etc/fstab
   
# chmod o= /etc/ftpusers
   
# chmod o= /etc/group
   
# chmod o= /etc/hosts
   
# chmod o= /etc/hosts.allow
   
# chmod o= /etc/hosts.equiv
   
# chmod o= /etc/hosts.lpd
   
# chmod o= /etc/inetd.conf
   
# chmod o= /etc/login.access
   
# chmod o= /etc/login.conf
   
# chmod o= /etc/newsyslog.conf
   
# chmod o= /etc/rc.conf
   
# chmod o= /etc/ssh/sshd_config
   
# chmod o= /etc/sysctl.conf
   
# chmod o= /etc/syslog.conf
   
# chmod o= /etc/ttys

 

Następnym krokiem, który powinniśmy wykonać jest zabezpieczenie folderu logów wraz z plikami znajdującymi się w nim. Takie zabezpieczenie oprócz standardowego wyłączenia praw dostępu powinno również wykorzystać flagi pliku. Dla plików typu logi bardzo przydatną jest flaga sappend, której zadaniem jest umożliwienie jedynie dodawania danych do pliku. Dzięki temu nie będzie się dało usunąć danych z tego katalogu lub ich zmodyfikować w sposób wykraczający poza zwykłe dodanie danych na koniec pliku. Niestety ta flaga uniemożliwia rotacje logów. Istnieją triki, które omijają ten problem jednak ich nie polecamy.

   
# chmod o= /var/log
   
# chflags sappnd /var/log
   
# chflags sappnd /var/log/*

 

W kolejnym kroku powinniśmy zabezpieczyć się przed niepowołanym dostępem do poleceń systemowych, które mogłyby się przydać ewentualnemu włamywaczowi do pozyskania dodatkowych informacji o naszym systemie.

   
# chmod o= /usr/bin/users
   
# chmod o= /usr/bin/w
   
# chmod o= /usr/bin/who
   
# chmod o= /usr/bin/lastcomm
   
# chmod o= /usr/sbin/jls
   
# chmod o= /usr/bin/last
   
# chmod o= /usr/sbin/lastlogin

 

Rozsądnym, również jest całkowite uniemożliwienie dostępu do narzędzi systemowych, które mogły by zostać wykorzystane w nieodpowiedni sposób.

   
# chmod ugo= /usr/bin/rlogin
   
# chmod ugo= /usr/bin/rsh

 

Ostatnim krokiem w ramach tego punktu jest wyłączenie dostępu osobom niepowołanym do pozostałych narzędzi, które mogą zagrażać bezpieczeństwu naszego systemu operacyjnego.

   
# chmod o= /usr/local/bin/nmap
   
# chmod o= /usr/local/bin/nessus

 

Harmonogram tylko dla root’a.

Bardzo rozsądnym jest zapewnienie tego, że wszystkie czynności jaki będą wykonywane przez daemona cron będą tylko i wyłącznie zlecane przez super-użytkownika. W tym celu należy wykonać poniższe polecenia. Pierwsze dwa z nich ustawiają super-użytkownika root jako jedynego użytkownika, który jest w stanie kontrolować daemona cron. Kolejne z nich wyłączają wszelkie pozwolenia dla pozostałych użytkowników (brak odczytu, zapisu i wykonania tych plików).

   
# echo "root" > /var/cron/allow
   
# echo "root" > /var/at/at.allow
   
# chmod o= /etc/crontab
   
# chmod o= /usr/bin/crontab
   
# chmod o= /usr/bin/at
   
# chmod o= /usr/bin/atq
   
# chmod o= /usr/bin/atrm
   
# chmod o= /usr/bin/batch

Odpowiednia konfiguracja pliku /etc/rc.conf.

Plik /etc/rc.conf jest głównym plikiem w systemie FreeBSD odpowiedzialnym za konfiguracje systemu. Zawiera takie dane jak nazwa hosta, szczegóły konfiguracji serwisów itp. Ważnym dla ogólnego poziomu bezpieczeństwa jest odpowiednie skonfigurowanie tego pliku.

Przede wszystkim wypadałoby włączyć mechanizm securelevels. Jest on odpowiedzialny między innymi za zabezpieczanie dostępu do niektórych urządzeń systemowych, uniemożliwienie zmian w plikach oznaczonych specjalnymi flagami, zabezpieczenie dysku przed zapisem, etc.

 

# echo ’kern_securelevel_enable="YES"’ >> /etc/rc.conf

 

Później powinniśmy ustawić odpowiedni dla naszych wymagań poziom bezpieczeństwa mechanizmu securelevels. Do wyboru mamy pięć opcji:

-1 - standardowo włączony poziom, brak jakichkolwiek zabezpieczeń, z tego poziomu nie da się podnieść securelevels.

0 - poziom, z którego można podnieść securelevels na wyższy, poza tym nie ma żadnych dodatkowych właściwości.

1 - poziom, na którym flag immutable oraz append-only nie można wyłączyć, zamontowane dyski nie mogą być otwarte do zapisu, brak dostępu do /dev/io, moduły jądra nie mogą być ładowane ani wyładowane

2 - wszystko co z powyższego poziomu jak również żadne z dysków nie mogą być otwarte do zapisu (mogą jedynie zostać zamontowane), dodatkowo czas systemowy nie może zostać zmieniony więcej niż jedna sekunda.

3 - to samo co powyżej plus ustawienia filtrów pakietów oraz ich konfiguracja nie może być zmieniana.

# echo ’kern_securelevel="3"’ >> /etc/rc.conf

 

Włączymy teraz funkcjonalność ignorującą pakiety ICMP REDIRECT oraz będziemy wszystkie takie pakiety logować. Ochroni nas to przed niektórymi atakami typu odmowa usługi.

# echo ’icmp_drop_redirect="YES"’ >> /etc/rc.conf
# echo ’icmp_log_redirect="YES"’ >> /etc/rc.conf
# echo ’log_in_vain="YES"’ >> /etc/rc.conf

 

Wyłączmy również standardowego daemon’a poczty (sendmail), który może powodować duże zagrożenie dla naszego serwera ze względu na jego liczne podatności.

 

# echo ’sendmail_enable="NO"’ >> /etc/rc.conf

 

Uniemożliwmy również uruchamianie usług NFS.

# echo ’nfs_server_enable="NO"’ >> /etc/rc.conf
# echo ’nfs_client_enable="NO"’ >> /etc/rc.conf

Zabezpieczenie trybu jednego użytkownika.

Standardowo w systemach z rodziny BSD tryb pojedynczego użytkownika jest niezabezpieczony hasłem. Jest to bardzo przydatne w momencie, w którym zapomnimy hasła super-użytkownika do naszego systemu lub coś źle skonfigurujemy. Jesteśmy wtedy w stanie uruchomić nasz system w trybie jednego użytkownika a następnie z konsoli wykonać odpowiednie operacje i przywrócić jego pełną funkcjonalność. Od razu nasuwa się problem związany z tym że ktoś niepowołany w ten sposób zmieni nam hasło super-użytkownika. Aby zabezpieczyć się przed takim działaniem musimy w pliku /etc/ttys skonfigurować w wpis konsoli w następujący sposób.

console none unknown off insecure

Wybranie odpowiedniego algorytmu haszującego hasła.

System FreeBSD obsługuje kilka różnych formatów przechowywania haseł. Aktualnie FreeBSD wykorzystuje trzy różne funkcje haszujące hasła są nimi  MD5 oraz dwie funkcje oparte na algorytmach DES i Blowfish. Standardowym dla tego systemu jest algorytm MD5. Sam algorytm MD5 nie jest najlepszym rozwiązaniem dla zapewnienia wysokiego standardu bezpieczeństwa. Ze względu na jego kryptoanalityczne słabości np.: kolizje - zalecamy zmianę na algorytm Blowfish. Wykonanie poniższego polecenia wraz ze zmianami w pliku /etc/login.conf spowoduje zmianę standardowej metody haszującej na Blowfish.

 

# echo "crypt_default=blf" >> /etc/auth.conf

Należy dokonać poniższych zmian w pliku /etc/login.conf na przykład w sekcji default.

   
 :passwd_format=blf:\
   
 :minpasswordlen=9:\
   
 :mixpasswordcase=true:\
   
 :passwordtime=90d:\
   
 :idletime=30:\
   
 :accounted=true:\
   
 :autodelete=90d:\
   
 :warnpassword=14d:\

 

Następnie aby nasze ustawienia poskutkowały powinniśmy przebudować bazę haszy.

# /usr/bin/cap_mkdb /etc/login.conf

Kilka przydatnych zmian w pliku sysctl.conf.

Plik sysctl.conf bezpośrednio modyfikuje stan jądra systemu FreeBSD. Dlatego ważne jest ustawienie kilku opcji, które pozwolą nam podnieść jeszcze wyżej poziom bezpieczeństwa.

 

Uniemożliwmy użytkownikom oglądanie procesów innych użytkowników.

# echo ’security.bsd.see_other_uids=0’ >> /etc/rc.conf

 

Włączmy również funkcjonalność porzucającą wszystkie pakiety wysyłane na zamknięte porty naszej maszyny.

# echo ’net.inet.tcp.blackhole=2’ >> /etc/rc.conf
# echo ’net.inet.udp.blackhole=1’ >> /etc/rc.conf

 

Przydatne również jest włączenie randomizacji identyfikatorów pakietów IP.

# echo ’net.inet.ip.random_id=1’ >> /etc/rc.conf

 

Dodatkowo możemy zastosować mechanizm log_in_vain, który to będzie odpowiedzialny za logowanie wszystkich prób nawiązania połączenia na porty na których nie działa żadna usługa. Może to posłużyć nam do określenia czy przypadkiem nie byliśmy skanowani.

# echo ’net.inet.tcp.log_in_vain=1’ >> /etc/rc.conf
# echo ’net.inet.udp.log_in_vain=1’ >> /etc/rc.conf

Logowanie to podstawa.

Na samym końcu rozdziału o bezpieczeństwie wewnętrznym chcielibyśmy poruszyć kwestie związane z logowaniem zdarzeń. FreeBSD standardowo obsługuje dwa mechanizmy rejestracji zdarzeń. Pierwszym z nich jest syslogd a drugim newsyslog.

W zależności od potrzeb w pliku konfiguracyjnym /etc/syslog.conf mogą znajdować się różne konfiguracje. Aby monitorować dostęp do naszej maszyny możemy za pomocą syslogd sprawdzać wszystkie próby autoryzacji do naszego systemu. Przykład takiego wpisu znajduje się poniżej.

auth.*,authpriv.*	   /var/log/authlog

 

W przeciwieństwie do syslogd, newsyslog nie jest uruchamiany jako daemon lecz jako zadanie z poziomu crontab. Żeby newsyslog poprawnie się uruchamiał powinniśmy dodać poniższy wpis do pliku /etc/crontab.

0       *       *       *       *       root    /usr/sbin/newsyslog

Możemy ustawić tak /etc/newsyslog.conf aby wybrane pliki z logami po osiągnięciu rozmiaru 100K zostały spakowane gzip’em Następnie te pliki zostaną przemianowane oraz zmienione zostaną im pozwolenia na 640 oraz ustawiony zostanie właściciel na root.wheel.

   
/var/log/maillog        root.wheel      640  7     100  *     Z
   
/var/log/authlog        root.wheel      640  7     100  *     Z
   
/var/log/messages       root.wheel      640  7     100  *     Z

Utrzymanie aktualności.

Od wersji 6.3, FreeBSD zawiera w sobie narzędzie ułatwiające aktualizacje całego systemu. Tym narzędziem jest freebsd-update. Dzięki niemu utrzymanie systemu w pełni zaktualizowanego nie stanowi już tak dużego problemu jak przedtem. freebsd-update zawiera w sobie dwie osobne funkcjonalności. Pierwsza z nich pozwala na wykonywanie aktualizacji zabezpieczeń i błędów. Druga z nich zapewnia mechanizm aktualizacji systemu do nowszych wersji. Narzędzie freebsd-update jest konfigurowana za pomocą pliku freebsd-update.conf. Standardowy plik konfiguracyjny wygląda mniej więcej tak:

   
KeyPrint 800651ef4b4c71c27e60786d7b487188970f4b4169cc055784e21eb71d410cc5
   
ServerName update.FreeBSD.org
   
Components src world kernel
   
UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile
   
MergeChanges /etc/ /var/named/etc/ /boot/device.hints

 

   
### Default configuration options:
   
WorkDir /var/db/freebsd-update
   
MailTo root
   
BackupKernel yes
   
BackupKernelDir /boot/kernel.old

Do dyspozycji mamy kilka argumentów polecenia freebsd-update.



# freebsd-update fetch

 

Za pomocą powyższego polecenia zostanie pobrany zestaw aktualizacji.

# freebsd-update install

 

To polecenie natomiast zainstaluje aktualizacje, które zostały wcześniej pobrane.

# freebsd-update rollback

Jeśli z przyczyny wykonanej aktualizacji utracimy stabilność naszego systemu za pomocą tego polecenia jesteśmy wstanie usunąć z najnowsze aktualizacje.

Wild wild Net

 

Zajmijmy się teraz zabezpieczeniem naszego systemu operacyjnego od strony zewnętrznej. Postaramy się odpowiednio skonfigurować usługi systemowe oraz je zabezpieczyć za pomocą mechanizmów oferowanych przez FreeBSD.

inetd czyli główny daemon systemowy.

Daemon’a inetd jest to "super-serwer", którego zadaniem jest minimalizacja zużywanych zasobów systemowych. Polega to na tym że zamiast uruchamiania od początku dedykowanych usług, na naszym serwerze działa jedynie inetd, który nasłuchuje na nadchodzące połączenia.

Gdy takie połączenie zostanie nawiązane inetd wybiera odpowiednią usługę a następnie uruchamia ją i przekazuje do niej połączenie. Po skończonym połączeniu usługa uruchomiona przez inetd jest wyłączana.

inetd jest przydatny właśnie w przypadku oszczędzania zużywanych zasobów systemowych. Nie jest to wydajna metoda gdy nasz system ma obsługiwać dużą ilość połączeń. Dlatego też w takim przypadku należy ustawić poniższą linię w pliku konfiguracyjnym /etc/rc.conf.

inetd_enable="NO"

Jeśli jednak nie zdecydujemy się na korzystanie z inetd powinniśmy zwiększyć ilość obsługiwanych połączeń z standardowych 256 na jakąś większą liczbę - zmniejszy to ryzyko wykonania ataku odmowy usługi na nasz system - w naszym przypadku jest to 1024, przełącznik "-R". Warto zwrócić uwagę na to, że wybrana liczba ilości obsługiwanych połączeń nie powinna być zbyt duża. Jeśli okaże się za duża to możemy wyczerpać zasoby systemowe i doprowadzić do odmowy usługi. Dodatkowo warto również włączyć logowanie wszystkich udanych połączeń - przełącznik "-l". Powinniśmy się upewnić że sekcja inetd w /etc/rc.conf wygląda tak jak poniżej.

inetd_enable="YES"
inetd_flags="-l -R 1024"

Jeśli już zdecydowaliśmy się na wykorzystanie inetd to możemy za jego pomocą uruchomić kilka dodatkowych daemonów.

Jednym z nich jest telnetd, którego używania odradzamy. Dlatego też powinniśmy się upewnić że linijki odpowiedzialne za konfigurację daemona telnetd w pliku /etc/inetd.conf jest wykomentowana.



#telnet stream  tcp     nowait  root    /usr/libexec/telnetd    telnetd
#telnet stream  tcp6    nowait  root    /usr/libexec/telnetd    telnetd

 

W przypadku gdy jednak zdecydujemy się na korzystanie z telnetd powinniśmy postarać się o możliwie najbezpieczniejsze jego skonfigurowanie. Do dyspozycji mamy opcję "-h", która wyłącza wyświetlanie banerów informacyjnych hosta przed poprawnym zalogowaniem, oraz opcję "-U", której zadaniem jest uniemożliwienie nawiązania połączenia z daemonem w przypadku nieposiadania przez klienta symbolicznej nazwy hosta. Dlatego też w przypadku wykorzystania IPv4 linijka odpowiedzialna za konfiguracje telnetd w pliku /etc/inetd.conf powinna wyglądać jak poniżej.

telnet	stream	tcp	nowait	root	 /usr/libexec/telnetd	telnetd -h -U

 

Kolejnym z daemonów jest popularny serwer plików ftpd. Tak jak w przypadku telnetd nie zaleca się jego wykorzystania ze względu na niski poziom bezpieczeństwa jaki gwarantuje (między innymi dane uwierzytelniające przesyłane są otwartym tekstem). Dlatego też jeśli zdecydujemy się korzystać z tego daemona to powinniśmy umożliwić jedynie anonimowy dostęp do zasobów ftp naszego serwera poprzez dodanie opcji "-A" oraz włączenie logowania zdarzeń ftpd za pomocą opcji "-l".

ftp	stream	tcp	nowait	root	/usr/libexec/ftpd	ftpd -l -A

 

Ostatnim z omawianych w tej części daemonów jest fingerd, który również powinien być wyłączony. Jeśli już z jakichś względów chcemy mieć tą usługę włączoną to powinniśmy dodać opcję "-l", która zapewni logowanie zdarzeń.

finger	stream	tcp	nowait	nobody	/usr/libexec/fingerd	fingerd -s -l

sshd.

Aby zabezpieczyć serwer ssh nie musimy się wiele natrudzić, dlatego że standardowo jest już on wystarczająco bezpiecznie skonfigurowany. Pomimo tego warto abyśmy zapoznali się z kilkoma opcjami konfiguracyjnymi tego daemona. Są one zawarte w pliku /etc/ssh/sshd_config.

 

Wymuszanie drugiej wersji protokołu ssh.

Protocol 2

Ustawienie poziomu logowania na INFO.

LogLevel INFO

Ustawienie maksymalnego czasu oczekiwania na zalogowanie się na 2 minuty.

LoginGraceTime 2m

Uniemożliwienie logowania się root’owi.

 

PermitRootLogin no

 

Sprawdzanie uprawnień plików i katalogów użytkowników przed umożliwieniem im zalogowania się na naszą maszynę.

StrictModes yes

 

Ustawienie maksymalnej ilości nieudanych prób logowania.

MaxAuthTries 3

Uniemożliwienie logowania się z pustym hasłem.

PermitEmptyPasswords no

 

Wyświetlanie ostatniego czasu i lokalizacji logowania.

PrintLastLog yes

Wykorzystywanie separacji uprawnień.

UsePrivilegeSeparation yes

 

Wykorzystanie DNS’a do określenia czy przedstawiona nazwa zdalnego hosta jest identyczna z nazwą hosta uzyskaną za pomocą jego adresu IP.

UseDNS yes

Aplikacje do więzienia.

FreeBSD wprowadził w wersji 4.0 nowe narzędzie do zabezpieczania usług. Tym narzędziem jest jail, którego zadaniem jest dostarczenie lepszego mechanizmu separacji aplikacji od systemu niż chroot. W ramach tej części postaramy się stworzyć przykładowy jail.

 

Najpierw musimy zacząć od stworzenia środowiska, w którym jail mógłby być uruchomiony. Aby to osiągnąć musimy wykonać poniższe kroki.

 

Stwórzmy katalog, w którym nasz jail będzie się znajdował a następnie ustawmy zmienną systemową wskazującą na ten katalog. W naszym przypadku będzie on się znajdował w katalogu /jails/myjail.

# mkdir -p /jails/myjail
# setenv D /jails/myjail

 

Następnie musimy zainstalować w naszym katalogu środowisko, czyli cały system FreeBSD ze źródeł oraz dodać do niego pliki urządzeń.

# mount -t devfs devfs $D/dev

 

Dzięki powyższym działaniom mamy już odpowiednią strukturę katalogów - środowisko - na którym możemy uruchamiać naszego jail’a. Teraz powinniśmy przystąpić do konfiguracji naszego systemu.

Musimy zaznaczyć że jail do komunikacji sieciowej wykorzystuje aliasy zdefiniowane na naszych systemowych interfejsach. Dlatego też powinniśmy się upewnić że nasz system nie uruchamia żadnych usług na aliasie wykorzystywanym przez jail’a. Na przykład gdy wykorzystujemy inetd powinniśmy ustawić opcję odpowiedzialną za nasłuchiwanie na wybranym adresie w pliku /etc/rc.conf - w naszym przypadku jest to adres 200.100.50.25.

 

Dla pewności przypomnimy jeszcze raz że powinniśmy tak skonfigurować wszystkie nasze aplikacje aby nie korzystały z adresu przeznaczonego na jail’a.

 

W tym momencie możemy uruchomić powłokę w naszym środowisku jail’owym - w naszym przypadku nadaliśmy mu adres 200.100.50.125.

 

# jail -c path=$D host.hostname=jailed ip4.addr=200.100.50.125 command=/bin/sh

 

Po udanym uruchomieniu powłoki w jail’u powinniśmy dokonać pełnej konfiguracji symulowanego systemu, w taki sam sposób w jaki dokonujemy konfiguracji zwyczajnego systemu. Powinniśmy poustawiać hasło root’a, potworzyć konta użytkowników, zainstalować aplikacje, które chcemy uruchamiać w jail’u oraz napisać skrypty startowe /etc/rc itp.

 

Teraz jesteśmy gotowi na ponowne uruchomienie naszego jail’a. Musimy dodać alias do naszego interfejsu, zamountować procfs do naszego jail’a oraz uruchamić skrypt startowy naszego środowiska jail’owego.

 

# ifconfig ed0 inet alias 200.100.50.125/32
# mount -t procfs proc /jails/myjail/proc
# jail -c path=/jails/myjail host.hostname=jailed ip4.addr=200.100.50.125 command=/bin/sh /etc/rc

 

Te podstawowe czynności zapewniają nam możliwość korzystania z jail’a poprzez uruchomienie w nim wybranych usług. Dla usprawnienia procesu zarządzaniem jail’em możemy wszystko oskryptować.

 

Jail zapewni nam ochronę aplikacji, które w momencie skompromitowania nie będą stanowiły dużego zagrożenia dla naszego systemu. Wszystkie niebezpieczne zdarzenia będą od niego izolowane.

Firewalle.

FreeBSD standardowo udostępnia trzy różne firewalle – IPF, IPFW oraz PF. Aby z nich skorzystać należy załadować moduł jądra z którymś z nich. Na przykładzie PF taka procedura wymaga wczytania modułu jądra – ręcznie:

# kldload pf.ko

lub podczas startu systemu:

# echo 'pf_enable="YES"' >> /etc/rc.conf

 

Oraz ustawienia ścieżki do pliku z konfiguracją:

# echo 'pf_rules="/sciezka/do/pf.conf"' >> /etc/rc.conf

 

A następnie – w przypadku ręcznego załadowania modułu - uruchomienie filtra:

# /etc/rc.d/pf start

 

W ramach tego artykułu nie będziemy się skupiać na obsłudze czy konfiguracji firewalli. Ten temat zostanie omówiony w kolejnym tekscie.

Podsumowanie.

 

Postaraliśmy się naświetlić potencjalne miejsca, w których mogą występować problemy związane z bezpieczeństwem. Pokazaliśmy również w jaki sposób można się przed nimi bronić w systemie FreeBSD. Omówiliśmy zarówno tematykę związaną z ochroną jaki bezpieczeństwem systemu operacyjnego oraz naświetliliśmy różnicę pomiędzy nimi. Tematy zostały omówione w sposób zaledwie sygnalizujący pewne zagadnienia i nie wyczerpują w zagadnień związanych z haredningiem systemów operacyjnych. Zachęcamy do dalszego pogłębiania wiedzy z tej dziedziny.

 

-- Marcin Piotr Pawłowski

Przydatne informacje? Polub nas na facebooku.

Nawigacja
 
Darmowy magazyn o ITsec

zine
Subskrybuj RSS:
RSS