3 Przed i w trakcie instalacji

3.1 BIOS - czyli zanim zaczniesz

Manual Securing Debian mówi:

Before you install any operating system on your computer, set up a BIOS password. After installation (once you have enabled bootup from the hard disk) you should go back to the BIOS and change the boot sequence to disable booting from floppy, CD-ROM and other devices that shouldn’t boot. Otherwise a cracker only needs physical access and a boot disk to access your entire system.

Disabling booting unless a password is supplied is even better. This can be very efective if you run a server, because it is not rebooted very often.

Co można przetłumaczyć mniej więcej tak:

Zanim zaczniesz instalować jakikolwiek system operacyjny na swoim komputerze ustaw hasło w BIOSie. Po instalacji powinieneś zmienić kolejność bootowania uniemożliwiając wystartowanie systemu z dyskietki, płyty CD i innych urządzeń. W przeciwnym wypadku crackerowi wystarczy fizyczny dostęp do maszyny i bootowalny nośnik.

Wyłączenie bootowania przed podaniem hasła jest jeszcze lepszym rozwiązaniem. Może być bardzo efektywne w przypadku serwerów ponieważ nie potrzebują częstych restartów

Zakładając hasło na BIOS należy pamiętać o kilku sprawach:

• Wielu prodeucentów BIOSu udostępnia tak zwane hasła uniwersalne, które umożliwiają obejście hasła wybranego przez użytkownika.
• Domowe PC’ty nie są trzymane w żadnych szafach czy sejfach więc jest do nich bezpośredni dostęp co umożliwia zresetowanie ustawień BIOSu.
• Nigdy nie myśl, że hasło BIOSu jest wystarczającym zabezpieczeniem przed dostępem do konsoli.

3.2 Partycjonowanie

Przystępując do instalacji systemu zawsze, we wcześniejszych bądź późniejszych etapach, stajemy przed problemem partycjonowania. Jak podzielić dysk żeby było dobrze? Jaki katalog na jakiej partycji? Jaki system plików na poszczególne partycje? Jakie rozmiary partycji? Odpowiedź na te i tym podobne pytania nie jest prosta i zależna od innej odpowiedzi: „Do czego będziemy używać systemu?”. Inne rozmiary partycji będą dla serwera www, inne dla shellowego a jeszcze inne dla desktopa. Postaram się naprowadzić Cię trochę i ułatwić podjęcie decyzji jednak nie podam gotowego rozwiązania typu: taki i taki rozmiar tej i tej partycji z takim i takim systemem plików.

Po pierwsze partycjonowanie powinno być przeprowadzone z głową. Nie ma najmniejszego sensu tworzyć osobnych partycji po 10–20MB na katalogi typu /etc, /dev, /mnt, /media.

W systemach wielodostępowych warto stworzyć osobne partycje dla katalogów:

• do których użytkownik ma prawo zapisu: /home, /tmp
• o szybko/często zmieniającej się zawartości: /var (ze szczególnym naciskiem na /var/log)
• przeznaczonych dla niedystrybucyjnego oprogramowania, czyli /opt, /usr/local.

Dlaczego katalogi z podpunktów pierwszego i drugiego warto umieścić na osobnych partycjach? Ponieważ zmniejsza to ryzyko DoS¹ poprzez zapełnienie głównego punktu montowania / co spowodowałoby niestabilną pracę systemu, łącznie z zawieszeniem się. Ktoś może powiedzieć, że jest to nie do końca prawda ponieważ zawsze część dysku jest zarezerwowana dla użytkownika root. Owszem poniekąd tak jest pod warunkiem, że stosujemy system plików z rodziny EXT przy domyślnych ustawieniach mkfs.etxX (gdzie X=2,3,4). Jednak wystarczy sformatować partycję w taki sposób:

mkfs.ext3 -m 0 /dev/hda1

i już nie mamy zarezerwowanej przestrzeni. Domyślnie jest rezerwowane 5% ale tylko domyślnie.

Instalując Debiana i przeznaczając na katalog /var osobną partycję warto pamiętać o pewnym zapasie ponieważ apt przechowuje tam ściągane pakiety (dokładnie w /var/cache/apt/archives).

W przypadku serwerów pocztowych warto dołożyć jeszcze partycję na katalog /var/mail i/lub /var/spool/mail. Nie jest to konieczne, jednak w przypadku zapełnienia przestrzeni dyskowej na partycji z katalogiem /var i podkatalogami może dojść do sytuacji, kiedy logi systemowe nie będą tworzone, zostanie zablokowana możliwość instalacji pakietów oraz mogą wystąpić problemy z uruchamianiem programów korzystających z katalogu /var/run

Jeżeli nie jesteśmy pewni ile dany katalog potrzebuje miejsca, jak szybko (i czy w ogóle) będzie się rozrastał to podczas instalacji warto zainstalować LVM², który umożliwi rozłożenie danego katalogu na kilku dyskach fizycznych.

3.3 Systemy plików

A co z systemem plików? Moim zdaniem powinno się wybierać systemy plików z księgowaniem. Należą do nich: EXT3, ReiserFS, JFS, EXT4, Reiser4³, XFS⁴. Jeżeli katalog /boot znajduje się na osobnej partycji można go sformatować jako EXT2 — uważam, że księgowanie na tej partycji jest zbędne i dodatkowo wydłuża czas startu systemu. Inną ciekawostką jest fakt, iż partycji /boot można nie montować w ogóle. Dlatego w /etc/fstab można usunąć wpis odpowiedzialny za jej montowanie lub dodać opcję noatime,noauto. Katalog /boot musi być zamontowany w momencie gdy instalujemy lub uaktualniamy kernel/bootloader. Podobnie sprawa ma się z katalogiem /tmp. Jeżeli znajduje się na osobnej partycji zastosowanie na niej systemu EXT2, oraz montowanie z opcją noatime umożliwi automatyczne usunięcie zawartości podczas startu systemu.

Jeżeli nie posiadasz zasilacza UPS to odradzam stosowanie XFS. Nieoczekiwana utrata zasilania lub inna awaria i dane mogą zostać bezpowrotnie utracone. Jeżeli posiadasz UPS to możesz możesz wybrać XFS musisz jednak pamiętać o robieniu częstych kopii bezpieczeństwa. Dla serwerów bardzo często poleca się stosowanie systemu EXT3 ze względu na kompatybilność wsteczną z systemem EXT2, z którego stosunkowo łatwo można odzyskać dane. Drugim systemem, z którego można w miarę bezboleśnie odzyskać dane jest ReiserFS⁵.

3.4 Podłączenie do sieci

Czytając maunal bezpieczeństwa znajdziemy tam mniej więcej takie zdanie:

Komputer na którym instalujemy system nie powienien być podłączany do sieci tak szybko jak to możliwe.

Stwierdzenie to może wydawać się śmieszne zwłaszcza gdy instalacja z nośników typu netinstall czy businesscard jest stosunkowo powszechna. Zapytasz zapewne to jak z obrazu netinstall/businesscard zainstalować system? Odpowiedzią może być mirror w lokalnej sieci. Przy korzystaniu z płyt netinstall można spokojnie bez dostępu do sieci zainstalować system. Na tej płytce znajduje się minimalny system gotowy do pracy tuż po instalacji. Innym rozwiązaniem jest ściągnięcie pierwszej płyty CD/DVD i zainstalowanie systemu z niej. Dlaczego nie zaleca się instalacji z połączeniem do sieci globalnej? Ponieważ pakiety zawarte na płytce, z której korzystasz mogą mieć niezałatane luki bezpieczeństwa (mogły nie być znane w trakcie tworzenia obrazu). Jeżeli maszyna na której instalujesz system znajduje sie za NATem to nie musisz, aż tak bardzo brać sobie do serca tego punktu.

Inną zaletą instalacji bez dostępu do sieci jest to, że nie zostaną zainstalowane pakiety oznaczone w zależnościach jako recommended czy suggested. Im mniej zbędnych aplikacji/pakietów tym mocniej ograniczamy ryzyko kompromitacji systemu.

Należy pamiętać o tym, że już podczas instalacji z dostępem do sieci system może zostać skompromitowany (całkowicie lub częściowo), zwłaszcza przy bezpośrednim połączeniu.

3.5 Hasła

Jedną z podstawowych metod zabezpieczenie dostępu do komputera jest ustawienie skomplikowanego hasła, ale łatwego do zapamiętania. Dla użytkownika root hasło powinno być wyjątkowo skomplikowane.

Dobrze dobrane hasło POWINNO zawierać małe i wielkie litery (w systemach Unixowych są one rozróżniane), znaki specjalne typu

!@#$%^&*()_|:;<>

oraz cyfry. Niektórzy twierdzą, że wystarczą znali specjalne lub cyfry jednak ja jestem zwolennikiem umieszczania jednych i drugich w hasłach. Odradzam też stosowanie tak zwanego leet speak⁶ do ustawiania haseł. Przy atakach słownikowych na hasła takie opcje też są brane pod uwagę.

Hasłem NIE POWINNO być:

• własne imię
• imię współmałżonka czy partnera
• imię dzieci
• imię domowego zwierzaka
• data urodzenia czy zlepek dat
• inne łatwe do skojarzenia z naszą osobą

Niektóre „szkoły”⁷ mówią , że jedną z ciekawszych metod doboru hasła jest zapisanie jakiegoś długiego, ale łatwo zapadajacego w pamięc zdania i wybranie co n-tej litery (lub pierwszych liter wyrazów) i/lub zastąpienie pewnych liter cyframi, np:

"Ojciec Chrzestny" to bardzo dobry film na podstawie książki Mario Puzo

"OC"7bdfnpkMP

i inne wariancje.

W Debianie hasła, a właściwie ich skróty, domyślnie tworzone są w oparciu o funkcję MD5. Niestety mimo, iż umożliwia używanie haseł dłuższych niż 8 znaków (poprzednie funkcje haszujące⁸ ograniczały długość hasła do 8 zaków) już nie jest tak bezpieczna. Developerzy dystrybucji takich jak Gentoo, Ubuntu czy Fedora Core porzucili MD5 na rzecz SHA512. Po zakończeniu instalacji bardzo łatwo możemy zmusić system do używania innej funkcji skrótu. Wystarczy edytować plik: /etc/pam.d/common-password, znaleźć w nim linijkę:

password required pam_unix.so nullok obscure min=4 max=8 md5

i zastąpić wpisem:

password required pam_unix.so nullok obscure min=4 max=8 sha512

Dopóki w systemie nie mamy dodanych nowch użytkowników nie musimy się niczym przejmować, ale gdy już mamy dodane konta to trzeba zmusić użytkowników do zmiany hasła. Najprościej dokonać tego wydając polecenie:

chage -d 0 login

Gdzie login zastępujemy nazwą użytkownika.

Warto jeszcze przyglądnąć się bliżej parametrom min i max określają one minimalną oraz maksymalną długość hasła.

Bardzo ważne jest regularne zmienianie haseł — min co 30 dni. Może wydawać się to uciążliwe, ale nie możemy o tym zapomnieć. Na szczęście Debian, a właściwie mechanizm PAM, może to na nas wymuszać. Wyedytujmy plik /etc/pam.d/login i dopiszmy do niego takie linijki:

password required pam_cracklib.so retry=3 minlen=12 difok=3
password required pam_unix.so use_authtok sha512

Co to daje? Otóż pierwsza linijka załaduje bibliotekę cracklib mechanizmu PAM, która będzie pytać o nowe hasło o minimalnej długości 12 znaków, różniące się o minimum 3 znaki od poprzedniego i będzie pozwalać tylko na 3 próby wpisania nowego hasła. Druga linijka odpowiada za ładowanie standardowego modułu autentykacji SHA512

UWAGA! cracklib jest zależne od pakietów słownikowych: wpolish, wenglish, wspanish, ect więc przed wprowadzeniem tych zmian należy zainstalować odpowiednie słowniki.

Aby system przypominał nam o konieczności zmiany hasła musimy lekko zmodyfikować plik /etc/login.defs. Zmiany wymagają parametry: PASS_MAX_DAYS oraz PASS_WARN_AGE. Oba przyjmują wartości liczbowe. Pierwszy to maksymalna liczba dni jakie mogą upłynąć między zmianami hasła. Drugi określa na ile dni przed wygaśnięciem hasła mają zacząć się pojawiać przypomnienia o konieczności jego zmiany.

3.6 Minimalizacja

Podczas instalacji systemu wybierajmy tylko to oprogramowanie, które jest nam niezbędne do pracy/użytkowania i tylko wymagane zależności. Jak wspomniałem wcześniej im mniej oprogramowania tym mniejsze ryzyko wykorzystania przez atakującego luk w nim zawartych. W Debianie do wyboru mamy dwa podstawowe narzędzia do zarządzania oprogramowaniem: apt-get oraz aptitude. Pierwszy domyślnie NIE instaluje paczek, które w drzewie zależności są zaznaczone jako suggested lub recommended, natomiast aptitude instaluje te zależności. Jeżeli nie korzystamy z interfejsu ncurses aptitude to kwestię instalacji dodatkowych pakietów załatwimy wpisując:

aptitude --without-recommends --without-suggests install pakiet

Jeżeli jednak nie możemy się obejść bez „okienkowego” aptitude to po jego uruchomieniu wyłączamy instalację zbędnych pakietów przez:

Opcje → Zależności

i odznaczamy:

Automatyczna instalacja rekomendowanych pakietów

Kolejnym krokiem jest wyłączenie zbędnych usług. Usługi to programy typu serwer ftp/www, które (na ogół) non stop nasłuchują przychodzących połączeń i pozwalają zewnętrznym maszynom na dostęp do Twojego komputera. Po raz kolejny powtórzę: nie instalujemy usług, z których nie korzystamy. Jeżeli już potrzebujemy co jakiś czas dostać się do, powiedzmy, serwera ftp to należy go uruchamiać ręcznie przed skorzystaniem z niego i zaraz po zakończeniu transferu wyłączyć. Jeżeli podczas instalacji nie skorzystaliśmy z opcji „expert” to w systemie mamy usługi takie jak: Exim czy maper portów RPC⁹ (niezbędny dla usług typu NFS). Każda usługa może działać albo w trybie inetd albo w trybie daemon.

Usługi daemon działają jako samodzielne programy, same bindują gniazda TCP/UDP, i można je kontrolować przez /etc/init.d. Ponad to są uruchamiane przy starcie systemu, domyślnie na każdym runlevelu, a symlinki do nich umieszczane są w katalogach /etc/rcX.d/, którymi zarządza SysVinit lub jego odpowiednik.

Usługi inetd bindują gniazda/porty dopiero wtedy gdy nadejdzie odpowiednie żądanie. Nasłuchem i zarządzaniem żądań zajmuje się serwer RPC.

„Spis” wszystkich usług działających w trybie na żądanie znajduje się w pliku /etc/inetd.conf.

Wszystkie rc-skrypty znajdują sie w katalogach /etc/rcX.d/ gdzie X to numer odpowiedniego runlevelu. Usługi można wyłączyć na kilka sposobów.

Pierwszy: ręczny i mało elegancki polega na zmianie nazwy skryptu startowego w odpowiednim katalogu. Skrypty usług uruchamianych przy starcie systemu rozpoczynają się od litery S. Nazwy tych które nie mają być uruchamiane zaczynają się od K. Skryptów z katalogów /etc/rcX.d nie należy usuwać ponieważ i tak zostaną przywrócone przy aktualizacji/reinstalacji pakietu.

Drugi: użycie narzędzia update-rc.d lub jego odpowiednika z interfejsem w ncurses **8sysv-rc-conf***. Używanie tego drugiego sprowadza się do zaznaczenia/odznaczenia usług(i), do zatrzymania/uruchomienia.

Mając już zainstalowany system powinniśmy się zastanowić czy na pewno potrzebujemy usług inetd, a jeżeli tak to jakich. W starszych wersjach kernela usługi działające w trybie inetd miały „nadrabiać” jego niedociągnięcia. Dzisiaj są tylko kolejną furtką do ataku (czy to świadomego przeprowadzonego z zewnątrz, czy przypadkowego spowodowanego przez nieumyślnego użytkownika lokalnej maszyny) DoS. Większość użytkowników preferuje jednak usługi samodzielne. Jeżeli jednak chcesz żeby część usług działała jako inetd to warto zmienić ich zarządcę. Daemon xinetd, rlinetd czy openbsd-inetd mają dużo większe możliwości konfiguracji. Aby zabezpieczyć system powinniśmy wyłączyć zbędne usługi inetd takie jak: echo, chargen, discard, daytime, time, talk, ntalk i przede wszystkim usługi zdalne typu: rsh, rlogin, rcp, telnet. Te ostatnie są uważane ze wyjątkowo niebezpieczne i zamiast nich poleca się używanie ssh,scp. Wyłączenia usług inetd można dokonać na dwa sposoby:

• mało wygodną ręczną edycję pliku /etc/inetd.conf
• wykorzystując update-inetd

np:

update-inetd --disable telnet

Po raz kolejny słów kilka o instalacji oprogramowania. W systemie po świeżej instalacji znajduje się kilka pakietów developerskich. Jeżeli nie jesteś programistą, nie zamierzasz nic kompilować to powinieneś usunąć te pakiety. Narzędzia typu kompilatory, interpretery o debuggery ułatwiają uruchaminie exploitów (można je skompilować i/lub przetestować). Oczywiście jeżeli cracker ma konto shell może wykorzystać narzędzia i polecenia powłoki do kompromitacji systemu. W takim wypadku usunięcie zbędnego oprogramowania nie uniemożliwi takiego ataku ale znacznie go utrudni. Poniższe pakiety znajdują się w systemie (przy instalacji wydania testowego z płyty netinstall bez dostępu do sieci):

• gcc-4.2-base
• gcc-4.3-base

Są to pakiety należące do grupy developerskich i znajdują się w systemie tylko dlatego, że posiadają priorytet Standard. Jeżeli nie zmierzasz kompilowac (jądra, sterowników dla kart graficznych/sieciowych etc) to można je śmiało usunąć. Zmniejszamy ilość potencjalnych dziur w systemie i dodatkowo możemy zwolnić trochę miejsca na dysku (co prawda ten drugi argument przy pojemności dzisiejszych dysków twardych nie jest zbyt przekonujący, ale zawsze jakieś „za”).

Propozycja dla zaawansowanych użytkowników, którzy potrafią pisać poważne skrypty powłoki oraz mają manię na punkcie bezpieczeństwa. Można pokusić się o usunięcie z systemu perla. Jednak nie jest to takie proste. Sporo plików, w tym krytycznych dla systemu, to skrypty perlowskie. Jeżeli bardzo byśmy chcieli usunąć perla to najpierw musimy przepisać wszystkie skrypty. Listę skryptów napisanych w perlu uzyskamy wydając polecenie:

for i in /bin/* /sbin/* /usr/bin/* /usr/sbin/*;do [ -f $i ] && {type=‘file $i |grep -il perl‘;[ -n "$type" ]&&echo $i;};done

Jak widać lista jest długa. Dlateg należy się poważnie nad tym zastanowić, ponieważ w pewnym momencie może się okazać, że mamy do przepisania połowę skryptów systemowych i połowę skryptów używanych przez zainstalowane usługi. Osobiście odradzam takie rozwiązanie — no chyba, że jesteś geekiem i cierpisz na nadmiar wolnego czasu.

---

1. DoS — Denial of Service, więcej na: http://pl.wikipedia.org/wiki/DoS
2. Logical Volume Manager — http://pl.wikipedia.org/wiki/LVM
3. EXT4 i Reiser4 ciągle są w fazie testów.
4. XFS jest systemem plików z księgowaniem metadanych,co może się wiązać z utratą danych — http://pl.wikipedia.org/wiki/XFS
5. krótki poradnik jak to zrobić jest dostępny pod tym adresem:
   
   http://dug.net.pl/tekst/15/reiserfs___odzyskiwanie_danych
6. http://pl.wikipedia.org/wiki/Leet
7. Dobre hasło:
   
   http://drfugazi.eu.org/index.php?page=diceware
   
   http://bromirski.net/docs/tutorials/gen_hasel.html
8. http://en.wikipedia.org/wiki/Hash_function
9. RPC — Remote Procedure Call, http://pl.wikipedia.org/wiki/RPC

---

Wstecz | Spis treści | Dalej