Ten artykuł jest trzecim z serii artykułów „Jak przejąć kontrolę nad infrastrukturą sieciową”. Można znaleźć treść wszystkich artykułów z serii oraz linki tutaj.

Nie ma sensu mówić o całkowitym wyeliminowaniu zagrożeń bezpieczeństwa. W zasadzie nie możemy ich zredukować do zera. Musimy także zrozumieć, że w miarę jak staramy się zwiększać bezpieczeństwo sieci, nasze rozwiązania stają się coraz droższe. Musisz znaleźć kompromis między kosztami, złożonością i bezpieczeństwem, który ma sens dla Twojej sieci.

Oczywiście projektowanie zabezpieczeń jest organicznie zintegrowane z ogólną architekturą, a zastosowane rozwiązania bezpieczeństwa wpływają na skalowalność, niezawodność, łatwość zarządzania… infrastruktury sieciowej, co również należy wziąć pod uwagę.

Ale przypomnę, że teraz nie mówimy o tworzeniu sieci. Nawiazujac do naszej warunki początkowe wybraliśmy już projekt, wybraliśmy sprzęt, stworzyliśmy infrastrukturę i na tym etapie, jeśli to możliwe, powinniśmy „żyć” i szukać rozwiązań w kontekście wcześniej wybranego podejścia.

Naszym zadaniem jest teraz identyfikacja zagrożeń związanych z bezpieczeństwem na poziomie sieci i redukcja ich do rozsądnego poziomu.

Audyt bezpieczeństwa sieci

Jeśli Twoja organizacja wdrożyła procesy ISO 27k, audyty bezpieczeństwa i zmiany w sieci powinny płynnie wpasować się w ogólne procesy w ramach tego podejścia. Ale te standardy nadal nie dotyczą konkretnych rozwiązań, konfiguracji, projektu... Nie ma jednoznacznych porad, żadnych standardów określających szczegółowo, jak powinna wyglądać Twoja sieć, na tym polega złożoność i piękno tego zadania.

Chciałbym podkreślić kilka możliwych audytów bezpieczeństwa sieci:

• audyt konfiguracji sprzętu (hartowanie)
• audyt projektu bezpieczeństwa
• audyt dostępu
• audyt procesu

Audyt konfiguracji sprzętu (hartowanie)

Wydaje się, że w większości przypadków jest to najlepszy punkt wyjścia do audytu i poprawy bezpieczeństwa Twojej sieci. IMHO, jest to dobra demonstracja prawa Pareto (20% wysiłku daje 80% wyniku, a pozostałe 80% wysiłku daje tylko 20% wyniku).

Konkluzja jest taka, że ​​zazwyczaj mamy zalecenia od dostawców dotyczące „najlepszych praktyk” w zakresie bezpieczeństwa podczas konfigurowania sprzętu. Nazywa się to „hartowaniem”.

Często można też znaleźć ankietę (lub samodzielnie ją stworzyć) bazującą na tych zaleceniach, która pomoże Ci określić na ile konfiguracja Twojego sprzętu jest zgodna z tymi „najlepszymi praktykami” i zgodnie z wynikami dokonać zmian w Twojej sieci . Umożliwi to znaczne zmniejszenie zagrożeń bezpieczeństwa w dość prosty sposób, praktycznie bez żadnych kosztów.

Kilka przykładów dla niektórych systemów operacyjnych Cisco.

Ulepszanie konfiguracji Cisco IOS
Wzmocnienie konfiguracji Cisco IOS-XR
Wzmocnienie konfiguracji Cisco NX-OS
Bazowa lista kontrolna zabezpieczeń Cisco

Na podstawie tych dokumentów można stworzyć listę wymagań konfiguracyjnych dla każdego typu sprzętu. Na przykład w przypadku Cisco N7K VDC te wymagania mogą wyglądać tak.

W ten sposób można tworzyć pliki konfiguracyjne dla różnych typów urządzeń aktywnych w infrastrukturze sieciowej. Następnie ręcznie lub korzystając z automatyzacji możesz „przesłać” te pliki konfiguracyjne. Sposób automatyzacji tego procesu zostanie szczegółowo omówiony w kolejnej serii artykułów na temat orkiestracji i automatyzacji.

Audyt projektu zabezpieczeń

Zazwyczaj sieć korporacyjna zawiera następujące segmenty w takiej czy innej formie:

• DC (strefa DMZ usług publicznych i centrum danych intranetowych)
• Dostęp do Internetu
• Dostęp zdalny do sieci VPN
• Krawędź sieci WAN
• Oddział
• Kampus (biuro)
• rdzeń

Tytuły zaczerpnięte z Cisco BEZPIECZNE modelu, ale oczywiście nie trzeba wiązać się dokładnie z tymi nazwami i tym modelem. Chcę jednak porozmawiać o istocie i nie dać się wciągnąć w formalności.

Dla każdego z tych segmentów wymagania bezpieczeństwa, ryzyka i w związku z tym rozwiązania będą inne.

Przyjrzyjmy się każdemu z nich osobno pod kątem problemów, które możesz napotkać z punktu widzenia projektowania zabezpieczeń. Oczywiście powtarzam jeszcze raz, że artykuł ten w niczym nie pretenduje do kompletności, co nie jest łatwe (jeśli nie niemożliwe) do osiągnięcia w tym naprawdę głębokim i wieloaspektowym temacie, ale odzwierciedla moje osobiste doświadczenia.

Nie ma idealnego rozwiązania (przynajmniej jeszcze nie). To zawsze kompromis. Ważne jest jednak, aby decyzję o zastosowaniu takiego czy innego podejścia podjąć świadomie, ze zrozumieniem zarówno jego zalet, jak i wad.

Centrum danych

Najbardziej krytyczny segment z punktu widzenia bezpieczeństwa.
I tutaj jak zwykle nie ma uniwersalnego rozwiązania. Wszystko zależy w dużej mierze od wymagań sieci.

Czy zapora sieciowa jest konieczna, czy nie?

Wydawałoby się, że odpowiedź jest oczywista, jednak nie wszystko jest tak jasne, jak mogłoby się wydawać. Na Twój wybór można mieć wpływ nie tylko cena.

Przykład 1. Opóźnienia.

Jeżeli istotnym wymaganiem pomiędzy niektórymi segmentami sieci są małe opóźnienia, co ma miejsce np. w przypadku centrali, to nie będziemy mogli zastosować firewalli pomiędzy tymi segmentami. Trudno znaleźć badania dotyczące opóźnień w zaporach ogniowych, ale niewiele modeli przełączników może zapewnić opóźnienie mniejsze lub rzędu 1 mks, więc myślę, że jeśli mikrosekundy są dla Ciebie ważne, to zapory ogniowe nie są dla Ciebie.

Przykład 2. Wydajność.

Przepustowość najlepszych przełączników L3 jest zwykle o rząd wielkości większa niż przepustowość najpotężniejszych zapór sieciowych. Dlatego w przypadku ruchu o dużej intensywności najprawdopodobniej będziesz musiał pozwolić temu ruchowi na ominięcie zapór sieciowych.

Przykład 3. Niezawodność.

Zapory ogniowe, zwłaszcza nowoczesny NGFW (Next-Generation FW), to złożone urządzenia. Są znacznie bardziej złożone niż przełączniki L3/L2. Zapewniają dużą liczbę usług i opcji konfiguracyjnych, nic więc dziwnego, że ich niezawodność jest znacznie niższa. Jeśli ciągłość usług ma kluczowe znaczenie dla sieci, być może będziesz musiał wybrać, co doprowadzi do lepszej dostępności — bezpieczeństwo dzięki zaporze sieciowej czy prostota sieci zbudowanej na przełącznikach (lub różnego rodzaju strukturach szkieletowych) przy użyciu zwykłych list ACL.

W przypadku powyższych przykładów najprawdopodobniej (jak zwykle) będziesz musiał znaleźć kompromis. Spójrz na następujące rozwiązania:

• Jeśli zdecydujesz się nie używać zapór ogniowych wewnątrz centrum danych, musisz pomyśleć o tym, jak maksymalnie ograniczyć dostęp na obwodzie. Na przykład można otworzyć tylko niezbędne porty z Internetu (dla ruchu klientów) i uzyskać dostęp administracyjny do centrum danych tylko z hostów skoku. Na hostach skoku wykonaj wszystkie niezbędne kontrole (uwierzytelnianie/autoryzacja, program antywirusowy, rejestrowanie, ...)
• można zastosować logiczną partycję sieci centrum danych na segmenty, podobnie jak w schemacie opisanym w PSEFABRIC przykład p002. W takim przypadku routing musi być skonfigurowany w taki sposób, aby ruch wrażliwy na opóźnienia lub o dużej intensywności przechodził „w obrębie” jednego segmentu (w przypadku p002, VRF) i nie przechodził przez zaporę ogniową. Ruch pomiędzy różnymi segmentami będzie w dalszym ciągu przechodził przez zaporę. Możesz także użyć przecieku tras pomiędzy urządzeniami VRF, aby uniknąć przekierowywania ruchu przez zaporę
• Zaporę sieciową można także używać w trybie przezroczystym i tylko dla tych sieci VLAN, w których te czynniki (opóźnienie/wydajność) nie są znaczące. Musisz jednak dokładnie przestudiować ograniczenia związane z używaniem tego moda dla każdego dostawcy
• możesz rozważyć użycie architektury łańcucha usług. Dzięki temu przez zaporę będzie mógł przejść tylko niezbędny ruch. Ładnie wygląda w teorii, jednak nigdy nie widziałem takiego rozwiązania w produkcji. Testowaliśmy łańcuch usług dla Cisco ACI/Juniper SRX/F5 LTM około 3 lata temu, ale wtedy to rozwiązanie wydawało nam się „prymitywne”.

Poziom ochrony

Teraz musisz sobie odpowiedzieć na pytanie jakich narzędzi chcesz używać do filtrowania ruchu. Oto niektóre funkcje, które zwykle są obecne w NGFW (na przykład tutaj):

• stanowa zapora sieciowa (domyślna)
• zapora sieciowa aplikacji
• zapobieganie zagrożeniom (antywirus, oprogramowanie antyszpiegowskie i podatność na zagrożenia)
• Filtrowanie adresów URL
• filtrowanie danych (filtrowanie treści)
• blokowanie plików (blokowanie typów plików)
• ochrona

I też nie wszystko jest jasne. Wydawać by się mogło, że im wyższy poziom ochrony, tym lepiej. Ale to też trzeba wziąć pod uwagę

• Im więcej powyższych funkcji firewalla użyjesz, tym będzie on naturalnie droższy (licencje, moduły dodatkowe)
• użycie niektórych algorytmów może znacznie zmniejszyć przepustowość zapory sieciowej, a także zwiększyć opóźnienia, patrz na przykład tutaj
• jak każde złożone rozwiązanie, stosowanie skomplikowanych metod ochrony może obniżyć niezawodność Twojego rozwiązania, przykładowo podczas korzystania z firewalla aplikacyjnego spotkałem się z blokowaniem niektórych całkiem standardowych działających aplikacji (dns, smb)

Jak zawsze musisz znaleźć najlepsze rozwiązanie dla swojej sieci.

Nie da się jednoznacznie odpowiedzieć na pytanie, jakie funkcje zabezpieczające mogą być wymagane. Po pierwsze, zależy to oczywiście od danych, które przesyłasz lub przechowujesz i które próbujesz chronić. Po drugie, w rzeczywistości często wybór narzędzi bezpieczeństwa jest kwestią wiary i zaufania do dostawcy. Nie znasz algorytmów, nie wiesz, jak skuteczne są i nie możesz ich w pełni przetestować.

Dlatego w kluczowych segmentach dobrym rozwiązaniem może być skorzystanie z ofert różnych firm. Można na przykład włączyć program antywirusowy na zaporze sieciowej, ale także zastosować ochronę antywirusową (od innego producenta) lokalnie na hostach.

Segmentacja

Mówimy o logicznej segmentacji sieci centrów danych. Na przykład podział na sieci VLAN i podsieci jest również segmentacją logiczną, ale nie będziemy tego rozważać ze względu na jego oczywistość. Ciekawa segmentacja uwzględniająca takie podmioty jak strefy bezpieczeństwa FW, VRF (oraz ich analogi w stosunku do różnych dostawców), urządzenia logiczne (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant,…),…

Przykład takiej logicznej segmentacji i obecnie poszukiwanego projektu centrum danych podano w p002 projektu PSEFABRIC.

Po zdefiniowaniu logicznych części sieci możesz następnie opisać, w jaki sposób ruch przemieszcza się pomiędzy różnymi segmentami, na jakich urządzeniach będzie wykonywane filtrowanie i w jaki sposób.

Jeśli Twoja sieć nie ma wyraźnej partycji logicznej i zasady stosowania zasad bezpieczeństwa dla różnych przepływów danych nie są sformalizowane, oznacza to, że otwierając ten czy inny dostęp, jesteś zmuszony rozwiązać ten problem i z dużym prawdopodobieństwem za każdym razem rozwiąże to inaczej.

Często segmentacja opiera się wyłącznie na strefach bezpieczeństwa FW. Następnie musisz odpowiedzieć na następujące pytania:

• jakich stref bezpieczeństwa potrzebujesz
• jaki poziom ochrony chcesz zastosować w każdej z tych stref
• czy ruch wewnątrzstrefowy będzie domyślnie dozwolony?
• jeśli nie, jakie zasady filtrowania ruchu będą stosowane w każdej strefie
• jakie zasady filtrowania ruchu będą stosowane dla każdej pary stref (źródłowa/docelowa)

TCAM

Częstym problemem jest niewystarczająca ilość TCAM (Ternary Content Addressable Memory), zarówno do routingu, jak i dostępu. IMHO to jedna z najważniejszych kwestii przy wyborze sprzętu, dlatego trzeba do tej kwestii podchodzić z odpowiednią ostrożnością.

Przykład 1. Tabela spedycyjna TCAM.

Weźmy pod uwagę Palo Alto 7 tys zapora sieciowa
Widzimy, że rozmiar tabeli przesyłania dalej IPv4* = 32 KB
Co więcej, ta liczba tras jest wspólna dla wszystkich VSYS.

Załóżmy, że zgodnie ze swoim projektem decydujesz się na użycie 4 VSYS.
Każdy z tych VSYS jest połączony poprzez BGP z dwoma MPLS PE w chmurze, których używasz jako BB. W ten sposób 4 VSYS wymieniają między sobą wszystkie określone trasy i mają tabelę przesyłania z w przybliżeniu tymi samymi zestawami tras (ale różnymi NH). Ponieważ każdy VSYS ma 2 sesje BGP (z tymi samymi ustawieniami), wówczas każda trasa odebrana poprzez MPLS ma 2 NH i odpowiednio 2 wpisy FIB w Tabeli Przekierowań. Jeśli założymy, że jest to jedyny firewall w centrum danych i musi znać wszystkie trasy, to będzie to oznaczać, że łączna liczba tras w naszym centrum danych nie może być większa niż 32K/(4 * 2) = 4K.

Teraz, jeśli założymy, że mamy 2 centra danych (o tej samej konstrukcji) i chcemy wykorzystać sieci VLAN „rozciągnięte” pomiędzy centrami danych (na przykład dla vMotion), to aby rozwiązać problem routingu, musimy użyć tras hostów . Oznacza to jednak, że w przypadku 2 centrów danych będziemy mieli nie więcej niż 4096 możliwych hostów i oczywiście może to nie wystarczyć.

Przykład 2. ACL TCAM.

Jeśli planujesz filtrować ruch na przełącznikach L3 (lub innych rozwiązaniach wykorzystujących przełączniki L3, np. Cisco ACI), to przy wyborze sprzętu warto zwrócić uwagę na listę ACL TCAM.

Załóżmy, że chcesz kontrolować dostęp do interfejsów SVI Cisco Catalyst 4500. Następnie, jak widać z ten artykuł, do kontroli ruchu wychodzącego (jak również przychodzącego) na interfejsach można używać wyłącznie linii 4096 TCAM. Co przy użyciu TCAM3 da ci około 4000 tysięcy ACE (linii ACL).

Jeśli stoisz przed problemem niewystarczającego TCAM, to przede wszystkim musisz oczywiście rozważyć możliwość optymalizacji. Zatem w przypadku problemu z rozmiarem Tabeli Przekierowań należy rozważyć możliwość agregacji tras. W przypadku problemu z wielkością TCAM dla dostępów, przeprowadź audyt dostępów, usuń nieaktualne i nakładające się zapisy i ewentualnie zrewiduj procedurę otwierania dostępów (zostanie to szczegółowo omówione w rozdziale o audytowaniu dostępów).

Duża dostępność

Pytanie brzmi: czy powinienem zastosować HA do firewalli, czy zainstalować dwie niezależne skrzynki „równolegle” i w przypadku awarii jednej z nich kierować ruch przez drugą?

Wydawałoby się, że odpowiedź jest oczywista – użyj HA. Pytanie to wciąż pojawia się dlatego, że niestety teoretyczne i reklamowe 99 oraz kilka dziesiętnych procent dostępności w praktyce okazuje się wcale nie tak różowe. HA jest logicznie dość złożoną rzeczą i na innym sprzęcie i u różnych dostawców (nie było wyjątków) wyłapaliśmy problemy, błędy i przerwy w świadczeniu usług.

Jeśli korzystasz z HA, będziesz miał możliwość wyłączenia poszczególnych węzłów, przełączania się między nimi bez zatrzymywania usługi, co jest ważne np. przy dokonywaniu aktualizacji, ale jednocześnie masz dalekie od zera prawdopodobieństwo, że oba węzły w tym samym czasie ulegnie awarii, a także, że następna aktualizacja nie przebiegnie tak gładko, jak obiecuje sprzedawca (tego problemu można uniknąć, jeśli masz możliwość przetestowania aktualizacji na sprzęcie laboratoryjnym).

Jeśli nie używasz HA, to z punktu widzenia podwójnej awarii ryzyko jest znacznie mniejsze (ponieważ masz 2 niezależne zapory ogniowe), ale ponieważ... sesje nie są zsynchronizowane, wówczas za każdym razem, gdy przełączasz się między tymi zaporami, nastąpi utrata ruchu. Można oczywiście zastosować bezstanową zaporę ogniową, ale wtedy w dużej mierze traci się sens używania zapory ogniowej.

Dlatego jeśli w wyniku audytu odkryłeś samotne firewalle i zastanawiasz się nad zwiększeniem niezawodności swojej sieci, to HA jest oczywiście jednym z zalecanych rozwiązań, ale warto też wziąć pod uwagę wady z tym związane przy takim podejściu i być może specjalnie dla Twojej sieci bardziej odpowiednie byłoby inne rozwiązanie.

Zarządzalność

W zasadzie HA dotyczy także sterowalności. Zamiast konfigurować 2 boxy osobno i zajmować się problemem synchronizacji konfiguracji, zarządzasz nimi tak, jakbyś miał jedno urządzenie.

Ale być może masz wiele centrów danych i wiele zapór sieciowych, wtedy to pytanie pojawia się na nowym poziomie. Pytanie nie dotyczy tylko konfiguracji, ale także

• konfiguracje kopii zapasowych
• aktualizacje
• ulepszenia
• monitorowanie
• Logowanie

A wszystko to można rozwiązać za pomocą scentralizowanych systemów zarządzania.

Na przykład, jeśli używasz zapór sieciowych Palo Alto Krajobraz jest takim rozwiązaniem.

Aby być kontynuowane.

Źródło: www.habr.com