ARP-спуфінг та отруєння кешу: захист від MitM-атак у локальній мережі

Ви підключаєте ноутбук до спільної мережі Wi-Fi в аеропорту або коворкінгу. Уже за кілька мілісекунд після встановлення радіозв'язку сторонній пристрій у тій самій підмережі розпочинає безперервну розсилку сфальсифікованих кадрів протоколу визначення адрес (ARP). Операційна система не показує жодних попереджень безпеки, індикатор мережі сигналізує про нормальний стан, проте системна таблиця зіставлення апаратних MAC-адрес виявляється непомітно перезаписаною. Атакувальний вузол перетворюється на невидимого посередника Man-in-the-Middle (MitM) між вашим пристроєм і маршрутизатором шлюзу.

Ця поширена мережева загроза відома як ARP-спуфінг (ARP Spoofing) або отруєння кешу ARP (ARP Cache Poisoning). Стандартизований у листопаді 1982 року Девідом К. Пламмером у специфікації IETF RFC 826, протокол ARP створювався для локальних мереж епохи абсолютної взаємної довіри. У ньому відсутні вбудована автентифікація відправника, криптографічні підписи та перевірка узгодженості між парами запитів і відповідей.

Як наслідок, будь-який комп'ютер у сегменті Ethernet або Wi-Fi може оголосити себе власником довільної IP-адреси, утворюючи канал перехоплення для збору відкритих даних, примусового зняття шифрування SSL Stripping та маніпулювання незахищеними протоколами.

[Робоча станція жертви]                 [Вузол перехоплення (MitM)]             [Маршрутизатор шлюзу]
  IP: 192.168.1.50                        IP: 192.168.1.105                      IP: 192.168.1.1
  MAC: AA:AA:AA:AA:AA:AA                  MAC: BB:BB:BB:BB:BB:BB                 MAC: CC:CC:CC:CC:CC:CC
         │                                       │                                         │
         │ <── Сфальсифікована відповідь ARP ────┤                                         │
         │     "192.168.1.1 має MAC BB:BB:BB"    │                                         │
         │                                       ├──── Сфальсифікована відповідь ARP ────> │
         │                                       │     "192.168.1.50 має MAC BB:BB:BB"
         ▼                                       ▼                                         ▼
   [Отруєний кеш ARP]                      [Міст перехоплення трафіку]               [Отруєний кеш ARP]
   192.168.1.1 -> BB:BB:BB:BB:BB:BB        Аналіз та пересилання пакетів             192.168.1.50 -> BB:BB:BB:BB:BB:BB

Конструктивна вада: безстатусний механізм RFC 826

Для розуміння принципу атаки слід розглянути взаємодію між мережевим рівнем Layer 3 (протокол IPv4) та канальним рівнем Layer 2 (кадри Ethernet 802.3).

Коли пристрій готується надіслати IP-пакет за межі локальної підмережі, дані інкапсулюються в кадр Ethernet. Заголовок кадра вимагає фізичної MAC-адреси локального шлюзу. Якщо цей запис ще не занесено до кешу ядра, операційна система транслює широкомовний запит ARP Request:

"Who has 192.168.1.1? Tell 192.168.1.50" (Broadcast: FF:FF:FF:FF:FF:FF)

Справжній шлюз повертає адресну відповідь ARP Reply:

"192.168.1.1 is at CC:CC:CC:CC:CC:CC" (Unicast: AA:AA:AA:AA:AA:AA)

Вразливість криється в логіці обробки відповідей мережевим стеком:

Прийом без перевірки стану (Stateless Acceptance): Операційні системи оновлюють кеш ARP відразу після надходження відповіді, навіть якщо комп'ютер не надсилав запиту. Такі пакети мають назву Gratuitous ARP.
Перезапис новими даними: У разі отримання суперечливих відповідей пакет, що надійшов останнім, замінює чинний запис у пам'яті.
Відсутність валідації відправника: Мережевий протокол не має інструментів перевірки повноважень вузла розпоряджатися адресою 192.168.1.1.

Транслюючи фальшиві відповіді з інтервалом в 1–2 секунди жертві та маршрутизатору, зловмисник фіксує перенаправлення трафіку. Усі пакети, спрямовані до Інтернету, спершу надходять на мережевий інтерфейс зловмисника, а потім ретранслюються шлюзу.

+-----------------------------+-------------------------------+---------------------------------+
| Рівень моделі OSI           | Протокольний компонент        | Стан безпеки в локальній мережі |
+-----------------------------+-------------------------------+---------------------------------+
| Layer 2 (Канальний)         | ARP RFC 826 / Ethernet 802.3  | Без автентифікації, довіра      |
| Layer 3 (Мережевий)         | IPv4 / ICMP                   | Вразливий до зміни маршруту     |
| Layer 4 (Транспортний)      | TCP / UDP (Порти 53, 80, 443) | Видно порти та таймінги сплесків|
| Layer 7 (Прикладний)        | HTTP, відкриті DNS-запити     | Повний доступ до тексту даних   |
+-----------------------------+-------------------------------+---------------------------------+

Загрози, пов'язані з перехопленням трафіку на канальному рівні

Контроль проміжного вузла відкриває можливості для проведення небезпечних дій:

Перехоплення відкритих даних та метаданих: Запити до звичайних DNS-серверів через порт UDP 53, незахищений трафік HTTP та сервісні повідомлення IoT транслюються відкритим текстом. Навіть для сесій TLS зловмисник бачить IP-адреси серверів, розміри переданих файлів та ім'я сайту в полі SNI без ECH.
Примусове зняття шифрування (SSL Stripping): Застосовуючи утиліти на кшталт sslstrip, зловмисник перехоплює початкові відповіді перенаправлення HTTP 301/302 на HTTPS, змушуючи жертву залишатися на відкритій версії ресурсу.
Підміна відповідей DNS (DNS Spoofing): Перехоплюючи вихідні пакети UDP 53, зловмисник надсилає фальшиві IP-адреси швидше за справжні сервери DNS, перенаправляючи користувача на шахрайські сайти.
Блокування зв'язку (Blackholing DoS): Зловмисник може навмисно скидати всі перехоплені пакети, відключаючи жертву від зовнішньої мережі без зміни статусу підключення до Wi-Fi.

Архітектурний захист через криптографічний тунель L3 VPN

Апаратні методи комутаторів, такі як Dynamic ARP Inspection (DAI) та статичні прив'язки MAC-адрес, доступні лише в корпоративних мережах. У публічних зонах Wi-Fi користувачі не мають доступу до налаштування комутаторів.

Надійним засобом захисту є повна криптографічна інкапсуляція на мережевому рівні Layer 3 за допомогою VPN.

[Дані програм: Браузер, Пошта, Термінал]
                        │
                        ▼
[Layer 3: Криптографічний рушій WireGuard / RiceGuard]
  ├─ Автентифіковане шифрування: ChaCha20-Poly1305 (256-біт)
  └─ Віртуальний мережевий адаптер: tun0 / wg0
                        │
                        ▼
[Layer 2: Фізичний кадр Ethernet на wlan0]
  ├─ MAC призначення: BB:BB:BB:BB:BB:BB (MAC-адреса зловмисника!)
  └─ Корисне навантаження: Непроникний шифротекст високої ентропії
                        │
                        ▼
[Вузол перехоплення зловмисника]
  ├─ Фіксація кадра: УСПІШНО (Рівень Layer 2)
  ├─ Читання вмісту: НЕМОЖЛИВО (Стійкий шифротекст)
  ├─ Внесення правок: НЕМОЖЛИВО (Мітка Poly1305 спричиняє скидання пакета)
  └─ Зняття захисту SSL Stripping: НЕМОЖЛИВО (Відсутнє відкрите рукостискання)

За умов активного VPN-з'єднання:

Кадри містять виключно шифротекст: Навіть якщо кадр Ethernet через отруєний кеш ARP прямує до мережевої карти зловмисника, всередині знаходяться лише надійні зашифровані блоки.
Контроль цілісності повідомлень: Протоколи WireGuard та RiceGuard використовують алгоритм ChaCha20-Poly1305 зі 128-бітною міткою автентифікації. Будь-яка зміна хоча б одного біта веде до миттєвого видалення пакета на приймальному шлюзі.
Захист системних запитів DNS: Усі звернення до служби імен спрямовуються крізь зашифрований тунель до рекурсивних DNS-серверів VPN-сервісу.
Стійкість до атак SSL Stripping: Початкове узгодження з'єднань здійснюється всередині захищеного каналу, що унеможливлює втручання в HTTP-заголовки на локальному рівні.