АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Фильтрация входящего трафика

Фильтрация входящего трафика (англ. ingress filtering) — это техника в области компьютерных сетей, применяемая для того, чтобы удостовериться, что входящие пакеты данных действительно поступают из тех сетей, откуда утверждают, что они были отправлены. Эта мера широко используется в качестве контрмера против различных атак с подделкой (спуфингом), при которых атакующие внедряют в пакеты ложные IP-адреса. Спуфинг часто используется при атаках типа «отказ в обслуживании» (DoS), и ограничение их последствий является одной из ключевых сфер применения фильтрации входящего трафика[1].

Проблема

Сети получают пакеты от других сетей. Обычно каждый пакет содержит IP-адрес отправителя, что позволяет устройствам принимающей сети узнать его источник, обеспечить возможность ответа и ряд других функций, за исключением случаев, когда используются прокси или подделанные IP-адреса, что не позволяет определить конкретного пользователя в пуле адресов.

IP-адрес отправителя может быть подделан (спуфинг), что соответствует атаке с подделкой. В результате источник отправки пакетов маскируется, например, в случае атаки типа «отказ в обслуживании». Подобные последствия наблюдаются и при использовании прокси, хотя механизм отличается от IP-спуфинга.

Отмечается рост пиковой мощности DDoS-атак свыше 1 Тбит/с, а также активное использование злоумышленниками многовекторных техник[2][3]. Среди актуальных угроз, использующих подмену IP-адресов, выделяются:

  • DNS Flood — массированный поток запросов на авторитетные DNS-серверы жертвы для исчерпания их ресурсов[4];
  • DNS Amplification — отправка небольших запросов открытым DNS-резолверам, которые возвращают ответы значительно большего размера на подменённый IP-адрес жертвы[4];
  • CLDAP Flood — атака типа отражения и усиления, эксплуатирующая открытые конечные точки Active Directory LDAP-over-UDP путём отправки запросов с подменённым IP-адресом[4];
  • краткосрочные точечные атаки — атаки длительностью несколько минут, исходящие из распределённых пулов IP-адресов и нацеленные на конкретные эндпоинты веб-сайтов или API[5].

Возможные решения

Одно из решений связано с внедрением на промежуточных интернет-шлюзах (то есть серверах, соединяющих разнородные сети на пути следования пакета) фильтрации или отклонения пакетов, признанных нелегитимными. Такой шлюз может просто игнорировать подозрительный пакет или, где это возможно, отправить отправителю уведомление, что пакет отклонён. Системы предотвращения вторжений на конечных устройствах (HIPS) — пример инженерных решений, помогающих выявлять, предотвращать и/или сдерживать нежелательные, подозрительные или вредоносные события и вторжения.

Маршрутизатор с фильтрацией входящего трафика проверяет поле источника IP в каждом принимаемом пакете. Если пакет не содержит IP-адреса из диапазона сетевого интерфейса, через который он получен, пакет будет отброшен. Это невозможно в случае, если конечный хост является мультихомингом (имеет несколько подключений) и пропускает через себя транзитный трафик.

В контексте фильтрации входящего трафика пакеты, поступающие в сеть, отбрасываются, если отправляющая сеть не должна отправлять пакеты с данным исходным IP-адресом. Если конечный хост — это граничная сеть или станция, маршрутизатор должен отфильтровывать пакеты, в которых в качестве источника указывается частный адрес (RFC 1918), bogon-адреса или адреса, не совпадающие с сетью интерфейса[6].

Для высокопроизводительной фильтрации входящего трафика на интернет-шлюзах применяются технологии eBPF и XDP (eXpress Data Path). Обработка пакетов с помощью XDP происходит на самом низком уровне сетевого стека, что позволяет отбрасывать вредоносный трафик с минимальными задержками и достигать пропускной способности до 40 миллионов пакетов в секунду на одно ядро процессора[7].

В сетях IPv6 специфика предотвращения IP-спуфинга связана с использованием механизмов автоконфигурации и протокола Neighbor Discovery (NDP). Для защиты от подмены адресов и маршрутизаторов применяются такие методы, как ND Snooping, который отслеживает ND-сообщения и отбрасывает недействительные пакеты, а также технология SAVI (Source Address Validation Improvements), создающая единую таблицу привязок адресов и портов для проверки подлинности источника[8].

Сложности фильтрации

Внедрение протокола QUIC и технологии Encrypted Client Hello (ECH) существенно усложняет сетевую фильтрацию входящего трафика, лишая традиционные средства защиты возможности анализировать метаданные соединений. QUIC работает поверх UDP и интегрирует шифрование TLS 1.3 непосредственно в транспортный уровень, скрывая большинство заголовков пакетов. Это делает невозможным отслеживание сессий по TCP-флагам и нарушает работу архитектур фильтрации, построенных на базе TCP-прокси. Технология ECH скрывает расширение Server Name Indication (SNI), шифруя имя конечного хоста на этапе первичного рукопожатия. В результате пассивные сетевые устройства видят лишь IP-адрес провайдера контента (CDN), что делает неэффективными правила межсетевых экранов, основанные на SNI. Для выявления трафика, скрытого за VPN-сервисами и публичными прокси, применяются современные многоуровневые методы:

  • Глубокий анализ пакетов (DPI) и TCP/IP Fingerprinting: анализ параметров сетевого соединения (например, TTL и размера начального окна) для выявления несоответствий между реальной операционной системой и заявленным User-Agent.
  • Browser Fingerprinting: сбор уникальных аппаратных характеристик устройства и проверка скрытых запросов WebRTC для обнаружения реального IP-адреса, отличного от адреса HTTP-запроса.
  • Поведенческий анализ: отслеживание действий пользователя и параметров соединения в реальном времени (включая особенности согласования протоколов HTTP/2 и HTTP/3) для выявления ботов и резидентных прокси.
  • Интеграция с Threat Intelligence: использование глобальных систем обмена данными об угрозах, OSINT-фидов и honeypot-ловушек для непрерывного обновления баз данных коммерческих VPN, узлов Tor и скомпрометированных адресов.

Сетевые аспекты

Фильтрация входящего трафика на уровне сети — это техника фильтрации пакетов, применяемая многими интернет-провайдерами для предотвращения подделки IP-адресов в интернет-трафике, что в свою очередь способствует борьбе с различными проявлениями сетевых злоупотреблений, обеспечивая трассируемость интернет-пакетов к их источнику.

Фильтрация входящего сетевого трафика существенно облегчает отслеживание источников атак типа «отказ в обслуживании», чтобы устранить угрозу[9].

Сетевые фильтры — это своеобразная «политика добрососедства», основанная на кооперации между интернет-провайдерами во имя общей безопасности.

Наилучшие текущие практики (BCP — Best Current Practices) по организации фильтрации входящего трафика на сети зафиксированы Инженерным советом Интернета (IETF) в документах BCP 38 и BCP 84, определённых в RFC 2827 и RFC 3704 соответственно[10][11]. Актуальным дополнением к базовым практикам валидации адресов источника является стандарт RFC 8704, внедряющий метод Enhanced Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF) для более гибкой проверки обратного пути и значительного снижения ложных срабатываний[12].

Документ BCP 84 рекомендует, чтобы вышестоящий провайдер IP-соединения фильтровал пакеты, поступающие в его сеть от клиентских/подключённых сетей, и отбрасывал пакеты с адресами-источниками, не относящимися к этим клиентам.

Политика может реализовываться множеством способов; один из наиболее распространённых механизмов — включение обратной маршрутизации на интерфейсах к клиентам, что позволяет реализовать данную политику на основе фильтрации объявлений маршрутов клиентов.

Традиционные методы фильтрации неэффективны против масштабных DDoS-атак мощностью более 2 Тбит/с. Для успешного отражения подобных угроз требуется использование специализированных глобальных сетей очистки трафика[13].

Внедрение

По данным одного доклада за 2012 год, вопреки расхожему мнению о низком уровне внедрения BCP 38, фильтрацию антиспуфинговых пакетов уже применяли порядка 80 % участников сети Интернет (по различным оценкам)[14].

По мнению отдельных специалистов в области компьютерной безопасности, требуется принятие закона, обязывающего 100 % всех провайдеров реализовать фильтрацию входящего трафика сети по стандарту IETF BCP 38. В США, по замыслу авторов, надзор за исполнением такого закона могла бы осуществлять FCC[9].

В российских системах АСБИ (ТСПУ) для глубокого анализа трафика применяются технологии DPI и планируется внедрение систем на основе машинного обучения. К концу 2026 года планируется охватить 100 % трафика российского сегмента интернета с последующим увеличением пропускной способности[15].[16].

В микросервисных архитектурах

В средах Kubernetes эволюция фильтрации входящего трафика связана с переходом на новые стандарты. В марте 2026 года была официально прекращена поддержка Ingress NGINX: 24 марта репозиторий проекта был заархивирован, что означало полное прекращение выпуска обновлений и патчей безопасности[17][18]. На смену Ingress пришёл стандарт Gateway API. Он обеспечивает нативную поддержку протоколов уровней L4 и L7 (включая HTTP/HTTPS, TCP, UDP, TLS и gRPC)[19]. Новый стандарт предлагает расширенную маршрутизацию по произвольным заголовкам, параметрам запроса и HTTP-методам, а также встроенные функции управления трафиком, такие как разделение, зеркалирование и модификация запросов[20]. Gateway API поддерживается в основных управляемых облачных сервисах. В Google Kubernetes Engine (GKE) реализована нативная поддержка со встроенным контроллером. В AWS Elastic Kubernetes Service (EKS) и Azure Kubernetes Service (AKS) работа со стандартом обеспечивается через AWS Load Balancer Controller и Application Gateway for Containers соответственно, что требует установки дополнительных компонентов[21][22].

Защита систем искусственного интеллекта

В современной практике защиты систем искусственного интеллекта принципы безопасности входящего трафика применяются на уровне приложений (L7). Это необходимо для защиты больших языковых моделей (LLM) от специфических угроз, таких как промпт-инъекции, которые обходят традиционные средства контроля на сетевом и транспортном уровнях[23].

Основные компоненты архитектуры защиты включают:

  • AI-шлюзы (AI Gateways), выступающие в роли единого слоя контроля политик[24];[25]
  • валидацию и санитизацию (очистку) пользовательского ввода для блокировки известных атак[24];[25]
  • ограничение частоты запросов (Rate Limiting) для предотвращения злоупотреблений и контроля затрат[24];[25]
  • проверку политик доступа перед выполнением запроса[24].[25]

Примечания

  1. ↑ Zhauniarovich, Yury. Sorting the Garbage: Filtering Out DRDoS Amplification Traffic in ISP Networks // 2019 IEEE Conference on Network Softwarization (NetSoft) : [англ.] / Yury Zhauniarovich, Priyanka Dodia. — IEEE, июнь 2019. — P. 142–150. — ISBN 978-1-5386-9376-6. — doi:10.1109/netsoft.2019.8806653.
  2. ↑ Cloudflare H1 2026 DDoS Trends Report. Help Net Security (13 августа 2026). Дата обращения: 26 августа 2026.
  3. ↑ Число гипермасштабных DDoS-атак выросло более чем в шесть раз за квартал. Security Media. Дата обращения: 26 августа 2026.
  4. ↑ 1 2 3 DDoS Threat Report H1 2026. Cloudflare Blog. Дата обращения: 26 августа 2026.
  5. ↑ Best Practices to Prevent DDoS Attacks. Indusface Blog. Дата обращения: 26 августа 2026.
  6. ↑ Роберт Гезелтер (1995). Security on the Internet. Глава 23 в Hutt, Bosworth, and Hoytt (1995) «Computer Security Handbook, Third Edition», Wiley, раздел 23.6(b), стр. 23-12 и далее.
  7. ↑ XDP и eBPF для обработки пакетов в Linux. FDCServers. Дата обращения: 26 августа 2026.
  8. ↑ 11-ND Snooping Configuration. NAG Wiki. Дата обращения: 26 августа 2026.
  9. ↑ 1 2 David A. Wheeler. What laws should be created to improve computer security? (англ.). Дата обращения: 26 августа 2026.
  10. ↑ P. Ferguson, D. Senie. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing (англ.). IETF (май 2000). Дата обращения: 26 августа 2026.
  11. ↑ F. Baker, P. Savola. Ingress Filtering for Multihomed Networks (англ.). IETF (март 2004). Дата обращения: 26 августа 2026.
  12. ↑ RFC 8704: Enhanced Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF). IETF. Дата обращения: 26 августа 2026.
  13. ↑ Ingress Filtering: Whitepaper. Qrator Labs Blog. Дата обращения: 26 августа 2026.
  14. ↑ Barry Greene. Everyone should be deploying BCP 38! Wait, they are … (англ.). senki.org (11 июня 2012). Дата обращения: 26 августа 2026. Архивировано 8 апреля 2014 года.
  15. ↑ Внедрение DPI и машинного обучения в ТСПУ. Коммерсантъ. Дата обращения: 26 августа 2026.
  16. ↑ Планы по охвату 100% трафика ТСПУ. Коммерсантъ. Дата обращения: 26 августа 2026.
  17. ↑ Ingress NGINX End-of-Life 2026: Migration and Support. HeroDevs Blog. Дата обращения: 26 августа 2026.
  18. ↑ Ingress NGINX EOL & CVE-2026-4342. Tech Insider. Дата обращения: 26 августа 2026.
  19. ↑ Is It Time to Migrate? A Practical Look at Kubernetes Ingress vs. Gateway API. Tigera Blog. Дата обращения: 26 августа 2026.
  20. ↑ Migrating from Ingress. Kubernetes Gateway API Documentation. Дата обращения: 26 августа 2026.
  21. ↑ Kubernetes Gateway API Tutorial 2026. Tech Insider. Дата обращения: 26 августа 2026.
  22. ↑ EKS vs AKS vs GKE 2026. Luca Berton Blog. Дата обращения: 26 августа 2026.
  23. ↑ Ingress Security for AI Workloads in Kubernetes: Protecting AI Endpoints with WAF. Tigera. Дата обращения: 26 августа 2026.
  24. ↑ 1 2 3 4 Mitigating Indirect Prompt Injection Attacks on LLMs. Solo.io. Дата обращения: 26 августа 2026.
  25. ↑ 1 2 3 4 DMZ Architecture for Secure AI Deployment. Swfte. Дата обращения: 26 августа 2026.

Литература

  • Zhauniarovich, Yury. Sorting the Garbage: Filtering Out DRDoS Amplification Traffic in ISP Networks // 2019 IEEE Conference on Network Softwarization (NetSoft) : [англ.] / Yury Zhauniarovich, Priyanka Dodia. — IEEE, июнь 2019. — P. 142–150. — ISBN 978-1-5386-9376-6. — doi:10.1109/netsoft.2019.8806653.
  • Роберт Гезелтер (1995). Security on the Internet. Глава 23 в Hutt, Bosworth, and Hoytt (1995) «Computer Security Handbook, Third Edition», Wiley, раздел 23.6(b), стр. 23-12 и далее.

Ссылки

Категории