Wersja polska

English version & info about BUS(1) lectures in English

Bezpieczeństwo Usług Sieciowych 2

Terminy zajęć

• Wykłady -- s.23/c-3 w godz. 15:15-17:00, środy
• Zajęcia laboratoryjne -- sala 013/c3, L2.1

Egzamin:

• I termin (zwykły) -- TBD
• II termin (poprawkowy) TBD

Laboratorium:

• sniffing/podsłuchiwanie pakietów w sieci

  Przygotowanie się do zajęć:

  Należy znaleźć jakie programy w systemie unix/linux służą do monitorowania aktywności karty sieciowej i podłuchiwania pakietów.

  Zadania do wykonania w trakcie laboratorium:

  Podglądając pakiety sieciowe należy znaleźć, jak działają programy diagnostyczne wyznaczające routing: traceroute, mtr (w różnych trybach działania).

• skanowanie sieci

  1. Należy przeskanować sieć lokalną (np. 156.17.40/24) w poszukiwaniu wszystkich serwerów usług: HTTP, HTTPS, SSH, SMTP, FTP i usług logowania interaktywnego (telnet, rlogin, rsh i podobne)

  2. Korzystając z listy uzyskanej w punkcie (1) należy określić wersje serwerów i zaraportować te, które są niebezpieczne -- tzn. działający serwer to wersja uznawana za dziurawą. To, które programy są bezpieczne/dziurawe powinniście znaleźć samodzielnie - korzystająć z googla, archiwów list dyskusyjnych (np. bugtraq) i innych źródeł.

  Zadaniem tego skryptu jest pomoc administratorowi sieci lokalnej w wyszukiwaniu dziurawych serwerów w jego własnej sieci (stawianych ad hoc przez użytkowników) i z tego punktu widzenia liczy się funkcjonalność skryptu - nie wystarczy go uruchomić raz (bo jakiś serwer lokalny może być akurat wyłączony i uniknąć w ten sposób skanowania), tylko uruchamiamy go periodycznie, skanując sieć lokalną i interesują nas informacje o niebezpiecznych serwerach lokalnych.

  3. wśród serwerów poczty elektronicznej (znalezionych wcześniej) należy przeprowadzić zautomatyzowany test, sprawdzający czy serwer jest serwerem otwartym czy zamkniętym. Otwarty serwer to taki, który pozwala dowolnemu (nielokalnemu) klientowi wysłać pocztę adresowaną w świat - pozwalając tym samym spamerom na relayowanie swojego spamu do innych. Serwer zamknięty pozwoli w takim przypadku wyłącznie na przesłanie poczty adresowanej do użytkowników lokalnych, ale nie poczty idącej w świat.

  W tym celu należy przeprowadzić typową komunikację SMTP, np:

    220 cyber.ict.pwr.wroc.pl ESMTP Sendmail 8.9.3 Mon, 17 Apr 2000 21:00:00 +0200 (MET DST)
    ehlo okapi.ict.pwr.wroc.pl
    250-cyber.ict.pwr.wroc.pl Hello ts@okapi [156.17.42.30], pleased to meet you
    mail from: 
    250 ... Sender ok
    rcpt to: 
    250 ... Recipient ok
    rcpt to: 
    550 ... User not local, go away
  

  W powyższej konwersacji błąd 550 oznacza, że serwer nie jest serwerem otwartym (odrzucił pocztę). Gdyby na próbę wysłania poczty na adres nielokalny odpowiedzią serwera było "250 ..." (tak jak wcześniej dla lokalnego adresu xx@cyber.ict.pwr.wroc.pl>, to uznalibyśmy, że serwer jest otwarty.

  Narzędzia przydatne w realizacji zadania: netcat, chat (z pakietu ppp i pppd), awk, perl, sed i inne (nie wszystkie naraz :-) )

• OpenSSL

  Przygotowanie się do zajęć:

  dokumentacja SSL

  narzędzia: w podkatalogu ssl

  Slajdy z wykładu: openssl.pdf

  Cel zajęć:

  1. Utworzenie własnego CA

  2. Modyfikacja openssl.conf w celu wpisania parametrów domyślnych własnego CA.

  3s. Utworzenie i podpisanie certyfikatu serwera

  3k. Utworzenie i podpisanie przez CA kilku certyfikatów dla klientów, wygenerowanie wersji PKCS12.

  4s. Skonfigurowanie Apache WWW do używania certyfikatu serwera i nawiązywania komunikacji po https://

  4k. Skonfigurowanie klienta (Firefox) do używania certyfikatu klienckiego w postaci klucza PKCS12

  5. Skonfigurowanie serwera, by wybrane katalogi udostępniał tylko klientom zalogowanym za pomocą certyfikatów klienckich

  W raporcie należy zdokumentować wszystkie kolejne kroki, na tyle szczegółowo (komendy z parametrami, znaczenie plików, itd. -- analogicznie jak na str. 8 slajdów z wykładu), żeby powtarzając te kroki zgodnie z instrukcją można było jeszcze raz uzyskać dokładnie taką samą konfigurację (tyle, że z nowymi certyfikatami).

  Do raportu należy dołączyć wygenerowane certyfikaty (jeśli zostały zabezpieczone hasłami, to także hasła do nich -- wystarczy w opisie/raporcie), plik openssl.conf, konfigurację serwera Apache lub diff względem wersji standardowej, spakowaną zawartość katalogów serwera (klucze, certyfikaty i serwowana strona).

• OpenSSL - API

  Przygotowanie się do zajęć:

  dokumentacja SSL

  narzędzia: w podkatalogu ssl

  Slajdy z wykładu: ssl-api.pdf

  Cel zajęć:

  Napisanie w języku C aplikacji klient-serwer używającej SSL do autoryzacji dostępu. W tym celu należy wykorzystać certyfikaty serwera/klienta wygenerowane na poprzednich zajęciach (lub powtórzyć proces, generując nowe) i wzbogacić aplikację o nawiązywanie bezpiecznego połączenia z użyciem SSL i wzajemną weryfikację certyfikatów. Zaimplementować można np. serwer chat pozwalający na połączenie się kilku klientów i przesyłanie kounikatów między nimi, albo tablicę ogłoszeń (klient łączy się z serwerem i odczytuje komunikaty/ogłoszenia pozostawione dla niego lub publicznie, sam może kasować swoje ogłoszenia i wysyłać nowe - do konkretnego innego klienta lub do wszystkich (publicznie)).

  Najbardziej istotny jest aspekt weryfikacji toższamości klienta za pomocą certyfikatu oraz samo ustanowienie bezpiecznej/szyfrowanej komunikacji za pomocą SSL -- w miarę możliwości nie tylko za pomocą parametrów domyślnych, ale także np. z wyborem konkretnej metody szyfrowania.

• firewalle

  Firewalle - wg dostarczonych specyfikacji projektów, różnych dla poszczególnych grup. Oddać należy papierową wersję sprawozdania - może to być skrypt firewalla, ale uzupełniony komentarzami.