%%%% ZAWARTOŚĆ OBLIGATORYJNA - NALEŻY DOSTOSOWAĆ %%%%%%%%%%%%%%%%%%%%%%%% %% Tytuł opracowania \title{Projektowanie bezpiecznej konfiguracji sieci\\ %% Tu należy podać nazwę przedmiotu, którego tyczy sprawozdanie. \begin{small} Projekt z przedmiotu BSS \end{small}} %% Autorzy opracowania, po dwie linie z nazwiskiem i adresem e-mail na %% osobę. Każdy opis oddzielony separatorem 'and'. %% \author{Tomasz Jordan Kruk\\ T.Kruk@ia.pw.edu.pl \and Jan Nieznany\\ jn@n.pl} \author{Tomasz Jordan Kruk\\ T.Kruk@ia.pw.edu.pl} % To stworzy właściwy format tytułu oraz spis treści. \maketitle \tableofcontents %%%% PONIŻEJ ZAWARTOŚĆ DOWOLNA %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Dokument podzielony powinien być na elementy: section, subsection, % ewentualnie subsubsection. \section{Strategie zabezpieczeń} Przed opisaniem poszczególnych architektur zabezpieczeń sieci przedstawione zostaną podstawowe strategie używane do wymuszania bezpieczeństwa w sieci. Jedną z najbardziej podstawowych zasad bezpieczeństwa jest \e{zasada minimalnych przywilejów} \ang{least privilege}. Polega ona na tym, że każdy obiekt (użytkownik, administrator, program, system itp.) powinien mieć tylko takie uprawnienia, które są mu niezbędne do wykonania przydzielonego zadania - i żadnych więcej. Pomaga to ograniczyć ryzyko ataku i zniszczeń, które spowoduje. Nie każdy użytkownik musi mieć dostęp do wszystkich usług internetowych. Nie każdy musi mieć możliwość czytania wszystkich plików w systemie. Nie każdy system musi mieć dostęp do wszystkich plików innego systemu. Klasycznym przykładem jest rejestrowanie się administratora systemu uniksowego do systemu. Doświadczeni administratorzy nigdy nie rejestrują się do systemu jako użytkownik \e{root}. Każdy ma własne konto z prawami zwykłego użytkownika, natomiast przełącza się komendą \e{su} \ang{switch user} na użytkownika \e{root} tylko w przypadku konieczności dokonania właściwych czynności administracyjnych. Inną zasadą bezpieczeństwa jest tzw. \e{dogłębna obrona} \ang{defence in depth}. Nie powinno się polegać na tylko jednym mechanizmie zabezpieczającym, jakkolwiek wydaje się skuteczny. Powinno się instalować wiele mechanizmów wspierających bądź też uzupełniających swoją funkcjonalność. Nie jest realistycznym założenie, iż nasze pojedyncze zabezpieczenie jest nie do złamania. Dlatego też powinno się stosować ochronę wielowarstwową. Należy zapamiętać, iż celem stosowania nadmiarowych zabezpieczeń nie jest głównie obrona przed atakami, lecz ochrona przed awariami innych poziomów zabezpieczeń. Kolejną zasadą bezpieczeństwa jest wykorzystywanie tzw. \e{wąskiego przejścia} \ang{choke point}. Wąskie przejście zmusza napastników do używania kanału, który można kontrolować i monitorować. W sieciach takim wąskim gardłem jest ściana ogniowa między siecią wewnętrzną a siecią zewnętrzną. Każdy, kto chce zaatakować sieć wewnętrzną z sieci zewnętrznej, musi użyć tego kanału, który z kolei powinien być dostatecznie zabezpieczony przed próbami ataków. Koncepcja wąskiego przejścia staje się bezużyteczna, gdy istnieje inna efektywna droga do systemu. Takim potencjalnym obejściem może być na przykład niezabezpieczony serwer terminali dla połączeń telefonicznych czy też dodatkowe bezpośrednie połączenie z siecią innej firmy, która nie podjęła w trosce o własną sieć wystarczających środków bezpieczeństwa. Podstawową zasadą bezpieczeństwa jest \e{zasada najsłabszego ogniwa}. Każdy łańcuch zabezpieczeń jest tak silny jak jego najsłabszy punkt. Napastnicy będą szukali właśnie takiego najsłabszego punktu i bezlitośnie wykorzystają jego słabości. Należy być świadomym słabych punktów swojej obrony i je albo wyeliminować, albo jeżeli eliminacja nie jest możliwa, na ich kontroli skupić szczególna uwagę. Najsłabsze ogniwo będzie istniało zawsze, trzeba jedynie sprawić by było wystarczająco silne, proporcjonalnie do ryzyka. Przykładowo przeważnie bardziej uzasadniona jest obawa przed atakami z sieci niż przed faktem fizycznego włamania się do zasobów instytucji. Często więc, m.in. ze względu na koszty, świadomie decyduje się, by ochrona fizyczna była właśnie takim ogniwem. Jednak nie wolno całkiem zaniedbać ochrony fizycznej, ponieważ istnieje ryzyko takich ataków. Jedną z podstawowych zasad bezpieczeństwa jest \e{bezpieczna reakcja w przypadku uszkodzenia}. Jeżeli elementy systemu zabezpieczeń ulegają awarii, powinny uniemożliwić atakującemu dostęp, zamiast mu go w pełni otworzyć. Awaria zazwyczaj odetnie wtedy dostęp również uprawnionym użytkownikom (do momentu jej usunięcia), jest to jednak akceptowalna i uzasadniona niedogodność na zasadzie mniejszego zła. Jeżeli router filtrujący pakiety zostanie wyłączony przestanie routować pakiety. Jeżeli usługa pośredniczenia przestanie być aktywna, nie będzie udostępniała swoich usług. Aby działać efektywnie, większość systemów zabezpieczeń wymaga od personelu \e{współpracy}, a przynajmniej niewykonywania czynności mogących storpedować system zabezpieczeń. Nawet najlepsza ściana ogniowa stanie się bezużyteczna, gdy któryś z pracowników uzna ją za niewygodną przeszkodę i zainstaluje przy swoim komputerze w sieci wewnętrznej modem wraz z protokołem PPP na komputerze biurowym. Jest to oczywista tylna furtka, która równie łatwo jak niesubordynowany pracownik może wykorzystać potencjalny intruz. Współpracę personelu osiąga się metodami edukacyjnymi i restrykcyjnymi. Niezbędne są szkolenia informujące użytkowników o potencjalnych zagrożeniach wynikających z różnych działań konfiguracyjnych podejmowanych bez konsultacji z administratorami bezpieczeństwa - to jest metoda edukacyjna. Użytkownik świadomy zagrożeń dwa razy zastanowi się, zanim w imię własnej wygody zaryzykuje zmniejszenie odporności sieci teleinformatycznej instytucji na potencjalne włamania. Metoda restrykcyjna, komplementarna w stosunku do edukacyjnej, polega na wdrożeniu regulaminów korzystania z sieci komputerowej i wymuszeniu na pracownikach korzystania z zasobów informatycznych zgodnie z założeniami odpowiednich fragmentów polityki bezpieczeństwa teleinformatycznego danej instytucji. Użytkownik świadomy podpisanych zobowiązań dwa razy zastanowi się, zanim przyjmie ryzyko konsekwencji dyscyplinarnych, a być może i prawnych, złamania uprzednio zaakaceptowanych regulacji dotyczących wykorzystywania zasobów informatycznych. Strategia określana mianem \e{zróżnicowanej obrony} jest ściśle powiązana z dogłębną obroną, ma jednak inne znaczenie. Wedle tej strategii nie można się nie tylko ograniczać do pojedynczej warstwy zabezpieczeń, ale i środki zabezpieczeń powinny być zróżnicowane. Systemy zabezpieczeń tego samego rodzaju (na przykład filtry pakietów) mają te same słabości techniczne. Również systemy konfigurowane przez tę samą osobę mogą zawierać ten sam błąd merytoryczny. Jest wysoce prawdopodobnym, że systemy operacyjne tego samego producenta będą miały tę samą lukę, np. w stosie protokołów TCP/IP. Z drugiej strony, tendencja do unifikacji używanych typów zabezpieczeń ma także swoje uzasadnienie. Łatwiej jest zarządzać dziesięcioma urządzeniami pracującymi pod kontrolą tego samego systemu operacyjnego, niż pod kontrolą dziesięciu różnych systemów operacyjnych. Wśród strategii zabezpieczeń należy również wymienić prostotę. Po pierwsze, rozwiązania proste są łatwiej weryfikowalne pod względem ich poprawności. Po drugie, złożoność oznacza wiele źródeł potencjalnych dodatkowych problemów. Łatwiej jest zabezpieczyć jeden komputer z kilkoma usługami niż sieć komputerów z rozdystrybuowanymi usługami. Zawsze należy jednak pamiętać, że efektywne zabezpieczenie jest z natury skomplikowane. Zabezpieczenia powinno się konstruować tak prosto jak to jest możliwe - ale nie prościej. Mimo wszystko, to bezpieczeństwo sieci a nie prostota projektu jest głównym celem wdrożenia systemu zabezpieczeń. Jako ostatnią należy również wymienić kontrowersyjną w niektórych środowiskach strategię \e{zabezpieczania przez utajnianie} \ang{security through obscurity}. Zabezpieczenia tego typu są niewłaściwe, gdy są jedyną formą zabezpieczenia (przykład: szyfr z niejawnym, czyli niezweryfikowanym pod względem mocy i poprawności, algorytmem szyfrującym) lub gdy uniemożliwiają określenie prawdziwego poziomu zabezpieczenia produktu. Warto jednak uczynić z tej strategii środek dodatkowy w zabezpieczaniu zasobów sieci. Pewnej grupy informacji nie powinno się udostępniać na zewnątrz. Przykładowo, nie powinno się udostępniać osobom postronnym: \begin{itemize} \item dokładnego rodzaju sprzętu jakiego używa się do realizacji ściany ogniowej, \item szczegółów polityki bezpieczeństwa kontroli i filtrowania ruchu zaimplementowanej w architekturze zabezpieczeń, \item nazw hostów i użytkowników, \item informacji o wdrożonych systemach wykrywania włamań. \end{itemize} Nie da się i nie zawsze jest sens utajniania wszystkich informacji dotyczących architektury zabezpieczeń, ale im mniej z nich wydostanie się na zewnątrz, tym trudniejsze zadanie będzie miał potencjalny napastnik. Podsumowując, przy projektowaniu zabezpieczeń sieci instytucji, należy uwz\-ględnić i odpowiednio powiązać następujące strategie zabezpieczeń: \begin{itemize} \item przydział minimalnych wystarczających przywilejów, \item wykorzystanie dogłębnej obrony, \item zapewnienie wąskiego przejścia, \item zasadę najsłabszego ogniwa, \item bezpieczną reakcję w przypadku uszkodzenia, \item wykorzystanie zróżnicowanych środków obrony, \item maksymalną prostotę wystarczająco bezpiecznego rozwiązania, \item wykorzystanie w pewnym zakresie zabezpieczania poprzez utajnianie. \end{itemize} \section{Architektury styku z siecią Internet} W poniższym podrozdziale przedstawiono metody zabezpieczania sieci instytucji poprzez różne architektury zabezpieczeń. Architektury te różnią się takimi własnościami jak: poziom zabezpieczenia, łatwość instalacji i póżniejszego zarządzania oraz cena rozwiązania. \subsection{Wszystko w jednym} Najprostszą architekturą jest pojedynczy obiekt \ang{single-box architecture} pełniący funkcję ściany ogniowej. Wadą takie rozwiązania jest fakt, iż całe bezpieczeństwo zależy od tego jednego miejsca. Nie ma wielowarstwowych zabezpieczeń. Inna wada to ograniczenie zakresu przyłożonych zabezpieczeń ze względu na ograniczenia wydajnościowe pojedynczej maszyny. W praktyce, zaletą pojedynczej architektury jest nie tyle zadowalający poziom bezpieczeństwa, co względy praktyczne. W porównaniu z bardziej rozbudowanymi architekturami jest tańsza i łatwiej zarządzalna. Ponieważ wszystkie funkcje mieszczą się w jednym pudełku, zabezpieczenia takie są oferowane przez producentów zabezpieczeń jako łatwo instalowalny i konfigurowalny, wymagający minimalnego doglądania w trakcie pracy, produkt. Ponieważ rozwiązania oferowane są jako seryjne produkty, ich cena może być odpowiednio niższa. Ponadto, zarządzanie takim zabezpieczeniem wymaga mniej wiedzy w zakresie sieci komputerowych i zabezpieczeń, niż w przypadku innych rozwiązań. Jest to rozwiązanie dedykowane przede wszystkim dla firm o nierozbudowanej infrastrukturze sieciowej oraz ograniczonym zakresie wykorzystania sieci. Najprostszym typem pojedynczego zabezpieczenia jest zastosowanie \e{routera osłaniającego} określanego również mianem \e{routera ekranującego} w charakterze ściany ogniowej. Jest to rozwiązanie tanie, gdyż i tak zazwyczaj do kontaktu z siecią Internet potrzebny jest router. Wystarczy go jedynie skonfigurować tak, by filtrował pakiety. Ponieważ nowe routery poza klasycznym filtrowaniem pakietów oferują również bardziej zaawansowane mechanizmy, jak badanie stanu wybranych protokołów czy zwrotne listy dostępu, osiągnięty poziom bezpieczeństwa jest dużo wyższy od minimalnego. Router ekranujący nadaje się do zastosowania jako ściana ogniowa w następujących przypadkach: \begin{itemize} \item chroniona sieć ma dobrze zabezpieczone hosty, \item liczba używanych protokołów jest ograniczona d o kilku prostych, \item potrzebna jest maksymalna wydajność i nadmiarowość. \end{itemize} Innym typem pojedynczego zabezpieczenia jest \e{host dwusieciowy} \ang{dual-homed host}. Jest to architektura oparta o host, który ma co najmniej dwa interfejsy sieciowe. Host taki może służyć jako router pomiędzy sieciami, do których ma interfejsy (np. siecią wewnętrzną i zewnętrzną). Jednak aby używać takiego komputera jako ściany ogniowej, należy wyłączyć funkcję trasowania. Pakiety z jednej sieci nie są bezpośrednio przesyłane do drugiej podsieci. Systemy chronione ścianą ogniową mogą się z nią komunikować. Tak samo mogą się z nim komunikować systemy zewnętrzne. Powyższe grupy nie mogą się komunikować bezpośrednio. Ruch IP między nimi jest całkowicie zablokowany. Host dwusieciowy może zapewnić bardzo wysoki poziom kontroli. Jeżeli nie dopuszcza się żadnym pakietom na przechodzenie między sieciami, można mieć np. pewność, ze każdy pakiet w wewnętrznej sieci, który ma zewnętrzny adres źródłowy, oznacza niebezpieczeństwo. Z drugiej strony, rozwiązanie takie nie jest zbyt wydajne. Hosty muszą więcej pracować nad każdym połączeniem niż filtr pakietów i potrzebują więcej zasobów. Host bastionowy sam w sobie musi być bardzo bezpiecznie skonfigurowany. Intruz, który potrafiłby opanować taki host, dostaje pełen dostęp do sieci prywatnej a także może skutecznie uniemożliwić korzystanie z sieci zewnętrznej. Host dwusieciowy może świadczyć usługi tylko poprzez pośredniczenie bądź bezpośrednią interakcję z użytkownikami. Problem polega na tym, że wymaga to zazwyczaj bazy kont użytkowników na hoście zabezpieczającym, a to stanowi samo w sobie dodatkowy problem. Ponadto, wielu użytkowników uważa za uciążliwość konieczność logowania się na takim hoście. Pośredniczenie znacznie lepiej współpracuje z usługami wychodzącymi niż z przychodzącymi. W konfiguracji z hostem dwusieciowym większość usług internetowych musi być uruchamiana na tym hoście. Z drugiej strony, ma on przecież zasadnicze znaczenie dla bezpieczeństwa, więc nie powinno się na nim uruchamiać ryzykownych usług, jak np. serwer WWW. Reasumując, host z dwoma interfejsami nadaje się do zastosowania jako ściana ogniowa w następujących sytuacjach: \begin{itemize} \item ruch do sieci Internet jest niewielki, \item łączność z siecią Internet nie decyduje o prowadzeniu interesów firmy, \item sieć firmowa nie udostępnia na zewnątrz żadnych usług, \item sieć chroniona nie zawiera wyjątkowo wartościowych danych. \end{itemize} \subsection{Architektura ekranowanego hosta} Podczas gdy architektura z hostem wielosieciowym udostępnia usługi z hosta, który jest przyłączony do wielu sieci (ale ma wyłączony routing), to \e{architektura z ekranowanym hostem} \ang{screened host} udostępnia je z hosta, który jest przyłączony do sieci wewnętrznej z użyciem oddzielnego routera. W takim rozwiązaniu głównym zabezpieczeniem jest filtrowanie pakietów. Na rysunku \ref{fig:screenedhost} przedstawiono prostą wersję architektury z ekranowanym hostem. Host bastionowy jest umieszczony w sieci wewnętrznej. Filtrowanie pakietów w routerze skonfigurowano tak, by host bastionowy był jedynym hostem w sieci wewnętrznej, z którym mogą się łączyć hosty z sieci Internet (na przykład dostarczające pocztę elektroniczną). Dozwolone są tylko pewne typy połączeń, każdy system zewnętrzny próbujący uzyskać dostęp do wewnętrznych systemów lub usług musi się połączyć z tym hostem. Host bastionowy musi być szczególnie dobrze zabezpieczony. \begin{figure*} \begin{center} \input{screenedhost} \end{center} \caption[Architektura z ekranowanym hostem] {\label{fig:screenedhost} Architektura z ekranowanym hostem.} \end{figure*} Dzięki filtrowaniu pakietów host bastionowy może nawiązywać ze światem zewnętrznym dozwolone połączenia. Router ekranujący może być skonfigurowany tak, by wykonywał jedno z poniższych zadań: \begin{itemize} \item pozwalał hostom wewnętrznym na nawiązywanie połączeń z hostami w sieci Internet na potrzeby pewnych usług, \item zabraniał nawiązywania połączeń z wewnętrznych hostów - zmuszając je do korzystania z usług pośredniczenia w hoście bastionowym. \end{itemize} Oczywiście w zależności od potrzeb bądź dodatkowych ograniczeń możliwe są rozwiązania pośrednie. Niektóre usługi mogą być dostępne bezpośrednio przez filtr pakietów, inne tylko poprzez system pośredniczący. Jest to zależne od zaimplementowanej polityki bezpieczeństwa. Pozornie architektura ekranowanego hosta wydaje się być bardziej ryzykowna od architektury z hostem wielosieciowym, gdyż pozwala na przepływ pakietów z sieci Internet do sieci wewnętrznej. W praktyce jednak i ta druga architektura jest podatna na awarie, które pozwalają pakietom przechodzić z sieci zewnętrznej do wewnętrznej. Ponadto, łatwiej jest bronić router niż host. W większości zastosowań, architektura ekranowanego hosta zapewnia i lepsze zabezpieczenie i większą użyteczność niż architektura z hostem wielosieciowym. Ponieważ host bastionowy jest możliwym punktem awarii bądź ataku, nie należy na nim uruchamiać bardzo ryzykownych usług, na przykład serwera WWW. Host bastionowy powinien mieć zapewniony równie wysoki poziom ochrony, jakiego wymagałby host z wieloma interfejsami zastosowany jako pojedynczy element realizujący funkcje ściany ogniowej. \subsection{Architektura ekranowanej podsieci} \e{Architektura ekranowanej podsieci} \ang{screened subnet architecture} dodaje warstwę zabezpieczeń do architektury z ekranowanym hostem poprzez dodanie \e{sieci peryferyjnej} \ang{perimeter network}, która dodatkowo izoluje sieć wewnętrzną od sieci Internet. Najbardziej narażonymi na potencjalne ataki są hosty bastionowe. Pomimo ich odpowiedniego zabezpieczenia, należy przewidzieć sytuację, w której host bastionowy zostanie skutecznie zaatakowany. W architekturze z ekranowanym hostem nie ma żadnej linii obrony między hostami bastionowymi a pozostałymi maszynami należącymi do sieci wewnętrznej. Izolując host bastionowy od sieci wewnętrznej poprzez wprowadzenie sieci peryferyjnej można zmniejszyć skutki ewentualnego włamania do hosta bastionowego. W najprostszym przypadku architektura z ekranowaną podsiecią tworzona jest poprzez wykorzystanie dwóch routerów, z których każdy podłączony jest do tej podsieci. Jeden jest umiejscowiony między siecią zewnętrzna a siecią ekranowaną, drugi między siecią wewnętrzną a siecią ekranowaną. Na rysunku \ref{fig:screenedsubnet1} przedstawiono przykładową konfigurację ściany ogniowej, która opiera się na ekranowanej podsieci. \begin{figure*} \begin{center} \input{screenedsubnet1} \end{center} \caption[Architektura ekranowanej podsieci z wykorzystaniem dwóch routerów] {\label{fig:screenedsubnet1} Architektura ekranowanej podsieci z wykorzystaniem dwóch routerów.} \end{figure*} \e{Sieć peryferyjna} pełni funkcję dodatkowej bariery między napastnikiem a systemami wewnętrznymi. Jeżeli ktoś włamie się do hosta bastionowego będzie mógł podejrzeć tylko ruch w tej sieci. Ponieważ żaden całkowicie wewnętrzny ruch nie przechodzi przez siec peryferyjną, ruch ten będzie zabezpieczony przed przechwyceniem nawet w przypadku włamania na host bastionowy. Oczywiście ruch do i z hosta do sieci zewnętrznych nadal będzie widoczny. Etapem projektowania ściany architektury zabezpieczeń jest m.in. upewnienie się, że ruch ten nie będzie zawierał niezabezpieczonych informacji na tyle poufnych, by ich ujawnienie naraziło cały ośrodek. W opisywanej architekturze host bastionowy (lub kilka hostów bastionowych) włącza się do sieci peryferyjnej. Host ten jest głównym miejscem kontaktu połączeń przychodzących z zewnątrz z siecią instytucji. Usługi wychodzące są obsługiwane w jeden z następujących sposobów: \begin{itemize} \item ustawienie filtrów pakietów w zewnętrznym i wewnętrznym routerze tak, by pozwolić wewnętrznym klientom na bezpośredni dostęp do zewnętrznych serwerów, \item ustawienie serwerów proxy w hoście bastionowym (o ile wykorzystywane jest pośredniczenie) tak, by pozwolić wewnętrznym klientom na pośredni dostęp do zewnętrznych serwerów. Powinno się również ustawić filtrowanie pakietów, aby pozwolić wewnętrznym klientom na komunikację z serwerem proxy w hoście bastionowym i odwrotnie, ale jednocześnie zabronić bezpośredniej komunikacji między wewnętrznymi klientami a światem zewnętrznym. \end{itemize} W każdym z przypadków filtrowanie pakietów pozwala hostowi bastionowemu na połączenie się z siecią zewnętrzną oraz akceptowanie ustalonych typów połączeń z sieci zewnętrznej. Większość czynności hosta bastionowego polega na działaniu jako serwer proxy dla różnych usług. \e{Router wewnętrzny}, określany również mianem \e{routera dławiącego} \ang{choke router}, zabezpiecza sieć wewnętrzną przed atakami zarówno z sieci zewnętrznej jak i sieci peryferyjnej. Powinno się ograniczyć usługi dozwolone między hostem bastionowym a siecią wewnętrzną tylko do tych, które są rzeczywiście niezbędne, jak np. SMTP (by host bastionowy mógł przekierowywać przychodzącą pocztę), DNS (by host bastionowy mógł odpowiadać na zapytania komputerów zewnętrznych lub zadawać pytania, w zależności od konfiguracji) i tak dalej. Można również ograniczyć usługi w jeszcze większym zakresie umożliwiając komunikację w wybranych protokołach z hostem bastionowym tylko z wybranych komputerów sieci wewnętrznej. Przykładowo, SMTP może być ograniczone tylko do komunikacji między hostem bastionowym a wewnętrznym serwerem poczty. Teoretycznie zadaniem \e{routera wewnętrznego} \ang{exterior router}, zwanego czasem również \e{routerem dostępowym} \ang{access router}, jest ochrona zarówno sieci peryferyjnej jak i sieci wewnętrznej. W praktyce, routery zewnętrzne zazwyczaj pozwalają wszystkim danym wychodzącym wydostać się na zewnątrz i prawie nie filtrują pakietów. Jedynymi specjalnymi regułami filtrowania w zewnętrznym routerze są te, które chronią maszyny w sieci peryferyjnej (czyli host bastionowy i router wewnętrzny). Zazwyczaj jednak specjalna ochrona nie jest konieczna, ponieważ hosty w sieci peryferyjnej chronione są przez własne zabezpieczenia. Aby wspierać usługi pośredniczące, dopuszczonych przez router wewnętrzny z hostów wewnętrznych do hosta bastionowego, router zewnętrzny może przepuszczać te protokoły tylko wtedy, gdy pochodzą z hosta bastionowego. Innym użytecznym zadaniem, które powinien wykonywać router zewnętrzny jest blokowanie wchodzących z sieci zewnętrznej pakietów z fałszywym adresem źródłowym, czyli pakietów usiłujących udawać pakiety z sieci wewnętrznej. Router zewnętrzny może również zabraniać wyjścia z sieci pakietom z nieprawidłowym adresem źródłowym. Architektura z ekranowaną podsiecią jest odpowiednia do większości zastosowań. Oczywiście, podane rozwiązanie jest pewnym schematem posiadającym wiele różnych wariacji. Kładą one zazwyczaj jeszcze większy nacisk na bezpieczeństwo, na zwiększenie przepustowości bądź zapewnienie większego poziomu ciągłości działania w wypadku wystąpienia awarii. W \e{wieloczęściowej sieci ekranowej} \ang{split-screened subnet} nadal występują routery wewnętrzny i zewnętrzny, ale pomiędzy nimi jest kilka (zazwyczaj dwie) sieci. Osłonięte podsieci są przeważnie połączone ze sobą za pomocą jednego bądź wielu hostów wielosieciowych zamiast następnych routerów \rys{fig:screenedsubnet2}. Architektura ta stosowana jest w celu zapewnienia sobie wielowarstwowego zabezpieczenia i ochrony hostów z usługa pośredniczenia za pomocą routerów. Routery zapewniają ochronę przed fałszerstwem i takimi awariami hosta wielosieciowego, w wyniku których zaczyna on tarasować ruch. Host wielosieciowy, w porównaniu do filtrów pakietów, umożliwia bardziej dokładną kontrolę połączeń. Architektura wieloczęściowej sieci ekranowej wykorzystywana jest czasem również w celu umożliwienia administracji usługami na hostach bastionowych z wykorzystaniem protokołów uznanych ogólnie za niewystarczająco bezpieczne, by mogły się znaleźć w sieci chronionej jedynie przez router zewnętrzny. Przykładami takich protokołów mogą być własne protokoły systemu NT używane podczas zdalnego uruchamiania menedżera użytkowników i monitora wydajności albo też usługi w systemach Unix wykorzystujące do konfiguracji protokół bez szyfrowania ruchu (np. telnet). \begin{figure*} \begin{center} \input{screenedsubnet2} \end{center} \caption[Architektura dwuczęściowej ekranowanej sieci bez przechodzącego ruchu] {\label{fig:screenedsubnet2} Architektura dwuczęściowej ekranowanej sieci bez przechodzącego ruchu.} \end{figure*} W pewnych przypadkach zasadnym jest zastosowanie \e{niezależnych podsieci ekranowanych}\ang{independent screened subnet} z oddzielnymi parami routerów zewnętrznych i wewnętrznych. Jednym z powodów może być konieczność zapewnienia nadmiarowości. Awaria czy skuteczny atak na jedną z sieci peryferyjnych nie powoduje całkowitego braku łączności z siecią Internet. Rozwiązanie takie wydaje się być zasadnym na przykład w przypadku dostawców usług internetowych. W dużych instytucjach można też pokusić się o oddzielenie usług przychodzących (np. do oficjalnego serwera WWW naszej instytucji) od usług wychodzących (ruch generowany przez użytkowników z sieci wewnętrznej). Znacznie prościej jest zapewnić ścisłe bezpieczeństwo jeżeli ruch przychodzący i wychodzący zostaną rozdzielone. Opisane powyżej architektury obrazują pewną strukturę logiczną systemu zabezpieczeń, jednak fizycznie pewna funkcjonalność może być na przykład scalona w jednym urządzeniu. Ze względu na cenę często \e{scala się router wewnętrzny z zewnętrznym} . W takiej sytuacji jedna grupa portów pełni funkcję routera zewnętrznego a druga grupa portów routera wewnętrznego. Podobnie jak w klasycznym rozwiązaniu występuje sieć peryferyjna, odgradzająca sieć zewnętrzną od sieci wewnętrznej. W normalnych warunkach poziom bezpieczeństwa jest dokładni taki sam jak przy rozłącznych routerach. Router taki stanowi jednak pojedynczy punkt awarii. W przypadku opanowania go przez intruza (co jest przy dobrym zabezpieczeniu mało prawdopodobne jednak nie niemożliwe) sieć wewnętrzna jest bezbronna. W pewnych przypadkach można używać pojedynczej maszyny z wieloma interfejsami zarówno jako hosta bastionowego jak i routera zewnętrznego. Przypuśćmy, że do sieci zewnętrznej łączymy się jedynie przez łącze komutowane z wykorzystaniem protokołu PPP. W takim przypadku można używać PPP w hoście bastionowym i pozwolić mu działać i jako host bastionowy i jako router zewnętrzny. Używanie hosta wielosieciowego do routowania nie zapewni wydajności i elastyczności dedykowanego routera, ale nie jest to potrzebne w przypadku wolnego pojedynczego połączenia. W przeciwieństwie do łączenia routera zewnętrznego i wewnętrznego, połączenie hosta bastionowego z routerem zewnętrznym nie otwiera nowych poważnych luk. Po prostu host bastionowy jest chroniony przez filtry na swoich własnych interfejsach, które jak i w standardowej konfiguracji muszą być szczególnie uważnie zabezpieczone. Nie wszystkie scalania są jednak bezpiecznie. Należy pamiętać o następujących zasadach: \begin{itemize} \item nie powinno się łączyć hosta bastionowego z routerem wewnętrznym, \item nie powinno używać się wielu routerów wewnętrznych dla jednej sieci peryferyjnej i jednego routera zewnętrznego, \item niebezpiecznie jest używać jednocześnie i ekranowanych podsieci i ekranowanych hostów. \end{itemize} W pierwszym przypadku system staje się systemem z ekranowanym hostem zamiast podsiecią. Jeżeli ktoś włamie się do hosta bastionowego, ma także natychmiast dostęp do sieci prywatnej. W drugim przypadku problemem jest to, iż oprogramowanie routujące może uznać, iż najszybsza droga między dwoma komputerami wewnętrznymi będzie powadzić przez sieć peryferyjną. W przypadku konieczności wydzielenia w sieci wewnętrznej osobnych podsieci, lepiej wydzielić je na jednym routerze wewnętrznym albo też, w przypadku dużej liczby koniecznych podziałów, zdecydować się na stworzenie za routerem wewnętrznym prywatnej sieci szkieletowej łączącej wewnętrzne routery. Nie stanowi natomiast, z punktu widzenia bezpieczeństwa, dodatkowego problemu użycie wielu routerów zewnętrznych podłączonych do tej samej sieci peryferyjnej. \section{Zalecenia odnośnie bezpiecznej konfiguracji} Architektura zabezpieczeń sieci jest pojęciem obejmującym swoim zakresem zarówno pojedyncze routery brzegowe z filtrowaniem pakietów jak i zaawansowane rozwiązania angażujące wiele ścian ogniowych, systemów pośredniczenia i systemów wykrywania włamań. Jest jednak kilka zaleceń ogólnych, odnoszących się do każdego systemu zabezpieczeń. \begin{itemize} \item \e{prostota rozwiązania} \ang{KISS, Keep It Simple}, rozwiązanie nie może być zbyt skomplikowane, gdyż wtedy trudno w pełni je rozumieć, zweryfikować oraz nim zarządzać. Złożoność w projektowaniu i funkcjonalności często prowadzi do błędów konfiguracyjnych. Jest to najważniejsze z poniższych zaleceń. \item \e{wykorzystywanie urządzeń zgodnie z ich pierwotnym przeznaczeniem}, przede wszystkim zaleca się nie zatrudnianie do funkcji ściany ogniowej komputerów do tego pierwotnie nie dedykowanych. Analogicznie, podstawowym przeznaczeniem routerów jest routing a nie filtrowanie pakietów. Nie oznacza to, że nie należy wykorzystywać ich możliwości filtrowania pakietów, jednak nie powinno się polegać jedynie na routerach. \item \e{ochrona wielowarstwowa}, powinno się stosować architekturę wielowarstwową, przygotowywać kilka linii obrony. Tam, gdzie można wykorzystać kilka ścian ogniowych, należy je wykorzystać. Tam, gdzie można wdrożyć filtrowania pakietów w kilku punktach sieci, powinno się je wdrożyć. Jeżeli systemy operacyjne serwerów usług mają możliwość własnych metod zabezpieczenia, należy je również skonfigurować i uaktywnić. \item \e{niebagatelizowanie zagrożeń wewnętrznych} koncentrując się na zabezpieczeniach przed zagrożeniami zewnętrznymi nie wolno zapominać o potencjalnych zagrożeniach wewnętrznych. Rozpatrywać należy nie tylko sytuację, w której pracownik próbuje naruszyć bezpieczeństwo sieci własnej instytucji, ale i fakt, iż z powodu niedbałości bądź błędów użytkowników, intruz może uzyskać formalnie poprawny dostęp do zasobów wewnętrznych (zdobycie hasła pracownika, kradzież laptopa z konfiguracją VPN w przypadku użytkowników mobilnych), po czym może próbować atakować zasoby sieciowe mając już przyczółek w sieci wewnętrznej. \end{itemize} Decydując się na konkretną architekturę, która ma zabezpieczać sieć, należy rozpatrywać ściany ogniowe, które oferują następujące własności: \begin{itemize} \item filtrowanie pakietów i protokołów (filtrowanie na bazie typu protokołu, adresów i numerów portów źródła i celu, interfejsu wejściowego/wyjściowego pakietu), \item filtrowanie z badaniem stanu dla usług połączeniowych (co najmniej dla protokołów SMTP, FTP oraz HTTP), \item świadczenie usługi pośredniczenia \ang{proxy} dla planowanych do wykorzystywania protokołów, \item możliwość rejestracji zarówno ruchu przepuszczanego jak i odrzucanego, \item mechanizmy uwierzytelniania użytkowników o niestatycznym charakterze, tak by nawet ewentualne podsłuchanie protokołu uwierzytelniania nie umożliwiło intruzowi podanie się za uprawnionego użytkownika. \end{itemize} Decydując się na podłączenie do sieci Internet powinno się stworzyć co najmniej jedną ekranowaną sieć peryferyjną (najlepiej dwie, zewnętrzną i wewnętrzną), określaną również mianem strefy zdemilitaryzowanej \ang{DMZ}. Usługi dostępne publicznie powinny być oddzielone od sieci wewnętrznej i umieszczone w sieci peryferyjnej. Użytkownicy wewnętrzni powinni być dodatkowo ochraniani przez wewnętrzną ścianę ogniową (co najmniej przez router dławiący). \begin{figure*} \begin{center} \input{fwarch1} \end{center} \caption[Rozbudowana architektura ściany ogniowej] {\label{fig:fwarch1} Rozbudowana architektura ściany ogniowej.} \end{figure*} Na rysunku \ref{fig:fwarch1} pokazano przykład dobrze zabezpieczonej sieci z dużą liczbą elementów zabezpieczających. Użytkownicy zdalni powinni raczej korzystać z sieci VPN. O ile serwer połączeń telefonicznych dial-in mógłby być umieszczony za ścianą ogniową, o tyle bezpieczniej jest powiązać go z serwerem usługi VPN, by połączenia zdalne mogły umożliwiać uwierzytelnienie i szyfrowanie. Jako dodatkowy element systemu zabezpieczeń, poza dotychczas omawianymi, pojawiają się systemy wykrywania intruzów \ang{IDS}. Na rysunku umieszczono sieciowe systemy wykrywania intruzów \ang{network-based intrusion detection systems, NIDS}. Systemy typu host-based \ang{HIDS} mogą być dodatkowym zabezpieczeniem w przypadku instalacji na serwerach niekrytycznych pod względem wymagań na przepustowość, na przykład na serwerach poczty elektronicznej. W przypadku sieci wewnętrznych zaleca się stosowanie mechanizmu translacji adresów \ang{NAT} oraz konfigurację osobnych, rozmieszczonych w osobnych podsieciach, serwerów DNS do wykorzystywania przez użytkowników zewnętrznych i użytkowników wewnętrznych. Informacja w serwerach DNS może być zróżnicowana - tak, by ukryć szczegóły konfiguracyjne sieci wewnętrznej przed potencjalnymi intruzami. Użytkownicy zdalni powinni być zobligowani wdrożoną polityką bezpieczeństwa teleinformatycznego instytucji, do instalacji na komputerach przenośnych, z których łączą się do sieci instytucji, systemów typu \e{osobista ściana ogniowa} \ang{personal firewall}, zabezpieczających sam komputer przenośny przed atakami z sieci Internet. Przed podjęciem decyzji o architekturze zabezpieczeń powinno się przeprowadzić analizę ryzyka krytyczności poszczególnych elementów i informacji przesyłanej w systemie teleinformatycznym. Rezultatem analizy powinny być decyzje dotyczące metody zabezpieczania i kosztów przeznaczonych na to zabezpieczenie. Przed konfiguracją urzadzeń sieciowych pod względem zabezpieczania powinna być przygotowana polityka zabezpieczeń, zawierająca między innymi informacje jako informacje należy przepuszczać a jakie blokować. Domyślną polityką dotyczącą ruchu przychodzącego powinno być blokowanie wszystkich pakietów i połączeń, które jawnie nie zostały uznane za dozwolone. Alternatywa - blokowanie tego, co jest jawnie zabronione, jest rozwiązaniem mniej bezpiecznym. Powinno się przyjąć jako generalną zasadę, iż każdy protokół i ruch, który nie jest niezbędnie konieczny powinien być zablokowany juz na pierwszym zabezpieczeniu, czyli na routerze dostępowym. Dzięki temu zredukuje się możliwość ataków i zmniejszy nasilenie ruchu w sieciach peryferyjnych, przez co zwiększy możliwość kontroli ruchu. Zarówno do wychodzącego ruchu HTTP, jak i do wychodzącego i przychodzącego ruchu SMTP, powinno się wykorzystywać systemy pośredniczące \ang{proxy}. Stosowane rozwiązania pośredniczące co najmniej powinny: \begin{itemize} \item umożliwiać blokowanie apletów i aplikacji w języku Java, \item posiadać możliwość filtrowania ActiveX i JavaScript, \item blokować zadane konfiguracją typy załączników MIME poczty elektronicznej, \item wykonywać skanowania antywirusowe. \end{itemize} To na ile aktywna zawartość stron WWW jest blokowana czy filtrowana zależy od przyjętej w instytucji polityki bezpieczeństwa. Należy znaleźć sensowny kompromis między możliwością przeglądania jak największego spektrum stron sieci WWW a bezpieczeństwem. Jedynym elementem, który bezwarunkowo powinien być blokowany są listy z wirusami i koniami trojańskimi. Z punktu widzenia bezpieczeństwa oczywiście idealną sytuacją byłoby blokowanie całej aktywnej zawartości wszystkich zewnętrznych stron WWW. Załączniki poczty posiadające następujące rozszerzenia zawierają instrukcje, które mogą być wykonane półautomatycznie bądź automatycznie na komputerze odbiorczym: \e{.ade}, \e{.adp}, \e{.bas}, \e{.bat}, \e{.chm}, \e{.cmd}, \e{.com}, \e{.cpl}, \e{.crt}, \e{.dll}, \e{.eml}, \e{.exe}, \e{.hlp}, \e{.hta}, \e{.inf}, \e{.ins}, \e{.isp}, \e{.js}, \e{.jse}, \e{.lnk}, \e{.mdb}, \e{.mde}, \e{.msc}, \e{.msi}, \e{.msp}, \e{.mst}, \e{.pcd}, \e{.pif}, \e{.pl}, \e{.pot}, \e{.reg}, \e{.scr}, \e{.sct}, \e{.scx}, \e{.shs}, \e{.url}, \e{.vb}, \e{.vbe}, \e{.vbs}, \e{.wsc}, \e{.wsc}, \e{.wsf}, \e{.wsh}. Rozszerzenia te w znakomitej większości są charakterystyczne dla systemów MS Windows. Nie oznacza to jednak, iż inne systemy operacyjne są wolne od zagrożeń związanych z możliwością uruchomienia robaków poprzez otwarcie załącznika poczty. Kod wykonywalny może być umieszczony również poprzez odwołania do adresów URL, a także w bezpiecznych wydawać by się mogło plikach jak np. pliki w postaci Postscript. To, że destrukcyjne czy intruzyjne załączniki preparowane są najczęściej dla systemu Windows wiąże się jedynie z mniejszą popularnością innych systemów, a nie ich lepszymi założeniami pod względem bezpieczeństwa. W najbliższym czasie można na przykład spodziewać się coraz większej liczby robaków przygotowywanych pod odbiorcę w systemie Linux - ze względu na rosnącą popularność tego systemu. Domyślną polityką ściany ogniowej powinno być blokowanie całego przychodzącego ruchu o ile ten nie został jawnie dopuszczony dla wybranych protokołów czy adresów. Poniżej przedstawiono zestawienie serwisów i aplikacji, które powinny przedmiotem konfiguracji na ścianie ogniowej wraz z opisem działania, które należy przedsięwziąć. Zestawienie stworzono na bazie zaleceń organizacji CERT/CC (www.cert.org/tech\_tips/packet\_filtering.html) oraz SANS Institute (www.sans.org/top20.htm). \begin{figure*} \begin{small} \begin{center} \noindent \begin{tabular}{|c|l|l|} \hline \bf{Aplikacja} & \bf{Numer portu} & \bf{Akcja} \\ \hline \hline Usługi & telnet - 23/tcp & ograniczenie z silnym \\ & & uwierzytelnianiem\\ \cline{2 - 3} logowania & SSH - 22/tcp & ograniczenie do ustalonych \\ & & systemów\\ \cline{2 - 3} & FTP - 21/tcp & ograniczenie z silnym \\ & & uwierzytelnianiem\\ \cline{2 - 3} & \e{r-usługi} - 512-514/tcp & zawsze zablokowane\\ \hline \hline RPC i NFS & portmap/rpcbind - 111/tcp/udp & zawsze zablokowane\\ \cline{2 - 3} & NFS - 2049/tcp/udp & zawsze zablokowane\\ \cline{2 - 3} & lockd - 4045/tcp/udp & zawsze zablokowane\\ \hline \hline NetBIOS & 135/tcp/udp & zawsze zablokowane\\ \cline{2 - 3} w Windows NT & 137/udp & zawsze zablokowane\\ \cline{2 - 3} & 138/udp & zawsze zablokowane\\ \cline{2 - 3} & 139/tcp & zawsze zablokowane\\ \cline{2 - 3} & 445/tcp/udp (W2K) & zawsze zablokowane\\ \hline \hline X Window & 6000/tcp - 6255/tcp & zawsze zablokowane\\ \hline \hline Usługi & DNS - 53/udp & ograniczone do zewnętrznych \\ nazewnicze & & serwerów DNS \\ \cline{2 - 3} & DNS, transfer strefy - 53/udp & zablokowane, o ile nie ma \\ & & zewnętrznych \e{slave}\\ \cline{2 - 3} & LDAP - 389/tcp/udp & zawsze zablokowane\\ \hline \hline poczta & SMTP - 25/tcp & zablokowane z wyjątkiem \\ & & serwerów poczty \\ \cline{2 - 3} & POP - 109/tcp i 110/tcp & zawsze zablokowane\\ \cline{2 - 3} & IMAP - 143/tcp & zawsze zablokowane\\ \hline \hline WWW & HTTP - 80/tcp i SSL - 443/tcp & zablokowane z wyjątkiem \\ & & publicznych serwerów WWW \\ \cline{2 - 3} & \multicolumn{2}{c|}{być może również inne porty: 8000/tcp, 8080/tcp, 8888/tcp}\\ \hline \hline ,,małe porty'' & porty poniżej 20/tcp/udp & zawsze zablokowane\\ \cline{2 - 3} & time - 37/tcp/udp & zawsze zablokowane\\ \hline \hline różne & TFTP - 69/udp & zawsze zablokowane\\ \cline{2 - 3} & finger - 79/tcp & zawsze zablokowane\\ \cline{2 - 3} & NNTP - 119/tcp & zawsze zablokowane\\ \cline{2 - 3} & NTP - 123/tcp & zawsze zablokowane\\ \cline{2 - 3} & LPD - 515/tcp & zawsze zablokowane\\ \cline{2 - 3} & syslog - 514/tcp & zawsze zablokowane\\ \cline{2 - 3} & SNMP - 161-162/tcp/udp & zawsze zablokowane\\ \cline{2 - 3} & BGP - 179/tcp & zawsze zablokowane\\ \cline{2 - 3} & SOCKS - 1080/tcp & zawsze zablokowane\\ \hline \end{tabular} \end{center} \end{small} \caption[Zalecana konfiguracja filtrowania pakietów] {\label{tab:frules} Zalecana konfiguracja filtrowania pakietów.} \end{figure*} Jeżeli chodzi o filtrowanie protokołu ICMP, zaleca się blokowanie przychodzących żądań echa (ping i traceroute) oraz blokowanie wychodzących odpowiedzi echo, przekroczenia czasu, i nieosiągalności celu - z wyjątkiem pakietów typu ,,wiadomość zbyt duża'' (typ 3, kod 4). Jest to podejście restrykcyjne, która utrudnia pracę również w przypadku prawidłowych prób użycia pakietów ICMP. Na podejście mniej restrykcyjne, pozwalające na ograniczoną listę dopuszczanych typów pakietów ICMP z określonych źródeł (np. od własnego dostawcy sieci Internet) można sobie pozwolić, o ile posiada się router, który potrafi dokładnie analizować i filtrować pakiety ICMP. Następujące typy ruchu sieciowego powinny być zawsze zablokowane: \begin{itemize} \item ruch wejściowy z nieautoryzowanych źródeł podający jako adres źródła adres ściany ogniowej, \item ruch wejściowy z adresem źródłowym stwierdzającym, iż pakiet jakoby pochodzi z sieci wewnętrznej, \item ruch wejściowy ze źródła z zakresu zdefiniowanego w RFC 1918 jako zarezerwowanego dla sieci prywatnej, \item ruch wejściowy z nieautoryzowanego źródła zawierający protokół SNMP (Simple Network Management Protocol), \item ruch wejściowy zawierający informacje o routingu źródłowym IP, \item ruch wejściowy i wyjściowy zawierający jako źródło bądź przeznaczenie adres lokalny 127.0.0.1, \item ruch wejściowy i wyjściowy zawierający jako adres źródła bądź przeznaczenia 0.0.0.0, \item ruch wejściowy i wyjściowy zawierający adresy ukierunkowanego rozgłaszania \ang{directed broadcast}. \end{itemize} Jeżeli ściana ogniowa została zainstalowana na standardowym systemie operacyjnym (np. Unix, Windows NT), system operacyjny musi oferować zminimalizowany (być może żaden) zestaw usług sieciowych. Najlepszą sytuacją jest ta, w której system taki nie oferuje żadnych usług sieciowych (żadne usługi nie słuchają na portach IP) oprócz niezbędnych do realizacji funkcji ściany ogniowej. System operacyjny musi być też regularnie uaktualniany poprzez nakładanie łatek na system przygotowanych przez producenta. Kopia zapasowa systemu ściany ogniowej nie powinna być przeprowadzana przez sieć. Do tworzenia kopii powinno się wykorzystywać jedynie wewnętrzne mechanizmy, np. dołączony streamer. Wykonywanie kopii zapasowych przez sieć byłoby źródłem potencjalnych luk w systemie zabezpieczeń. Ściana ogniowa powinna rejestrować ustalony przez administratora ruch. Zarejestrowane dzienniki systemowe powinny być analizowane przez administratora systemu codziennie. O ile system ściany ogniowej posiada zdalny interfejs graficzny do konfiguracji i przeglądania zapisanych informacji, warto zastanowić się czy nie należy stworzyć dedykowanej sieci wewnętrznej połączonej do ściany dedykowanym interfejsem jedynie do łączenia się ze ścianą ogniową przez administratora poprzez klienta interfejsu graficznego. Mimo silnych zabezpieczeń każda instytucja powinna być przygotowana na wystąpienie incydentów naruszenia bezpieczeństwa zasobów sieciowych o różnym poziomie konsekwencji. Procedury obsługi incydentów powinny być przygotowane zanim takowe incydenty wystąpią.