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 ujednolicił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 pozostał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 adres IP, zachowanie przepływu i niewiele więcej.

Na urządzeniu sytuacja wygląda inaczej, bo system operacyjny wie, która aplikacja otworzyła każde połączenie, zanim jakikolwiek bajt zostanie zaszyfrowany. 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 jego działania widać systemowe powiadomienie. We własnym buildzie Androida inspekcję można zamiast tego 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żytkownicy odróżniali 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, Encrypted Client Hello i DNS over HTTPS 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 Cyber inspekcja pakietów działała wewnątrz własnego systemu Android. 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.