Głęboka inspekcja pakietów (DPI)

Klasyczna zapora sieciowa decyduje na podstawie nagłówka pakietu: adresu źródłowego i docelowego, portu i protokołu. Głęboka inspekcja pakietów czyta dalej. Składa pakiety przepływu w całość i patrzy, co przenoszą, więc potrafi rozpoznać aplikację albo protokół niezależnie od portu, którego używają. ITU-T opisało wymagania wobec DPI w sieciach operatorskich w zaleceniu Y.2770 (2012 r.). Ta sama technika działa dziś w bramkach firmowych, chmurowych proxy i na samych urządzeniach.

Silnik DPI łączy trzy metody. Dysektory protokołów rozbierają znane protokoły i wyciągają z nich pola: nazwę w zapytaniu DNS, nagłówek Host w zwykłym HTTP, nazwę serwera w handshake'u TLS. Sygnatury dopasowują wzorce bajtów typowe dla danej aplikacji. Gdy ruchu nie da się odczytać, o jego rodzaju świadczą cechy statystyczne i behawioralne przepływu: rozmiary pakietów, odstępy czasu, parametry handshake'u. Częstym elementem takich systemów jest nDPI, otwarta biblioteka na licencji LGPLv3 rozwijana przez ntop. Jej autorzy podają ponad 450 rozpoznawanych protokołów warstwy 7, a biblioteka wyciąga metadane z połączeń szyfrowanych do analizy ruchu szyfrowanego.

Szyfrowanie stale zmniejsza to, co DPI widzi bez odszyfrowania. W TLS 1.3 (RFC 8446) wszystkie wiadomości handshake'u po ServerHello są szyfrowane, łącznie z certyfikatem serwera, który TLS 1.2 wysyłał jawnie. Nazwa serwera (SNI) w ClientHello pozostawała widoczna i na niej opiera się wiele klasyfikatorów. Encrypted Client Hello (ECH), opublikowane jako RFC 9849 w marcu 2026 r., szyfruje ClientHello kluczem publicznym serwera i chroni nazwę serwera oraz listę ALPN. DNS over HTTPS (DoH, RFC 8484) przenosi zapytania o nazwy do zwykłego ruchu HTTPS, więc wykrywanie oparte na DNS też traci dane wejściowe. Bez odszyfrowania urządzenie DPI w sieci coraz częściej widzi tylko adres IP i zachowanie przepływu.

Na urządzeniu sytuacja wygląda inaczej, bo system operacyjny wie, która aplikacja otworzyła połączenie, zanim cokolwiek zostanie zaszyfrowane. W standardowym Androidzie aplikacja może sprawdzać ruch tylko przez VpnService, które tworzy wirtualny interfejs sieciowy i przekazuje aplikacji każdy wychodzący pakiet. Platforma to ogranicza: użytkownik musi zatwierdzić pierwsze połączenie VPN, chyba że właściciel urządzenia albo profilu skonfiguruje stały VPN (always-on); w danej chwili może działać tylko jeden VPN, a przez cały czas widać systemowe powiadomienie. We własnym buildzie Androida inspekcję można umieścić w samym systemie.

W praktyce DPI to silnik polityk z klasyfikatorem na wejściu, a większość pracy idzie w polityki, ich aktualizacje i zachowanie systemu, gdy klasyfikacja zawiedzie. Wymagania dla każdego systemu, który sprawdza lub filtruje ruch urządzeń:

• Zdecyduj, gdzie działa inspekcja: w sieci, w chmurowym proxy, w aplikacji na urządzeniu czy w systemie operacyjnym. Każde z tych miejsc widzi inne dane i inaczej zawodzi (patrz tabela).
• Polityka to wersjonowane dane dla organizacji i grupy urządzeń: zablokowane protokoły, aplikacje, domeny, słowa kluczowe i wzorce adresów URL. Urządzenia synchronizują ją z backendem i raportują, którą wersję stosują.
• Określ zachowanie, zanim klasyfikacja się zakończy, i dla ruchu, którego silnik nie rozpozna. Tryb fail-open przepuszcza nieznany ruch, tryb fail-closed psuje aplikacje, gdy pojawi się nowy protokół. Wybierz tryb dla każdej polityki i pokaż go w panelu administratora.
• Zablokowane połączenie kończy się szybko i z czytelnym błędem, żeby aplikacje nie wisiały na timeoutach, a użytkownik odróżnił zablokowaną stronę od awarii sieci.
• Biblioteka wykrywania to zależność z własnym cyklem aktualizacji. Protokoły się zmieniają, więc sygnatury i dysektory trafiają do urządzeń razem z aktualizacjami systemu, a build jest robiony pod procesor urządzenia, często ARM.
• Zaplanuj mniejszą widoczność. TLS 1.3, ECH i DoH usuwają pola, na których opierają się starsze reguły. Odszyfrowanie TLS na urządzeniu oznacza instalację własnego certyfikatu głównego, a to osobna decyzja dotycząca bezpieczeństwa i prawa; aplikacje przypinające certyfikaty przestaną działać.
• Logi sprawdzanego ruchu to dane osobowe, jeśli wiążą osobę ze stronami i aplikacjami. Zgodnie z RODO, czyli rozporządzeniem (UE) 2016/679, system potrzebuje określonego celu, okresu przechowywania i kontroli dostępu do tych logów.
• Przed wdrożeniem zmierz zużycie procesora, pamięci i baterii na docelowym sprzęcie przy prawdziwym ruchu.

ITU-T Y.2770 (2012 r.) określa wymagania wobec DPI w sieciach następnej generacji. To punkt odniesienia dla sprzętu operatorskiego, a nie obowiązek prawny. Protokoły, które ograniczają DPI, to standardy IETF: TLS 1.3 w RFC 8446, ECH w RFC 9849 i DoH w RFC 8484. W UE zapisy ruchu powiązane z użytkownikiem podlegają RODO, więc inspekcja ruchu na urządzeniach pracowników wymaga podstawy prawnej, poinformowania osób, których dotyczy, i zasady przechowywania danych. Sprawdź też przepisy prawa pracy i telekomunikacyjnego w każdym kraju, w którym używane są urządzenia.

W projekcie systemu Raw Control inspekcja pakietów działała wewnątrz systemu operacyjnego. Pierwszą warstwą, budowaną od 2020 r., był klasyfikator linków: system synchronizował z backendu słowa kluczowe, reguły i adresy, odrzucał połączenie, gdy adres zawierał słowo kluczowe, pokrywał się z adresem z listy albo pasował do wyrażenia regularnego, i zwracał błąd EHOSTUNREACH, żeby aplikacje od razu dostawały odmowę.

W kwietniu 2021 r. skompilowaliśmy nDPI pod ARM i zintegrowaliśmy jego API z systemem operacyjnym. W maju doszło wykrywanie DNS, w czerwcu wyciąganie adresów URL. W sierpniu i wrześniu 2021 r. dodaliśmy blokowanie protokołów i aplikacji rozpoznawanych przez nDPI: administrator wybiera je w panelu dla firmy albo grupy, backend udostępnia ustawienia telefonom, a Android blokuje pasujący ruch.