Losowo wybrane artykuły

apache

ProFTPD - serwer ftp na Linuxa (wirtualni użytkownicy)

Proftpd jest jednym z najpopularniejszych serwerów ftp dla Linuxa. Łatwy w konfiguracji, dość powiedzieć, że od razu po instalacji można z niego korzystać.
UWAGA:Po zainstalowaniu proftpd uzyskujemy pełny dostęp do plików i katalogów na serwerze!!! Dlatego odradzałbym pozostawienie proftpd w domyślnej konfiguracji.
Przed omówieniem podstawowej konfiguracji musimy sobie zadać pytanie: "kogo ma obsługiwać nasz serer plików i jakie zasoby udostępniać?"
Mamy do wyboru:

  • użytkownicy systemowi - użytkownicy mający dostęp do kont shell na naszym serwerze (zaufani)
  • użytkownicy ftp - użytkownicy posiadający tylko dostęp do konta na ftp (mniej zaufani)
  • użytkownicy anonimowi - użytkownicy posiadający dostęp to tzw.nonymous ftp, czyli przeważnie mogący ściągać pliki udostępnione przez administratora bez podawania loginu ani hasła
Domyślna konfiguracja jest zorientowana na użytkowników systemowych i na razie skupię się na niej.
Edytujemy plik proftpd.conf:

# Dołączamy konfigi ewentualnie aktywowanych modułów.
Include /etc/proftpd/modules.conf

# Tryb pracy serwera, uruchamiamy jako samodzielny proces.
ServerType                      standalone
# Określamy konfigurację jako domyślną
DefaultServer                   on

# Jesli nie używamy IPv6.
UseIPv6                         off

# Te 3 opcje znacznie skracają czas logowania.
UseReverseDNS                   off
IdentLookups                    off
ServerIdent                     off

# Określamy nazwę naszego serwera, nie podajemy jego nazwy ani wersji.
ServerName                      "ftp by ulos.pl"

# Komunikat powitalny.
DisplayLogin                    welcome.msg

# Zezwalamy na komunikat powitalny dopiero po zalogowaniu.
DeferWelcome                    on

MultilineRFC2228                on

# Zezwalamy na wyświetlanie dowiązań.
ShowSymlinks                    on

# Czas w jakim zostanie przerwane połączenie z serwerem.
TimeoutNoTransfer               600
TimeoutStalled                  600
TimeoutIdle                     1200


DisplayChdir                    .message true

DenyFilter                      \*.*/

# Blokoda logowania użytkownikowi root.
RootLogin                       off

# Uwięzienie użykowanika w wyznaczonym katalogu, z którego nie będzie mógł się wydostać.
# znak ~ katalog domowy w systmie Linux.
DefaultRoot                     ~

# Opcje do listowania plików w trybie binarnym:
# "-a"="ls -a" , "+a"=blokada parametru a czyli plików ukrytych(z kropką).
ListOptions "+a"

# Sprawdzamy czy dany użytkownik, który się loguje 
# posiada przypisaną w /etc/shells powłokę (szybka metoda do zablokowania).
RequireValidShell               on

# Port na którym nasłchuje proftpd.
Port                            21

# Konfiguracja portów trybu pasywnego używanego przez przeglądarki (ftp://host.pl).
# PassivePorts                  49152 65534

# Użyteczna opcja jeśli nasz komputer stoi za NAT-em.
# MasqueradeAddress             1.2.3.4

# This is useful for masquerading address with dynamic IPs:
# refresh any configured MasqueradeAddress directives every 8 hours

# DynMasqRefresh 28800


# Maksymalna liczba procesów demona FTP. 
# Dzięki tej dyrektywie możemy ustrzec się przed atakami typu DoS. 
MaxInstances                    30

# Użytkownik i grupa do których bedzie należał proces serwera.
User                            proftpd
Group                           nogroup

# Ustawienie prawa dostępu wlasciciela do modyfikacji pliku i katalogów.
# 022 => 755 , 077 => 700 , 002 =>  775
Umask                           022  022

# Pozwolenie na nadpisywanie plików.
AllowOverwrite                  on

# Konfiguracja logów.
TransferLog /var/log/proftpd/xferlog
SystemLog   /var/log/proftpd/proftpd.log

Oczywiście po zmianie w pliku proftpd.conf restartujemy serwer.

Jest to przykład podstawowej konfiguracji proftpd z zachowaniem pewnch norm bezpieczęństwa dla użytkowników systemowych.
Należy wspomnień o jeszcze jednej istonej sprawie, protoków ftp przesyła hasła i loginy w postaci niezaszyforwanej , jako tzw.plain text co daje możliość podsłuchania tych dość ważnych informacji.

Teraz zajmiemy się wirtualnymi użytkownikami, którzy będą tylko posiadali konto ftp.

  • Pierwszym krokiem będzie stworzenie katalogu dla wirtualnych uzytkowników i nadanie mu odpowiednich praw.
  • mkdir /home/ftp
    chown proftpd:nobody /home/ftp
    chmod 751 /home/ftp
  • Tworzenie użykowników realizujemy za pomocą narzędzia ftpasswd:
  • ftpasswd --passwd --file /etc/proftpd/ftpd.passwd --name nazwa_usera  --home /home/ftp/nazwa_katalogu -p  --uid id_usera_ftp  --gid id_grupy_ftp --shell /bin/false

    gdzie: id_usera_ftp i id_grupy_ftp są to z pliku proftpd.conf dyrektywy: User i Group
    Możemy sie posłużyc prostym skryptem który uwolni nas od żmudnego pisania tylu paramtrów:
  • mcedit ftpcreate.sh
  • 
    #!/bin/sh
    if [ $# -lt 2 ] ; then
    echo "podaj jako pierwszy parametr nazwe uzytkownika, jako drugi parametr jego folder"
    else
    ftpasswd --passwd --file /etc/proftpd/.ftpd.passwd --name $1  --home /home/ftp/$2 -p  --uid 106  --gid 65534 --shell /bin/false
    mkdir -p /home/ftp/$2
    chown -R proftpd:nogroup /home/ftp/$2
    chmod 751 /home/ftp/$2
    fi
    
    

    Nadajemy odpowiednie uprawnienia: chmod 700 ftpcreate.sh Korzystamy w następujący sposób: ./ftpcreate.sh nazwa_użytkownika jego_katalog, po czym padnie pytanie o hasło...
    Pamiętajmy również o modyfikacji uprawnień pliku ftpd.passwd: chmod 600 .ftpd.passwd
  • Następnie trzeba poddać lekkim modyfikacją główny plik konfiguracyjny proftpd.conf
  • Dodajemy ścieżkę do pliku z użytkownikami i hasłami, w naszym przypadku: AuthUserFile /etc/proftpd/ftpd.passwd
    Zmieniamy dyrektywę: RequireValidShell on na RequireValidShell off

W tym momencie serwer obsługuje użytkowników zarówno wirtualnych jak i systemowych.

darmowe zaufane certyfiakty ssl

Generowanie i instalowanie certyfiaktu SSL na serwerze www nginx

W poprzednim artykule: Darmowe certyfikaty SSL opisałem gdzie można zdobyć darmowy a zarazem zaufany przez przeglądarki certyfikat SSL. Tym razem zajmiemy się częścią pratyczną czyli generowaniem i instalacją certyfikatu SSL dla naszej strony. Jako, że jestem fanem serwera nginx, opis konfiguracji będzie dotyczył właśnie tego serwera www. Tworząc certyfikat będziemy korzystali z pakietu openssl, choć zawsze można posiłkować się generatorem online.
Drugim warunkiem jest nginx skompliowany z obsługą modułu ssl. W konsoli wywłujemy: nginx -V, jeśli dostaniemy: --with-http_ssl_module to "jesteśmy w domu", w innym przypadku musimy przekompliować nginx-a. Proces kompliacji można znaleźć w artykule o konfiguracji rtorrent + rutorrent = GUI/WebUI.

Tworzenie certyfiaktu:

  • wszytskie czynności wykonujemy z konta root
  • Stwórzmy katalog na certyfikat, np. mkdir -p /etc/nginx/ssl/nazwa_naszej_domeny
  • Generujemy klucz RSA bez hasła (umożliwia restart serwera www bez podawania hasłą):
  • openssl genrsa -out mojadomena.key 2048
  • Jeśli nam nie przeszkadza podawanie za każdym razem hasła (min. 4 litery):
  • openssl genrsa -des3 -out mojadomena.key 2048
  • Generowanie żądania certyfiaktu:
  • openssl req -new -key mojadomena.key -out mojadomena.csr
  • Podczas generowania żądania certyfikatu (CSR) zostaniemy poproszeni o podanie kilku informacji nie używając polskich znaków diakrytycznych (ą, ł, ó, Ł, Ó...) oraz znaków specjalnych ( ? . , > ~ ! # @ $ % ^ * / \ ( ) ) :
  • Country Name - podajemy dwuliterowy symbol kraju
  • State or Province Name - pełna nazwa województwa, np. Małopolskie
  • Locality Name - pełna nazwa miasta
  • Organization Name - pełna nazwa naszej firmy / organizacji, np.Nazwa Firmy SA
  • Organizational Unit Name - dział firmy / organizacji
  • Common Name - pełna nazwa domenowa (FQDN) szyfrowanej strony, np. poczta.nasza_domena.pl
  • Email - do kontaktu w sprawie certyfiaktu (pole nie wymagane)
  • A challenge password []: - nie uzupełniamy
  • An optional company name []: - nie wymagane
  • Po utworzeniu pliku csr logujemy się do serwisu StartSSL a następnie klikamy w Certificates Wizard wybierając Web Server SSL/TLS Certificate
  • Następnie wybieramy Skip, dochodzimy do Submit Certificate Request. Wklejamy zawartość naszego pliku csr
  • Jeśli wszytsko poszło po naszej myśli zobaczmy kominukat: Certificate Request Received
  • Wybieramy z listy naszą domenę
  • Następnie zostaniemy poproszeni o podanie subdomeny, którą chcemy zabezpieczyć (np. www.nasza_domena.pl)
  • Zapisujemy wygenerowany certyfiakt pod nazwą mojadomena.crt
  • Ściągamy na serwer plik: wget https://www.startssl.com/certs/class1/sha2/pem/sub.class1.server.sha2.ca.pem
  • Dołączamy zawartość pliku do naszego certyfikatu: cat mojadomena.crt sub.class1.server.sha2.ca.pem >> mojadomena.pem
  • Dobrze nadać prawidłowe prawa naszym plikom:
  • chmod 600 /etc/nginx/ssl/nazwa_naszej_domeny/mojadomena.key
    chmod 600 /etc/nginx/ssl/nazwa_naszej_domeny/mojadomena.pem

Konfiguracja: nginx + SSL
W tym momencie pozostaje uruchomienie SSL na serwesze nginx. Jako, że wygenerowaliśmy certyfiakt SSL dla subdomeny, skonfigurujemy v-hosta. Dla urposzczenia przyjmuję, że naszą domeną jest: poczta.domena.pl . Sama konfiguracja jest identyczna dla wszystkich dystrybucji niemniej jednak może różnić się np. scieżkami. Poniższa konfiguracja została przeprowadzona na Debianie. Konfiguracja będzie tak skonstuowana, żeby użytkownik nie musiał specjalnie wpisywać w przeglądarkę: https://poczta.domena.pl wystraczy: poczta.domena.pl .

  • Tworzymy plik konfiguracyjny naszego wirtualnego hosta: touch /etc/nginx/sites-available/poczta
  • server {
                listen  80;
                server_name  poczta.domena.pl;
    			
                ## stare mało optymalne rozwiązanie: wiki.nginx.org/IfIsEvil
                # if ($host = 'poczta.domena.pl' ) {
                #     rewrite ^/(.*)$ https://poczta.domena.pl/$1 permanent;
                # }
    			
                # aktualne rozwiązanie
                return       301 https://poczta.domena.pl$request_uri;
    			
                access_log  /var/log/nginx/poczta.domena.pl.access.log;
                error_log  /var/log/nginx/poczta.domena.pl.error.log;
            }
    
    server	{
                listen 443;
                ssl on;
                server_name poczta.domena.pl; 
    ssl_certificate /etc/nginx/ssl/poczta.domena.pl/mojadomena.pem; ssl_certificate_key /etc/nginx/ssl/poczta.domena.pl/mojadomena.key;
    access_log /var/log/nginx/poczta.domena.pl.access_log; error_log /var/log/nginx/poczta.domena.pl.error_log; . . # dalsza część pliku konfiguracyjnego }
  • Tworzymy link symboliczny: ln -s /etc/nginx/sites-available/poczta /etc/nginx/sites-enabled/poczta
  • Następnie restart nginx-a: /etc/init.d/nginx restart
  • Na koniec sprawdźmy czy przeglądarka akceptuje nasz certyfikat (widok:Google Chrome):
nginx

Nginx serwer www z obsługą php@FastCGI part I

Nginx to lekki serwer http i reverse proxy. Potrafi także działać jako load balancer, dlatego często określany jest jako router HTTP. Stanowi poważną alternatywę dla przeładowanego apache. W środowisku prodykcyjnym nginx zaskakuje wydajnością oraz małym zużyciem pamięci co jest zaletą dla dużych jak wordpress.com jak i małych jak słabiutki vps z 128MB.
Na niekorzyść nginx-a przemawia fakt, braku wsparcia plików .htaccess oraz składnia modułu rewrite jest nieco inna od składni mod_rewrite. Brak obsługi .htaccess determinuje konieczność wprowadzania czy to dyrektyw rewrite czy innych obsługiwanych w .htaccess do konfiguracji serwera przez jego administratora.
Przewagę jaką uzyskuje nginx nad popularnym apachem wynika z modelu obsługi przychodzących połączeń. W Apache każde nowe połączenie wymaga uruchomienia nowego procesu (mpm-prefork) lub wątku (mpm-worker), który obsłuży przychodzące żądanie.
W przypadku nginx-a mamy do czynienia z modelem zdarzeniowym polegającym na obsłudze wielu połączeń przez ten sam proces, który reaguje na takie zdarzenia, jak nowe żądanie od klienta, odpowiedź od serwera aplikacji itp. Jeżeli na jednym połączeniu nic się nie dzieje, proces nginxa może obsługiwać inne, aktywne połączenie. Proces (wątek) Apache'a czeka wtedy bezczynnie.
Nginx tworzy 1-n... procesów (w zależności od potrzeb i sprzetu) ,każdy z tych procesów, może obsłużyć kilkadziesiąt/set tysięcy połączeń. Pokrótce tyle teorii.

Na początku chcę zaznaczyć, iż nie będe się wdawał w sam proces instalowania nginx-a, wiadomo to już jest uzależnione od dystrybucji (paczki) lub indywidulanej konfiguracji (kompilacji ze źródeł).

  • Globalna konfiguracja serwera:
  • główny plik konfiguracyjny - nginx.conf
  • 
    user www-data;
    worker_processes  1;
    
    error_log  /var/log/nginx/error.log;
    pid        /var/run/nginx.pid;
    
    events {
        worker_connections  1024;
    }
    
    http {
        include       /etc/nginx/mime.types;
        default_type  application/octet-stream;
    
        access_log  /var/log/nginx/access.log;
    
        sendfile        on;
        tcp_nopush     on;
    
        keepalive_timeout  0;
        keepalive_timeout  65;
        tcp_nodelay        on;
    
        gzip  on;
    
        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
    }
    
    i krótki opis do tego pliku:
  • user www-data; - konfiguracja z jakimi prawami będzie uruchomiony serwer
  • worker_processes 1; - ilość uruchomionych procesów, tutaj kierować się należy zasadą: ilość rdzeni = ilość procesów (jeżeli jest taka potzreba)
  • worker_connections 1024; - maksymalna ilość połączeń w ramach 1 procesu
    Dzięki dwóm powyższym parametrom teoretycznie możemy oszacować maksmalną liczbę równocześnie obsłużonych klientów: max_clients = worker_processes * worker_connections , natomiast trzeba pamiętać, że w przypadku serwowania stron dynamicznych np. w php jeden klient otwiera dwa połączenia (FastCGI), i już wtedy: max_clients = worker_processes * worker_connections / 2
    a jescze bezpieczniej przez 4.
  • include - cała konfigurację można umieścić w pliku nginx.conf ale dla większej przejrzystości i porządku, szczególnie jesli jest ona rozbudowana (np. wiele domen) można umieszczać w osobnych plikach.
  • W Debianie i pokrewnych dystrybucjach model rozmieszczenia plików jest zapożyczony z Apache (katalogi: sites-available , sites-enabled).
    Trzymając się konwencji Debiana dodatkową konfigurację oddeleguję do osobnych plików.
  • Nginx serwujący kontent statyczny:
  • stworzmy w /etc/nginx/sites-available plik example a w nim:
  • 
    server {
    	# Dyrektywa okreslająca adres i/lub port, na których serwer nasłuchuje
    	listen       80;
    	
    	# Dyrektywa przypisująca nazwy wirtualnym serwerom
    	server_name  przyklad.pl www.przyklad.pl;
    	
    	# Logi domeny przyklad.pl
    	access_log  /var/log/nginx/przyklad.access.log; 
    	error_log /var/log/nginx/przyklad.pl.error.log;
            
    		location / {
    		root   ścieżka naszego katalogu ze stroną;
    		index  index.html index.htm;    
    		}  
    
    }
    
  • teraz tworzymy dowiązanie symboliczne: ln -s /etc/nginx/sites-available/przyklad /etc/nginx/sites-enabled/przyklad
  • następnie restart nginx-a: /etc/inid.d/nginx restart
  • Jeśli nie mamy domeny nie uzywamy wtedy dyrektywy server_name, jeżeli jednak chcemy mieć kilka stron na jednym IP możemy wystawić je na różnych portach:
    
    # strona_1:
    server {
    	listen       80;
    	
    	# ....
    
    		location / {
    		root   /var/www/strona_1;
    		index  index.html index.htm;    
    		}  
    
    }
    # strona_2:
    server {
    	listen       81;
    	
    	# ....
    
    		location / {
    		root   /var/www/strona_2;
    		index  index.html index.htm;    
    		}  
    
    }
    

    W czasie konfiguracji nginx-a natknąłem sie na dość kłopotkiwą sytuacje. Przedstawie ją na konkretnym przykładzie:
    Wyobraźmy sobie, że mamy domenę example.com, 4 subdomeny: main.example.com, poczta.example.com, users.example.com, qwerty.example.com . Trzy pierwsze są wirtualnymi hostami wykorzystywanymi przez nginx-a nastomiast ostania qwerty.example.com nie jest powiązana z żadną konfiguracją wirtualnego hosta. I tu pojawia się problem, gdyż kiedy wpiszemy w przeglądarkę http://qwerty.example.com/ - wtedy wyswietli nam się jedna z tych trzech stron (chyba zależy od kolejności jaką nginx robi include).
    W pliku nginx.conf wstawiamy blok server przed dyrektywami include:

    
    server {
        listen          80 default;
        server_name    _ ; # Catch all
        
        return 444;  # Kod 444 zamyka połączenie bez wysyłania nagłówków.
    }
    

    Oczywiście jest to ułamek możliwośći nginx-a, nic nie wspomniałem o konfiguracj reverse-proxy czy silnemu wsparciu wyrażeń regularnych...
  • Nginx z obsługa PHP poprzez FastCGI part II

rkhunter linux

Rkhunter (Rootkit Hunter) - skaner złośliwego oprogramowania

Rkhunter jest narzędziem skanującym nasz system w poszukiwaniu złośliwego oprogramowania, głównie: rootkity, backdoory, exploity. Oprócz w/w czynności skrypt sprawdza m.in. pliki strartowe, stan interfejsów sieciowych, konfigurację niektórych aplikacji (np. sshd).
Rkhunter działa z powodzeniem na wielu dystrybucjach Linuxa oraz systemach BSD.

Rkhunter dostępny jest w wielu dystrybucjach jako gotowy pakiet:

Instalacja skanera Rkhunter

  • Debian/Ubuntu : aptitude install rkhunter
  • RedHat/CentOS : yum install rkhunter

Jeśli chcemy mieć najświeższą wersrję możemy zainstalować ze źródeł.

  • Pobieramy najnowszą wersję: wget -O rkhunter.tar.gz http://sourceforge.net/projects/rkhunter/files/latest/download
  • Rozpakowywujemy: tar -xzvf rkhunter.tar.gz
  • Przechodzimy do katalogu: cd rkhunter-*
  • Instalując oczywiśćie możemy użyć innych opcji, polecam plik README w katalogu files: ./installer.sh --layout default --install
  • Po udanej instalacji powinien wyświetlić się raport:
Checking system for:
 Rootkit Hunter installer files: found
 A web file download command: wget found
Starting installation:
 Checking installation directory "/usr/local": it exists and is writable.
 Checking installation directories:
  Directory /usr/local/share/doc/rkhunter-1.4.0: creating: OK
  Directory /usr/local/share/man/man8: creating: OK
  Directory /etc: exists and is writable.
  Directory /usr/local/bin: exists and is writable.
  Directory /usr/local/lib: exists and is writable.
  Directory /var/lib: exists and is writable.
  Directory /usr/local/lib/rkhunter/scripts: creating: OK
  Directory /var/lib/rkhunter/db: creating: OK
  Directory /var/lib/rkhunter/tmp: creating: OK
  Directory /var/lib/rkhunter/db/i18n: creating: OK
 Installing check_modules.pl: OK
 Installing filehashsha.pl: OK
 Installing stat.pl: OK
 Installing readlink.sh: OK
 Installing backdoorports.dat: OK
 Installing mirrors.dat: OK
 Installing programs_bad.dat: OK
 Installing suspscan.dat: OK
 Installing rkhunter.8: OK
 Installing ACKNOWLEDGMENTS: OK
 Installing CHANGELOG: OK
 Installing FAQ: OK
 Installing LICENSE: OK
 Installing README: OK
 Installing language support files: OK
 Installing rkhunter: OK
 Installing rkhunter.conf: OK
Installation complete

Instalując program ze źródeł powinniśmy doinstalować program Unhide. Rkhunter instalowany z oficjalnych repozytoriów debiana ma już w zależnościach program unhide. Unhide jest aplikacją, która wykrywa ukryte procesy w systemie. Jest dobrym uzupełnieniem skanera Rkhunter. Można go zainstalować z repozytoriów jak i samemu skompilować. Nie będę opisywać kompilacji, ponieważ na kilku systemach zakończyła się niepowodzeniem. Zainstalowana z repozytoriów działa prawidłowo. Można to sprawdzić sprawdzając logi:

root@jvm grep -A2 "hidden_procs" /var/log/rkhunter.log
[20:49:15] Info: Starting test name 'hidden_procs'
[20:49:15] Info: Found the 'unhide' command: /usr/sbin/unhide
[20:49:15] Info: Found 'unhide' command version: 20100201

Jeżeli po powyższym spradzeniu mamy inny komunikat to poszukajcie w logach: "Warning: The file '/usr/sbin/unhide' exists on the system, but it is not present in the rkhunter.dat file.". Wtedy należy jescze wykonać polecenie: rkhunter --propupd

Usuwanie skanera jeśli został zainstalowany ze źródeł jest dziecinnie proste, wystarczy wejść do katalogu ze źródłem i wydać polecenie: ./installer.sh --layout default --remove, prawidłowe usunięcie zwieńczy raport:

Starting uninstallation

Checking installation directory "/usr/local": it exists and is writable.
Removing installation files:
 Removing rkhunter.8: OK
 Removing /usr/local/bin/rkhunter: OK
 Removing /etc/rkhunter.conf: OK

Please remove any /etc/rkhunter.conf.* files manually.

Removing installation directories:
 Removing /usr/local/lib/rkhunter: OK
 Removing /usr/local/share/doc/rkhunter-1.4.0: OK
 Removing /var/lib/rkhunter: OK

Finished removing files. Please double-check.

Pierwsze uruchomienie

Przed uruchomieniem dokonamy aktualizacji następującymi komendami (co dokładnie oznaczają: man rkhunter):

rkhunter —update
rkhunter --propupd
#skanowanie, ewenualnie z opcją --sk (skip keypress)
rkhunter -c

Należy wspomnieć o możliwości bogatej konfiguracji skanera znajującej się przeważnie w /etc/rkhunter.conf lub /usr/local/etc/rkhunter.conf

Nie zamierzam się rozpisywać o konfiguracji, każda opcja w pliku rkhunter.conf jest dość dobrze opisana. Prostym przykładem może byc ostrzeżenie o możliwości zdalnego logowania się przez ssh na konto root. Jeśli jesteśmy świadomi zagrożenia i denerwuje nas to ostrzeżenie wystarczy w pliku konfiguracyjny zmienić z ALLOW_SSH_ROOT_USER=no na ALLOW_SSH_ROOT_USER=yes.

#ALLOW_SSH_ROOT_USER=no
Performing system configuration file checks
   Checking for SSH configuration file                      [ Found ]
   Checking if SSH root access is allowed                   [ Warning ]
   Checking if SSH protocol v1 is allowed                   [ Not allowed ]

#ALLOW_SSH_ROOT_USER=yes
Performing system configuration file checks
   Checking for SSH configuration file                      [ Found ]
   Checking if SSH root access is allowed                   [ Allowed ]
   Checking if SSH protocol v1 is allowed                   [ Not allowed ]

Cykliczne skanowanie systemu

Zapewnienie odpowiedniego poziomu bezpieczeństwa wymaga od nas systematyczności w działaniu. Tak jak powinno się dbać o aktualizację systemy tak powinniśmy go skanować. Twórcy Rkhunter wbudowali kilka opcji, które są przydatne do cyklicznego skanowania. Najlepiej posłużyć się cronem, pamiętając o podaniu pełnych scieżek. W tym przypadku sprawdzamy: whereis rkhunter i whereis mail. Skrypt będzie uruchamiany codziennie, wymagany jest zainstalowany serwer smtp.
Tworzymy plik: /etc/cron.daily/rkhunter.sh, nadając uprawnienia: chmod 755 etc/cron.daily/rkhunter.sh

#!/bin/sh
(
/usr/local/bin/rkhunter --versioncheck
/usr/local/bin/rkhunter --update
/usr/local/bin/rkhunter --cronjob --report-warnings-only
) 2>&1 | /usr/bin/mail -s "RKhunter Raport" nasz_login@domena.pl

Rkhunter a OpenVZ

Nie miałem okazji testować skanera na innego typu wirtualizacjach ale na OpenVZ Rkhunter potrafi kolokwialnie ujmując "sypać ostrzeżeniami". W telegraficznym skrócie OpenVZ nie jest pełną wirtualizacją (m.in. wspólne jądro dla kontenerów). Błąd na który możemy się napotkać: Warning: The kernel modules directory '/lib/modules' is missing or empty. Wyeliminowanie ostrzeżenia wygląda następująco, edytujemy konfigurację: /etc/rkhunter.conf:

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps"
#dodajmy do stringa: os_specific
DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps os_specific"

Rkhunter - fałszywe alarmy

Jak w tytule - zdarzają się. Jednym z popularniejszech jest wykrycie: Xzibit Rootkit, jeżeli mamy zainstalowany pakiet hdparm . Z moich doświadczeń wynika, że na pewno rkhunter będzie nas alarmował zainstalowany z oficjalnych repozytoriów Debiana 6, choć i na innych dystrybucjach Xzibit Rootkit potrafi się "przypałętać". Błąd na pewno nie występuje od wersji Rkhunter 1.4.0. Jest kilka rozwiązań, możemy to zignorować, odinstalować hdparm (głupie rozwiązanie) albo wykorzystać funkcjonalność rkhunter-a, mianowicie białe listy. W pliku konfiguracyjnym odnajdujemy RTKT_FILE_WHITELIST i po kolei podajemy ściezki, o których Rkhunter fałszywie alarmował. Na przykład:

RTKT_FILE_WHITELIST="/etc/init.d/hdparm  /etc/init.d/.depend.boot"

Oczywiście musimy byc pewni, dodając do białej listy.