📬 ISN 186: Firewall na Straży Bezpieczeństwa: HTTPS, SFTP, FTPS pod Lupą! + CLI i SD-WAN!

Obsługa ruchu HTTPS, SFTP i FTPS przez firewalle

DNS, SFTP, and FTPS: Why Firewalls Handle These Protocols Differently

KISS IT Design Principle - Human Error Prevention

Kerry CorderoKerry Cordero

TL;DR Protokoły różnią się sposobem wykorzystania nazwy domeny po jej rozwiązaniu przez DNS.

Protokół HTTPS (HTTP over TLS/SSL) należy do najbardziej rozpowszechnionych sposobów bezpiecznej komunikacji internetowej. Gdy użytkownik łączy się z witryną przez HTTPS, proces wygląda następująco:

1. Komputer wywołuje zapytanie DNS w celu ustalenia adresu IP dla nazwy domeny, np. innasiec.pl.
2. Nawiązywane jest szyfrowane połączenie TCP na port 443.
3. Następuje negocjacja parametrów połączenia TLS pomiędzy klientem a serwerem.
4. W komunikacie ClientHello klient przesyła serwerowi Server Name Indication (SNI), czyli wskazanie, do której domeny nastąpiło połączenie.
5. Serwer wykorzystuje SNI do obsłużenia żądania i dostarczenia odpowiedniego certyfikatu SSL.

Server Name Indication, pełni bardzo istotną rolę w kontekście konfiguracji zapory. Ponieważ zawiera nazwę domeny, umożliwia urządzeniom zabezpieczającym (zaporom, proxy, WAF) rozpoznanie faktycznego miejsca docelowego połączenia i podjęcie stosownych działań.

Dzięki SNI zapory nowej generacji mogą blokować dostęp do wybranych domen, egzekwować polityki dostępu dla określonych zasobów WWW oraz przeprowadzać szczegółowe inspekcje ruchu sieciowego. Zasady mogą być tworzone na podstawie pełnych nazw domen, nie tylko adresów IP, co znacznie upraszcza zarządzanie i zwiększa bezpieczeństwo.

Zupełnie inaczej wygląda sytuacja w przypadku SFTP (SSH File Transfer Protocol). SFTP opiera się na protokole SSH, który natychmiast po nawiązaniu połączenia TCP w pełni szyfruje całą komunikację. Tak więc przebieg ustanawiania sesji SFTP wygląda następująco:

1. Komputer wywołuje zapytanie DNS w celu ustalenia adresu IP dla nazwy domeny, np. innasiec.pl.
2. Nawiązywane jest szyfrowane połączenie TCP na port 22.
3. Następuje negocjacja parametrów szyfrowania i uwierzytelnienie klienta na serwerze (np. hasło, klucz).
4. Po ustanowieniu bezpiecznego tunelu SSH wszelka dalsza komunikacja jest w pełni zaszyfrowana.

Jak widać, w protokole SFTP, w przeciwieństwie do HTTPS, nie ma ekwiwalentu Server Name Indication. Po rozwiązaniu nazwy przez DNS wszelkie dalsze informacje dotyczące docelowego hosta są ukryte pod szyfrowaniem.

Dla zapory sieciowej oznacza to, że nigdy nie dowie się ona, do jakiej domeny było kierowane żądanie SFTP. Może jedynie stwierdzić obecność połączenia SSH z danym adresem IP. W związku z tym zasady zapory dotyczące SFTP mogą być oparte wyłącznie na adresach IP, a nie nazwach domen.

Na koniec warto wspomnieć jeszcze o FTPS (FTP over TLS/SSL), będącym bezpieczniejszą wersją protokołu FTP. W jego przypadku sytuacja jest bardziej złożona i zależy od użytej odmiany:

• Explicit FTPS (FTPES, port 21) - przed wymianą komend FTP następuje negocjacja parametrów TLS. Komunikacja zawiera Server Name Indication, jako że opiera się na TLS/SSL.
• Implicit FTPS (port 990) - połączenie jest szyfrowane od samego początku. Brak możliwości dowiedzenia się nazwy docelowej domeny, podobnie jak przy SFTP.

Podsumowując, zarówno Explicit FTPS, jak i HTTPS, umożliwiają konfigurację zasad zapory opartą na nazwach domen dzięki mechanizmowi SNI w TLS. Z kolei SFTP i Implicit FTPS nie mają tej możliwości - zapora może widzieć tylko adresy IP.

Polecenia z CLI Cisco, Juniper, Arista w SR Linux

Learn SR Linux - MultiCLI Project

Open documentation for open Network OS

Learn SR LinuxSR Linux

W SR Linux wszystkie polecenia "show" są zapisane jako egzekwowalne skrypty Pythona, bezpośrednio korzystające z infrastruktury opartej na modelach YANG, aby uzyskać dostęp do informacji o stanie systemu. Co więcej, użytkownicy mają możliwość modyfikowania tych skryptów lub tworzenia całkowicie nowych poleceń CLI, wykorzystując to samo podejście co zespół programistów SR Linux. Te wtyczki użytkowników są znane jako "Custom CLI plugins" (Niestandardowe wtyczki CLI).

Ponieważ SR Linux jest modelowany w całości w YANG, wtyczki te mogą uzyskiwać dostęp do dowolnych obiektów stanu lub atrybutów w systemie i wyświetlać je w formacie, do którego jesteś przyzwyczajony. To prowadzi do fascynującego pytania: czy możemy sprawić, by polecenia CLI w SR Linux wyglądały i działały tak, jak w innym NOS-ie?

MultiCLI to otwarte źródłowa inicjatywa mająca na celu stworzenie kolekcji wtyczek SR Linux implementujących polecenia pokazowe z innych systemów operacyjnych sieciowych. Jej celem jest ułatwienie migracji do SR Linux dla użytkowników znających inne platformy sieciowe, a także ponowne wykorzystanie istniejących narzędzi i zasobów w ich środowiskach. Pierwsza faza projektu obejmuje polecenia z czterech różnych NOS-ów: Arista EOS, Cisco NX-OS, Juniper JunOS i Nokia SR OS.

Testując te wtyczki, zauważysz kilka bardzo przydatnych funkcji wbudowanych w interfejs wiersza poleceń SR Linux:

• Funkcja natywnego automatycznego uzupełniania poleceń działa również dla wtyczek.
• Przycisk Tab wyświetla kolejne opcje, które można przeglądać za pomocą klawiszy strzałek.
• Podczas pisania słowa kluczowego, pojawia się cień pełnej frazy.
• Dla każdej opcji można zdefiniować sekcję pomocy, w pełni programowalną.
• Na końcu wyjścia każdego polecenia podane jest odpowiednie polecenie SR Linux, ułatwiające naukę i nawigację w CLI tej platformy.

Jak mogę uzyskać więcej takich wtyczek?

MultiCLI jest projektem open source. Jeśli masz na myśli konkretne polecenia i jesteś skłonny opracować odpowiednie wtyczki, dołącz do projektu i zacznij współtworzyć. Zapoznaj się z samouczkiem i istniejącymi wtyczkami, aby dowiedzieć się więcej o tworzeniu własnych dodatków.

AI narysuje Ci drawing

Film prezentuje nowatorskie podejście do automatycznego generowania diagramów sieciowych, wykorzystując integrację Draw.io z Cisco pyATS przez Model Context Protocol (MCP). Dzięki tej technologii możliwe jest dynamiczne aktualizowanie topologii sieci za pomocą protokołów HTTP i WebSocket, co ułatwia dokumentację, integrację z narzędziami CI/CD, ChatOps czy systemami AI.

Poznaj Catalyst SD-WAN za darmo

Build a Catalyst SDWAN 20.12.3 Home Lab

This free course walks you through the steps necessary to create your own home lab so you can explore SDWAN topics on your own or by enrolling in the upcoming “Ultimate Catalyst SDWAN Course”.

sd-geeks.comkofi Agyei

Darmowy kurs oferuje szczegółowe, praktyczne wprowadzenie do Cisco Catalyst SD-WAN, idealne dla osób chcących zdobyć praktyczne umiejętności w tej technologii. Materiał obejmuje instalację i konfigurację labu w środowiskach takich jak ESXi, Proxmox czy EVE-NG, wraz z omówieniem kluczowych komponentów systemu SD-WAN, jak vManage, vBond, vSmart oraz zarządzanie certyfikatami. Kurs zawiera 29 lekcji i ponad 9 godzin wideo, które krok po kroku przeprowadzają przez proces budowy i obsługi środowiska testowego.

Nowe Protokoły w Centrach Danych dla AI