Изображение


Главы


1. Введение: зачем администратору знать, кто использует VPN

2. Правовая основа: когда мониторинг законен, а когда — нет

3. Как VPN оставляет следы в корпоративной сети

4. Метод 1 — DHCP-логи: связать IP с устройством и временем

5. Метод 2 — MAC-адреса: идентифицировать устройство в сегменте

6. Метод 3 — DNS-логи: обнаружить обращения к VPN-инфраструктуре

7. Метод 4 — NetFlow / IPFIX: анализ трафика без DPI

8. Метод 5 — Firewall и прокси-логи: порты, протоколы, паттерны

9. Метод 6 — Active Directory и RADIUS-логи: кто и когда аутентифицировался

10. Метод 7 — Обнаружение по сигнатурам протоколов VPN

11. Корреляция данных: связать IP → MAC → пользователя → время

12. Инструменты: Zeek, Suricata, Elasticsearch, Graylog для анализа

13. Практический кейс: восстановить хронологию инцидента по логам

14. FAQ: 12 горячих вопросов о детектировании VPN в корпоративной сети

15. Чек-лист: настроить постоянное обнаружение несанкционированных VPN

16. Заключение и теги




1. Введение: зачем администратору знать, кто использует VPN


В корпоративной сети несанкционированный VPN — это не просто нарушение политики. Это открытый тоннель, трафик через который не видит ни DLP, ни прокси, ни межсетевой экран. Сотрудник, поднявший личный VPN-клиент, фактически создал неконтролируемый выход из корпоративной сети — и вход в неё.

Три основных сценария, в которых администратору нужно это знать:

Обнаружение несанкционированных VPN. Сотрудники используют личные VPN (Outline, WireGuard, Tailscale, коммерческие клиенты) для обхода корпоративных прокси и DLP-систем. Это нарушение политики ИБ и потенциальный канал утечки данных.

Расследование инцидента. После инцидента (утечка данных, подозрительная активность) нужно восстановить: кто был в сети, с какого устройства, в какое время, какие соединения устанавливал.

Проверка соответствия. Аудит для подтверждения того, что только авторизованные VPN-соединения происходят через корпоративную инфраструктуру (например, для соответствия требованиям PCI DSS или ISO 27001).

Источник данныхЧто даётСложность настройкиГлубина истории
DHCP-логиIP → MAC → время арендыНизкаяЗависит от хранения
DNS-логиДоменные запросы от IPНизкаяЗависит от хранения
NetFlow/IPFIXОбъём, порты, направление трафикаСредняяЗависит от хранения
Firewall-логиРазрешённые/запрещённые соединенияНизкаяЗависит от политики
AD/RADIUS-логиЛогин → IP → времяНизкаяПо умолчанию хранятся
Zeek/SuricataСигнатуры протоколов, DPI-лайтВысокаяПотоковый анализ

> *💡 Статья написана для системных администраторов и специалистов по ИБ. Все описанные методы применяются к инфраструктуре, которой вы управляете, на основании соответствующих полномочий.*





Прежде чем приступать к анализу сетевого трафика, важно убедиться в наличии правовой основы. Это не только про юридическую защиту — это про разницу между профессиональным мониторингом и нарушением закона.

Что делает мониторинг законным


Корпоративные устройства и сеть. Работодатель вправе контролировать использование корпоративного оборудования и сети, если это предусмотрено внутренними документами. Ключевые условия:

1
. Сотрудник подписал политику использования корпоративных 
ресурсов, в которой явно указано, что использование
корпоративной сети может мониторироваться

2. Мониторинг направлен на защиту корпоративных интересов,
а не на слежку за личной жизнью

3. Данные мониторинга используются только для служебных целей
и не передаются третьим лицам без оснований


Метаданные vs. содержимое. Анализ метаданных трафика (IP-адреса, порты, объём, время) — менее чувствителен, чем DPI (анализ содержимого пакетов). Мониторинг метаданных без анализа личной переписки — более оправданная практика.

Что требует осторожности


Личные устройства в корпоративной сети (BYOD). Если сотрудник подключается к корпоративному Wi-Fi с личного устройства — сеть ваша, но устройство его. Мониторинг трафика с личных устройств требует явного согласия или чёткого регламента BYOD.

Сохранение содержимого коммуникаций. Перехват и хранение содержимого личных сообщений — 138 УК РФ (нарушение тайны переписки). Мониторинг сетевых соединений (кто куда подключался, сколько трафика) — не то же самое, что чтение переписки.

Минимальные документы для законного мониторинга


text
Обязательно:
✓ Политика использования корпоративных ресурсов и сети
(с подписью сотрудника при найме)
✓ Положение об информационной безопасности
✓ Уведомление о том, что трафик в корпоративной сети
может логироваться (достаточно пункта в политике)

Рекомендуется:
✓ Регламент реагирования на инциденты
✓ Порядок доступа к логам и их хранения
✓ Назначение ответственного за обработку данных мониторинга





3. Как VPN оставляет следы в корпоративной сети


Прежде чем искать следы, нужно понять, какие именно следы оставляет VPN.

Следы на сетевом уровне


Характерные порты и протоколы. Большинство VPN-решений используют известные порты и протоколы:

openvpn
:     UDP 1194 (по умолчанию), также TCP 443
WireGuard: UDP 51820 (по умолчанию), но настраивается
IPsec/IKEv2: UDP 500, UDP 4500
PPTP: TCP 1723 + GRE (протокол 47)
L2TP: UDP 1701 + IPsec
SSTP: TCP 443
Shadowsocks: TCP/UDP 8388 (по умолчанию, настраивается)
Outline: TCP/UDP случайный высокий порт

Коммерческие VPN:
NordVPN: UDP 1194, TCP 443, UDP 51820 (WireGuard)
ExpressVPN: UDP 1194, TCP 443
ProtonVPN: UDP 1194, TCP 443, UDP 51820


Характерные паттерны трафика. VPN-трафик отличается от обычного:
- Высокий и стабильный объём трафика к одному IP-адресу
- Трафик зашифрован полностью (нет cleartext-заголовков HTTP)
- Постоянное соединение на одном порту длительное время
- Высокая энтропия пакетов (зашифрованные данные выглядят как случайные)

DNS-следы. Перед установкой VPN-соединения устройство, как правило, резолвирует DNS-имя VPN-сервера. Даже если трафик зашифрован — DNS-запрос к `us-east.nordvpn.com` виден в DNS-логах, если сотрудник использует корпоративный DNS-резолвер.

Следы на уровне устройства (если есть доступ)


windows
:
Event Log → Security → Event ID 4624/4634 (логин/логаут)
Event Log → System → NetworkProfile изменения
Реестр: HKLM\SYSTEM\CurrentControlSet\Services\...VPN...

Linux/Mac:
/var/log/syslog — записи о сетевых интерфейсах
ip link show — tun0 или wg0 интерфейсы при активном VPN
netstat -tulnp — активные соединения





4. Метод 1 — DHCP-логи: связать IP с устройством и временем


DHCP-логи — первый инструмент для идентификации устройства по IP-адресу. DHCP-сервер фиксирует каждое выданное и продлённое соединение с временной меткой.

Что хранится в DHCP-логах


text
Типичная запись DHCP-лога (Windows DHCP Server):
ID,Date,Time,Description,IP Address,Host Name,MAC Address
10,01/15/2026,09:23:41,Assign,10.10.5.142,DESKTOP-ABC123,00:1A:2B:3C:4D:5E
11,01/15/2026,21:45:12,Renew,10.10.5.142,DESKTOP-ABC123,00:1A:2B:3C:4D:5E
12,01/16/2026,09:01:05,Release,10.10.5.142,DESKTOP-ABC123,00:1A:2B:3C:4D:5E


Из DHCP-лога можно извлечь: какой IP-адрес был выдан, когда (timestamp), какому устройству (hostname и MAC-адрес), как долго использовался (от Assign до Release/следующего Assign).

Где хранятся DHCP-логи


Windows DHCP Server:
text
По умолчанию: C:\Windows\System32\dhcp\
Файлы: DhcpSrvLog-Mon.log, DhcpSrvLog-Tue.log, ...
Хранение: 7 дней по умолчанию (настраивается через реестр)

Увеличить срок хранения:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters
DhcpLogFilesMaxSize (DWORD) — размер лог-файлов


Linux (isc-dhcp-server):
bash
<h2 id="logi-v-syslog">Логи в syslog</h2>
grep -i dhcp /var/log/syslog

<h2 id="ili-v-journald">Или в journald</h2>
journalctl -u isc-dhcp-server

<h2 id="primer-zapisi">Пример записи:</h2>
<h2 id="jan-15-09-23-41-dhcpd-dhcpack-on-10-10-5-142">Jan 15 09:23:41 dhcpd: DHCPACK on 10.10.5.142</h2>
<h2 id="to-00-1a-2b-3c-4d-5e-desktop-abc123-via-eth0">to 00:1a:2b:3c:4d:5e (DESKTOP-ABC123) via eth0</h2>


MikroTik (RouterOS):
text
/ip dhcp-server lease print
<h2 id="pokazyvaet-aktivnye-arendy-s-mac-i-hostname">Показывает активные аренды с MAC и hostname</h2>

/log print where topics~"dhcp"
<h2 id="istoricheskie-dhcp-sobytiya-iz-loga">Исторические DHCP-события из лога</h2>


Сценарий расследования: кто был на IP 10.10.5.142 в 14:30 15 января?


bash
<h2 id="poisk-po-vremeni-v-windows-dhcp-loge">Поиск по времени в Windows DHCP-логе</h2>
grep "01/15/2026" DhcpSrvLog-Wed.log | grep "10.10.5.142"

<h2 id="rezultat-pokazhet">Результат покажет:</h2>
<h2 id="mac-adres-ustroystva-kotoromu-vydan-etot-ip">- MAC-адрес устройства, которому выдан этот IP</h2>
<h2 id="hostname-ustroystva">- hostname устройства</h2>
<h2 id="vremya-nachala-i-okonchaniya-arendy">- время начала и окончания аренды</h2>

<h2 id="ubezhdaemsya-chto-arenda-ohvatyvala-14-30">Убеждаемся, что аренда охватывала 14:30:</h2>
<h2 id="assign-09-23-release-21-45-arenda-aktivna-v-14-30">Assign: 09:23 → Release: 21:45 → аренда активна в 14:30</h2>
<h2 id="mac-00-1a-2b-3c-4d-5e-desktop-abc123">MAC: 00:1A:2B:3C:4D:5E → DESKTOP-ABC123</h2>


Важные ограничения DHCP-логов


text
⚠️ Статические IP-адреса: устройства с ручно настроенным IP
не оставляют записей в DHCP-логах

⚠️ MAC-спуфинг: MAC-адрес можно подделать программно.
DHCP-запись будет содержать поддельный MAC.

⚠️ Срок хранения: по умолчанию Windows DHCP хранит 7 дней.
Для расследования инцидентов нужно централизованное
хранение с большим сроком.





5. Метод 2 — MAC-адреса: идентифицировать устройство в сегменте


MAC-адрес — идентификатор сетевой карты на уровне L2. В отличие от IP (который может меняться при каждой DHCP-аренде), MAC-адрес привязан к конкретному физическому адаптеру.

Источники MAC-адресов в корпоративной сети


ARP-таблицы маршрутизаторов и коммутаторов. ARP-таблица — это соответствие IP → MAC, которое маршрутизатор поддерживает для отправки пакетов. Запросить её можно в любой момент.

bash
<h2 id="na-marshrutizatore-linux-servere">На маршрутизаторе Linux / сервере</h2>
arp -a
<h2 id="ili">Или</h2>
ip neigh show

<h2 id="vyvod">Вывод:</h2>
<h2 id="10-10-5-142-dev-eth0-lladdr-00-1a-2b-3c-4d-5e-reachable">10.10.5.142 dev eth0 lladdr 00:1a:2b:3c:4d:5e REACHABLE</h2>
<h2 id="10-10-5-100-dev-eth0-lladdr-00-50-56-ab-cd-ef-stale">10.10.5.100 dev eth0 lladdr 00:50:56:ab:cd:ef STALE</h2>

<h2 id="mikrotik">MikroTik</h2>
/ip arp print

<h2 id="cisco-ios">Cisco IOS</h2>
show arp
<h2 id="ili-dlya-konkretnogo-ip">или для конкретного IP:</h2>
show arp 10.10.5.142


MAC-таблицы управляемых коммутаторов. Управляемый коммутатор хранит таблицу MAC → порт: с какого физического порта пришёл MAC-адрес. Это позволяет определить, к какому порту подключено устройство.

bash
<h2 id="cisco-ios">Cisco IOS</h2>
show mac address-table
<h2 id="ili-dlya-konkretnogo-mac">или для конкретного MAC:</h2>
show mac address-table address 001a.2b3c.4d5e

<h2 id="primer-vyvoda">Пример вывода:</h2>
<h2 id="vlan-mac-address-type-ports">VLAN MAC Address Type Ports</h2>
<h2 id="">---- --------- ------ -----</h2>
<h2 id="10-001a-2b3c-4d5e-dynamic-gi0-5">10 001a.2b3c.4d5e DYNAMIC Gi0/5</h2>


Зная порт (Gi0/5) — вы знаете физическое место подключения устройства в офисе (если документирована схема портов).

Определение производителя по MAC-адресу (OUI)


Первые три октета MAC-адреса — OUI (Organizationally Unique Identifier), регистрируемый производителем. Анализ OUI помогает быстро идентифицировать тип устройства.

bash
<h2 id="onlayn-servis-dlya-oui-lookup">Онлайн-сервис для OUI-lookup</h2>
<h2 id="macvendors-com-wireshark-org-tools-oui-lookup">macvendors.com, wireshark.org/tools/oui-lookup</h2>

<h2 id="lokalno-s-pomoschyu-wireshark-ili-nmap">Локально с помощью Wireshark или nmap:</h2>
nmap --script=address-info 10.10.5.0/24

<h2 id="primer">Пример:</h2>
<h2 id="00-1a-2b-eto-oui-kompanii-dell-inc">00:1A:2B — это OUI компании Dell Inc.</h2>
<h2 id="00-50-56-vmware-virtualnaya-mashina">00:50:56 — VMware (виртуальная машина)</h2>
<h2 id="ac-37-43-huawei-technologies">AC:37:43 — Huawei Technologies</h2>

<h2 id="podozritelnye-oui-pri-rassledovanii">Подозрительные OUI при расследовании:</h2>
<h2 id="00-50-56-vmware-ili-08-00-27-virtualbox-v-seti">00:50:56 (VMware) или 08:00:27 (VirtualBox) в сети,</h2>
<h2 id="gde-net-avtorizovannyh-virtualnyh-mashin-povod-dlya-proverki">где нет авторизованных виртуальных машин — повод для проверки</h2>


MAC-адреса во времени: DHCP-аренды как история


Сопоставляя DHCP-логи и текущие ARP/MAC-таблицы, можно построить историческую картину:

text
Сессия 1: 09:23 — MAC 00:1a:2b:3c:4d:5e получил IP 10.10.5.142
12:47 — этот MAC/IP фигурирует в netflow к 45.33.32.156:1194
(порт 1194 = OpenVPN)

Вывод: устройство с MAC 00:1a:2b:3c:4d:5e использовало OpenVPN
с IP 10.10.5.142 около 12:47.

Следующий шаг: по DHCP-логу определить hostname устройства,
по hostname — найти в AD-записях пользователя.


Ограничение: MAC-спуфинг


bash
<h2 id="proverit-mac-adres-windows-vruchnuyu-esli-fizicheskiy-dostup">Проверить MAC-адрес Windows вручную (если физический доступ):</h2>
getmac /v /fo list

<h2 id="ili-v-reestre">Или в реестре:</h2>
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\
{4d36e972-...}\0001\NetworkAddress

<h2 id="esli-networkaddress-soderzhit-znachenie-mac-izmenyon-vruchnuyu">Если NetworkAddress содержит значение — MAC изменён вручную</h2>
<h2 id="esli-pusto-ispolzuetsya-zavodskoy-mac">Если пусто — используется заводской MAC</h2>


Изменить MAC-адрес в Windows/Linux можно за минуту. Поэтому MAC — хороший индикатор для большинства случаев, но не криминалистически надёжный идентификатор при целенаправленном сокрытии следов.




6. Метод 3 — DNS-логи: обнаружить обращения к VPN-инфраструктуре


DNS-логи — часто недооценённый, но очень информативный источник. Перед установкой VPN-соединения клиент обычно резолвирует DNS-имя сервера. Если корпоративный DNS используется устройством — запрос виден.

Настройка логирования на DNS-серверах


Windows DNS Server:
powershell
<h2 id="vklyuchit-polnoe-logirovanie-dns-zaprosov">Включить полное логирование DNS-запросов</h2>
Set-DnsServerDiagnostics -All $true

<h2 id="ili-izbiratelno-tolko-zaprosy">Или избирательно — только запросы:</h2>
Set-DnsServerDiagnostics -Queries $true -LogFilePath "C:\dns-debug.log"

<h2 id="proverit-tekuschee-sostoyanie">Проверить текущее состояние:</h2>
Get-DnsServerDiagnostics


BIND (Linux):
bash
<h2 id="etc-named-conf-dobavit-v-sektsiyu-options">/etc/named.conf — добавить в секцию options:</h2>
logging {
channel query_log {
file "/var/log/named/queries.log" versions 10 size 50m;
print-time yes;
severity info;
};
category queries { query_log; };
};

<h2 id="perezapustit-bind">Перезапустить BIND:</h2>
systemctl restart named

<h2 id="prosmotr-v-realnom-vremeni">Просмотр в реальном времени:</h2>
tail -f /var/log/named/queries.log


Pi-hole / AdGuard Home (если используется как DNS-резолвер):
Имеют встроенный журнал запросов с IP-адресом клиента и запрошенным доменом. Данные доступны через веб-интерфейс или API.

Какие DNS-запросы выдают VPN


text
Запросы к VPN-серверам коммерческих провайдеров:
*.nordvpn.com
*.expressvpn.com
*.protonvpn.com
*.mullvad.net
*.privateinternetaccess.com
*.surfshark.com

Запросы к Self-hosted решениям:
(нет характерных паттернов, зависит от конфигурации)

Запросы к Cloudflare WARP:
engage.cloudflareclient.com
*.cloudflare-gateway.com

Tailscale:
login.tailscale.com
controlplane.tailscale.com

Wireguard (если через клиент Outline):
Запросы к домену конкретного Outline-сервера


Анализ DNS-логов для поиска VPN-активности


bash
<h2 id="poisk-v-logah-bind-po-izvestnym-vpn-domenam">Поиск в логах BIND по известным VPN-доменам:</h2>
grep -E "(nordvpn|expressvpn|protonvpn|mullvad|privateinternetaccess)" \
/var/log/named/queries.log | awk '{print $1, $2, $NF}'

<h2 id="primer-vyvoda">Пример вывода:</h2>
<h2 id="15-jan-2026-14-32-11-423-10-10-5-142-us1234-nordvpn-com">15-Jan-2026 14:32:11.423 10.10.5.142 us1234.nordvpn.com</h2>
<h2 id="15-jan-2026-14-32-12-001-10-10-5-142-us1234-nordvpn-com">15-Jan-2026 14:32:12.001 10.10.5.142 us1234.nordvpn.com</h2>
<h2 id="ustroystvo-10-10-5-142-rezolvilo-nordvpn-v-14-32">Устройство 10.10.5.142 резолвило NordVPN в 14:32</h2>

<h2 id="poisk-neobychnyh-dns-zaprosov-vysokochastotnye-k-odnomu-domenu">Поиск необычных DNS-запросов (высокочастотные к одному домену):</h2>
awk '{print $NF}' /var/log/named/queries.log | sort | uniq -c | sort -rn | head -20


DNS over HTTPS (DoH): ограничение метода


Если устройство использует DNS over HTTPS (настроен в браузере или ОС) — DNS-запросы уходят зашифрованно напрямую к DoH-провайдеру (Cloudflare 1.1.1.1, Google 8.8.8.8), минуя корпоративный резолвер.

bash
<h2 id="obnaruzhit-doh-trafik-cherez-netflow">Обнаружить DoH-трафик через NetFlow:</h2>
<h2 id="doh-vyglyadit-kak-https-trafik-k-konkretnym-ip">DoH выглядит как HTTPS-трафик к конкретным IP:</h2>
<h2 id="cloudflare-1-1-1-1-443-1-0-0-1-443">Cloudflare: 1.1.1.1:443, 1.0.0.1:443</h2>
<h2 id="google-8-8-8-8-443-8-8-4-4-443">Google: 8.8.8.8:443, 8.8.4.4:443</h2>
<h2 id="quad9-9-9-9-9-443">Quad9: 9.9.9.9:443</h2>

<h2 id="netipichno-postoyannye-https-soedineniya-k-etim-ip-s-nizkim-obyomom">Нетипично: постоянные HTTPS-соединения к этим IP с низким объёмом,</h2>
<h2 id="harakternym-dlya-dns-zaprosov-ne-veb-trafik">характерным для DNS-запросов (не веб-трафик)</h2>

<h2 id="reshenie-blokirovat-doh-na-urovne-firewall-dlya-korporativnyh-ustroystv">Решение: блокировать DoH на уровне firewall для корпоративных устройств</h2>
<h2 id="i-trebovat-ispolzovanie-korporativnogo-dns">и требовать использование корпоративного DNS</h2>





7. Метод 4 — NetFlow / IPFIX: анализ трафика без DPI


NetFlow (Cisco) и IPFIX (стандартизированный аналог) — протоколы экспорта сетевой статистики. Маршрутизатор или коммутатор отправляет агрегированные записи о каждом сетевом потоке: кто с кем, через какой порт, сколько байт и пакетов, в какое время.

NetFlow не захватывает содержимое пакетов — только метаданные. Это отличает его от DPI и делает менее чувствительным с точки зрения приватности.

Включение NetFlow на основных платформах


Cisco IOS:
interface
GigabitEthernet0/0
ip flow ingress
ip flow egress
!
ip flow-export destination 10.10.1.50 9995
ip flow-export version 9
ip flow-cache timeout active 1
ip flow-cache timeout inactive 15


MikroTik RouterOS:
text
/ip traffic-flow
set enabled=yes
/ip traffic-flow target
add dst-address=10.10.1.50 port=9995 version=9


Linux (с помощью softflowd):
bash
apt install softflowd
softflowd -i eth0 -n 10.10.1.50:9995 -v 9


Сбор и анализ NetFlow-данных


nfdump + nfcapd (стандартный стек для Linux):
bash
<h2 id="zapusk-kollektora">Запуск коллектора:</h2>
nfcapd -w -D -l /var/cache/nfdump/ -p 9995

<h2 id="analiz-top-soedineniy-po-obyomu-trafika-s-hosta-10-10-5-142">Анализ: топ соединений по объёму трафика с хоста 10.10.5.142</h2>
nfdump -r /var/cache/nfdump/nfcapd.202601151400 \
'src ip 10.10.5.142' \
-s record/bytes -n 20

<h2 id="poisk-soedineniy-na-vpn-porty">Поиск соединений на VPN-порты:</h2>
nfdump -r /var/cache/nfdump/nfcapd.202601151400 \
'src ip 10.10.5.142 and (dst port 1194 or dst port 51820 or dst port 500)' \
-o "fmt:%ts %sa %da %sp %dp %byt %pkt"


Паттерны VPN-трафика в NetFlow


text
Признаки активного VPN-туннеля в NetFlow:

1. Длинный поток на нестандартный порт к одному внешнему IP
src: 10.10.5.142:54123 → dst: 45.33.32.156:1194
Duration: 3600s, Bytes: 150MB — длинная сессия, большой объём

2. Постоянный UDP-поток на порт 51820 (WireGuard)
UDP-потоки WireGuard имеют характерный размер пакетов (1280–1420 байт)
и высокую регулярность при активном использовании

3. Аномально большой исходящий трафик относительно входящего
(при загрузке данных внутри тоннеля из корпоративной сети)

4. Трафик к известным диапазонам IP VPN-провайдеров
# Диапазоны NordVPN, ExpressVPN и т.д. публично известны
# и могут быть добавлены как индикаторы в SIEM


ntopng: веб-интерфейс для анализа NetFlow


bash
<h2 id="ustanovka-ntopng-besplatnaya-versiya">Установка ntopng (бесплатная версия)</h2>
apt install ntopng

<h2 id="konfiguratsiya-etc-ntopng-ntopng-conf">Конфигурация /etc/ntopng/ntopng.conf:</h2>
-G=/var/run/ntopng.pid
-i=eth0
-w=3000 # веб-порт
-F="nflow;tcp;127.0.0.1;9995" # получать NetFlow

<h2 id="veb-interfeys-http-localhost-3000">Веб-интерфейс: http://localhost:3000</h2>
<h2 id="pozvolyaet-iskat-po-ip-videt-top-hostov-po-trafiku">Позволяет искать по IP, видеть топ хостов по трафику,</h2>
<h2 id="detalizirovat-soedineniya-po-vremeni">детализировать соединения по времени</h2>





8. Метод 5 — Firewall и прокси-логи: порты, протоколы, паттерны


Межсетевой экран — первая линия видимости. Если настроен правильно, он логирует всё, что проходит через него, включая VPN-трафик.

Анализ логов iptables / nftables (Linux-шлюз)


bash
<h2 id="vklyuchit-logirovanie-vseh-prohozhdeniy-vnimanie-vysokiy-obyom">Включить логирование всех прохождений (внимание: высокий объём!)</h2>
iptables -A FORWARD -j LOG --log-prefix "FORWARD: " --log-level 4

<h2 id="luchshe-logirovat-tolko-podozritelnye-porty">Лучше — логировать только подозрительные порты:</h2>
iptables -A FORWARD -p udp --dport 1194 -j LOG --log-prefix "VPN_UDP1194: "
iptables -A FORWARD -p tcp --dport 1194 -j LOG --log-prefix "VPN_TCP1194: "
iptables -A FORWARD -p udp --dport 51820 -j LOG --log-prefix "VPN_WG: "

<h2 id="logi-popadayut-v-var-log-kern-log-ili-var-log-syslog">Логи попадают в /var/log/kern.log или /var/log/syslog</h2>
<h2 id="prosmotr">Просмотр:</h2>
grep "VPN_" /var/log/kern.log | awk '{print $1, $2, $3, $12, $14}' | head -20


Анализ логов pfSense / OPNsense


pfSense хранит firewall-логи в формате, доступном через веб-интерфейс (Status → System Logs → Firewall) и через CLI.

bash
<h2 id="na-pfsense-cherez-ssh">На pfSense через SSH:</h2>
<h2 id="log-v-formate-var-log-filter-log">Лог в формате /var/log/filter.log</h2>
<h2 id="poisk-po-portu-1194-openvpn">Поиск по порту 1194 (OpenVPN):</h2>
grep ":1194" /var/log/filter.log | tail -50

<h2 id="filtr-po-istochniku">Фильтр по источнику:</h2>
grep "src_ip=10.10.5.142" /var/log/filter.log | grep -E "dst_port=(1194|51820|500)"


Прокси-логи (Squid, nginx-proxy)


Если весь HTTP/HTTPS трафик идёт через корпоративный прокси — это дополнительный источник. Прокси-лог показывает: какой хост обратился, к каким URL, в какое время.

bash
<h2 id="squid-access-log-poisk-po-ip-adresu-klienta">Squid access.log: поиск по IP-адресу клиента</h2>
grep "10.10.5.142" /var/log/squid/access.log | grep -v "200\|304" | head -30

<h2 id="format-zapisi">Формат записи:</h2>
<h2 id="timestamp-elapsed-client-ip-action-status-bytes-method-url">timestamp elapsed client_ip action/status bytes method url ...</h2>
<h2 id="1705320731-123-10-10-5-142-tcp-miss-200-1024-connect-nordvpn-com-443">1705320731 123 10.10.5.142 TCP_MISS/200 1024 CONNECT nordvpn.com:443 ...</h2>

<h2 id="connect-zaprosy-k-vpn-domenu-pryamoe-svidetelstvo-popytki-podklyucheniya">CONNECT-запросы к VPN-домену — прямое свидетельство попытки подключения</h2>
<h2 id="cherez-proksi-klient-zaprosil-tunnel-cherez-proksi-k-vpn-serveru">через прокси (клиент запросил туннель через прокси к VPN-серверу)</h2>


FortiGate / Cisco ASA: структурированные логи


fortigate
log формат (syslog):
date=2026-01-15 time=14:32:11 type=traffic subtype=forward
action=accept srcip=10.10.5.142 dstip=45.33.32.156
dstport=1194 proto=17 sentbyte=1524 rcvdbyte=984

<h2 id="filtratsiya-po-protokolu-udp-i-portu-1194-za-period">Фильтрация по протоколу UDP и порту 1194 за период:</h2>
<h2 id="veb-konsol-log-report-traffic-log-forward-traffic">Веб-консоль: Log &amp; Report → Traffic Log → Forward Traffic</h2>
<h2 id="filtr-destination-port-1194-protocol-udp">Фильтр: Destination Port = 1194, Protocol = UDP</h2>






Сетевые логи (DHCP, NetFlow) дают IP и MAC. Чтобы связать их с конкретным пользователем, нужны логи аутентификации: Active Directory или RADIUS.

Active Directory: Event Log аутентификаций


Ключевые Event IDs для идентификации пользователя:

event
ID 4624 — успешный вход в систему
Содержит: имя пользователя, домен, IP-адрес (для сетевых входов),
тип входа (Type 3 = сетевой), время

Event ID 4634 — выход из системы (конец сессии)

Event ID 4625 — неудачный вход
Полезен для выявления перебора паролей перед VPN-подключением

Event ID 4768/4769 — Kerberos TGT / Service Ticket запрос
Содержит IP-адрес клиента — привязывает IP к учётной записи


powershell
<h2 id="powershell-nayti-uspeshnye-vhody-s-ip-10-10-5-142-za-15-yanvarya">PowerShell: найти успешные входы с IP 10.10.5.142 за 15 января</h2>
Get-WinEvent -ComputerName DC01 -FilterHashtable @{
LogName = 'Security'
Id = 4624
StartTime = '2026-01-15 00:00:00'
EndTime = '2026-01-16 00:00:00'
} | Where-Object {
$_.Properties[18].Value -eq '10.10.5.142'
} | Select-Object TimeCreated,
@{N='User';E={$_.Properties[5].Value}},
@{N='IP';E={$_.Properties[18].Value}},
@{N='LogonType';E={$_.Properties[8].Value}}


powershell
<h2 id="eksport-v-csv-dlya-posleduyuschego-analiza">Экспорт в CSV для последующего анализа:</h2>
Get-WinEvent -FilterHashtable @{
LogName = 'Security'; Id = 4624
StartTime = '2026-01-15'; EndTime = '2026-01-16'
} | Select-Object TimeCreated,
@{N='User';E={$_.Properties[5].Value}},
@{N='Domain';E={$_.Properties[6].Value}},
@{N='LogonType';E={$_.Properties[8].Value}},
@{N='WorkstationName';E={$_.Properties[11].Value}},
@{N='SourceIP';E={$_.Properties[18].Value}} |
Export-Csv -Path "C:\logons_jan15.csv" -NoTypeInformation


RADIUS-логи для авторизации в Wi-Fi и VPN


Если корпоративный Wi-Fi или VPN использует 802.1X с RADIUS-аутентификацией — RADIUS-логи содержат прямую связку: пользователь → MAC → IP → время.

bash
<h2 id="freeradius-var-log-freeradius-radius-log">FreeRADIUS: /var/log/freeradius/radius.log</h2>
grep "Auth: Login OK" /var/log/freeradius/radius.log | \
awk '{print $1, $2, $8, $10}' | head -20

<h2 id="primer-zapisi">Пример записи:</h2>
<h2 id="tue-jan-15-14-31-55-2026-auth-login-ok">Tue Jan 15 14:31:55 2026 : Auth: Login OK:</h2>
<h2 id="jsmith-from-client-ap-floor2-port-0">[jsmith] (from client ap-floor2 port 0</h2>
<h2 id="via-tls-tunnel-calling-station-id-00-1a-2b-3c-4d-5e">via TLS tunnel) Calling-Station-Id = 00-1A-2B-3C-4D-5E</h2>

<h2 id="zdes-jsmith-voshyol-cherez-tochku-dostupa-ap-floor2">Здесь: jsmith вошёл через точку доступа ap-floor2,</h2>
<h2 id="s-mac-00-1a-2b-3c-4d-5e-v-14-31">с MAC 00:1A:2B:3C:4D:5E в 14:31</h2>


Корпоративный VPN-сервер (OpenVPN, FortiClient VPN)


Если расследуете использование корпоративного VPN (кто подключался к VPN компании удалённо):

bash
<h2 id="openvpn-server-var-log-openvpn-openvpn-status-log">OpenVPN-сервер: /var/log/openvpn/openvpn-status.log</h2>
<h2 id="aktivnye-klienty-v-realnom-vremeni">Активные клиенты в реальном времени:</h2>
cat /var/log/openvpn/openvpn-status.log

<h2 id="istoricheskiy-log-openvpn">Исторический лог OpenVPN:</h2>
<h2 id="var-log-openvpn-openvpn-log">/var/log/openvpn/openvpn.log</h2>
grep "Peer Connection Initiated" /var/log/openvpn/openvpn.log | \
grep "2026-01-15" | awk '{print $1, $2, $NF}'

<h2 id="primer">Пример:</h2>
<h2 id="2026-01-15-14-31-55-jsmith-203-0-113-45-54321">2026-01-15 14:31:55 jsmith/203.0.113.45:54321</h2>
<h2 id="jsmith-peer-connection-initiated">[jsmith] Peer Connection Initiated</h2>





10. Метод 7 — Обнаружение по сигнатурам протоколов VPN


Продвинутый уровень: анализ не только портов и IP, но и самого трафика для идентификации протокола — даже если VPN использует нестандартный порт.

Zeek (bro): пассивный сетевой анализ


Zeek — платформа для пассивного анализа сетевого трафика. Он записывает не содержимое пакетов, а структурированные события: соединения, DNS-запросы, HTTP-запросы, TLS-рукопожатия.

bash
<h2 id="ustanovka-zeek">Установка Zeek:</h2>
apt install zeek

<h2 id="zapusk-na-setevom-interfeyse">Запуск на сетевом интерфейсе:</h2>
zeek -i eth0 /opt/zeek/share/zeek/base/protocols/

<h2 id="zeek-sozdayot-log-fayly-v-tekuschey-direktorii">Zeek создаёт лог-файлы в текущей директории:</h2>
<h2 id="conn-log-vse-soedineniya-s-metrikami">conn.log — все соединения с метриками</h2>
<h2 id="dns-log-dns-zaprosy">dns.log — DNS-запросы</h2>
<h2 id="ssl-log-tls-soedineniya-sni-imena">ssl.log — TLS-соединения (SNI-имена)</h2>
<h2 id="weird-log-anomalii-protokolov">weird.log — аномалии протоколов</h2>

<h2 id="analiz-conn-log-nayti-dlinnye-soedineniya-na-udp-porty-vpn">Анализ conn.log: найти длинные соединения на UDP-порты VPN</h2>
<h2 id="duration-300-sekund-na-nestandartnyy-port">(duration &gt; 300 секунд на нестандартный порт)</h2>
zeek-cut ts id.orig_h id.resp_h id.resp_p proto duration < conn.log | \
awk '$5 == "udp" && $6 > 300 && ($4 == 1194 || $4 == 51820)' | \
head -20


Suricata: IDS/IPS с VPN-сигнатурами


Suricata работает как IDS и может обнаруживать VPN-трафик по сигнатурам даже на нестандартных портах.

bash
<h2 id="pravilo-suricata-dlya-obnaruzheniya-wireguard-trafika">Правило Suricata для обнаружения WireGuard-трафика:</h2>
<h2 id="etc-suricata-rules-vpn-detection-rules">/etc/suricata/rules/vpn-detection.rules</h2>

<h2 id="wireguard-handshake-initiation-harakternaya-struktura-pervogo-paketa">WireGuard handshake initiation (характерная структура первого пакета)</h2>
alert udp any any -> any any (
msg:"WireGuard Handshake Initiation Detected";
content:"|01 00 00 00|";
offset:0; depth:4;
content:!"|00 00 00 00|";
offset:4; depth:4;
sid:9000001; rev:1;
metadata:affected_product VPN;
)

<h2 id="openvpn-cherez-tls-harakternyy-tls-handshake-na-portu-1194">OpenVPN через TLS (характерный TLS handshake на порту 1194)</h2>
alert tcp any any -> any 1194 (
msg:"OpenVPN TLS Client Hello on TCP/1194";
flow:to_server,established;
content:"|16 03|";
offset:0; depth:2;
sid:9000002; rev:1;
)


Обнаружение через JA3/JA3S отпечатки TLS


Многие VPN-клиенты оставляют характерный TLS fingerprint (JA3-hash) при установке соединения. Zeek автоматически вычисляет JA3-хэши в ssl.log.

bash
<h2 id="prosmotr-ja3-heshey-v-ssl-log-zeek">Просмотр JA3-хэшей в ssl.log Zeek:</h2>
zeek-cut ts id.orig_h id.resp_h ja3 ja3s < ssl.log | head -20

<h2 id="izvestnye-ja3-heshi-vpn-klientov-publikuyutsya-v-threat-intel-fidah">Известные JA3-хэши VPN-клиентов публикуются в threat intel-фидах</h2>
<h2 id="naprimer-ja3er-com-soderzhit-bazu-izvestnyh-ja3-heshey">Например, ja3er.com содержит базу известных JA3-хэшей</h2>

<h2 id="poisk-konkretnogo-hesha-primer-dlya-openvpn-klienta">Поиск конкретного хэша (пример для OpenVPN-клиента):</h2>
grep "51c64c77e60f3980eea90869b68c58a8" ssl.log





11. Корреляция данных: связать IP → MAC → пользователя → время


Каждый метод по отдельности даёт фрагмент. Ценность появляется при корреляции — объединении данных из разных источников для получения полной картины.

Схема корреляции для идентификации пользователя


text
Событие-триггер (из любого источника):
NetFlow: IP 10.10.5.142 → 45.33.32.156:1194 в 14:32



Шаг 1: Кто был на IP 10.10.5.142 в 14:32?
DHCP-лог → MAC: 00:1a:2b:3c:4d:5e, hostname: DESKTOP-ABC123
Аренда активна с 09:23 до 21:45 → в 14:32 — этот хост



Шаг 2: Кто пользователь этого хоста?
AD-лог (Event 4624) → в 09:15 на DESKTOP-ABC123
вошёл пользователь jsmith@company.ru



Шаг 3: Подтверждение через другие источники
DNS-лог → в 14:31 с IP 10.10.5.142 был запрос к us1234.nordvpn.com
Firewall-лог → в 14:32 разрешено UDP 10.10.5.142 → 45.33.32.156:1194



Вывод: пользователь jsmith@company.ru на устройстве DESKTOP-ABC123
использовал NordVPN в 14:32 15 января 2026 года.
Продолжительность сессии: ~3.5 часа (по NetFlow).


Python-скрипт для базовой корреляции


python
#!/usr/bin/env python3
"""
Базовая корреляция DHCP-лога + NetFlow для поиска VPN-активности.
Запускать на машине с доступом к логам.
"""
import re
from datetime import datetime, timedelta

<h2 id="shag-1-zagruzka-dhcp-arend-iz-loga-windows">─── Шаг 1: Загрузка DHCP-аренд из лога Windows ───────────────────────────</h2>
def parse_dhcp_log(filepath):
"""Возвращает {ip: [(mac, hostname, start, end), ...]}"""
leases = {}
pattern = re.compile(
r'(?P<id>\d+),(?P<date>[\d/]+),(?P<time>[\d:]+),'
r'(?P<action>\w+),(?P<ip>[\d.]+),(?P<host>[^,]*),(?P<mac>[0-9A-Fa-f:]+)'
)
current = {} # ip -> (mac, host, start_dt)
with open(filepath) as f:
for line in f:
m = pattern.match(line.strip())
if not m:
continue
ip = m.group('ip')
mac = m.group('mac')
host = m.group('host')
dt = datetime.strptime(
f"{m.group('date')} {m.group('time')}", "%m/%d/%Y %H:%M:%S")
action = m.group('action')

if action in ('Assign', 'Renew'):
current[ip] = (mac, host, dt)
elif action == 'Release' and ip in current:
mac_s, host_s, start = current.pop(ip)
leases.setdefault(ip, []).append((mac_s, host_s, start, dt))
return leases

<h2 id="shag-2-zagruzka-netflow-zapisey-nfdump-csv-vyvod">─── Шаг 2: Загрузка NetFlow-записей (nfdump CSV-вывод) ───────────────────</h2>
def load_netflow_vpn(filepath):
"""
Ожидает CSV: ts,src_ip,dst_ip,dst_port,proto,bytes
(получить через: nfdump -r ... -o csv)
Возвращает список VPN-потоков.
"""
vpn_ports = {1194, 51820, 500, 4500}
flows = []
with open(filepath) as f:
next(f) # пропустить заголовок
for line in f:
parts = line.strip().split(',')
if len(parts) < 6:
continue
ts, src, dst, dport, proto, byt = parts[:6]
if int(dport) in vpn_ports:
flows.append({
'ts': datetime.strptime(ts, "%Y-%m-%dT%H:%M:%S"),
'src': src,
'dst': dst,
'dport': int(dport),
'bytes': int(byt),
})
return flows

<h2 id="shag-3-korrelyatsiya">─── Шаг 3: Корреляция ────────────────────────────────────────────────────</h2>
def correlate(dhcp_leases, vpn_flows):
results = []
for flow in vpn_flows:
ip = flow['src']
ts = flow['ts']
if ip not in dhcp_leases:
results.append({flow, 'mac': 'UNKNOWN', 'hostname': 'UNKNOWN'})
continue
for (mac, host, start, end) in dhcp_leases[ip]:
if start <= ts <= end:
results.append({flow, 'mac': mac, 'hostname': host})
break
else:
results.append({flow, 'mac': '?', 'hostname': '?'})
return results

<h2 id="zapusk">─── Запуск ───────────────────────────────────────────────────────────────</h2>
if __name__ == '__main__':
leases = parse_dhcp_log('DhcpSrvLog-Wed.log')
flows = load_netflow_vpn('netflow_jan15.csv')
report = correlate(leases, flows)

print(f"{'Время':<20} {'Src IP':<16} {'Hostname':<20} "
f"{'MAC':<20} {'DstPort':<8} {'Bytes'}")
print('-' * 95)
for r in sorted(report, key=lambda x: x['ts']):
print(f"{r['ts']!s:<20} {r['src']:<16} {r['hostname']:<20} "
f"{r['mac']:<20} {r['dport']:<8} {r['bytes']}")





12. Инструменты: Zeek, Suricata, Elasticsearch, Graylog для анализа


Минимальный стек для малого предприятия (бесплатно)


1
. Маршрутизатор с NetFlow-экспортом
(MikroTik, pfSense — оба умеют бесплатно)

2. ntopng Community Edition
Сбор и визуализация NetFlow.
Бесплатно для сетей до 1 000 хостов.
Установка: apt install ntopng

3. Pi-hole или AdGuard Home как DNS
Полные логи всех DNS-запросов.
Бесплатно, устанавливается на любой Linux.

4. Syslog-сервер (rsyslog / syslog-ng)
Централизованный сбор syslog от всех устройств.
rsyslog предустановлен в большинстве дистрибутивов.


Средний стек (SIEM уровня SMB)


graylog
Open (бесплатно для 1 ноды):
Сбор: syslog, GELF, Beats
Хранение: Elasticsearch/OpenSearch
Поиск: веб-интерфейс с фильтрами и дашбордами
Алерты: email/Slack при обнаружении паттернов

Установка Graylog + OpenSearch + MongoDB:
docker-compose.yml доступен на graylog.org/downloads/

Источники данных для Graylog в контексте VPN-детектирования:
- syslog от маршрутизаторов (MikroTik, Cisco, pfSense)
- Windows Event Log через Winlogbeat (Elastic Agent)
- DHCP-логи через filebeat
- DNS-запросы через Pi-hole syslog


Корпоративный стек


elastic
SIEM / Microsoft Sentinel / Splunk:
Сбор из всех источников через агентов
Готовые detection rules для VPN-протоколов
Автоматическая корреляция IP → пользователь через AD
Алерты, тикеты, интеграция с SOAR

Готовые Elastic detection rules для VPN:
github.com/elastic/detection-rules
Поиск по тегу "network" и "vpn"


Zeek: быстрый старт для анализа PCAP-файла


bash
<h2 id="esli-est-zahvachennyy-trafik-naprimer-s-zerkalirovannogo-porta">Если есть захваченный трафик (например, с зеркалированного порта):</h2>
zeek -r capture.pcap

<h2 id="zeek-sozdast-fayly">Zeek создаст файлы:</h2>
<h2 id="conn-log-vse-tcp-udp-soedineniya">conn.log — все TCP/UDP соединения</h2>
<h2 id="dns-log-vse-dns-zaprosy">dns.log — все DNS-запросы</h2>
<h2 id="ssl-log-tls-soedineniya-s-ja3-i-sni">ssl.log — TLS-соединения с JA3 и SNI</h2>
<h2 id="weird-log-anomalii">weird.log — аномалии</h2>

<h2 id="poisk-vpn-v-conn-log">Поиск VPN в conn.log:</h2>
zeek-cut ts id.orig_h id.resp_h id.resp_p proto duration orig_bytes < conn.log | \
awk '($4==1194 || $4==51820 || $4==500) && $6>60'

<h2 id="poisk-vpn-domenov-v-dns-log">Поиск VPN-доменов в dns.log:</h2>
zeek-cut ts id.orig_h query < dns.log | \
grep -E "nordvpn|expressvpn|protonvpn|mullvad|wireguard"





13. Практический кейс: восстановить хронологию инцидента по логам


Ситуация: В 17:30 среды 15 января 2026 года DLP-система зафиксировала большой исходящий трафик (850 МБ) за короткое время. Трафик ушёл через зашифрованный канал — содержимое неизвестно. Нужно восстановить: кто, с какого устройства, куда и когда.

Шаг 1: Firewall-лог — откуда трафик


bash
grep "2026-01-15 17:" /var/log/fw/forward.log | \
awk '$7 > 1000000' | sort -k7 -rn | head -5

<h2 id="rezultat">Результат:</h2>
<h2 id="17-28-41-src-10-10-3-87-dst-185-220-101-45-dport-1194-proto-udp-bytes-893241">17:28:41 src=10.10.3.87 dst=185.220.101.45 dport=1194 proto=udp bytes=893241</h2>
<h2 id="istochnik-10-10-3-87-port-naznacheniya-1194-openvpn">Источник — 10.10.3.87, порт назначения 1194 (OpenVPN)</h2>


Шаг 2: DHCP-лог — чьё устройство


bash
grep "10.10.3.87" /var/log/dhcp/DhcpSrvLog-Wed.log

<h2 id="10-01-15-2026-08-54-21-assign-10-10-3-87-laptop-xf7823-b4-2e-99-11-22-33">10,01/15/2026,08:54:21,Assign,10.10.3.87,LAPTOP-XF7823,B4:2E:99:11:22:33</h2>
<h2 id="ustroystvo-laptop-xf7823-mac-b4-2e-99-11-22-33">Устройство: LAPTOP-XF7823, MAC: B4:2E:99:11:22:33</h2>
<h2 id="arenda-s-08-54-do-sleduyuschego-release">Аренда с 08:54 (до следующего Release)</h2>


Шаг 3: AD-лог — кто вошёл на это устройство


powershell
Get-WinEvent -ComputerName LAPTOP-XF7823 -FilterHashtable @{
LogName='Security'; Id=4624
StartTime='2026-01-15 08:00'; EndTime='2026-01-15 17:30'
} | Select-Object TimeCreated,
@{N='User';E={$_.Properties[5].Value}} | Format-Table

<h2 id="timecreated-user">TimeCreated User</h2>
<h2 id="">─────────────────── ────</h2>
<h2 id="01-15-2026-08-52-14-mivanova">01/15/2026 08:52:14 mivanova</h2>


Шаг 4: DNS-лог — что резолвировало устройство


bash
grep "10.10.3.87" /var/log/named/queries.log | \
grep "2026-01-15T17:" | head -10

<h2 id="2026-01-15t17-27-58-10-10-3-87-nl3-nordvpn-com-a">2026-01-15T17:27:58 10.10.3.87 nl3.nordvpn.com A</h2>
<h2 id="2026-01-15t17-27-59-10-10-3-87-nl3-nordvpn-com-a">2026-01-15T17:27:59 10.10.3.87 nl3.nordvpn.com A</h2>
<h2 id="ustroystvo-rezolvilo-nordvpn-za-minutu-do-trafika">Устройство резолвило NordVPN за минуту до трафика</h2>


Шаг 5: NetFlow — детали трафика


bash
nfdump -r /var/cache/nfdump/nfcapd.202601151700 \
'src ip 10.10.3.87 and dst ip 185.220.101.45' \
-o "fmt:%ts %sa %da %sp %dp %byt %pkt"

<h2 id="2026-01-15-17-28-41-10-10-3-87-185-220-101-45-54891-1194-893241-621">2026-01-15 17:28:41 10.10.3.87 185.220.101.45 54891 1194 893241 621</h2>
<h2 id="odin-potok-893-kb-za-1-min-sootvetstvuet-vyyavlennomu-intsidentu">Один поток: 893 КБ за ~1 мин — соответствует выявленному инциденту</h2>


Итоговая хронология


08
:52 — пользователь mivanova вошёл на LAPTOP-XF7823 (B4:2E:99:11:22:33)
08:54 — устройство получило IP 10.10.3.87 по DHCP
...
17:27 — DNS-запрос к nl3.nordvpn.com с IP 10.10.3.87
17:28 — установлено UDP-соединение на 185.220.101.45:1194 (OpenVPN/NordVPN)
17:28 — 893 МБ трафика исходящего за ~1 мин
17:30 — DLP-алерт зафиксирован

Заключение: пользователь mivanova на устройстве LAPTOP-XF7823
в 17:28 подключила NordVPN и передала ~893 МБ данных через
зашифрованный тоннель, обойдя DLP-систему.





14. FAQ: 12 горячих вопросов о детектировании VPN в корпоративной сети


Q 01 Можно ли обнаружить VPN, если он использует порт 443?
A Да, но сложнее. VPN через TCP/443 маскируется под HTTPS. Методы обнаружения: JA3-fingerprinting (TLS-клиент VPN имеет характерный хэш, отличный от браузерного), анализ объёма и длительности сессии (VPN-туннель длиннее обычного HTTPS-запроса), SNI (Server Name Indication) в TLS handshake — если VPN не использует ESNI, имя сервера видно.

Q 02 Что делать, если устройство с VPN использует статический IP, не DHCP?
A DHCP-лог не поможет. Используйте ARP-таблицу маршрутизатора для связки IP→MAC: `show arp` на Cisco или `ip neigh show` на Linux. MAC-таблица коммутатора покажет физический порт подключения. По порту определяется рабочее место.

Q 03 Как долго хранить логи для расследований?
A Рекомендуемый минимум: DHCP — 90 дней, DNS — 30–90 дней, NetFlow — 30 дней, Firewall — 90 дней, AD Event Log — 180 дней. Для соответствия требованиям PCI DSS или ISO 27001 — не менее 12 месяцев. Хранение в SIEM с индексацией позволяет быстрый поиск по любому периоду.

Q 04 Что, если VPN использует UDP с обфускацией (Shadowsocks, V2Ray, obfs)?
A Обфускация усложняет сигнатурный анализ, но не делает трафик невидимым. Остаются: аномальный объём трафика к конкретному IP, высокая энтропия данных (характерна для зашифрованных/обфусцированных потоков), DNS-запросы перед соединением (если не используется DoH), поведенческий анализ — регулярные потоки в нерабочее время.

Q 05 Нужен ли DPI (глубокая инспекция пакетов) для обнаружения VPN?
A Для большинства задач — нет. Анализ портов, NetFlow-паттернов, DNS-запросов и временны́х характеристик соединений достаточен для обнаружения. DPI нужен только для идентификации протокола при нестандартных портах и обфускации. При этом DPI-анализ зашифрованного трафика даёт только метаданные, не содержимое.

Q 06 Tailscale использует корпоративные IP для relay — как его обнаружить?
A Tailscale устанавливает прямые P2P-соединения или использует DERP-серверы (Tailscale relay) при невозможности прямого соединения. Признаки: DNS-запросы к `login.tailscale.com`, `controlplane.tailscale.com`, HTTPS-трафик к DERP-серверам Tailscale (IP диапазоны публично известны), UDP-трафик на порт 41641 для прямых соединений.

Q 07 Как отличить корпоративный VPN от несанкционированного?
A Корпоративный VPN подключается к известным корпоративным серверам (IP/домены из белого списка). Несанкционированный — к сторонним IP/доменам. Подход: вести белый список корпоративных VPN-серверов, настроить алерт на VPN-трафик за пределы белого списка.

Q 08 Что делать, если MAC-адрес изменён (спуфинг)?
A MAC-спуфинг — признак целенаправленного сокрытия следов. Это само по себе является нарушением политики ИБ. Дополнительные методы идентификации: DHCP hostname (hostname подделывают реже, чем MAC), AD-аутентификация через Kerberos (привязана к сертификату устройства при 802.1X), анализ поведения устройства (какие ресурсы использует, в каких AD-группах состоит).

Q 09 Как автоматически оповещать о появлении VPN-трафика?
A Три подхода по сложности. Простой: правило в firewall — трафик на VPN-порты (1194, 51820) логируется и отправляется на syslog с высоким приоритетом. Средний: Graylog/Elasticsearch alert — поисковый запрос по VPN-паттернам, срабатывающий раз в 5 минут. Продвинутый: Suricata с кастомными правилами — немедленный алерт при обнаружении сигнатуры VPN-протокола.

Q 10 Сотрудник использовал мобильный телефон как точку доступа (hotspot) — видно ли это?
A Не видно через корпоративную сеть — трафик идёт через сотовую сеть оператора, минуя корпоративный шлюз. Видно косвенно: устройство отсутствует в DHCP-логах в этот период (отключилось от корпоративной сети), в NetFlow нет трафика с этого IP в нерабочее время. Контроль hotspot требует MDM-решения или endpoint DLP на устройстве.

Q 11 Нужно ли уведомлять сотрудника при расследовании?
A Зависит от контекста и внутренних процедур. При проведении расследования инцидента с участием службы безопасности — обычно нет, до определённого момента. При плановом мониторинге соблюдения политики — сотрудник информирован через подписанную политику использования корпоративных ресурсов. Юридические нюансы: проконсультируйтесь с юристом, особенно при возможном дисциплинарном или уголовном преследовании.

Q 12 Как убедиться, что логи не были изменены?
A Для форензически значимых расследований: централизованный syslog на отдельный сервер (логи записываются сразу на удалённый сервер, а не только локально), WORM-хранение (write-once, read-many) — NFS mount с ограниченными правами, хэширование лог-файлов при записи и верификация при чтении. В большинстве корпоративных расследований такой строгости не требуется, но при передаче материалов в правоохранительные органы — желательна.




15. Чек-лист: настроить постоянное обнаружение несанкционированных VPN


Фундамент: логирование (настроить один раз)
- ☐ Включить и проверить DHCP-логирование (минимум 90 дней хранения)
- ☐ Включить DNS-логирование всех запросов (минимум 30 дней)
- ☐ Включить NetFlow/IPFIX на пограничном маршрутизаторе
- ☐ Настроить централизованный syslog-сервер (rsyslog / Graylog)
- ☐ Убедиться, что AD-логи (Event ID 4624/4768) централизованно хранятся
- ☐ Проверить, что все источники синхронизированы по NTP (критично для корреляции!)

Обнаружение: правила и алерты
- ☐ Создать правила firewall с логированием на VPN-порты (1194, 51820, 500, 4500)
- ☐ Настроить DNS-алерт на обращения к известным VPN-доменам (NordVPN, ExpressVPN и т.д.)
- ☐ В SIEM: поисковый запрос на длинные UDP-потоки (>60 сек) к нестандартным портам
- ☐ Настроить порог NetFlow-алерта: исходящий трафик >100 МБ/час с одного хоста
- ☐ Создать белый список корпоративных VPN-серверов — алертить на всё за пределами списка

Инструменты
- ☐ Развернуть ntopng или аналог для визуализации NetFlow
- ☐ Рассмотреть Zeek для пассивного анализа трафика (если есть зеркалирование порта)
- ☐ Настроить dashboard с топ-10 хостов по исходящему трафику

Процессы
- ☐ Убедиться, что политика использования корпоративных ресурсов содержит упоминание о мониторинге
- ☐ Описать процедуру реагирования: что делать при обнаружении несанкционированного VPN
- ☐ Раз в квартал: проверка срока хранения логов и доступности данных для ретроспективного анализа
- ☐ Раз в квартал: обновление списка известных VPN-доменов (новые провайдеры появляются регулярно)




16. Заключение и теги


Обнаружение несанкционированного VPN в корпоративной сети — не задача с единственным инструментом. Это слои: DNS-логи дают первый сигнал, DHCP связывает IP с устройством, AD-логи называют пользователя, NetFlow показывает масштаб. Ни один источник в одиночку не даёт полной картины — ценность в корреляции.

Практический маршрут для организаций: начать с минимального — DNS-логирование через Pi-hole и централизованный syslog от маршрутизатора. Это бесплатно, занимает один рабочий день, и уже даёт видимость основных VPN-активностей. Следующий уровень — NetFlow + Graylog для исторического поиска. Максимум — Zeek или Suricata на зеркалированном порту для сигнатурного анализа.

Самое важное, что нужно помнить: все эти методы работают только в том случае, если логи собираются заблаговременно. Настроить логирование после инцидента — поздно. История существует только там, где была включена запись.

> 🔍 Видимость сети — это не слежка. Это базовое условие управления безопасностью инфраструктуры, которой вы отвечаете.