Bezpieczeństwo Usług Sieciowych dr inż. Tomasz Surmacz 30 stycznia 2015
Zagadnienia wstępne Zagadnienia wstępne Semestr 2 studiów mgr: 30h wykładu (środy 15:15-17:00) Forma zaliczenia: kolokwium ostatni tydzień zajęć (ustalimy dokładną datę w ciągu najbliższych 2-3 tygodni) laboratorium: 30h zajęć w 013/c3 (terminy po ok. 10-12 osób) Forma zaliczenia: obecność, sprawozdania z ćwiczeń Konsultacje i formy kontaktu Konsultacje: wtorek 13:00-15:00, środa 17:00-19:00 pok. 105/C3 e-mail: tsurmacz@ict.pwr.wroc.pl, tomasz.surmacz@pwr.wroc.pl, Subject: BUS WWW: http://dream.ict.pwr.wroc.pl/bus/ Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 2
Zagadnienia wstępne Literatura Garfinkel & Spafford Bezpieczeństwo w Uniksie i Internecie Silberschatz, Abraham Podstawy systemów operacyjnych Literatura uzupełniająca Bach, Maurice J. Budowa systemu operacyjnego UNIX Stevens, W. Richard Programowanie zastosowań sieciowych w systemie UNIX Schneier, Bruce Kryptografia dla praktyków Kutyłowski, Mirosław Kryptografia. Teoria i praktyka zabezpieczania systemów komputerowych Clifford Stoll Kukułcze jajo Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 3
Zagadnienia wstępne Tematyka wykładu Zagrożenia w warstwie 3 protokołów IP (ICMP, UDP, TCP) Sniffing i spoofing Zagrożenia poszczególnych usług w protokołach TCP/IP i UDP/IP (SMTP, FTP, itp.) Zagrożenia bezpieczeństwa aplikacji, wirusy, konie trojańskie, robaki, błędy konfiguracji systemów Problemy bezpieczeństwa w programowaniu aplikacji Programy systemowe działające z uprawnieniami nadzorcy systemu Skanowanie portów i metody aktywnego badania stanu sieci Filtry pakietów Systemy firewall Polityka bezpieczeństwa Secure Sockets Layer (SSL) i inne mechanizmy warstw 3-7 (S-HTTP, PGP) Elementy bezpieczeństwa w protokole IPv6; IPSec Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 4
Bezpieczeństwo komputerów i usług sieciowych Bezpieczeństwo komputerów i usług sieciowych Bezpieczeństwo poszczególnych komputerów Bezpieczeństwo serwerów sieciowych Bezpieczeństwo routerów Bezpieczeństwo fizyczne połączeń Bezpieczeństwo protokołów używanych do transmisji danych Bezpieczeństwo fizyczne sprzętu i zapasowych kopii danych Bezpieczeństwo danych w systemie komputerowym Kontrola dostępu do danych i do systemu Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 5
Aspekty bezpieczeństwa systemu Bezpieczeństwo i niezawodność usług sieciowych Niezawodność sprzętu Czy niezawodność na poziomie 99,7% (lub 0,997) jest wystarczająco dobra? Może 99,97% (lub 0,9997)? Czy MTBF (mean time between failure średni czas pomiędzy uszkodzeniami) rzędu 100000 godzin jest wystarczająco długi? Ochrona przed niezamierzonym lub złośliwym nadużywaniem sprzętu i usług. Ochrona przed wykradzeniem danych. Ochrona przed używaniem systemu niezgodnie z przeznaczeniem. Aspekty bezpieczeństwa systemu Bezpieczeństwo sprzętu Bezpieczeństwo dostępu Bezpieczeństwo systemu operacyjnego Wytyczne i procedury Polityka bezpieczeństwa Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 6
Sniffery Sniffery Warstwy sieciowe (1-4) w sieciach TCP/IP przesyłają dane w postaci jawnej. Metoda komunikacji w medium transmisyjnym rozgłaszanie (broadcast). Mając fizyczny dostęp do medium transmisyjnego (kabel sieciowy, host) można podsłuchiwać cały przechodzący ruch. host1 host2 host3 host4 host10 host9 host5 Ethernet 10base2 host6 Token Ring Ethernet 10base5 host8 host7 host11 PPP/SLIP host14 *c(ts host12 hub host16 host5 host13 Ethernet 100BaseT Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 7
Sniffery Punkty narażone na podsłuch Kable w sieci lokalnej, huby, routery sieci lokalnych. Wszystkie routery i urządzenia sieciowe znajdujące się pomiędzy komunikującymi się hostami. Wszystkie urządzenia sieciowe zdolne do przekierowywania ruchu. Lokalna stacja robocza. W systemach z dostępem zdalnym: lokalny terminal lub pseudo-terminal (/dev/ttyxx, /dev/ptyxx). Pliki tymczasowe w katalogu /tmp z niewłaściwymi prawami dostępu. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 8
Sniffery Punkty narażone na podsłuch poziom protokołów SMTP: wszystkie hosty MX, WWW, FTP: serwery proxy, Firewall w sieci lokalnej idealne miejsce do włamań i założenia podsłuchu całej sieci. radio przez internet: routery milticastowe IRC: serwery IRC Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 9
Sniffery Sniffery Wiele różnych programów dostępnych jest zarówno w środowisku UNIX jak i MS-Windows. Solaris: snoop Linux, *BSD: tcpdump Wszystkie systemy UNIX: specyficzne sniffery ukierunkowane na zbieranie haseł z nawiązywanych połączeń FTP, POP3 i innych protokołów. Wiele z nich można znaleźć pod adresem http://freshmeat.net/ lub http://sourceforge.net/ Niektóre nazwy: snort, IPgrab, ettercap, One Way Network SNiffer, etc. Przykładowy wynik działania: 49 asic ts/pub/src# snoop cyber asic -> cyber TELNET C port=53218 cyber -> asic TELNET R port=53218 login: asic -> cyber TELNET C port=53218 asic -> cyber TELNET C port=53218 t cyber -> asic TELNET R port=53218 t asic -> cyber TELNET C port=53218 asic -> cyber TELNET C port=53218 s cyber -> asic TELNET R port=53218 s asic -> cyber TELNET C port=53218 cyber -> asic TELNET R port=53218 s/key 90 cy11009\r\n asic -> cyber TELNET C port=53218 cyber -> asic TELNET R port=53218 PASSCODE or Password asic -> cyber TELNET C port=53218 asic -> cyber TELNET C port=53218 a cyber -> asic TELNET R port=53218 asic -> cyber TELNET C port=53218 b cyber -> asic TELNET R port=53218 asic -> cyber TELNET C port=53218 c cyber -> asic TELNET R port=53218 asic -> cyber TELNET C port=53218 Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 10
Sniffery wykrywanie Sniffery wykrywanie Metody wykrywania oparte na zmianie zachowania karty sieciowej w trybie promiscuous Karta sieciowa pracująca w trybie promiscuous zmienia nieco sposób reakcji hosta na pewne pakiety sieciowe: pakiety adresowane (IP) do tego hosta, ale z innym adresem MAC pakiety ICMP pakiety ARP REQUEST i ARP REPLY Zwiększona liczba odbieranych i analizowanych pakietów zwiększa czas reakcji na przychodzące pakiety. Ale czas reakcji zwiększa także jakiekolwiek inne obciążenie procesora innymi zadaniami. Wniosek Bardzo trudne, jeśli nie niemożliwe, do wykrycia. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 11
Sniffery wykrywanie Sniffery wykrywanie Metoda ICMP: Wysyłamy do podejrzanego hosta pakiet ICMP ECHO z jego adresem IP, ale cudzym lub nieistniejącym MAC. Normalnie, taki pakiet nie ma prawa dotrzeć na miejsce Karta w trybie promiscuous dostarcza taki pakiet do warstwy 3 i otrzymujemy ICMP REPLY Metoda ARP cache: ARP w dynamiczny sposób poznaje adresy MAC innych hostów w sieci lokalnej Wszystkie odpowiedzi ARP REPLY są zapamiętywane w cache ARP Pakiety ICMP ECHO i ICMP REPLY nie powodują aktualizacji cache ARP. Testujemy z hosta A o adresie IP-A i MAC-A, podejrzany: MAC-B, IP-B, używamy także nieistniejącego w sieci MAC-T i IP-T Wysyłamy pakiet PING ze źródłowym adresem MAC-T, IP-T na MAC-B,IP-B. Nie powinna pojawić się żadna odpowiedź. Wysyłamy do B pakiet ARP REPLY na adres docelowy MAC-T, IP-T, zawierający w środku tłumaczenie MAC-A = IP-T. Jeśli B działa normalnie, zignoruje to. Jeśli podsłuchuje - zapamięta tłumaczenie. Wysyłamy pakiet PING na adres docelowy MAC-B, IP-B, z adresem źródłowym MAC-T, IP-T. Jeśli B podsłuchiwał, odeśle odpowiedź na MAC-A, IP-T. Jeśli nie zacznie generować ARP REQ pytając o MAC-T. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 12
Sniffery podsumowanie Sniffery podsumowanie Mogą być zainstalowane praktycznie wszędzie; Duże sieci o płaskiej topologii dodatkowo ułatwiają podsłuchiwanie pakietów; Switche i routery pozwalają zredukować ruch w sieci lokalnej, jednocześnie zmniejszając możliwości podsłuchiwania; W dalszym ciągu jednak istnieje możliwość modyfikacji ich działania przez routing dynamiczny lub dynamiczny ARP. Karta sieciowa musi zostać ustawiona w tryb promiscuous, pozwalający na odbieranie wszystkich pakietów nadchodzących z sieci; Bardzo trudne lub niemożliwe do wykrycia zdalnie; W sieci Internet można znaleźć wiele skryptów i programów automatycznie zbierających i sortujących dane pochodzące z interfejsów sieciowych. mogą być używane także we właściwy sposób, by zbierać statystyki działania sieci lub do oceny charakterystyki ruchu. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 13
Podstawowe fakty dotyczące sieci IPv4 Podstawowe fakty dotyczące sieci IPv4 Warstwa sieciowa IP nie gwarantuje żadnej poufności danych (ani szyfrownaia). W IPv4 wszystkie dane przesyłane są otwartym tekstem. Szyfrowanie i kontrola integralności danych muszą być implementowane w wyższych warstwach, jeśli są konieczne. Dane przesyłane siecią komputerową mogą zostać podsłuchane. Skoro przesyłamy dane otwartym tekstem, a pakiety przechodzą przez wiele routerów i sieci, to we wszystkich tych miejscach może znajdować się ktoś, kto podsłuchuje nasze pakiety. Często musimy zaufać danym uzyskiwanym z serwerów znajdujących się poza naszą kontrolą. Wiele informacji o kluczowym znaczeniu (np. nazwy hostów zwracane przez DNS) jest zwracane przez serwery znajdujące się poza kontrolą lokalnego administratora, a więc niekoniecznie godnych zaufania. IPv4 i protokoły sieciowe projektowano z reguły nie biorąc pod uwagę zagrożeń bezpieczeństwa. Pakiety IP mogą być fałszowane, przechwytywane, modyfikowane i przekierowywane, podsłuchiwane. Można się też z ich pomocą podszywać pod inne urządzenia sieciowe lub hosty. Wiele protokołów projektowanych z myślą o poprawieniu bezpieczeństwa jest tak naprawdę tylko obejściem problemu, a nie jego prawdziwym rozwiązaniem, które często jest niemożliwe. Największa zaleta sieci IP nieograniczona enkapsulacja warstw oprogramowania i elastyczność stosowania poszczególnych rozwiązać są także najsłabszymi elementami, jeśli chodzi o bezpieczeństwo. Rozszerzenia protokołów związane z bezpieczeństwem muszą być wprowadzane jako osobne warstwy protokołów i dopiero po powszechnej akceptacji (do tego czasu eksperymentalnie, tak jak np. SSL, IPSec) Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 14
Podstawowe fakty dotyczące sieci IPv4 Poprawa bezpieczeństwa w sieciach IP Szyfrowanie transmisji. Używanie jednorazowych metod dostępu tam, gdzie szyfrowanie nie jest możliwe. Stosowanie warstw pośrednich zapewniających poprawę bezpieczeństwa SSL Certyfikaty serwerów Działanie zgodne ze zdrowym rozsądkiem (zakładając bezustanny podsłuch sieci). Stosowanie IPSec lub IPv6 Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 15
Spoofing Spoofing Spoofing DNS Komputery znajdujące się w sieci lokalnej z reguły darzone są większym zaufaniem niż pozostałe. Dostęp do niektórych usług oparty jest często na nazwach łączących się komputerów, np. weryfikacji, czy należą do lokalnej domeny. W celu znalezienia tłumaczenia nazwa adres IP używany jest system DNS (mapy zwykłe i odwrotne ). Mapy odwrotne związane są z adresami IP i należą do właścicieli odpowiednich klas adresowych. Nie ma sposobu, by powstrzymać kogoś przed rozgłaszaniem fałszywych informacji, na przykład: 1.3.0.63.in-addr.arpa. IN PTR sun1000.pwr.wroc.pl. Jak w takim przypadku zachowa się komputer, którego użytkownik dopisał swoje konto i nazwę sun1000.pwr.wroc.pl do pliku /.rhosts albo odpowiednich skryptów IRC, dających na podstawie nazwy IP dodatkowe uprawnienia? Jedynym sposobem weryfikacji tej informacji jest sprawdzenie zwykłej mapy: sun1000.pwr.wroc.pl IN A 156.17.1.33 IN A 156.17.250.100 Jeśli adres użyty do tłumaczenia IP-nazwa nie zostanie znaleziony wśród adresów uzyskanych po przetłumaczeniu nazwy na IP ktoś się bawi w spoofing DNS. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 16
Spoofing SMTP spoofing Wspólny protokół SMTP dla klientów poczty wprowadzających list do systemu poczty elektronicznej, jak i dla serwerów przekazujących go dalej brak rozróżnienia klient-serwer możliwości nadużyć możliwości obrony: IDENT, pola Received: telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is ^]. 220 papaja.wroc.apk.net ESMTP Sendmail 8.9.3/8.9.3; Wed, 6 Sep 2000 02:43:01 +0200 ehlo podszywacz 250 papaja.wroc.apk.net Hello localhost [127.0.0.1], pleased to meet you mail from: <santa@heaven.org> 250 <santa@heaven.org>... Sender ok rcpt to: <ts@localhost> 250 <ts@localhost>... Recipient ok data 354 Enter mail, end with "." on a line by itself From: Santa <santa@heaven.org> To: ts co mi zrobisz, jak mnie złapiesz?. 250 CAA05466 Message accepted for delivery Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 17
Spoofing Inne rodzaje spoofingu Spoofing uwierzytelniania i autoryzacji dostępu Spoofing serwerów NIS Spoofing dostępu do serwerów NFS PAP/CHAP/Radius? Spoofing serwerów dostępowych Spoofing serwerów WWW (sklepy, certyfikaty). Spoofing serwerów DNS. Ataki typu Man in the middle Spoofing ARP Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 18
Ataki w oparciu o ARP Ataki w oparciu o ARP W warstwie fizycznej i łącza karty ethernet używają do wysyłania pakietów adresu urządzenia (adres MAC), a nie adresu IP. W tym przypadku jest to 6-bajtowy adres karty ethernetowej. Tłumaczenie adresów IP na adresy MAC i odwrotnie odbywa się automatycznie, przy użyciu protokołów ARP (Address Resolution Protocol) i RARP (Reverse ARP). Solaris> arp -a Device IP Address Mask Flags Phys Addr ------ --------------------- --------------- ----- --------------- le0 ALL-SYSTEMS.MCAST.NET 255.255.255.255 01:00:5e:00:00:01 le0 rush 255.255.255.255 00:10:5a:48:1e:20 le0 hop.ict.pwr.wroc.pl 255.255.255.255 00:e0:63:04:1c:c0 le0 okapi 255.255.255.255 SP 08:00:20:73:c8:42 Linux> arp -a asic.ict.pwr.wroc.pl (156.17.41.90) at 08:00:20:7B:07:FA [ether] on eth0 gorg1.ict.pwr.wroc.pl (156.17.41.81) at 00:C0:DF:AC:9B:63 [ether] PERM on eth0 gorg2.ict.pwr.wroc.pl (156.17.41.82) at 00:C0:DF:C1:A2:CB [ether] PERM on eth0 test.ict.pwr.wroc.pl (156.17.41.69) at * PERM PUP on eth0 Wpisy tablicy ARP tworzone są dynamicznie w miarę potrzeb lub mogą tam zostać dodane ręcznie. Wszystkie wpisy dotyczą wyłącznie lokalnego segmentu ethernetu. Problem spoofing ARP. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 19
Dynamiczny ARP i spoofing Dynamiczny ARP i spoofing Internet router ARP! ftp.xyz.com FIREWALL www.xyz.com mail.xyz.com Strefa chroniona Pozwolenie na dynamiczny ARP w strefie zdemilitaryzowanej systemu firewall może prowadzić do opłakanych skutków. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 20
Serwer inetd Serwer inetd inetd lub in.inetd Internet-superdaemon (UWAGA!!! NIE identd), program uruchamiający inne serwery na żądanie wtedy, gdy są potrzebne, np: in.telnetd, in.ftpd, tftpd, in.fingerd, in.rshd, in.rlogind, in.rshd, in.rexecd, in.identd (pidentd), pop3d, itp. connect() listen(s1) Procesy uruchamiane przez inetd nie martwią się o nawiązywanie połączenia, lecz komunikują się z klientem przez swoje standardowe wejście i wyjście; inetd dla każdej usługi znalezionej w /etc/inetd.conf przydziela osobne gniazdko, przypisuje mu za pomocą bind() właściwy numer portu, wykonuje listen(), by zacząć nasłuchiwać na połączenia, po czym za pomocą select() czeka, aż na którymś z nich można będzie wykonać accept(); Jakiekolwiek wątpliwości dotyczące spoofingu IP muszą zostać rozwiane na poziomie inetd, bo później poszczególne serwery mogą nie zdawać sobie sprawy w istnienia jakiegokolwiek problemu. read() write() synchronizacja wymiana danych dziecko fork() fork() dup2(s2,0); dup2(s2,1); setuid(); exec("rshd"); read(0); write(1); select(...); s2=accept(); wait?: - zwalnia s1 - wait3(pid) rodzic Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 21
Serwer inetd Ochrona serwerów sieciowych przed spoofingiem Standardowy sposób uruchamioania inetd lub inetd i tcpd inetd telnet - nr portu? - setuid() - /usr/sbin/server telnetd klient serwer telnet inetd - nr portu? - setuid() - /usr/sbin/tcpd tcpd - spoofing? - hosts.allow? - /usr/sbin/server telnetd tcpd przed uruchomieniem serwera sprawdza: Poprawność tłumaczenia IP (spoofing) Informacje demona identd na komputerze klienta lokalne pliki hosts.allow i hosts.deny Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 22
Ochrona serwerów sieciowych tcp wrappers Ochrona serwerów sieciowych tcp wrappers Pakiet tcp wrappers autorstwa Wietse Vanemy pozwala ograniczać dostęp do wybranych usług sieciowych uruchamianych za pośrednictwem inetd, a także niektórych samodzielnie działających serwerów. Pozwala chronić serwer przed dostępem z zewnątrz Każda próba połączenia z chronionymi serwerami jest logowana (nawet, jeśli się nie powiedzie (nie zakończy zalogowaniem użytkownika) Serwery automatycznie chronione są przed DNS-spoofingiem, czyli podszywaniem się z użyciem DNS. Plik /etc/inetd.conf telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd Pliki /etc/hosts.allow i /etc/hosts.deny # router czyta swoją konfigurację przez tftp, pozostałe hosty nie mają # dostępu via tftp in.tftpd: router.ict.pwr.wroc.pl : allow in.tftpd: all : rfc931 : deny # pocztę powinniśmy przyjmować z każdego adresu sendmail : all : rfc931 : allow # inne usługi in.talkd,in.fingerd : 156.17.0.0/255.255.0.0 : rfc931 : allow in.talkd,in.fingerd : ALL : deny # telnet tylko z hostów zarejestrowanych w DNS in.telnetd : KNOWN : rfc931 : allow ALL : ALL : rfc931 : deny Informacje o udanych i nieudanych próbach połączeń zapisywane są za pośrednictwem demona systemowego syslog zwykle w pliku /var/log/maillog lub /var/log/syslog (z priorytetem local0.info lub mail.info, zależnie od opcji kompilacji). Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 23
Ochrona serwerów sieciowych tcp wrappers Mar 14 15:36:24 papaja in.ftpd[128]: connect from ts@localhost Mar 14 15:41:06 papaja in.rlogind[190]: warning: host name/name mismatch: cyber.ict.pwr.wroc.pl!= cyber Mar 14 15:41:06 papaja in.rlogind[190]: refused connect from 156.17.9.30 Mar 14 15:41:32 papaja uucico[201]: connect from uucp@okapi Mar 14 15:46:36 papaja in.fingerd[241]: connect from root@sun5.unc.edu Mar 14 15:47:19 papaja in.telnetd[249]: connect from sun1000.pwr.wroc.pl Mar 14 15:47:48 papaja in.telnetd[251]: refused connect from 156.17.30.11 Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 24
Ochrona serwerów sieciowych tcp wrappers Opcje konfiguracyjne w pakiecie TCP wrapper Wybór hosta/użytkownika ALL pasuje do wszystkich użytkowników, hostów i usług LOCAL pasuje do wszystkich hostów, w których nazwie nie ma kropki KNOWN pasuje do nazw hostów, których adres IP daje się rozwinąć do jakiejkolwiek nazwy w DNS. Przy włączonej opcji PARANOID nazwa ta musi również dać się przetłumaczyć ponownie na ten sam adres IP. UNKNOWN pasuje do wszystkich nieznanych hostów (takich, których adres IP nie jest zarejestrowany w odwrotnym DNS, tzn. brak im rekordu PTR) PARANOID pasuje do wszystkich hostów z nieprawidłowościami w translacji DNS, tzn. gdy tłumaczenie ADRES IP nazwa DNS ADRES IP, nie zawiera tego adresu IP, od którego zaczęliśmy lista1 EXCEPT lista2 wprowadza wyjątek od bardziej ogólnej reguły Opcje rozszerzone: ALLOW lub deny jawne zezwolenie lub zabronienie dostępu w regule SPAWN uruchomienie dodatkowego podprocesu TWIST przekierowanie usługi do dodatkowego procesu RFC931 skierowanie zapytania do komputera klienta o identyfikator użytkownika inicjującego połączenie (sposób opisany w RFC 931) BANNERS /jakiś/katalog wyświetlanie plików nazwanych tak samo jak usługa znajdujących się w tym katalogu (np. in.ftpd) przed uruchomieniem właściwej usługi USER user zmiana UID przed uruchomieniem usługi Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 25
IDENT protokół identyfikacyjny IDENT protokół identyfikacyjny maruda 12345 connect (tajniak, 23) accept (tajniak, 23; maruda, 12345) tajniak 23 klient serwer in.identd 113 "UNIX : joeshmoe" IDENT: "23, 12345" serwer Cel: pomaga w identyfikacji użytkowników inicjujących połączenia pozwala dość skutecznie ograniczyć nadużycia w usługach takich jak IRC lub NEWS Sposób działania: Klient łączy się z serwerem, uzyskując tymczasowy numer portu; Serwer (tajniak) wykonuje połączenie zwrotne do usługi IDENT na komputerze klienta, pytając o właściciela połączenia identyfikowanego piątką parametrów (TCP, adresy, porty); Serwer usługi IDENT na komputerze klienta zwraca te informacje; Serwer tajniak akceptuje ostatecznie połączenie, uruchamiając odpowiedni program. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 26
IDENT protokół identyfikacyjny Nieporozumienia dotyczące protokołu IDENT Protokół IDENT nie jest protokołem AUTORYZACJI, nie należy go więc stosować do kontroli dostępu. Ufamy swojemu serwerowi IDENT, ale czy możemy ufać raportom z jego informacjami przysyłanym z zewnątrz? Serwer IDENT to łączący się klient, znajdujący się poza naszą kontrolą nie należy mu ufać. Jedynym zastosowaniem protokołu jest ułatwienie identyfikacji potencjalnego lub rzeczywistego włamywacza po fakcie, tzn. po udanej lub nieudanej próbie dostępu do innego komputera. Rozwiązania Wszystkie odpowiedzi serwera IDENT można także zapisywać lokalnie Nadal nie zawsze można takim zapisom ufać... Odpowiedzi można zapisywać na innym komputerze w sieci lokalnej (via syslog) Odpowiedzi można szyfrować wykorzystując algorytm DES. Uzyskujemy w ten sposób: poufność danych wysyłanych na zewnątrz kontrolę spójności tych danych Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 27
Ataki w warstwie sieciowej i transportowej Ataki w warstwie sieciowej i transportowej Stos protokołów sieciowych w systemie operacyjnym jest zbiorem programów i procedur, w których też zdarzają się błędy. W większości systemów operacyjnych te procedury wywodzą się ze wspólnego źródła systemu BSD ( BSD Sockets ). Typowe ataki w warstwie sieciowej Ping of death Odpowiednio popsuty fragment pakietu ICMP ECHO, powodujący przekroczenie maksymalnego rozmiaru pakietu i nadpisanie obszaru poza buforem przeznaczonym na odebranie pakietu. Teardrop Fragmenty pakietu zachodzące na siebie powodują załamanie niektórych systemów operacyjnych. Land Odpowiednio spreparowany pakiet, w którym adres źródłowy jest taki sam, jak adres docelowy. Smurf Pakiety ICMP wysyłane na adres rozgłoszeniowy sieci powodujące zalew sieci lokalnej odpowiedziami od wszystkich włączonych komputerów. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 28
Ataki DoS (Denial of Service) Ataki DoS (Denial of Service) Atak, w którym pojedynczy użytkownik lub proces zajmuje zasoby sytemowe w taki sposób, że inne procesy i użytkownicy nie są w stanie z nich korzystać (bo np. został wyczerpany limit dostępnych zasobów). Zasoby oznaczają miejsce na dysku, czas CPU, liczbę dostępnych procesów, połączenia sieciowe, przepustowość sieci, dostęp do poszczególnych usług i urządzeń, mechanizmy komunikacji (semafory, kolejki), itp. Niektóre z takich ataków są po prostu efektem pomyłki użytkownika (błędny warunek końca pętli, brak reakcji na błąd systemu, itp.). Najlepszy sposób likwidacji znalezienie użytkownika powodującego problem. Inne metody zabezpieczeń zależą od typu ataku: Wyczerpanie miejsca na dysku podział dysku na partycje, limity miejsca dla użytkowników (disk quota), używanie rezerwy administratora (reserved space), kontrolowanej parametrem minfree komendy tunefs. Procesy ustawienie maksymalnej liczby procesów na użytkownika lub powłokę. Ataki sieciowe systemy firewall, filtry, w szczególności systemy z limitami przepustowości dla poszczególnych usług. Są to niestety półśrodki i nie ma jak na razie dobrych rozwiązań chroniących przed sieciowymi atakami typu DoS. Problemy fizyczne (rozłączenie kabli przez sprz^h^h^h^h konserwatorów powierzchni poziomych) umieszczanie komputerów w bezpiecznym miejscu (zamykane pomieszczenia, kable sieciowe w zamkniętych rynienkach i kanałach). Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 29
Ataki DoS (Denial of Service) Sieciowe ataki typu DoS Zasypywanie pakietami (message flooding) Spowolnienie pracy komputera poprzez zasypywnaie komputera pakietami adresowanymi do niego. Technika ta może zostać użyta do efektywnego odcięcia serwera od sieci lub nawet zastąpienia go innym, odpowiadającym na żądania przychodzące pod jego adresem. Zasypywanie pakietami konkretnych usług (page flooding) Np. serwera WWW wysyłanie takiej liczby żądań, by serwer nie był w stanie na nie odpowiedzieć. Trudne do wyfiltrowania, bo trudno je odróżnić od zwykłych połączeń od klientów. Sztorm pakietów rozgłoszeniowych (broadcast storms Smurf) Wysyłanie pakietów na adresy rozgłoszeniowe, co powoduje wygenerowanie odpowiedzi z wielu maszyn. Stosowane razem z fałszowaniem adresów źródłowych w celu skierowania tych odpowiedzi na właściwą ofiarę. Wysyłane są pakiety ICMP (atak typu smurf ) lub UDP (atak typu Fraggle ) Podwójne sztormy rozgłoszeniowe (double broadcast storms) Nie tak skuteczne jak zwykłe sztormy rozgłoszeniowe, gdyż znacznie łatwiej je wyfiltrować. Wysyłanie pakietów spreparowanych w taki sposób, że adres źródła jest adresem rozgłoszeniowym. Odpowiedź na taki pakiet trafia do wielu adresatów, a ci z kolei generują pakiety ICMP typu port unreachable lub pakiety TCP z opcją reset, zaprzeczając tym samym istnieniu jakiegokolwiek połączenia. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 30
Zasypywanie pakietami SYN (SYN flooding) Zasypywanie pakietami SYN (SYN flooding) Nawiązanie połączenia TCP wymaga trzech czynności: klient connect (klient, 12345, serwer, 23) accept (serwer, 5001; klient, 12345) "ACK: serwer, 5001; klient, 12345" czas serwer Klient wysyła żądanie połączenia na dobrze znany numer portu serwera. Serwer akceptuje połączenia tworząc nowe gniazdko potencjalnie zmieniając także numer portu po swojej stronie, tak że odpowiedź do klienta trafia z nowego gniazdka (i nowego numeru portu). Klient potwierdza nawiązanie połączenia akceptując numer portu serwera, który mógł ulec zmianie. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 31
Zasypywanie pakietami SYN (SYN flooding) Nawiązywanie połączenia W celu nawiązania połączenia TCP konieczne jest wysłanie 3 pakietów: klient SRC: klient:12345 DST: serwer:23 TCP, opcje: SYN SRC: klient:12345 DST: serwer:23 TCP, opcje: ACK Czas serwer SRC: serwer:23 DST: klient:12345 TCP, opcje: SYN ACK Po wysłaniu odpowiedzi serwer czeka na otrzymanie potwierdzenia od klienta. Dopóki nie nadejdzie potwierdzenie (lub zostanie przekroczony maksymalny czas oczekiwania), nie można zwolnić zaalokowanego pół-otwartego połączenia. Jeśli pojawi się więcej półotwartych połączeń, serwer może osiągnąć limit połączeń oczekujących, tzn. całkowicie wypełnić tablicę przeznaczoną na trzymanie informacji o nawiązywanych połączeniach. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 32
Zasypywanie pakietami SYN (SYN flooding) Ochrona przed zasypywaniem pakietami SYN klient SRC: klient:12345 DST: serwer:23 TCP, opcje: SYN SRC: klient:12345 DST: serwer:23 TCP, opcje: ACK Czas firewall SRC: serwer:23 DST: klient:12345 TCP, opcje: SYN ACK SYN SYN, ACK ACK serwer Firewall monitorujący połączenia w warstwie 4 może przechwycić przychodzące pakiety SYN i chronić serwer akceptując połączenia w jego imieniu. Tylko połączenia, które zostały w pełni nawiązane, są następnie przekazywane do serwera, tworząc także tymczasowe wpisy w tablicy stanów firewalla, pozwalające na dalszą komunikację do czasu zakończenia lub zerwania połączenia. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 33
Zagrożenia związane z protokołem NFS Zagrożenia związane z protokołem NFS NFS Network File System system eksportowania dysków przez sieć (lokalną). Korzysta z UDP (NFS v.2) lub UDP i TCP (NFS v.3). Komunikacja klienta i serwera NFS odbywa się na poziomie warstwy prezentacji/sesji przy pomocy RPC. W celu poprawnego działania NFS konieczna jest pomoc procesu portmap (port 111 UDP) tłumaczącego numery funkcji RPC na numery portów TCP lub UDP. NFS na serwerze wymaga także demonów nfsd i mountd. Serwer może eksportować do klienta (lub wielu klientów) cały system plików lub jego część; w trybie do zapisu lub wyłącznie do odczytu; wszystkim lub tylko wybranym hostom. Dostęp zdalnego procesu do pliku na podstawie uid użytkownika, ale zgłaszanego przez podsystem NFS klienta. Serwer nfsd w wielu systemach nie sprawdza nawet, czy port źródłowy klienta jest portem specjalnym (poniżej 1024). Zagrożenia występują w obie strony serwer musi być chroniony przed nadużywającymi zaufania klientam, ale i klienci NFS muszą uważać na zawartość dysków importowanych z serwerów. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 34
Dyski przez sieć konfiguracja klienta NFS Dyski przez sieć konfiguracja klienta NFS Klient /etc/fstab tablica mapowania/podłączania dysków opcja nosuid pozwala ignorować programy suid, inne: nodev, noexec dev/cdrom /mnt/cdrom iso9660 noauto,nosuid,owner,ro 0 0 dev/fd0 /mnt/floppy auto noauto,nosuid,owner 0 0 serv1:/export/home /home/ext nfs defaults,nosuid,rsize=8192,wsize=8192 0 0 Opcja nosuid pozwala zabezpieczyć klienta przed wykonywaniem aplikacji typu suid z dysku serwera. Opcja nodev pozwala ignorować urządzenia specjalne na podłączanym dysku (mające być może inne prawa dostępu niż standardowe). /etc/mtab tablica aktualnie podłączonych systemów plików. To samo wynik operacji mount bez żadnych parametrów. Jeśli serwer nie sprawdza numeru portu klienta (czy mniejszy niż 1024), uruchomienie własnego klienta NFS przez dowolnego użytkownika pozostaje kwestią jego znajomości ogólnie dostępnego i publikowanego protokołu NFS. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 35
Dyski przez sieć konfiguracja serwera NFS Dyski przez sieć konfiguracja serwera NFS Za udostępnianie dysków przez sieć odpowiedzialne są demony nfsd i mountd. Dostęp do tych demonów odbywa się przez procedury RPC (Remote Procedure Calls), przy udziale demonów portmap i rpcbind (port 111). Ochrona przez tcp wrappers może się odbywać wyłącznie na poziomie programu portmap/rpcbind. Plik konfiguracyjny, określający które systemy są eksportowane: Solaris: /etc/dfs/dfstab: share -F nfs -o rw=klient1:klient2,root=klient1 -d "home" /export/home share -F nfs -o ro=klient1 -d "news" /var/spool/news Po zmianach należy wykonać ten plik jak skrypt. Linux: /etc/exports: /export/home klient1(rw,no_root_squash) klient2(rw) /var/news klient1(ro) Po dokonaniu zmian należy uruchomić program exportfs -a, a jeśli nie był do tej pory uruchomiony NFS, to wykonać także odpowiednie skrypty z katalogu /etc/rc2.d. Do sprawdzania lokalnie lub zdalnie eksportowanych systemów plików służy komenda showmount -e. Do sprawdzenia z jakich lokalnych systemów korzystają zdalni klienci służy showmount. Należy wystrzegać się eksportowania dysków do siebie (localhost) ze względu na znane problemy z bezpieczeństwem takich eksportów. Bezpieczeństwo Usług Sieciowych 2014/2015, Tomasz Surmacz 36