Narzędzia użytkownika

Narzędzia witryny


materialy:bezpieczenstwo:podstawy

Podstawowe zagadnienia administracyjne związane z bezpieczeństwem

Materiał poniższy obejmuje zakres tematów 110.1 Perform security administration tasks oraz 110.2 Setup host security dla LPI, egzamin 102, certyfikat LPIC-1. Jeśli chcesz sprawdzić praktycznie zakres poniższego materiału, możesz również zrealizować zadania.

Wstęp

Jednym z kluczowych zadań administratora jest dbanie o bezpieczeństwo systemu i usług. Nie każdy zdaje sobie sprawę, że bezpieczeństwo jest procesem. Ciągłe zmiany w technologiach, wykrywane błędy w oprogramowaniu, próby włamań z zewnątrz jak i wewnątrz środowiska w którym pracujemy, powszechnie dostępne exploity których mogą używać osoby nawet o znikomej wiedzy informatycznej, monitorowanie i ulepszanie zabezpieczeń wymaga ciągłej pracy. Zagadnienie to jest również o tyle skomplikowane, że wzrost bezpieczeństwa wpływa najczęściej na zmniejszenie „użyteczności systemu”. Ograniczenia, które mogą być nakładane ze względów bezpieczeństwa zmniejszają funkcjonalność systemu. Już na etapie projektowania powstają dylematy do rozstrzygnięcia i szacowanie - czy zysk z funkcjonalności jest większy w stosunku do potencjalnych strat wynikających z braku zabezpieczeń.

Poniższe zagadnienia dotyczą podstawowych aspektów bezpieczeństwa systemu, które każdy administrator powinien być świadomy i używać dla zabezpieczenia administrowanych zasobów jednocześnie dbając o rozwój biznesu dla którego systemy te działają.

Aktualizacja systemu

Podstawową operacją, którą powinien regularnie wykonywać administrator to aktualizacja oprogramowania w systemie.

Debian:

apt-get update && apt-get upgrade

CentOS:

yum update

Jeśli używamy stabilnych wersji dystrybucji, których aktualizacje są wcześniej przetestowane, możemy z małym ryzykiem aktualizację systemu skonfigurować jako zadanie zautomatyzowane. Przy bardzo ważnych systemach produkcyjnych zawsze warto przetestować wcześniej wpływ updatu na system i oprogramowanie na środowisku niższym. Na niższych środowiskach - przedprodukcyjnych automatyzacja updatów oszczędza czas operacyjny.

Bity SUID i SGID

Obok podstawowych uprawnień (zapis, odczyt, uruchamianie, przechodzenie przez katalog) nadawanych na obiekty w systemie są również dodatkowe atrybuty ułatwiające używanie systemu. Nadaje je się poprzez odpowiednie ustawienie bitu uprawnień za pomocą narzędzia chmod.

SUID

Atrybut SUID (set user id) jest ustawiany zazwyczaj na pliku binarnym uruchomieniowym lub skrypcie. Plik binarny czy skrypt mogą uruchomić użytkownicy, którzy maja do tego pliku uprawnienia read i execute. SUID zmienia użytkownika w kontekście którego program ten jest uruchomiony - jest nim zawsze właściciel pliku.

Przykładowo - właścicielem pliku binarnego /usr/sbin/pobierz-dane jest konto janek, jednocześnie wszyscy użytkownicy należący do grupy analitycy mają prawo uruchamiania tego pliku. Dzięki SUID ustawionym na skrypcie cały skrypt będzie działał tak, jakby uruchamiał go Janek, niezależnie który analityk ten program uruchomi.

Podstawowym przykładem wykorzystania tego atrybutu jest program passwd. Hasła użytkowników są przechowywane w pliku /etc/shadow do którego dostęp odczyt i zapis ma jedynie root. Ze względów oczywistych nikt poza kontem root nie powinien mieć dostępu do tego pliku. Jednak każdy użytkownik może zmienić hasło w systemie używając komendy passwd z ustawionym atrybutem SUID. Jest to możliwe dzięki temu, że program binarny z SUID po uruchomieniu pracuje w kontekście administratora. Sam użytkownik nie ma dostępu do wrażliwych danych na systemie, ale ma do niego dostęp program którego używa. Programy z ustawionym SUID są najczęściej programami, które pozwalają zwykłym użytkownikom na dostęp do zasobów do których ma tylko administrator. Sam program powinien dbać o to, aby operacje na danych były wykonywane bezpiecznie (program passwd nie odczytuje haseł, nie zmienia haseł innych użytkowników, jeśli uruchamia je zwykły user).

Uwaga: Niektóre dystrybucje ignorują atrybut SUID dla skryptów ze względów bezpieczeństwa.

Aby nadać atrybut SUID należy użyć komendy chmod na przykład z argumentem u+s

root@itmz-srv05:/usr/local/bin# ls -la po*
-rwxr-x---  1 root staff   61 May 24 12:28 pobierz-dane
root@itmz-srv05:/usr/local/bin# chmod u+s pobierz-dane 
root@itmz-srv05:/usr/local/bin# ls -la po*
-rwsr-x---  1 root staff   61 May 24 12:28 pobierz-dane

root@itmz-srv05:~# ls -la `which passwd`
-rwsr-xr-x 1 root root 45396 May 25  2012 /usr/bin/passwd

Ponieważ SUID nieodpowiednio użyty może spowodować sporą lukę w systemie, należy używać go ostrożnie i tylko tam gdzie jest to niezbędne. Proszę sobie wyobrazić konsekwencje ustawienia SUID na pliku /bin/rm.

Aby znaleźć w systemie plików z ustawionym SUID można użyć komendy find z parametrem -perm -4000

find /bin -perm -4000

SGID

Innym przydatnym atrybutem, tym razem przypisywanym głównie katalogom jest SGID. Katalog z tak ustawionym atrybutem ma tą właściwość, że wszystkie nowo tworzone pliki i katalogi w tym katalogu automatycznie dziedziczą GID (ID grupy właściciela) po tym katalogu. Jeśli utworzę katalog share z ustawioną grupą-właścicielem na marketing i atrybutem SGID to wszystkie pliki i katalogi w nim tworzone będę należeć również do grupy marketing.

Aby nadać atrybut SUID katalogowi należy użyć komendy chmod z argumentem g+s

root@itmz-srv05:/home# chmod g+s wspolne
root@itmz-srv05:/home# ls -lad wspolne
drwxrws--- 2 root marketing 4096 May 24 13:39 wspolne

Aby wyszukać w systemie katalogów z takimi uprawnieniami należy użyć komendy find z parametrem -perm -2000

Hasła i parametry kont użytkowników

Hasła dostępowe są podstawowym elementem bezpieczeństwa zapewniającym dostęp do określonych zasobów tylko powołanym do tego użytkownikom. Istnieje wiele dobrych praktyk odnośnie długości haseł, złożoności i częstotliwości zmian itp.

Do zmiany hasła służy komenda passwd. Uruchamiając ją bez parametrów można dokonać zmiany swojego hasła. Uruchamiając komendę z poziomu użytkownika root i z parametrem -u nazwa-usera można nadać nowe hasło dowolnemu użytkownikowi (gdyby na przykład hasło zapomniał).

Dodatkowym narzędziem do zarządzania kontami i hasłami jest komenda administracyjna chage:

root@itmz-srv05:/home# chage
Usage: chage [options] LOGIN

Options:
  -d, --lastday LAST_DAY        set date of last password change to LAST_DAY
  -E, --expiredate EXPIRE_DATE  set account expiration date to EXPIRE_DATE
  -h, --help                    display this help message and exit
  -I, --inactive INACTIVE       set password inactive after expiration
                                to INACTIVE
  -l, --list                    show account aging information
  -m, --mindays MIN_DAYS        set minimum number of days before password
                                change to MIN_DAYS
  -M, --maxdays MAX_DAYS        set maximim number of days before password
                                change to MAX_DAYS
  -R, --root CHROOT_DIR         directory to chroot into
  -W, --warndays WARN_DAYS      set expiration warning days to WARN_DAYS

Najważniejsze operacje, które można wykonać przy pomocy tej komendy:

  • wyświetlić informacje o parametrach konta dotyczące haseł (–list)
  • ustawić okres w dniach po którym hasło „wygasa” (ang. expiration) - po tym czasie użytkownik jest przy logowaniu zmuszony do zmiany hasła - MAX_DAYS;
  • ustawić ile dni wcześniej, przed „wygaśnięciem hasła” użytkownik będzie powiadamiany przy logowaniu, że wkrótce będzie musiał zmienić hasło - WARN_DAYS;
  • ustawić minimalny okres czasu, który musi minąć po zmianie hasła, aby ustawić kolejne, nowe hasło - MIN_DAYS - praktycznie niewykorzystywana funkcja, ustawiana domyślnie na 0;
  • jeśli hasło wygaśnie a użytkownik po wygaśnięciu nie zaloguje się do systemu przez określony czas - INACTIVE - wygasa konto i użytkownik nie jest w stanie zalogować się do systemu nawet ze starym hasłem;
  • w celach testowych można zmodyfikować znacznik czasu który jest przypisany do konta i oznacza datę, kiedy konto miało zmieniane hasło - LAST_DAY

Część tych samych, powyższych parametrów, można również modyfikować za pomocą komendy usermod.

Otwarte porty sieciowe

Jednym z pierwszych kroków jakie wykonuje atakujący system system lub urządzenie działające w sieci jest tzw. „skanowanie portów”. Jego efektem ma być uzyskanie listy otwartych portów TCP lub UDP które mogą wskazać potencjalną furtkę dostępu do systemu. Każda bowiem usługa, aby działać w sieci musi mieć otwarty port, aby klienci mogli z niej skorzystać. Jest oczywistym że serwer publiczny www będzie miał otwarty port 80 i prawdopodobnie 443 (https), Jednak praktyka pokazuje, że bardzo często inne usługi instalowane w systemie również otwierają porty sieciowe mimo, że tak na prawdę nie powinny swoich usług udostępniać na zewnątrz.

„Skanowanie portów” jest również podstawowym narzędziem procesu audytu bezpieczeństwa, które ma wykazać, czy przypadkiem nie mamy otwartych portów dla usług, które nie powinny być udostępnione na zewnątrz.

nmap

Narzędziem do skanowania portów jest nmap. Zazwyczaj nie jest on domyślnie instalowany w systemie.

Debian:

apt-get install nmap

CentOS:

yum install nmap

Aby przeskanować urządzenie wystarczy jako argument podać jego nazwę sieciową lub adres IP

root@itmz-dsrv05:/home# nmap 192.168.122.195

Starting Nmap 6.00 ( http://nmap.org ) at 2014-05-24 16:20 CEST
Nmap scan report for itmz-csrv05.test.itmz.pl (192.168.122.195)
Host is up (0.00029s latency).
Not shown: 999 filtered ports
PORT   STATE SERVICE
22/tcp open  ssh
MAC Address: 08:00:27:5C:E5:05 (Cadmus Computer Systems)

Nmap done: 1 IP address (1 host up) scanned in 5.08 seconds

Powyższe skanowanie pokazuje, że na urządzeniu otwarty jest tylko jeden port tcp - 22, za którym prawdopodobnie stoi usługa serwera SSH.

Nmap pozwala za pomocą jednej komendy zeskanować całą sieć. Poniżej przykład skanowanie całej sieci ograniczona do wysłania zapytania ping (nie ma skanowania portów):

nmap -sP 192.168.122.0/24

UWAGA: Jeśli nigdy nie skanowałeś portów i używasz narzędzia nmap po raz pierwszy - używaj go ostrożnie i tylko wobec własnych systemów we własnej sieci. Ze względu na to, że „skanowanie” jest często pierwszą czynnością, którą wykonuje potencjalny włamywacz to jest również obiektem monitoringu. Urządzenia i systemy monitorujące ruch w sieci próbują taki ruch wykryć i informować firewalle o konieczności zablokowania ruchu od potencjalnych „włamywaczy” (Intrusion Prevention Systems).

Administratorzy sieci powinny używać systemów IPS i dbać o to, aby podejrzany ruch wychodzący z ich sieci był blokowany. Ruch taki może być generowany nie tylko przez użytkowników ale przede wszystkim przez „złośliwe oprogramowanie”, które będzie próbowało dokonywać ataków na zewnątrz, aby podejrzenie na atak padło na użytkownika w naszej sieci.

netstat

To czy port jest otwarty czy nie można oczywiście również sprawdzić będąc zalogowanym na systemie na którym otwartych portów się spodziewamy. Służy do tego narzędzie netstat.

Otwarte porty TCP oraz powiązane z nim programy/demony:

root@itmz-srvd05:/home# netstat -ltnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2144/sshd       
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      2307/exim4      
tcp        0      0 0.0.0.0:48697           0.0.0.0:*               LISTEN      1524/rpc.statd  
tcp6       0      0 :::51534                :::*                    LISTEN      1524/rpc.statd  
tcp6       0      0 :::22                   :::*                    LISTEN      2144/sshd       
tcp6       0      0 ::1:25                  :::*                    LISTEN      2307/exim4      

Otwarte porty UDP oraz powiązane z nim programy/demony:

root@itmz-srvd05:/home# netstat -lunp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 0.0.0.0:68              0.0.0.0:*                           1491/dhclient   
udp        0      0 0.0.0.0:38218           0.0.0.0:*                           1491/dhclient   
udp        0      0 127.0.0.1:852           0.0.0.0:*                           1524/rpc.statd  
udp        0      0 192.168.122.115:123     0.0.0.0:*                           2048/ntpd       
udp        0      0 127.0.0.1:123           0.0.0.0:*                           2048/ntpd       
udp        0      0 0.0.0.0:123             0.0.0.0:*                           2048/ntpd       
udp        0      0 0.0.0.0:48288           0.0.0.0:*                           1524/rpc.statd  
udp6       0      0 :::43128                :::*                                1524/rpc.statd  
udp6       0      0 fe80::a00:27ff:fed6:123 :::*                                2048/ntpd       
udp6       0      0 ::1:123                 :::*                                2048/ntpd       
udp6       0      0 :::123                  :::*                                2048/ntpd       
udp6       0      0 :::54950                :::*                                1491/dhclient   

Limity systemowe na kontach użytkowników

Jeśli serwer jest użytkowany przez wiele osób (np. serwer uczelniany na który logują się setki studentów do shella) należy dla zapewnienia bezpieczeństwa systemu rozważyć wprowadzenie limitów dla kont użytkowników. Istnieje wtedy ryzyko przeciążenia zasobów ze względu na skalę użytkowników i potencjalne przeciążenie przez któregoś z nich.

Limity również przydają się wobec kont technicznych aby serwisy, uruchamiane w kontekście tych kont, nie spowodowały przeciążenia systemu i nie wpłynęły negatywnie na inne serwisy. Ma to szczególne znaczenie, jeśli mamy do czynienia z usługą „niedojrzałą”, co do której mamy podejrzenie, że została niedbale napisana przez programistów i stanowi potencjalne źródło ryzyka.

Za pomocą PAM i modułu pam_limits system kontroluje, czy limity nie zostały przekroczone.

Limity są definiowane w pliku /etc/security/limits.conf. Zazwyczaj na początku tego pliku zapisane są krótkie opisy możliwych limitów w postaci komentarzy. Same limity są definiowane w postaci czterech kolumn:

  • <domain> - nazwa użytkownika lub grupy (poprzedzona @) lub wildcard * (wszyscy);
  • <type> - typ limitu - soft lub hard - niektóry limity mogą być modyfikowane przez użytkowników w zakresie od wartości soft do hard za pomocą komendy ulimit;
  • <item> - oznacza rodzaj limitu
  • <value> - oznacza wartość limitu

Przykładowo:

#<domain>      <type>  <item>         <value>

u1              soft    nofile          20
u1              hard    nofile          40
cpu             hard    cpu             1
@student        hard    nproc           7
@student        -       maxlogins       4

Powyższe nakłada następujące limity:

  • konto użytkownika u1 może mieć maksymalnie 20 otwartych plików, ale użytkownik może zwiększyć ten limit do 40 (za pomocą komendy ulimit -n 40);
  • czas działania dowolnego procesu użytkownika nie może przekroczyć 1 minutę czasu procesora (CPU) (chcesz przetestować czas procesora użyty przez program - uruchom time komend a w wyniku otrzymasz wartość czasu użycia procesora - sys);
  • każdy z użytkowników grupy student może uruchomić maksymlanie 7 procesów;
  • wszyscy użytkownicy należący do grupy student mogą być zalogowani równolegle maksymalnie na 4 powłokach (każdy z nich maksymalnie 4 razy).

Każdy użytkownik może sprawdzić nałożone na jego konto limity przy pomocy:

ulimit -a

Listę otwartych plików można sprawdzić przy pomocy komendy lsof:

lsof #lista wszystkich otwartych plików w systemie
lsof -u u1 #lista otwartych plików przez użytkownika u1

Substitude user do (sudo)

Oprogramowanie sudo pozwala na uruchamianie komend w kontekście innych użytkowników. Funkcjonalność ta jest więc podobna do ustawiania bitu SUID na pliku uruchomieniowym. Jednak sudo pozwala na bardziej złożone reguły określające kto może się „podszyć”, pod kogo, jakie określone komendy może uruchomić i na jakich systemach.

Najczęściej spotykanym zastosowaniem sudo jest wykonywanie komend wymagających uprawnień roota bez logowania się wprost na konto użytkownika root. Obecnie większość dystrybucji w ten właśnie sposób jest skonfigurowana zaraz po instalacji. Wystarczy, że użytkownik uruchomi

sudo komenda

a komenda będzie uruchomiona w kontekście usera root. Sudo wcześniej zapyta o hasło użytkownika, który sudo wywołał (a nie hasło roota). Proszę zwrócić uwagę, że nie jest w takim przypadku potrzebna wiedza, jakie jest hasło roota. Brzmi niebezpiecznie? Na szczęście takie uprawnienia posiada tylko jeden user po instalacji - zazwyczaj administrator, który podczas instalacji został poproszony o założenie „konta administracyjnego”.

Sudo można skonfigurować i używać tak, aby wywoływać komendy nie tylko jako root ale jako dowolny użytkownik (jeśli oczywiście konfiguracja sudo na to pozwala):

sudo -u user komenda

Konfiguracja sudo znajduje się w pliku /etc/sudoers niemniej jednak nie powinno się edytować pliku bezpośrednio a jedynie za pomocą komendy visudo (bez parametrów). Plik można ewentualnie podejrzeć, aby zobaczyć jaka jest obecna konfiguracja. visudo automatycznie wykonuje sprawdzenie składni przy próbie zapisania konfiguracji.

Każda linia pliku to jeden wpis konfiguracyjny. Najogólniej składnia linii wygląda następująco:

UZYTKOWNIK SYSTEM=(JAKOKTO) NOPASSWD: KOMENDA

Legenda:

  • UZYTKOWNIK - nazwa użytkownika lub grupy (poprzedzona znakiem %) z użytkownikami którzy mogą wykonywać operacje uruchamiania komend jako inny użytkownik;
  • SYSTEM - nazwa domenowa hosta na którym można wykonywać komendę, jeśli wpisane ALL to można wykonywać na dowolnym systemie;
  • JAKOKTO - nazwa użytkownika w kontekście którego można uruchamiać komendy, jeśli wpisane ALL można uruchamiać jako dowolny użyhtkownik, jeśli (JAKOKTO) nie występuje w linii oznacza, że komendę można uruchamiać „jedynie” jako root;
  • NOPASSWD: - ten opcjonalny wpis oznacza, że sudo nie zapyta się o hasło użytkownika;
  • KOMENDA - komenda wraz z pełną ścieżką i parametrami, która może być użyta przez sudo, jeśli wpisane ALL to można uruchomić dowolną komendę.

Poniżej kilka przykładów pliku konfiguracyjnego po uruchomieniu programu visudo wraz z wyjaśnieniem:

# pozwol na serwerze itmz-srvc05 uzytkownikowi u1 uruchomic 
# komende "/bin/cat /etc/shadow"
u1 itmz-srvc05=/bin/cat /etc/shadow

# pozwol na serwerze itmz-srvc05 uzytkownikowi u1 uruchomic 
# komende "/bin/touch /tmp/plik-u2" w kontekscie uzytkownika u2
u1 itmz-srvc05=(u2) /bin/touch /tmp/pliku2

# pozwol na dowolnym systemie uzytkownikowi u2 uruchomic 
# komende "/bin/touch /tmp/plik-u1" w kontekscie uzytkownika u1
u2 ALL=(u1) /bin/touch /tmp/plik-u1

# pozwol wszystkim uzytownikom, ktorzy naleza do grupy admins
# uruchamianie dowolnych komend (ostatnie ALL)
# na dowolnym systemie 
# w kontekscie dowolnego uzytkownika, 
# bez podawania wlasnego hasla,
%admins ALL=(ALL) NOPASSWD:ALL

Plik konfiguracyjny oprogramowania sudo może również zawierać aliasy komputerów, użytkowników czy komend używanych w innych miejscach konfiguracyjnych. Dokumentacja dystrybucji Gentoo posiada dobry przewodnik po narzędziu sudo, który można polecić również użytkownikom innych dystrybucji.

LPI 110.1 Perform security administration tasks

Zakres tematyki 110.1 w zapisie oryginalnym ze strony http://www.lpi.org:

Description: Candidates should know how to review system configuration to ensure host security in accordance with local security policies.

Key Knowledge Areas:

  • Audit a system to find files with the suid/sgid bit set.
  • Set or change user passwords and password aging information.
  • Being able to use nmap and netstat to discover open ports on a system.
  • Set up limits on user logins, processes and memory usage.
  • Basic sudo configuration and usage.
  • Terms and Utilities: find passwd lsof nmap chage netstat sudo /etc/sudoers su usermod ulimit

Shadow passwords - przechowywanie haseł w systemie

Hasła w systemie Linux nie są zapisywane czystym tekstem a w sposób zakodowany. Zajrzyj jako administrator do pliku /etc/shadow aby się o tym przekonać. Drugie pole tego pliku konfiguracyjnego dla użytkownik to zakodowane hasło:

cat /etc/shadow

Dawniej hasła były przechowane w pliku /etc/passwd, obecnie tylko we wspomnianym /etc/shadow, który jest dostępny do odczytu jedynie dla użytkownika root. /etc/passwd musi być możliwy do odczytu przez wszystkich użytkowników, gdyż są tam zapisane podstawowe informacje dla konta (choćby nazwa, UID i GID użytkownika).

Hasło jest kodowane przy pomocy jednokierunkowej funkcji haszującej (podobnie do md5) - to znaczy dla dowolnego ciągu znaków (w tym przypadku hasła) generowany jest inny ciąg znaków - hash. Dla tego samego ciągu znaków (hasła) funkcja haszująca wygeneruje zawsze ten sam hash. Znając hash nie ma możliwości odtworzenia pierwotnego ciągu znaków (hasła). Weryfikacja hasła podawanego na przykład przy logowaniu odbywa się na wykonaniu funkcji haszującej wobec podanego przez użytkownika hasła i porównanie wyniku z hashem hasła oryginalnego zapisanego w /etc/shadow. Obecnie jedyną metodą złamania tak zarejestrowanych haseł jest czasochłonna metoda brute force, jednak wobec „słabych i krótkich haseł” jest bardzo skuteczna.

Aby wzmocnić bezpieczeństwo, przy tworzeniu hasła jest dodawana tak zwana „sól” - wygenerowany losowo ciąg znaków doklejany do hasła. Hasło z solą jest dopiero „przepuszczane” przez funkcję haszującą. Dzięki temu to samo hasło może być zapisywane w systemie pod innym ciągiem znaków (hasło to samo, ale sól inna). Sól również jest zapisywana w /etc/shadow, aby odkodowanie hasła było w ogóle możliwe.

/etc/nologin

Jeśli plik /etc/nologin zostanie utworzony w systemie, system uwierzytelniania PAM nie pozwoli na zalogowanie do systemu jakiegokolwiek użytkownika poza root. Ta funkcjonalność przydaje się, jeśli prowadzimy prace maintanance i chcemy uniemożliwić na jakiś okres dostęp do systemu zwykłym użytkownikom.

Super-serwery i wrappery

Serwisami pracującymi samodzielnie (ang. standalone) określa się te, które same obsługują połączenie sieciowe z klientami, nie korzystają z pośredników. Są odpowiedzialne za otwarcie odpowiedniego portu, nasłuchiwanie na nim i zarządzanie dostępem do usługi (np. ograniczeniem połączeń, gdy tych jest zbyt dużo). Przykładowo, demon sshd do zdalnego zarządzania systemem może działać jako samodzielnie pracujący serwis, który nasłuchuje na porcie 22. Popularne i większe serwisy, takie jak Apache, Squid, Samba działają najczęściej samodzielnie, bez pośredników.

„Internet deamon” (inetd) lub „Extended Internet daemon” (xinetd) są serwisami, które tworzą dodatkową warstwę w połączeniu klient-serwer. Wprowadzają do systemu inny sposób uruchamiania serwisów w systemach operacyjnych rodziny UNIX i mapowania portów. Nazywane są często super-demonami lub super-serwerami, gdyż jego głównym zadaniem jest uruchamianie innych demonów oraz zarządzanie dostępem do nich. xinetd jest zupełnie nowszym produktem od inetd, choć jego podstawowa funkcjonalność jest taka sama. Obecnie super-serwisy mogą ale nie muszą być instalowane domyślnie w systemach operacyjnych Linux.

W przypadku, gdy w systemie zainstalowany jest super-serwis, może on pośredniczyć w nawiązywaniu połączenia między klientami a innymi serwisami, na przykład serwisem telnet.

Telnet jest niepolecany jako usługa do zdalnego dostępu do systemu gdyż nie zapewnia szyfrowania przesyłanych informacji (również hasła). W niniejszym opisie jest przedstawiony jako przykład serwisu, który można uruchomić przez super-serwis.

W tym przypadku super-serwis nasłuchuje na porcie 23, na którym normalnie nasłuchiwałby telnet. Inetd oczekuje na połączenia klientów, które są inicjowane na porcie 23. Serwis telnet nie nasłuchuje na porcie zewnętrznym interfejsu sieciowego, nie czeka na klientów, co więcej, nie musi być nawet uruchomiony. Klient telnet zestawia połączenie z portem 23, na którym pracuje super-serwis, który natomiast na podstawie konfiguracji wie, że jest to połączenie dedykowane dla serwisu telnet. Uruchamia ten serwis i przekazuje mu dane otrzymane od klienta. Dla klienta jest to rozwiązanie przeźroczyste, klient nie wie, że łączy się pośrednio przez jeszcze jeden serwis. Istnieje wiele prostych usług, które mogą działać przy pomocy pośrednika super-serwisu: serwery ftp, echo, talk, pop3, imap czy finger.

inetd

Serwis inetd jest konfigurowany za pomocą jednego pliku konfiguracyjnego - /etc/inetd.conf. Każda linia pliku konfiguracyjnego zawiera informacje o jednej usłudze kontrolowanej przez inetd. Przeglądając zawartość tego pliku można zauważyć, iż wiele usług zostało już skonfigurowanych lub są gotowe do włączenie poprzez usunięcia znaku komentarza - znak # na początku linii. Wcześniej należy tą usługę zainstalować w systemie).

Każda linia powinna zawierać przynajmniej 6 pierwszych parametrów z 7 możliwych:

  1. Nazwa serwisu – znana z pliku /etc/services.
  2. Typ gniazda – zależy od typu wykorzystywanego gniazda (strumień, datagram, inne.) przez usługę (przy tcp – stream, przy udp – dgram).
  3. Protokół (jeden z wymienionych w /etc/protcols).
  4. Dodatkowe flagi określające, czy serwer jest jednowątkowy i inetd ma czekać (parametr „wait”) na zakończenie połączenia zanim zezwoli na następne, czy też serwer jest wielowątkowy i może obsługiwać kilka połączeń jednocześnie (parametr „nowait”).
  5. Użytkownik – określa nazwę konta użytkownika w kontekście którego uruchomiona zostanie usługa.
  6. Ścieżka do serwera – ścieżka bezwzględna do pliku binarnego serwera kontrolowanego przez inetd.
  7. Argumenty – dodatkowe argumenty przekazywane uruchamianemu serwisowi.
pop3    stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/popa3d

Powyższy wpis przedstawia konfigurację serwisu protokołu pocztowego POP, uruchamianej z prawami administratora systemu (root). Serwer jest wielowątkowy (nowait). Jeśli klient będzie chciał połączyć się z usługą pop3 (gdy połączy się z portem 110 – wg /etc/services), inetd uruchomi w kontekście roota polecenie: /usr/sbin/tcpd /usr/sbin/popa3d

Inetd jest skonfigurowany w ten sposób, aby uruchomienie demona popa3d odbyło się przy pomocy programu tcpd.

Podstawowy plik konfiguracyjny /etc/inetd.conf może być swobodnie poszerzony o pliki zawarte w katalogu /etc/inetd.d/, jeśli tylko podstawowy plik konfiguracyjny będzie zawierał linię:

include-inetd /etc/inetd.d;

tcpd

Program ten pozwala na większą kontrolę uruchamianych serwisów, jest związany z super-serwisem inetd, który wykorzystuje jego funkcjonalność. Argumentem przy wywoływaniu tcpd jest nazwa serwisu, który ma być uruchomiony. Tcpd może logować zdarzenia oraz przy pomocy tzw. „tcp wrappers” określać, którzy klienci mają dostęp do danej usługi.

TCP Wrappers

TCP Wrappers jest jedną z kontrolnych warstw komunikacji pomiędzy klientem a serwerem. Choć nie ma funkcjonalności firewalla, jest narzędziem, dzięki któremu można zwiększyć bezpieczeństwo systemu operacyjnego i jego usług. Nie każda usługa sieciowa korzysta z tej warstwy – nie każde połączenie sieciowe z serwerem jest zatem analizowane przez TCP Wrappers. Aby aplikacja serwisu sieciowego mogła używać tej warstwy musi korzystać z biblioteki TCP Wrappers. Aby aplikacja korzystała natomiast z tej biblioteki musi o to zadbać programista usługi, który często daje możliwość określenia podczas kompilacji, czy biblioteka ma być wykorzystana czy nie. Większość usług w systemach Linux są skompilowane tak, aby wspomnianą bibliotekę wykorzystać. Aby sprawdzić, czy dana usługa korzysta rzeczywiście z tej warstwy można wykonać komendę:

strings -f ścieżka-do-serwisu | grep hosts_access

Jeśli komenda nie zwróci żadnej informacji oznacza to, iż serwis nie korzysta z obsługi TCP Wrappers. Ścieżka-do-serwisu oznacza ścieżkę do pliku binarnego, który uruchamia serwis. Poniżej sprawdzany jest demon sshd (serwer SSH) z TCP Wrappers korzysta.

itmzsrv# strings -f /usr/sbin/sshd | grep hosts_access
/usr/sbin/sshd: hosts_access

TCP Wrappers potrafi odrzucić połączenie od komputerów, które administrator uważa za podejrzane - zna ich adresy IP lub domenowe i dokona zmian w plikach konfiguracyjnych.

Program tcpd, wykorzystywany przez inetd również korzysta z TCP Wrappers. Zanim jakikolwiek serwis będzie uruchomiony przy pomocy tcpd, wcześniej zostanie dokonana analiza, czy klient może z danego serwisu korzystać czy nie.

Konfiguracja TCP Wrappers

Konfiguracja TCP Wrappers ogranicza się do edycji dwóch plików - /etc/hosts.allow i /etc/hosts.deny. Pierwszy zawiera informacje o tym, do jakich usług i kto ma prawo dostępu. Drugi zawiera informacje do jakich usług i kto nie ma tego prawa. Domyślna polityka zezwala na dostęp do wszystkich usług wszystkim klientom. Oznacza to, iż brak wpisów w jednym jak i drugim pliku oznacza pełny dostęp do serwisów. TCP Wrappers analizuje najpierw plik hosts.allow, następnie hosts.deny. Obydwa pliki posiadają taką samą składnię. Każda linia to jedna reguła, która opisuje, czy określeni klienci mogą korzystać z podanej usługi (hosts.allow), czy też nie (hosts.deny). Aby uniknąć problemów ostatnia linia w każdym z tych plików powinna być pusta. Każda z linii definiujących dostęp lub nie do usługi musi być zgodna z formatem:

<usługa lub lista usług>: <lista klientów> [: <dodatkowe opcje>]

Usługa jest przedstawiona w postaci nazwy procesu lub listy procesów (oddzielonych przecinkami). Lista klientów to adresy IP bądź domenowe oddzielone również przecinkami. Przykładowy wpis:

in.telnetd, sshd: 192.168.0.33, .nasza-firma.pl

zamieszczony w pliku /etc/hosts.allow pozwoli użytkownikom, którzy łączą się z domeny nasza-firma.pl oraz z komputera o adresie 192.168.0.33 korzystać z usług uruchamianych przez programy in.telnetd i sshd. Proszę zwrócić uwagę na kropkę przed nazwą domeny, określającą zakres uwzględniający poddomeny. Zakres adresów IP można uzyskać umieszczając kropkę na końcu jednego z oktetów. Przykładowo:

in.telnetd: 10.2.

Linia powyższa umieszczona w pliku /etc/hosts.deny zabroni komputerom o adresach IP 10.2.x.x (za x dowolny numer z zakresu 0-255) dostępu do usługi telnet. Istnieją również inne sposoby przedstawienia zakresu adresów, można na przykład podać adres i maskę: 192.168.44.0/255.255.255.0. Aby określić wszystkie adresy czy też wszystkie usługi można posłużyć się słowem ALL. Na przykład dla pliku /etc/hosts.allow:

sshd: ALL

A dla pliku /etc/hosts.deny

ALL: ALL

Powyższa konfiguracja pozwoli wszystkim użytkownikom skorzystanie z usługi SSH. Natomiast do reszty usług wykorzystujących TCP Wrappers nikt nie będzie miał dostępu.

Więcej informacji na temat wpisów do plików konfiguracyjnych TCP Wrappers można uzyskać w dokumentacji:

man 5 hosts_access

xinetd

Serwis xinetd - nowszy i bardziej zaawansowany od inetd - jest konfigurowany z użyciem pliku /etc/xinetd.conf. Na końcu tego pliku zazwyczaj znajduje się wpis konfiguracyjny:

includedir /etc/xinetd.d

co oznacza, że w konfiguracji biorą również udział wszystkie pliki, które znajdą się w katalogu /etc/xinetd.d/ przy założeniu, że nazwa pliku nie zawiera kropki lub znaku tyldy (~) na końcu.

itmzsrv# ls /etc/xinetd.d/
chargen-dgram   daytime-dgram   discard-dgram   echo-dgram   tcpmux-server  time-stream
chargen-stream  daytime-stream  discard-stream  echo-stream  time-dgram

Powyżej zestaw plików konfiguracyjnych dla poszczególnych usług zapewnionych przez xinetd.

Konfiguracja usługi dla xinetd zawarta jest bloku konfiguracyjnym:

service nazwa
{
  parametr1 = wartosc
  parametr2 = wartosc
  ...
}

Kilka ważniejszych parametrów wraz z opisem:

  • disable - przyjmuje wartości yes lub no i określa czy usługa jest wyłączona czy włączona
  • type - określa typ usługi, xinetd ma kilka wbudowanych usług (jak na przykład echo) i te są prekonfigurowane w plikach w katalogu /etc/xinetd.d/ i dla nich wartość tego parametru to INTERNAL; pozostałe usługi mogą być serwisami RPC (wylistowane w systemie w /etc/rpc), serwisami o tzw. „znanych portach” - TCPMUX (wylistowane w /etc/services) lub żadnymi z powyżyszych - wtedy wartość powinna być UNLISTED
  • socket_type oraz protocol - określają typ wykorzystywanego gniazda i protokołu; dla serwisów tcp socket_type=stream, protocol=tcp; dla serwisów udp socket_type=dgram, protocol=udp
  • server - ścieżka do pliku binarnego serwisu, którego xinetd ma uruchamiać i ma być dla niego pośrednikiem
  • user - w kontekście jakiego użytkownika ma działać usługa
  • port - określa port pod jakim ma działać usługa (nie trzeba podawać, jeśli usługa należy do listy znanych usług - /etc/services)
  • log_type - typ logowania: FILE - do pliku lub SYSLOG - do lokalnego demona logów.

Główne parametry bezpieczeństwa i obciążenia:

  • only_from - określa dla jakich adresów usługa będzie dostępna (forma adresu IP, IP/Maska, nazwy hosta bądź domeny)
  • no_access - dla jakich adresów usługa jest niedostępna
  • access_times - określa czas w którym usługa jest dostępna, np. 06:00-09:59
  • max_load - jeśli minutowy load average zostanie przekroczony usługa nie będzie obsługiwała dodatkowych klientów do momentu zmniejszenia obciążenia systemu
  • cps - limituje liczbę przychodzących połączeń, przyjmuje dwie wartości liczbowe - pierwsza określa maksymalną liczbę połączeń na sekundę druga określa na jaki czas w sekundach serwis ma być wyłączony po przekroczeniu pierwszej granicy

Powyżej przedstawiono tylko ułamek możliwych opcji konfiguracyjnych. Wszystkie zostały dokładne opisane w dokumentacji:

man xineted.conf

Wyłączanie niepotrzebnych usług

Jednym z prostszych procesów, które można przydzielić do zadań administratora bezpieczeństwa jest wyłączanie usług nieużywanych i niepotrzebnych. Szczególnie w dużych organizacjach można spotkać wiele systemów, które kiedyś miały uruchomioną usługę „na chwilę do testów” natomiast nikt nie zadbał o jej wyłączenie. Aby usługę całkowicie wyłączyć, bez jej odinstalowywania, należy wykorzystać narzędzia używanej dystrybucji do wyłączania serwisów.

Szczególną uwagę należy zwrócić na dystrybucje Debian i pochodne, gdyż bardzo często zainstalowanie dowolnej usługi sieciowej powoduje od razu jej uruchomienie i dostęp bez ograniczeń.

Jeśli system, którym zarządzasz korzysta jeszcze z pliku /etc/inittab, możesz również zwrócić uwagę na to, jakie usługi uruchamiane są przy starcie lub zmianie runlevela. Jeśli któraś z nich nie jest niezbędna możesz taką usługę „zakomentować” (wykonaj koniecznie wcześniej backup pliku, gdyż plik /etc/inittab jest krytycznie ważny przy uruchamianiu systemu). W większości przypadków zmiany w tym pliku konfiguracyjnym nie będą potrzebne. Wspominamy o takiej możliwości, gdyż wskazuje na to organizacja LPI w temacie 110.2 Setup host security

LPI 110.2 Setup host security

Zakres tematyki 110.2 Setup host security w zapisie oryginalnym ze strony http://www.lpi.org:

Description: Candidates should know how to set up a basic level of host security.

Key Knowledge Areas:

  • Awareness of shadow passwords and how they work.
  • Turn off network services not in use.
  • Understand the role of TCP wrappers.
  • Terms and Utilities: /etc/nologin /etc/passwd /etc/shadow /etc/xinetd.d/* /etc/xinetd.conf /etc/inetd.d/* /etc/inetd.conf /etc/inittab /etc/init.d/* /etc/hosts.allow /etc/hosts.deny

Masz potrzebę, aby powyższa strona była rozbudowana? - Napisz do nas!.

materialy/bezpieczenstwo/podstawy.txt · ostatnio zmienione: 2015/03/15 22:41 przez mzalewski

(C) 2017 ITMZ Mariusz Zalewski