1. Przyjąć do wiadomości, że można obronić się przed większością ataków z Internetu, gdyż ich autorami są najczęściej niewyszkolone osoby, których cała wiedza ogranicza się do umiejętności odpalenia atakujących skryptów (kiddie scripts, exploity). Przy niestandardowym zabezpieczeniu systemu te schematyczne narzędzia po prostu się gubią.

    
   *     *     *

    
   

2. Docenić rolę zabezpieczeń pozornie drobnych, które jednak w swojej liczbie mogą znacznie utrudnić atak i w konsekwencji zniechęcić intruza.

    
   *     *     *

    
   

3. Należy pilnować, aby na Twoim serwerze była zainstalowana najnowsza, stabilna wersja zarówno jądra systemu, jak i konkretnego oprogramowania. Instrukcję aktualizowania Mandrake opisałem na sąsiedniej stronie pt. ZARZĄDZANIE punkt AKTUALIZACJA. Uwaga: jeżeli nie masz w pobliżu osoby znającej się na aktualizacji jądra systemu, to nie rób tego samodzielnie, gdyż źle wykonane obniża bezpieczeństwo i funkcjonalność całego systemu.

    
   *     *     *

    
   

4. Zabezpieczyć fizycznie komputer i nie lekceważyć zagrożenia wypływajacego ze strony różnych cwaniaczków, którzy współpracują z Tobą i mają fizyczny dostęp do komputera. Mogą oni z dyskietki lub płytki CD odpalić np. małego Linuksa. Rozwinę nieco ten wątek. Nie każdy zdaje sobie sprawę, że przy wyłączonym komputerze wszystkie zabezpieczenia są nieaktywne, gdyż po prostu są zwykłymi danymi. Jeżeli uda się nam podpiąć taki dysk do innego systemu, to bez problemu uzyskamy możliwość penetracji i poprawiania jego ustawień, a nawet czyszczenia haseł (poprzez zmianę zawartości niektórych plików). Jak niebezpieczne są to narzędzia, niech świadczy przykład Linuksa przystosowanego do kasowania/łamania haseł w Windows 2000, XP, NT (nawet administratora) instalowanych na partycji NTFS. Inna technika przejmowania komputera kontrolowanego przez WindowsXP, to włam z wykorzystaniem portu FireWire. Więcej na stronie: www.pcworld.pl/news/142551.html.

   Aby uchronić się przed przejęciem kontroli nad komputerem przez osobę mającą bezpośredni (fizyczny) dostęp do maszyny należy:

   • Zamykać na klucz pomieszczenie z komputerem.
   • Ustawić BIOS tak, aby system startował wyłącznie z dysku twardego (wykluczyć bootowanie z flopka, CD-ROM, USB) i co za tym idzie zainstalować bootloadera na dysku. Aby utrudnić przestawienie BIOSu należy obowiązkowo zabezpieczyć go hasłem. Uwaga: istnieja tzw. hasła uniwersalne dla BIOSów poszczególnych producentów (Award, Ami itp.). Pełną listę takich haseł znajdziesz tutaj. Jeżeli link nie zadziała to możesz pobrać kopię tamtej witryny z moich rezerw. Uniwersalne hasła BIOSu umie wygenerować "ratunkowy" Linux np. opisany na sąsiedniej stronie Ultimate Boot CD. Pamiętaj, że włamywacz może też odkręcić obudowę, wyjać bateryjkę (lub przestawić zworkę) i skasować hasło. Ta metoda zostawi jednak ślady włamania w postaci braku hasła na BIOSIe serwera :-)
   • Usunąć z komputera czytnik CD-ROM oraz flopka 1,44, by uniemożliwić odpalenie Linuksa ratunkowego. Uwaga! Istnieje możliwość uruchomienia zewnętrznego czytnika CD-ROM, dysku twardego lub flopka za pośrednictwem łącza USB (nie wspominając o Pen Drive na USB). Wskazane jest więc zaślepić łącze USB na serwerze.
   • Usunąć z LILO etykietę Linux-failsafe, która umożliwia odpalenie systemu pod rootem bez podawania hasła. Edycję pliku /etc/lilo.conf wykonasz za pomocą dowolnego edytorka np. mcedit lub okienkowym narzędziem drakboot lub mcc (wiersz BOOT CONFIGURATION).
   • Zabezpieczyć bootloadera LILO (dotyczy serwera startujacego z dysku, nie z dyskietki) poprzez: dopisanie do pliku /etc/lilo.conf minimum dwóch ważnych wierszy:
     PASSWORD=haslo
     RESTRICTED
     Parametr RESTRICTED ma na celu złagodzenie wymagań LILO: podanie hasła będzie konieczne jedynie w przypadku, gdy podczas ładowania do systemu przekazywane będą parametry. Pamiętaj, by po każdej edycji pliku lilo.conf wydać komendę lilo, która zaktualizuje ustawienia bootloadera.
   • Zadbać, aby dostęp do pliku /etc/lilo.conf miał wyłącznie administrator, poprzez polecenie: chmod 600 /etc/lilo.conf
     Uwaga: zlecenie chattr +i /etc/lilo.conf blokuje nawet rootowi wprowadzanie zmian. Zdjęcie zabezpieczenia wykonasz poleceniem: chattr -i /etc/lilo.conf

     O tworzeniu dyskietki startowej z LILO przeczytasz tutaj, natomiast o tworzeniu kopii MBR napisałm kilka słów na sąsiedniej stronie. Przykład pliku /etc/lilo.conf znajdziesz tutaj. Opis opcji LILO umieściłem na stronie pt. bootloader.php.

      
     *     *     *

      
     

5. Aby zabezpieczyć się przed domownikami i uniemożliwić wykonanie restartu [Alt]+[Ctrl]+[Del], należy wyedytować plik /etc/inittab i zamienić linię:
   ca::ctrlaltdel:/sbin/shutdown -t1 -a -r -now
   na np.:
   ca::ctrlaltdel:/bin/echo "Po co wciskasz restart komputera?!?"
   Po zastosowaniu powyższych zmian naciśnięcie stosownych klawiszy spowoduje tylko wypisanie odpowiedniego komunikatu. Oczywiście spytasz się: no i co z tego, że nie będzie można teraz restartować komputera??? Ano nie wiesz, że taki restart przy pomocy kombinacji klawiszy CTRL+ALT+DELETE jest pierwszym krokiem do przejęcia praw roota. Jak to się robi? Zapraszam na stronę o sztuczkach.

   Oczywiście, na komputerze klienckim w biurze (ale nie na serwerze!) można zastosować wpis: ca::ctrlaltdel:/sbin/halt -p . Umożliwi to zatrzymanie systemu bez podania hasła roota. Przypominam, że w takich okolicznościach pierw skrótem klawiszowym CTRL ALT BACKSPACE zabijamy okienka, a następnie skrótem CTRL ALT DELETE kończymy pracę.

    
   *     *     *

    
   

6. Hasło - to newralgiczna część bezpieczeństwa systemu. Należy często je zmieniać (zwłaszcza hasło administratora). Czemu? Podam jeden z kilku powodów: przyjmijmy, że intruz przechwycił hasło roota z pliku /etc/shadow (np. edytując go za pomocą zewnętrznego Linuksa ratunkowego). Uzyskał zaszyfrowane hasło za pomocą md5. Wystarczy teraz, że za pomocą prostego skryptu w c++ sprawdzi wygląd md5 atakiem słownikowym lub siłowym. Jeżeli hasła będą często zmieniane (nawet gdy administrator uważa, że nie ma podstaw do obaw), to skrypt może nie zdążyć odkryć długiego, niesłownikowego hasła. Przykład mocnego hasła dla roota: oyTre17[P;]aftsj39T.
   
   Podczas tworzenia hasła należy bezwzględnie kierować się poniższymi zasadami:
   • Używać mieszaniny liczb, znaków specjalnych oraz liter wielkich i małych
   • Używać przynajmniej ośmiu znaków
   • Używać liter i liczb, które wydają się przypadkowe, a są łatwe do zapamiętania dla właściciela
   • Nie używać nazw osób lub rzeczy
   • Nie używać żadnego słowa polskiego, obcego lub skrótu
   • Nie używać żadnej informacji zwiazanej z kontem (nazwa użytkownika, inicjały, numer telefonu, data urodzin, numer pokoju itp.)
   • Nie używać kolejnych klawiszy na klawiaturze (np. qwerty)
   • Nie używać żadnej z wyżej wymienionych rzeczy wypisanych w odwrotnej kolejności, wielkimi literami lub ukrytej w inny sposób
   • Nie używać haseł składających się z samych cyfr
   • Nie używać przykładowego hasła znalezionego w jakiejkolwiek publikacji
   
   Przestrzegajac tych zasad unikniesz problemów podczas tzw. ataku słownikowego lub siłowego.

   
   *

   
   

   Hasła ukryte.
   Wyjaśnienie: w systemie Linux hasła tradycyjnie przechowywane są w postaci zaszyfrowanej w pliku /etc/passwd. Z tego pliku korzystają często programy, więc jego prawa dostępu pozwalają na odczyt wszystkim użytkownikom. Istnieje jednak możliwość zastosowania systemu haseł ukrytych, które znajdują się w osobnym pliku /etc/shadow, do którego dostęp ma jedynie administrator. Jeżeli w Twoim systemie nie jest wykorzystywana funkcja haseł ukrytych, użyj poleceń:
   • pwconv
     oraz
   • grpconv
   Przekonwertujesz w ten sposób hasła znajdujące się w plikach /etc/passwd oraz /etc/group do postaci ukrytej w plikach /etc/shadow oraz /etc/gshadow.
   Uwaga: w nowych dystrybucjach Linuksa ten sposób zabezpieczania haseł jest już standardowo instalowany.

   Polecam przeczytać notatkę o zleceniu useradd w części dotyczącej haseł.

    
   *     *     *

    
   

7. Opcja umożliwiająca używanie haseł długich.
   Wyjaśnienie: standardowa, maksymalna długość hasła w systemie to pierwotnie 8 znaków. Może być także krótsze, w zależności od ustawień w pliku /etc/login.defs. Aby móc używać haseł dłuższych, należy zastosować algorytm szyfrowania MD5. Wiele dystrybucji ma tę opcję włączoną automatycznie, a jeżeli tak nie jest, wyedytuj plik /etc/login.defs i wstaw wiersz:

   "MD5_CRYPT_ENAB yes"

   W systemie Red Hat i Mandrake możesz w tym celu skorzystać z polecenia authconfig . Uwaga: w nowych dystrybucjach Linuksa ten sposób zabezpieczania haseł jest już standardowo instalowany.

    
   *     *     *

    
   

8. Możliwość bezpośredniego logowania roota w shellu zarówno poprzez sieć (np. połączeniem ssh) jak i bezpośrednio z terminala (lub okienkowego pseudo-terminala) jest fatalnym pomysłem. W przypadku połączeń sieciowych (np. ssh) należy tak ustawić opcje konfigu demona (np. sshd), by pierw wymusić logowanie na zwykłego usera, a dopiero potem na roota (lub zastąpić hasła kluczami). Temat takiego logowania jest szerzej rozwinięty na stronach opisujących dany program (np. sshd).
   
   Pozostała więc do wyjaśnienia kwestia logowania bezpośrednio z terminala.
   
   W Linuksie Mandrake istnieje zestaw skryptów pod nazwą MSEC, których zadaniem jest między innymi blokowanie możliwości bezpośredniego logowania na roota (w 4-WYŻSZYM Poziomie Bezpieczeństwa).
   
   Należy także wyedytować plik /etc/securetty i upewnić się, że jest pusty. Jeżeli są w nim wpisy, to bardzo źle. Plik ten zawiera nazwy urządzeń (po jednym urządzeniu w jednym wierszu wpisu) z użyciem których root może się bezpośrednio zalogować. Oto przykład pliku /etc/securetty:
   
   tty1
   tty2
   vc/1
   vc/2
   
   tty? to terminal o określonym numerze
   pty to pseudoterminal (okienkowy terminal) z ang. pseudo-tty
   vc/? to urządzenie devfs
   We wpisach nie umieszczamy pełnej ścieżki do urządzeń (np. /dev/*).
   
   Polecam przy okazji przeczytać notatkę o PAM.

    
   *     *     *

    
   

9. Pamiętaj o systematycznym usuwaniu pliku .bash_history (lub jego zawartości) znajdującego się w Twoim katalogu domowym (np./home/antek/.bash_history) oraz /root/.bash_history , gdyż istnieje prawdopodobieństwo, że może się w nim znaleźć Twoje hasło! Zapytasz jak? Jeżeli nie umiesz bezwzrokowo klepać po klawiaturze, a śpieszysz się, to w chwili nieuwagi zamiast polecenia np. su wpiszesz bezmyślnie od razu hasło roota. Zamiast sprawdzić na monitorze co wpisałeś - wciskasz ENTER... i polecenie (w postaci tekstu hasła) utrwalone zostało w pliku /home/antek/.bash_history
   Plik ten może być automatycznie usuwany/czyszczony w chwili wylogowywania się z systemu, jeżeli dodasz do pliku .bash_logout w katalogu domowym wiersz:
   rm -f $HOME/.bash_history lub rm -f ~/.bash_history
   ewentualnie wiersz:
   clear

   Wyjaśnienie: kropka przed nazwą pliku oznacza, że ma on atrybut ukrycia. Dla własnego bezpieczeństwa sprawdź, czy wpis w pliku .bash_logout działa. Jeżeli nie, to po prostu ręcznie usuwaj plik .bash_history lub co lepsze edytuj go i usuwaj zawartość. Jeżeli używasz MC, to sprawdź zawartość katalogu .mc

   Sprawdzaj też pliki tego typu w katalogu /root ;)

   
   
   Pamiętaj, że w Mandrake/Mandriva narzędzie msec dodatkowo nadzoruje ilość wpisów historii shella. W szczególności zwróć uwagę na plik /usr/share/msec/msec.py

    
   *     *     *

    
   

10. Sprawdzić, czy kluczowe katalogi mają właściwe prawa dostępu.
    
    
    Posiadaczy Mandrake/Mandriva zapraszam na sąsiednią stronę zawierającą szczegółowy wykaz praw własności ustalanych zleceniami: msec 3, 4, 5. Jeżeli masz wątpliwości, czy Twój Mandrake/Mandriva ma prawidłowe ustawienia plików i katalogów to warto poczytać. Jeżeli chcesz znać przeznaczenie głównych katalogów Linuksa, to przeczytaj stronę: systemyplikow.php#punktymontowania.

    Poniżej przedstawiłem skróconą, w porównaniu z w/w dokumentem propozycję praw dla Mandrake 8.1 (wersja serwerowa).

    Wejdź (jako root) do katalogu głównego zleceniem cd / i wpisz ls -la . Porównaj swój wydruk (na ekranie) do poniższego ustawienia. Uwaga, moja propozycja jest dosyć restrykcyjna i może w wyjątkowych okolicznościach zablokować pracę jakiegoś demona. Przed wprowadzaniem zmian zapisz więc sobie na kartce pierwotne ustawienia.

    /archiwum   drwx --- --- root.root
    /boot   drwx --- --- root.root
    /bin   drwx --x --x root.root
    /boot   drwx --- --- root.root
    /dev   drwx --x --x root.root
    /etc   drwx --x --x root.adm
    /home   drwx r-x --x root.adm
    /initrd   drwx r-x r-x root.root
    /lib   drwx r-x --x root.adm
    /lost+found   drwx r-x r-x root.root
    /mnt   drwx r-x --- root.adm
    /opt   drwx r-x --x root.root
    /proc   dr-x r-x r-x root.root
    /root   drwx --- --- root.root
    /sbin   drwx r-x --x root.adm
    /SWAP   drwx r-x r-x root.root
    /tmp   drwx rwx -wt root.root
    /usr   drwx r-x --x root.adm
    Uwaga: wewnątrz /usr katalogi mają drwxr-x--x poza domyślnie ustawionymi /usr/doc i /usr/man)
    /var   drwx r-x r-x root.root
    Uwaga: wewnątrz /var podkatalog /var/log musi posiadać drwx --x --x
    Uwaga: wewnątrz /var podkatalog /var/portsentry powinien posiadać drwx --- ---
    Uwaga: wewnątrz /var pozostałe podkatalogi posiadają drwx r-x r-x (nie zwracamy uwagi na tmp, lock, catman, apache-mm, które można zostawić w zastanych opcjach)

    Zaleca się, aby tylko root miał pełne prawa dostępu do następujących katalogów: /etc , /var/log/ , /sbin , /lib , /boot, /root oraz ew. /archiwum
    Natomiast grupa oraz pozostali użytkownicy mogą mieć jedynie prawo wykonywania, czyli wejścia (i uruchomienia pliku) bez prawa wyświetlania zawartości katalogu. Takie prawa ustalane są poleceniem chmod 711 /nazwakatalogu

    
    
    
    W Mandrake można łatwo ustalić prawidłowe prawa do katalogów wpisując jako root msec 4 (ustalisz czwarty poziom, czyli dla serwerów).

    Uwaga: jeżeli zainstalowałeś Mandrake (od wersji 9.x) lub Mandriva i wybrałeś podczas instalacji WYŻSZY(4) - dla serwerów POZIOM BEZPIECZEŃSTWA (lub dałeś zlecenie msec 4), to podczas KAŻDEGO restartu - system wyzeruje (między innymi) prawa do newralgicznych katalogów zapewniając najwyższe bezpieczeństwo. Niestety, przy okazji zablokuje niechcąco np. użytkowników prywatnych z własnymi kontami www, ftp (trzeba wtedy wydać jako root polecenie chmod 711 /home/antek). Przeczytaj moją stronkę o POZIOMACH BEZPIECZEŃSTWA i proponowanym tam sposobie rozwiązania problemu.

    Zwróć uwagę na parametry montowania poszczególnych partycji. W pliku /etc/fstab można narzucić maksymalne prawa dostępu, głównie dla urządzeń typu: flopek, CD-ROM, partycja windowsowa. Przykładowo parametr umask=077 daje prawa 700 (rwx --- ---). Więcej znajdziesz na sąsiedniej stronie.

    Pamiętaj o błędzie KDE w Mandrake 8.1 - samo kliknięcie w napis MADRAKE CONTROL CENTER- BEZPIECZEŃSTWO zablokuje SDI-HISa.

     
    *     *     *

     
    

11. Bezpieczeństo Linuksa to szereg działań podjętych nie tylko w czasie instalacji, eksploatacji. Ważny jest także etap dzielenia dysku i sposób montowania partycji. Tutaj poruszamy się po terenie nieznanym użytkownikom Windows, którzy na dobrą sprawę mogli na całym dysku założyć 1 dużą partycję (o ile BIOS nie robił wstrętów) i normalnie pracować. Dzieląc dysk na linuksowe partycje musimy odpowiedzieć sobie na kilka pytań: jak dużo programów zainstalujemy, czy logi będą duże, czy konta ftp, www będą tylko publiczne, czy zezwolimy na prywatne konta userów Linuksa. Podział dysku ułatwi w przyszłości reinstalację systemu. Problem podziału dysku na partycje został szczegółowo opisany na sąsiedniej stronie pt. podzialdysku.php
    
     

     
    *     *     *

     
    

    
     
12. Jako admin bądź czujny. Mając na pokładzie serwery Apache, ProFTPd itd., możesz stać się ofiarą włamu poprzez exploita - osobiście widziałem, jak poprzez port 21 (proftpd) w ciągu kikunastu sekund intruz przejął prawo roota. Oczywiście nie należy załamywać rąk i trzeba przygotować się odparcia takiego ataku. Ponieważ największym zagrożeniem stanie się możliwość zmian w konfiguracji systemu, wskazane jest tak skonfigurować Linuksa, by... nawet root nic nie mógł zrobić. Oczywiście Ty będziesz wiedział co zabezpieczyłeś (i jak), więc Ty sobie poradzisz, ale obcy nie ;) Przyjmuję, że przeczytałeś sąsiednią stronę o podziale dysku oraz restrykcyjnych opcjach montowania partycji i zabezpieczyłeś partycje montowane jako: /usr , /var , /var/www , /var/ftp , /home itd.

    Co robi włamywacz po przejęciu praw roota? Jeżeli nie zniszczy systemu tak dla jaj, to prawdopodobnie będzie próbował bezczelnie zmienić zawartość plików konfiguracyjnych serwera apache, proftpd itd., a następnie... założy inny (nowy) katalog w dowolnym miejscu np. w /tmp do którego wszyscy mają dostęp (rozumiesz więc, że prawa i sposób mnotowania innych katalogów np. /tmp też powinny być ustalone restrykcyjnie). Po takich zabiegach serwer zacznie udostępniać w Internecie nowe, podmienione pliki z nowego katalogu, a stare będą sobie bezużytecznie leżeć w katalogu macierzystym :[ W ten sposób podmienia się strony serwisów www lub zawartość kont ftp, gdy administrator przebiegle zamontował partycje z danymi serwerów w trybie ro.

    Wejdź na chwilę w skórę włamywacza. Jest to prawdopodobnie gówniarz, który dorwał się do exploitów i im zawdzięcza swoje sukcesy. Jako niedouczony gostek stanie bezradnie w obliczu nietypowych zabezpieczeń, których nie przewidział twórca exploita. Wykorzystamy to i zabezpieczymy się nietypowo :)

    Moim pomysłem rozwiązującym opisany powyżej problem przekonfigurowania ustawień serwera apache, proftpd jest jednoczesne zastosowanie kliku czynności: użycie zlecenia chattr, pozbycie się (lub uszkodzenie) pliku /usr/bin/chattr oraz zamontowanie partycji /usr w trybie ro (tylko do odczytu - ten wątek rozwinąłem na sąsiedniej stronie). Najchętniej zamontowałbym cały katalog /etc na osobnej partycji w trybie ro (tylko do odczytu), ale niestety system podczas startu się wówczas zawiesza. Tak więc wykonujemy po kolei:

    
     

    • UŻYCIE ZLECENIA chattr. W katalogu /etc (i jego podkatalogach) sprawdź, czy masz interesujące Ciebie pliki konfiguracyjne:
      
      /etc/httpd/conf/*.conf
      /etc/proftpd.conf
      /etc/lilo.conf
      /etc/samba/*.conf
      /etc/security/*.*
      /etc/shorewall/*
      /etc/dhcpd.conf
      Jeżeli chcesz zabezpieczyć się przy okazji bardziej radykalnie to odszukaj:
      /etc/cron*
      /etc/host*
      /etc/grou*
      /etc/passw*
      /etc/shado*

      Gdy ustaliłeś listę plików do zablokowania, wydaj zlecenie:

      chattr +i /etc/nazwapliku
      i... od teraz nic w danym pliku nie zmienisz (nawet jako root) oraz go nie usuniesz. Ponieważ zablokowano plik /etc/passw* oraz /etc/shado*, więc nie będzie można zmienić hasła ani dodać nowego usera.
      Oczywiście jest bardzo kłopotliwym zakładanie zabezpieczeń po kolei każdemu plikowi z osobna, dlatego proponuję robić to grupowo, prostym skryptem. Nie zapomnij nadać właściwych praw: root.root 750. Zdejmujemy wówczas zabezpieczenia drugim skryptem. Szybko, łatwo i... skutecznie :) Zwróć uwagę, że przy okazji w ten sposób zabezpieczysz się przed... bezczelnym skasowaniem całego katalogu /etc (u mojego znajomego tak zrobił włamywacz).
       
    • POZBYCIE SIĘ PLIKU /usr/bin/chattr. Powyższe rozwiązanie już powinno wystarczyć na prymitywnie działające exploity, jednak Ty jestes adminem-paranoikiem, więc boisz się, że włamywacz będzie miał trochę oleju w głowie i... domyśli się, iż użyłeś zlecenia chattr. Inaczej mówiąc, boisz się, że po przejęciu praw roota da on zlecenie chattr -i /etc/nazwapliku i usunie blokadę. Należy więc wywalić z systemu program /usr/bin/chattr . Oczywiście zanim to zrobisz zarchiwizuj go gdzieś. Ja ten punkt wykonuję tak: kopiuję /usr/bin/chattr (oraz ewentualnie plik lsattr) na flopka, następnie nie tyle kasuję co uszkadzam oryginał usuwając z niego kilka znaków (w ten sposób włamywacz będzie widział, że plik /usr/bin/chattr jest, ale nie domyśli się, że coś z nim kombinowałem. Tak zabezpieczony system nawet pod rootem jest nie do przekonfigurowania. System można śmiało restartować, eksploatować i nic się nie zepsuje :) Oczywiście w razie potrzeby kopiuję z dyskietki plik chattr na jego oryginalne miejsce i nadaję mu pierwotne prawa root.root 755
      
      Zlecenie chattr może mieć opcję chattr +A, która zablokuje uaktualnianie daty modyfikacji pliku. Do listowania plików z rozszerzonymi atrybutami plików służy zlecenie: lsattr
       
    • Co może włamywacz zrobić przy wyżej opisanych zabezpieczeniach? Podłożyć swój plik chattr lub doinstalować w /usr jakieś pluskwy-trojany. Ty jednak masz już wiedzę jak montować partycje w restrykcyjny sposób (patrz pkt. wyżej), więc intruz może Ci... skoczyć. No chyba, że umie zamontować partycję z innymi parametrami bez restartu systemu, za pomocą zlecenia:
      mount  -o  remount,defaults  /dev/hda5
      Parametry partycji /dev/hda5 ustali, podglądając plik /etc/fstab oraz /etc/mtab. Dodatkowe informacje na sąsiedniej stronie.

      Ja dodatkowo zabezpieczam się poprzez usunięcie w plikach /etc/fstab oraz /etc/mtab wszelkich wpisów o partycjach typu /home , /var, /var/www , /var/ftp , /tmp itd. (zostawiam wiersze z opisem CD-ROM, flopka - gdyż chcę je w przyszłości swobodnie montować). Oryginalne pliki na wszelki wypadek kopiuję (przed modyfikacją) na flopka. Muszę niestety pamiętać, by przed każdym restartem systemu podłożyć na swoje miejsce oryginalne (pełne) pliki fstab i mtab i nadać im właściwe prawa czyli root.root 644.

      Skrajnym zabezpieczeniem jest... usunięcie pliku /bin/mount (oraz jego archiwizacja na dyskietce). Trzeba wówczas przed restartem systemu podłożyć go na właściwe miejsce.

    Uwaga. Jeżeli coś namieszasz w plikach /etc/fstab oraz /etc/mtab, to nie uruchomisz systemu :( Bądź uważny. W razie problemów pomocna może okazać się strona o Linuksach ratunkowych.

    Przykładowy plik /etc/fstab (inny przykład fstab) pobrany z Mandrake 9.0.

     
    *     *     *

     
    

13. Zauważyłem, że podczas testowego włamania do mojego systemu, bardzo skutecznym w wywaleniu zalogowanego już intruza okazał się... reset połączenia internetowego. Wystarczy odpalić skrypt rc.sdirestart (resetuje połączenie SDI). Niestety, jest to brutalna metoda i wywala wszystkich, także tych legalnie pracujących. Utwórz skrypt kontrolujacy logi i wyszukujący kluczowe słowa sygnalizujące włamanie, a po ich wystąpieniu uruchamiający wspomniany skrypt. Zadasz pytanie jakie wpisy informują o włamaniu? Oto przykład z pliku /var/log/secure . Zarestrowano tam nieuprawnione przejęcie prawa roota podczas kontrolowanego włamu za pomoca exploita działającego na porcie 21 (proftpd). Oto jego fragmenty: tuż przed włamaniem (zalogował się niewinnie na publiczne konto ftp) oraz tuż po włamaniu: przejął UID=0 (roota). 

    Jul 31 00:08:24 serwerek proftpd[3695]: serwerek.pd100.gorzow.sdi.tpnet.pl (wc125idsl.tpnet.pl[134.57.96.194]) - ANON anonymous: Login successful.

    Jul 31 00:09:23 serwerek proftpd[3730]: serwerek.pd100.gorzow.sdi.tpnet.pl (wc125idsl.tpnet.pl[134.57.96.194]) - SECURITY VIOLATION: root login attempted.

    Mój komputer to: serwerek.pd100.gorzow.sdi.tpnet.pl, agresor to: wc125idsl.tpnet.pl[134.57.96.194], natomiast wpisy o nieuprawnionym przejęciu praw roota u zalogowanego anonymousa to: SECURITY VIOLATION: root login attempted.

     
    *     *     *

     
    

14. Jeżeli masz podstawy sądzić, że właśnie włamują się na serwer - natychmiast (jako root) wydaj polecenie ps -aux >/root/uwaga1.txt , netstat >/root/uwaga2.txt , można też: who >/root/uwaga3.txt , wyjmij kabelek łączący Internet z serwerem, wyedytuj pliki /root/uwaga?.txt , skopiuj cały katalog /var/log oraz /etc na osobną partycję. Następnie sformatuj dyski i zainstaluj na nowo system. Edytując uratowane archiwalia odtwórz historię ataku i wyciągnij wnioski.

     
    *     *     *

     
    

15. Jeżeli użytkownicy kont www, ftp nie będą potrzebowali dostępu do shella (co jest bardzo dobrym pomysłem), a jedynie dostępu do własnych witryn www, ftp - to po utworzeniu userów wykonaj małą korektę ustawień: wpisz im w plikach /etc/passwd oraz /etc/passwd- powłokę false (zamiast domyślnej bash). Oczywiście nie zapomnij wpisać wiersza /bin/false w pliku /etc/shells (jeżeli go tam jeszcze nie ma). Takie rozwiązanie uniemożliwi zdalne i bezpośrednie zalogowanie na shella, ale jednocześnie udostępni pełnoprawne konto www, ftp użytkownikwi indywidualnemu. Można też ustawić jako domyślną powłokę /bin/false dla nowych userów - robisz to zmieniając w pliku /etc/default/useradd wpis /bin/bash na /bin/false lub/oraz w pliku /etc/adduser.conf wpisując DSHELL=/bin/false
    
    Można zamiast shella false podać /dev/null . Aby wszystko działało poprawnie trzeba wówczas dodać wiersz /dev/null do pliku /etc/shells.
    
    Proszę wypróbować, czy system będzie stabilnie działał w sytuacji, gdy tylko root oraz userzy stworzeni przez nas będą mieli oryginalne shelle, a pozostali /dev/null.
    
    Można bez większego ryzyka USUNĄĆ zbędnych userów ftp, news itp. zleceniem:
    userdel adm
    userdel lp
    userdel sync
    userdel shutdown
    userdel halt
    userdel news
    userdel uucp
    userdel operator
    userdel games
    userdel smmsp
    userdel ftp
    userdel rpc
    userdel pop
    userdel gdm
    oraz usunąć zbędne grupy zleceniem:
    groupdel adm
    groupdel lp
    groupdel news
    groupdel uucp
    groupdel games
    groupdel pop
    groupdel smmsp

     
    *     *     *

     
    

16. PAM czyli pomocnik administratora jest programem nadzorującym użytkowników. Posiada pliki konfiguracyjne w katalogu /etc/security. Nas interesuje plik /etc/security/limits.conf. Uwaga: plik /etc/limits jest bardzo podobny do pliku /etc/security/limits.conf.

    Przykład pliku /etc/security/limits.conf

    @antek hard maxlogins 3
    kajtek hard maxlogins 1
    kajtek hard priority 5
    @ftpantka hard maxlogins 0
    @ftp hard maxlogins 0
    ftp hard nproc 0
    apache hard nproc 0
    # End of file

    Wyjaśnienie: w pierwszym wierszu użytkownicy z grupy antek mogą logować się na maksymalnie trzech konsolach jednocześnie, w drugim i trzecim wierszu ustalono możliwości usera kajtek: może się logować na maksymalnie jednej konsoli z maksymalnym priorytetem 5. Na czerwono zaznaczyłem sposób na radykalne zabezpieczenie użytkowników ftp (publicznego). Jeżeli dałeś użytkownikom indywidualnym możliwość posiadania swojego konta ftp, to radykalnie ogranicz im prawa (nie zablokuje to możliwości logowania na konto ftp).

    Uwaga wpis: kajtek hard maxlogins 1 na Mandrake 8.x oraz 9.0, 9.1 zezwala userowi kajtek na logowanie (także poprzez sshd) na jednej konsoli. Na Mandrake 9.2 wpis kajtek hard maxlogins 1 blokuje całkowicie możliwość logowania na konto z odległego komputera za pomocą ssh.

     
    Plik /etc/security/time.conf ustala czas i porę, gdy będzie można logować się na serwerze.

    Pamiętaj, ze ważne ograniczenia dla usera możesz założyć już podczas tworzenia nowego użytkownika. Zapraszam tutaj.

     
    *

     
    

    Ciekawy artykuł Adndrzeja Nowaka dotyczący PAM znalazłem na pod adresem http://binboy.sphere.pl/index.php?show=77.

     
    *     *     *

     
    

    
    
    
17. Na stronie www.chkrootkit.org znalazłem projekt skryptu sprawdzającego system na okoliczność obecności ukrytych trojanów i snifferów. W grudniu 2003 był to chkrootkit 0.43. Zassaj paczkę na Desktop np. usera antek. Następnie jako root rozpakuj ją do katalogu np. /root zleceniem:

    cd /home/antek/Desktop;tar zxpvf chkrootkit*.tar.gz -C /root

    Jak widzisz mamy tutaj dwa zlecenia: cd oraz tar w jednym wierszu, ale oddzielone średnikiem ; (bez spacji!). Opcja -C w zleceniu tar zmuusza program tar do rozpakowania archiwum we wskazanym katalogu (tutaj /root).

    Pojawił się nowy katalog /root/chkrootkit-0.43 (oczywiście nr wersji może być nowszy). Wejdź do tego katalogu i wykonaj kompilację (potrzebny jest w systemie kompilator GCC) zleceniem:

    cd /root/chkrootkit-0.43;make sense

    Zlecenie make sense przekompiluje skrypt, ale nie będzie go instalować. Skrypt uruchomimy znajdując się w katalogu /root/chkrootkit* zleceniem:

    cd /root/chkrootkit*;./chkrootkit 2>&1 | tee LOGchkroot.txt

    Objaśnienia do powyższego zlecenia: ./chkrootkit 2>&1 | tee LOGchkroot.txt

    ./ czyli uruchomienie pliku wykonywalnego

    2>&1 oraz zlecenie tee opisałem na sąsiedniej stronie

    Jeżeli skrypt wyświetli komunikaty typu: nothing found (nic nie znaleziono), not founf (nie znaleziono), not infected (nie zainfekowane), to system jest czysty od robali. Natomiast, jeżeli podmieniono lub przerobiono jakiś plik to musisz go odszukać, odinstalować oraz na nowo zainstalować. Na koniec dla pewności na nowo uruchom chkrootkit. Pełną ścieżkę do danego pliku znajdziesz za pomocą zlecenia: which nazwapliku . Mając te dane paczkę odinstalujesz zleceniem: rpm -qf /usr/bin/passwd (przyjąłem, że spaskudzonym programem jest passwd). Więcej o zleceniu rpm znajdziesz tutaj.

     
    *     *     *

     
    

18. Zauważyłem, że program mc pozwala edytować pliki systemowe, mimo że nie mają atrybutu READ (do odczytu) np. zleceniem mcedit /etc/hosts.deny. Jest to bardzo niebezpieczne i należy zabrać zwykłym userom prawo do używania programu mc (i co za tym idzie mcedit) poprzez narzucenie praw root.adm 750 (zleceniami: cd /usr/bin oraz chmod 750 mc oraz chown root.adm mc) do pliku /usr/bin/mc . W ogóle program mc jest... dobry dla nowicjuszy (bo przyjazny), ale jest też dobry dla włamywaczy, gdyż (przy standardowych ustawieniach)  przechowuje w plikach z historią wszystkie polecenia. Aby się ich trwale pozbyć, trzeba wykonać kilka karkołomnych kroków:

    • Zmień nazwę plikowi /usr/bin/mc na inną dowolną np. pusia
    • Przenieś plik pusia do dowolnego katalogu w /etc np. /etc/fonts (tam nie zostanie tak łatwo znaleziony ;)
    • Uruchom plik pusia zleceniem /etc/fonts/pusia i otrzymasz program mc, który nie będzie archiwizował swojej działalności
    • acha... nie ma sensu dodawać pliku pusia do zmiennej PATH, gdyż zostanie zbyt łatwo odnaleziony przez wścibskich userów.

    
    

     
    *     *     *

     
    

    
     

19. Kiedy zakończysz instalację systemu i programów - sprawdź, w jakich plikach masz ustawione bity SUID, SGID (SetUID, SetGID). Określają one prawa użytkownika (SUID) lub grupy (SGID) do wykonania programu z prawami roota. Nie jest wskazane, abyś samodzielnie (w trakcie nauki) nadawał takie uprawnienia, gdyż dla wprawnego włamywacza nawet gra działajaca z prawami administratora może pomóc w przejęciu praw roota. Więcej na ten temat na sąsiedniej stronie.

     
    *     *     *

     
    

20. Pamiętaj o możliwości zabezpieczenia ważnych plików poprzez założenie tzw. bitu lepkości (ang. sticky) na wrażliwe katalogi (np. /tmp). Taki plik TYLKO właściciel będzie mógł go usunąć. Nadawanie praw sticky można wykonać tak:

    • chmod 1751 nazwapliku czyli 1-nadanie bitu sticky, o prawach rwxr-x--t
    • chmod +t /tmp czyli nadanie bitu sticky na katalog /tmp (pozostałe prawa bez zmian)
    • chmod -t nazwapliku czyli usunięcie bitu sticky (pozostałe prawa bez zmian)

    
    Jeżeli dasz zlecenie chmod 751 nazwapliku czyli wybierzesz trzycyfrowy zapis zlecenia chmod (lub dasz zlecenie typu chmod u=rx nazwapliku), to wykasujesz nadane już prawo sticky. Na wydruku polecenia ls -la taki katalog ma t zamiast standardowej krańcowej-prawej litery x. Więcej o nadawaniu praw znajdziesz tutaj.

     
    *     *     *

     
    

21. Pamiętaj o zabezpieczeniu systemu firewallem (ścianą ogniową). Firewall pracuje (pod Linuksem) w oparciu o stare narzędzie ipchains lub nowsze iptables. Problem jest bardzo rozległy. Planuję utworzyć osobną stronę na ten temat.

    Uwaga: KDE zawiera błędy, które po skonfigurowaniu firewalla przez MANDRAKE CONTROL CENTER skutkują blokowaniem HISa ew. sieci domowej. Dlatego proponuję następujące kroki:

    • Mandrake 8.1 - zamiast MANDRAKE CONTROL CENTER- BEZPIECZEŃSTWO- FIREWALL wybierz w powłoce tekstowej (jako root) mcc oraz doszlifuj ustawienia. W ten sposób nie zablokujesz sobie SDI.
    • Mandrake 9.x - można bez obaw użyć MANDRAKE CONTROL CENTER- FIREWALL (lub to samo, ale poprzez plik /usr/sbin/drakfirewall ew. mcc). Pamiętaj, aby po zakończeniu konfiguracji firewalla powtórzyć konfigurację udostępniania Internetu (w MANDRAKE CONTROL CENTER lub poleceniem drakgw). Projektanci Mandrake od wersji 9.0 zastosowali do zarządzania iptables skrypty shorewall.

     
    *     *     *

     
    

22. Zmniejszyć liczbę pamiętanych poleceń - poprzez edycję pliku /etc/profile, np.:

    HISTFILESIZE=15
    HISTSIZE=15
    export HISTFILESIZE HISTSIZE
    
    Aby zmiany  zadziałały - zrestartuj system. Uwaga: parametr HISTFILESIZE znajdziesz także w pliku /etc/sysconfig/msec

     
    *     *     *

     
    

23. Program PortSentry (oraz Logcheck) wykrywa próby skanowania portów, automatycznie tworzy wpis do pliku /etc/hosts.deny po wykryciu intruza i chroni przed atakami większości skanerów. Obecnie nie spełnia już takich zadań jak kiedyś, gdyż rozwinięto i uszczelniono programy typu firewall.
    Zapraszam na sąsiednią stronę PORTSENTRY. Przeniosłem na nią artykuł, który pierwotnie był w tym miejscu.
    Link wprowadziłem, by zachować zgodność adresowania stron ze starszymi wersjami witryny np. zarchiwizowanymi przez internautów.

     
    *     *     *

     
    

24. Jeżeli zdecydowałeś się na aktywizację usług serwerowych na swoim LINUXIE, to zacznij od edycji plików: /etc/hosts.allow i /etc/hosts.deny. W /etc/hosts.allow określ "zaufane" komputery, natomiast w /etc/hosts.deny zabroniony dostęp.
    Zapraszam na sąsiednią stronę etc_hosts.php. Przeniosłem na nią artykuł, który pierwotnie był w tym miejscu.
    Link wprowadziłem, by zachować zgodność adresowania stron ze starszymi wersjami witryny np. zarchiwizowanymi przez internautów.

    
    
    

    *     *     *
    
    

25. Najczęściej atakowanymi elementami oprogramowania systemu Linux jest sendmail oraz imap. Stąd wskazane jest zainstalować najnowszą wersję tych programów lub wręcz zrezygnować z nich. Zamiast sendmaila możesz użyć innego programu do obsługi poczty na przykład Postfix, ZMailer, qmail

    
    
    Ja jednak proponuję całkowitą rezygnację z tych serwerów. Jeżeli dopiero uczysz się obsługiwać Linuksa, to daj sobie na razie spokój z samodzielnym kontem pocztowym i załóż go na np. wp.pl, onet.pl, czy poczta.fm . Będziesz spokojniej spać, a pocztę Twoją zawsze obsłuży czynny 24 godziny na dobę profesjonalny serwer. Ostatnim argumentem może być informacja, że w przypadku wyhakowania Twojego serwera pocztowego - na Twoje konto jakiś dowcipas może wysyłać w świat spam w ilościach kilku tysięcy maili na dobę. I możesz mieć z tego powodu kłopoty - TY, a nie włamywacz, który po zatarciu śladów zniknie w eterze...

     
    *     *     *

     
    

26. Usuń możliwość uruchamiania usług na Twoim komputerze.

    W Mandrake można decydować, jakie programy mają być uruchamiane podczas startu systemu, poprzez MANDRAKE CONTROL CENTER - USŁUGI. Więcej na ten temat tutaj.

    Wyłącz niebezpieczne usługi:

    • Te, które zaczynaja się od literki r (rsh, rexec, rcp, rlogin itd.). Generalnie wszystkie te usługi można zastapić programem ssh. Mam tutaj uwagę: jeżeli podczas instalacji wybrałeś WYSOKI poziom zabezpieczeń - nie masz zainstalowanych domyślnie poniższych programów.

    • finger (udostępnia informacje o użytkownikach systemu)
    • echo
    • daytime
    • discard
    • chargen
    • tftp (umożliwia pobieranie plików bez autoryzacji)
    • nntp (serwer news)
    • smpt (zdalne Zarządzanie serwerem)
    • telnet (koniecznie zainstaluj ssh!)
    • systat
    • netstat (informacje o systemie i sieci)
    • talk
    • ntalk
    • printer...
    • Jeżeli jesteś adminem paranoikiem to wywal (po zakończeniu prac) także narzędzia do korygowania partycji dysku np. fdisk.
    
    
    O tym, czy wprowadzone zmiany odniosły skutek, możesz się dowiedzieć wydając polecenie: netstat -l (małe L) lub poleceniem netstat -n (patrz na górne wiersze wydruku). Program netstat wyświetli wówczas listę usług aktualnie udostępnianych przez Twoją maszynę i listę połączeń. Przykład bardziej rozbudowanej wersji zlecenia: netstat -l --tcp -p|grep ssh (od razu wybieramy interesujące nas linie dotyczące ssh). Znaczek | oznacza, że nastąpiło uruchomienie potoku (połączenie kilku zleceń).

     
    *     *     *

     
    

27. Aby ukryć przed innymi dane o swoim systemie wyedytuj plik /etc/issue.net i skasuj jego zawartość. Jeżeli będziesz chciał usunąć powitalny komunikat startowy zawierajacy między innymi dane o wersji systemu to skasuj zawartość pliku /etc/issue . Uwaga: na czas aktualizacji systemu przywróć oryginalne wpisy informujące o wersji systemu! W niektórych dystrybucjach Mandrake po restarcie komputera były przywrócone pierwotne wpisy (zrobił to wpis w pliku /etc/rc.d/rc.local). Zobacz jakie szkolne rozwiązanie proponuję w sprawie plików issue. Przypominam przy okazji, że plik /etc/motd zostanie wyświetlony po udanym zalogowaniu się. Jeżeli chcesz usunąć możliwość wyświetlenia informacji o systemie w pliku /etc/motd, to zahaszuj w pliku /etc/rc.d/rc.S wiersz:
    echo "$(/bin/uname -sr)." > /etc/motd
     
    

    *

    
    Podczas buszowania po Internecie nawet nie zdajesz sobie sprawy, ze zostawiasz ślady po swojej bytności zawierające: nazwę systemu, nr Kernela, typ przeglądarki itd. W Konquerorze można ukryć te dane wykonując: KONQUEROR - USTAWIENIA - KONFIGURUJ - PROGRAM UŻYTKOWNIKA - WYŚLIJ IDENTYFIKACJĘ PRZEGLĄDARKI.
    
    

    *

    
    Podobny problem występuje na Twoich serwerach typu APACHE, ProFTPd. Goście z Internetu mogą zdobyć nr wersji serwera i przygotować włam za pomocą exploita. Trzeba im to utrudnić. Proponuję ukryć informacje o serwerze APACHE poprzez edycję pliku /etc/httpd/conf/commonhttpd.conf i w dyrektywie ServerTokens podać wartość Prod zamiast domyślnej Full.
    Ponadto w pliku commonhttpd.conf wyłącz wpisem Off (duże O) dyrektywy ujawniające dane o konfiguracji i wersji Apache:
    UseCanonicalName Off
    ServerSignature Off
    HostnameLookups Off
    Wyedytuj też plik /etc/httpd/conf/httpd.conf (oraz ew. httpd2.conf) i zahaszuj # wiersze umożliwiające ładowanie modułów:
    - ładowanie modułu mod_autoindex - umożliwiającego automatyczne indexowanie zawartości katalogów ze stronami www
    - ładowanie modułu mod_info - udostępniającego informacje o konfiguracji Apache
    - ładowanie modułu mod_proxy - moduł o niebezpiecznym działaniu
    W pliku /etc/httpd/conf/httpd.conf (oraz ew. httpd2.conf), w sekcji Directory można zablokować dyrektywę exec (użytkownik nie wykona polecenie CGI na serwerze) oraz dyrektywę include (można przeglądać zawartość pliku na dysku kodem SSI np. odczytać hasło do bazy danych w pliku php). Aby zablokować listowanie katalogu, gdy nie ma w nim pliku index.* w sekcji Directory umieszczamy wpis Options -Indexes
    Ciekawe notatki o zabezpieczaniu Apache, PHP, MySQL znajdziesz w magazynie CHIP 4/2006 str. 134/136.
    
    Natomiast ProFTPd zabezpieczymy poprzez wpisanie do pliku /etc/proftpd.conf wiersza ServerIdent on "komunikat" . Więcej o konfiguracji serwerów znajdziesz na sąsiedniej stronie.
    
    Na przełomie 2005/2006 przeczytałem po raz pierwszy o możliwościach jakie daje wyszukiwarka GOOGLE w przygotowaniu włamania na serwer www. Temat jest rozległy. Gdy samodzielnie nauczę się korzystać z tych "dobrodziejstw", to opiszę je na stronie. Na razie polecam lekturę magazynu CHIP 2/2006 (str. 113-115). Ponadto radzę przeczytać kolejny artykuł w tym samym magazynie CHIP "Hotel dla www". Mamy tam analizę bezpieczeństwa kilku komercyjnych serwerów. Włos się jeży na głowie jak są amatorsko nadzorowane.

     
    *     *     *

     
    

28. Linuksy Mandrake/Mandriva mają domyślnie zainstalowane narzędzia kontrolujące zmiany w systemie. Jeżeli od czasu do czasu sprawdzisz system - uzyskasz dobry materiał do oceny stopnia zabezpieczenia komputera. O tym jak ważne są to narzędzia niech pokaże przykład: wykonaj modyfikację dowolnego pliku z bitem SUID - usuń ten bit. Następnie uruchom plik /usr/share/msec/security.sh, a zobaczysz, że otrzymasz komunikat ostrzegajacy o zmianach. Jeżeli sam to zrobiłeś, to nie ma strachu. Ale jeżeli nic Ci o tym nie wiadomo, to może oznaczać, że wyhakowano Twój komputer i zmodyfikowano kluczowe pliki. W Mandrake (przy WYSOKIM(4) POZIOMIE BEZPIECZEŃSTWA) cron raz na dobę odpala plik /usr/share/ msec/security.sh . Jeżeli więc wybrałeś niższy poziom zabezpieczeń, to dopisz wiersz w /etc/crontab

    Przykładowy plik /etc/crontab pobrany z Mandrake 9.x. Zwróć uwagę na wiersz 0 22,6,14 * * *   root   /usr/share/msec/security.sh oraz dodatkowe wpisy automatyzujące kopiowanie raportów na Desktop użytkownika antek . Daje to możliwość sprawdzania wybranemu uzytkownikowi (pod nieobecność roota) wyników kontroli systemu. Wiecej o automatyzowaniu prac na stronie o zarządzaniu Linuksem.

     
    *     *     *

     
    

29. Jako administrator powinieneś mieć kontrolę nad zdarzeniami zachodzącymi w systemie. Należy w tym celu regularnie edytować pliki z logami. Niestety - ich podstawową wadą jest... nadmiar informacji i bez narzędzi wyszukujących praca z nimi nie ma sensu. O logach i demonie syslogd znajdziesz trochę notatek na stronie pt. syslogd.php. Proponuję przeczytać także opis zabezpieczenia logów poprzez ich archiwizację. Jest to bardzo ważny punkt i zalecam by nie lekceważyć go. Jeżeli włamywacz dokona udanego ataku i zniszczy logi, przekonfiguruje system lub skasuje pliki userów, to tylko z backupów będziesz mógł odzyskać dane. Natomiast co do odtwarzania plików konfiguracyjnych, raz dziennie odpalam backupy i przywracam je do systemu tak na wszelki wypadek.

     
    *     *     *

     
    

30. Mając małą domową sieć, powinieneś zaopatrzyć się w dwa programy: s n i f f i t oraz n m a p. Umożliwi to nadzór nad łącznością w sieci i kontrolę portów na serwerze.

     
    *     *     *

     
    

    
    
    
31. Biblioteka libsafe zabezpiecza serwer przed atakiem exploitów. Strona domowa projektu: http://research.avayalabs.com/project/libsafe lub http://directory.fsf.org/libsafe.html. Należy z niej ściągnąć instalkę. Oto przykład libsafe dla mojego Mandrake 9.2.

    Z nieznanych mi powodów pakiet libsafe w Mandrake jest dostępny tylko w wersji 9.0 oraz 10.0. O ile w Mdk 10 instaluje się domyślnie i bez wiedzy użytkownika, to w Mdk 9.0 trzeba było wykonać kilka karkołomnych czynności:

    • na etapie RODZAJ INSTALACJI wybierz ZAINSTALUJ, ZAAWANSOWANA (czyli standardowo)
    • na etapie BEZPIECZEŃSTWO wybierz WYŻSZY (dla serwerów) POZIOM BEZPIECZEŃSTWA (czyli standardowo)
    • na etapie WYBÓR PAKIETÓW wybierz tylko SERWER SIECIOWY i... powróć do etapu BEZPIECZEŃSTWO klikając w zielony przycisk (pierwszy nietypowy krok)
    • na etapie BEZPIECZEŃSTWO zobaczysz znajomą planszę, ale... z dodatkową opcją zabezpieczającą serwer przed przepełnieniem buforu oraz atakami odpowiednio spreparowanych ciągów znaków (drugi nietypowy krok)
    • kolejne kroki instalacji wykonaj już standardowo. Po powrocie do panelu WYBÓR GRUP PAKIETÓW punkt SERWER SIECIOWY nie jest już zaznaczony i nie zmieniaj tego. Ewentualne serwery sieciowe typu OPENSSH, SAMBA itd. za chwilę dobierzesz ręcznie na kolejnym panelu.

     
    *     *     *

     
    

32. Osobiście byłem obiektem ataków poprzez serwer BIND (odpowiadający za DNS). Włamywacz poprzez port 53 przejmował uprawnienia roota. Na szczęście często kontroluję logi, więc dosyć szybko wyłapywałem zagrożenie. Niestety, nie mogłem sobie z gościem poradzić. Firewall byl w porządku, BIND w najnowszej wersji. Reinstalka systemu nie pomogła (w tym samym dniu miałem kolejne włamanie), więc usunąłem demona BINDa (po głębszym zastanowieniu uznałem, że został zupełnie niepotrzebnie zainstalowany podczas konfiguracji udostępnienia połączenia). I od tego momentu mam spokój, przynajmniej z atakami na port 53 ;-) . Pytasz się po co o tym wszystkim piszę? Gdyż to samo może dotyczyć Ciebie(!). Mandrake ma miłe narzędzia, które co prawda pomagają w konfiguracji, ale niestety posiadają wadę: trzeba po ich działaniu ręcznie uszczelnić system. Niestety, nikt w MandrakeSoft nie pomyślał, że użytkownicy SDI muszą konfigurować sieć na DNS od TPSA (194.204.159.1, 194.204.152.34) i własny DNS jest najczęściej nieprzydatny. Dlatego pamiętaj: PO KAŻDYM SKONFIGUROWANIU UDOSTĘPNIENIA (poprzez Mandrake Control Center lub drakgw) USUŃ demona BIND (plus dodatkowe pakiety). Usuwać możesz poprzez Mandrake Control Center- DODAJ USUŃ PAKIETY- ZNAJDŹ bind. Od biedy możesz nie tyle usuwać, a wyłączyć demona pod nazwą named. Pod KDE wyłączyć można w MANDRAKE CONTROL CENTER- USŁUGI.

    Na liście 20 najpoważniejszych dziur bezpieczeństwa opisanych w serwisie www.sans.org/top20 usługa DNS w dziale UNIX zajmuje niestety pierwsze miejsce.

    Jeżeli masz serwer http i koniecznie chcesz mieć możliwość korzystania z serwerów DNS, to kup domenę .pl od profesjonalnego dostawcy, a w zamian otrzymasz darmowe DNSy. Jak to zrobić? Zapraszam tutaj.

    Istnieje projekt djbdns dostępny na stronie http://cr.yp.to/djbdns.html , który może kiedyś zamieni BINDa . Paczki dla Mahdraka 9.1 są na stronie http://www.rpmhelp.net/rpmlist.php?distrib=mdk91&rid=68

     
    *     *     *

     
    

33. Mandrake zastosował narzędzie ułatwiające konfigurowanie systemu: linuxconf. Można go uruchomić zarówno w powłoce tekstowej i pod KDE. Ma swoje wady i zalety, ale ja nie o tym... . LINUXCONF ma opcję, o której niektórzy admini zapominają - można przy jego pomocy zdalnie (z odległego komputera) przekonfigurować system. Z jednej strony jest to przydatne zlecenie (gdy serwerem administrujemy mieszkając np. w innym mieście), z drugiej potencjalna dziura w bezpieczeństwie. Wybierz więc: linuxconf , -NETWORKING -LINUXCONF NETWORK ACCESS- usuń zaznaczenie przy opcji umożliwiające zdalne konfigurowanie. Jeżeli mimo wszystko chcesz korzystać z tej możliwości, zwróć uwagę na plik /var/log/linuxconf/htmlaccess.log . Kontakt ze zleceniem linuxconf odbywa się (przy pomocy przeglądarki) poprzez wpisanie adresu http://machine:98/ (machine to pełna nazwa serwera, 98 czyli nr portu, który ma być udostępniony na firewallu).

     
    *     *     *

     
    

34. Z zaskoczeniem przeczytałem artykuł http://gdr.free.komrel.net/gdrwpl/macspoof.php opisujący technikę ataku podszywania poprzez podmienianie adresu MAC w karcie sieciowej wpiętej do sieci. Parę miesięcy później także magazyn CHIP opisał ten problem. Inny przydatny link: ocmelbourne.com/tutorials/MACaddr/index.shtml. Więcej informacji znajdziesz na sąsiedniej stronie.

     
    *     *     *

     
    

35. Podczas instalacji Mandrake spotkałeś się z informacją, że Kernel 2.4 lub 2.6 może być w wersji secure. To małe słówko secure oznacza łatę grsec instalowaną podczas kompilacji Kernela. Kilka słów na ten temat znalazłem na stronie: http://security.linux.pl/ (mam ją w swoim archiwum).
    Uwaga: od wersji Mandrake 10.1 (wersja darmowa) po najnowsze Mandriva (free) nie udało mi się z płytek CD zainstalować Kernela Secure. Musiałem z Mdk 10.0 wykonać update za pomocą URPMI.
    
    
    
    Ciekawy link o kompilacji Kernela: http://members.lycos.co.uk/fenio).

     
    *     *     *

     
    

36. Włamywacz po przejęciu uprawnień usera spróbuje wrzucić na komputer ofiary swoje paczki z trojanem, jakimś backdoorem, klientem ssh, klientem telnetu lub nawet instalką serwera sshd, telnetu. Aby to zrealizować, będzie próbował odszukać jakiegoś klienta ftp, przeglądarki np. Lynx. Co dobry admin powinien więc zrobić? WYWALIĆ Z SERWERA WSZYSTKO, CO POZWOLI ZASSAĆ Z NETU PLIK oraz NIE UŻYWAĆ SERWERA JEDNOCZEŚNIE JAKO KLIENTA.

     
    *     *     *

     
    

37. Zaawansowani znawcy "pingwina" mogą po zakończeniu konfigurowania i zabezpieczania swojego Linuksa wykonać obraz dysku. Przyda się, gdy trzeba będzie odtworzyć szybko obraz systemu sprzed awarii lub włamu. Istnieją narzędzia windowsowe (w większości komercyjne) lub linuksowe (darmowe). Zapraszam na sąsiednią stronę, gdzie opisałem Linuksa SystemRescureCD.

     
    *     *     *

     
    

38. Są witryny, które sprawdzają odporność Twojego systemu na włamania:

    http://www.pcflank.com
    http://scan.sygate.com

    oraz inne adresy:

    https://grc.com/x/ne.dll?bh0bkyd2
    http://www.auditmypc.com/

     
    

     
    *     *     *

     
    

 
LINKI.

http://ipsec.pl/biblioteka.php
www.iana.org/assignments/port-numbers - lista portów z objaśnieniami.
ftp://ftp.portsdb.org/PortsDB/services - lista portów z objaśnieniami.
www.securityfocus.com/
www.cert.org/
linuxtoday.com
www.securityportal.com/
Tłumaczenia ważnych i przydatnych dokumentów.

Program antywirusowy dla Linuksa: http://www.ravantivirus.com