Безопасность локальной сети: ПК, Layer-2, Wi‑Fi, VoIP и SAN

Безопасность пользовательских компьютеров в локальной сети

Пользовательский компьютер (рабочая станция, ноутбук, тонкий клиент) — самая частая точка входа атакующего в локальную сеть. Причины простые: на ПК работает пользователь, который открывает письма, скачивает файлы, подключает устройства, а сам компьютер регулярно взаимодействует с внутренними сервисами (файловые шары, почта, корпоративные порталы, VoIP‑клиенты, Wi‑Fi, VPN). Поэтому защита ПК — это фундамент для всего курса: если конечные устройства скомпрометированы, то даже идеально настроенные VLAN, Wi‑Fi или VoIP не спасут от бокового перемещения, кражи учётных данных и саботажа.

Роль пользовательского ПК в модели угроз локальной сети

Пользовательский компьютер одновременно:

обрабатывает данные (документы, учётные данные, токены доступа)

инициирует сетевые соединения (внутренние API, SMB, RDP, SIP, web‑сервисы)

является промежуточной точкой для атак на инфраструктуру (AD, сервера, сетевое оборудование)

Типовой сценарий атаки на локальную сеть часто начинается с ПК:

Первичное заражение (фишинг, вредоносный сайт, уязвимость в ПО, заражённая флешка).

Закрепление (автозагрузка, сервисы, планировщик задач, расширения браузера).

Кража учётных данных (пароли, cookie, токены, NTLM‑хэши, ключи SSH).

Боковое перемещение (SMB/RDP/WinRM, “прыжки” по общим ресурсам).

Достижение цели (шифрование, утечка, изменение данных, атака на VoIP/SAN).

!Типовой путь атаки, начинающийся с пользовательского ПК

Базовые принципы защиты конечных устройств

Снижение поверхности атаки

Снижение поверхности атаки означает: чем меньше лишних функций и прав — тем меньше способов взлома. Это достигается комбинацией организационных и технических мер:

минимальный набор установленного ПО

отключение ненужных служб и компонентов

запрет небезопасных механизмов (например, макросов из интернета)

ограничение сетевой доступности ПК

Практический ориентир — следовать проверенным базовым профилям (baseline) и бенчмаркам:

CIS Benchmarks

Microsoft Security Baselines

Принцип наименьших привилегий

Пользователь не должен работать с правами администратора каждый день. Это одна из наиболее эффективных мер против массовых атак.

Рекомендуемая модель:

Обычная учётная запись для повседневной работы (почта, браузер, офисные приложения).

Административная учётная запись — только для задач администрирования, по возможности с дополнительными контролями (MFA, отдельная сессия, ограничение входа).

Разделение ролей: локальный администратор ПК не должен автоматически иметь административные права в домене.

Связь с дальнейшими темами курса: если на ПК есть локальный админ и атакующий получает эти права, ему проще внедрять снифферы/прокси, поднимать rogue‑службы и атаковать Layer‑2 (например, для перехвата трафика), а также атаковать VoIP‑клиенты.

Стандартизация и управляемость

С точки зрения безопасности, “зоопарк” конфигураций — проблема. Управляемость означает:

централизованные политики (например, через доменные политики)

инвентаризация устройств и ПО

управляемые обновления

единые шаблоны (golden image)

Защита учётных данных на ПК

Пароли, MFA и устойчивость к фишингу

Ключевые практики:

MFA везде, где возможно (почта, VPN, корпоративные порталы)

приоритет фишинг‑устойчивых методов (аппаратные ключи, passkeys)

запрет повторного использования паролей

менеджер паролей (корпоративно одобренный)

Важно: даже при сильном пароле пользовательский ПК остаётся целью для кражи токенов сессий и cookie из браузера. Поэтому защита браузера и ОС не менее важна, чем политика паролей.

Защита от кражи хэшей и токенов в Windows‑среде

Даже без детального погружения в AD уже на уровне ПК полезно понимать цель атакующего: получить материал для аутентификации (пароль, хэш, токен) и использовать его в сети.

Практические меры на ПК:

отключение хранения паролей в небезопасных местах, контроль автологина

ограничение локального кэша учётных данных там, где это допустимо организационно

защита LSASS и включение защитных механизмов ОС (в зависимости от платформы и редакции)

Для Windows применяют меры из руководств Microsoft по снижению риска кражи учётных данных, включая подходы класса Credential Guard (где применимо):

Protect derived domain credentials with Credential Guard

Управление обновлениями и уязвимостями

Большая доля компрометаций происходит из-за известных уязвимостей в браузерах, офисных пакетах, PDF‑читалках, клиентах удалённого доступа.

Практика безопасных обновлений:

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

Отдельный процесс обновления “третьего” ПО (архиваторы, Java‑рантаймы, PDF, VPN‑клиенты).

Учёт конечной точки: в локальной сети важны окна обновлений, чтобы не сломать бизнес‑процессы, но и не держать “дырявые” версии месяцами.

Контроль уязвимостей: хотя бы базовая отчётность “что установлено и насколько устарело”.

Антивирус, EDR и контроль поведения

Разница между классическим AV и EDR

Классический AV лучше ловит массовое известное вредоносное ПО по сигнатурам и простым эвристикам.

EDR (Endpoint Detection and Response) ориентирован на поведенческое обнаружение и расследование: цепочки процессов, подозрительные связи, дампы памяти, lateral movement.

Минимально зрелый набор возможностей на ПК:

защита в реальном времени

контроль подозрительных действий (например, запуск PowerShell со странными параметрами)

централизованная консоль и оповещения

изоляция хоста (если продукт это поддерживает)

Организационно важно заранее определить: кто и как реагирует на срабатывания, где хранится телеметрия и сколько времени.

Встроенный межсетевой экран и базовая хостовая сегментация

Хостовый firewall на ПК — это “последняя линия” перед тем, как машина станет удобной целью для сканирования и удалённого выполнения.

Что обычно делают в корпоративной локальной сети:

входящие соединения по умолчанию запрещены, разрешения выдаются по необходимости

админ‑протоколы (RDP, SMB admin shares, WinRM) ограничиваются по источникам (только админ‑подсети)

отдельные профили для корпоративной сети и публичных сетей (особенно для ноутбуков)

Связь с темой Layer‑2: даже если атакующий находится “внутри” (например, подключился к порту коммутатора), хостовый firewall значительно усложняет массовое распространение по сети.

Контроль приложений и сценариев (Application Control)

Большинство атак на ПК использует запуск:

вредоносных исполняемых файлов

скриптов (PowerShell, JavaScript, VBScript)

офисных макросов

Задача контроля приложений — разрешить только то, что нужно, и усложнить запуск остального.

Практики:

Запрет или жёсткое ограничение офисных макросов из файлов, полученных из интернета.

Ограничение интерпретаторов и “двойных” инструментов администрирования там, где они не нужны.

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

Для Windows полезная отправная точка — официальные рекомендации Microsoft по правилам сокращения поверхности атаки:

Attack surface reduction rules

Шифрование диска и защита данных на конечной точке

Даже идеальная защита сети не спасает от риска, если ноутбук потеряли или украли.

Базовые меры:

полное шифрование диска (Full Disk Encryption)

защита ключей шифрования (например, через TPM, где применимо)

блокировка экрана и короткий таймаут простоя

запрет хранения чувствительных данных в незашифрованных контейнерах

Смысл: атакующий не должен получить данные “в офлайне”, вытащив накопитель или загрузившись с внешнего носителя.

Защита браузера, почты и пользовательских привычек

Большинство атак на ПК начинается с контента.

Технические меры:

обновляемый браузер и расширения из доверенных источников

блокировка небезопасных типов вложений на почтовом шлюзе (если есть)

изоляция вложений и ссылок (где доступно: песочницы, safe links)

Организационные меры:

короткие, регулярные тренировки по фишингу

простой канал “сообщить о подозрительном письме”

Важно: обучение без технических мер даёт ограниченный эффект, потому что ошибки неизбежны.

Съёмные носители и периферия

USB‑устройства — классический канал заражения и утечки.

Практики:

политика использования USB‑накопителей (разрешить корпоративные, запретить личные)

контроль классов устройств (накопители, модемы, HID)

автозапуск отключён

Резервное копирование пользовательских данных

Резервное копирование — это не только про серверы. На ПК часто лежат:

рабочие документы

локальные базы/архивы

критичные файлы проектов

Правильный подход:

Стараться хранить рабочие данные в управляемых местах (сетевые диски, корпоративное облако), а не на C:.

Иметь версионирование, чтобы откатиться после шифрования или порчи файлов.

Проверять восстановление (иначе “бэкап” может оказаться фикцией).

Логи и готовность к реагированию на инциденты

Для локальной сети важно не только “защитить”, но и понять, что произошло.

Минимальный набор:

централизованный сбор событий безопасности (хотя бы с критичных групп ПК)

синхронизация времени (иначе корреляция событий почти невозможна)

понятный процесс эскалации: кто принимает решение об изоляции ПК, смене паролей, проверке соседних хостов

Для общей рамки процессов полезны документы NIST по реагированию:

NIST SP 800-61 Rev. 2 Computer Security Incident Handling Guide

Минимальный практический стандарт “защищённого ПК”

Ниже — чек-лист, который можно использовать как базовый стандарт для рабочих станций в локальной сети (не привязан к конкретному вендору, но легко маппится на GPO/MDM/EDR‑политики):

Пользователь работает без прав локального администратора.

Включены автоматические обновления ОС и браузера; есть процесс обновления остального ПО.

Включён и управляется хостовый firewall; входящие подключения ограничены.

Есть AV/EDR с централизованным управлением.

Включено шифрование диска (особенно для ноутбуков).

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

Настроены политики USB и автозапуска.

Данные пользователей хранятся в местах с резервным копированием и версионированием.

Логи безопасности доступны для расследования; время синхронизировано.

Есть процедура изоляции устройства и смены учётных данных при инциденте.

Как эта тема связывается со следующими модулями курса

В следующих статьях мы перейдём от защиты отдельного ПК к безопасности на уровне локальной инфраструктуры:

Layer‑2: даже защищённая сеть уязвима, если ПК легко заражается и начинает генерировать вредоносный трафик или участвовать в атаках (например, подмена ARP, попытки доступа к соседям).

Конфигурация Layer‑2: сетевые защиты (Port Security, DHCP Snooping и др.) эффективнее, когда конечные устройства тоже “жёсткие” и управляемые.

Wi‑Fi, VoIP, SAN: ПК часто является клиентом Wi‑Fi и VoIP‑сервисов, а также точкой доступа к данным в хранилищах. Компрометация ПК превращает любые “защищённые” сервисы в риск утечки или разрушения данных.

Угрозы и модели атак на втором уровне (Layer-2)

Защита пользовательских ПК (предыдущая тема курса) снижает риск первичного заражения и кражи учётных данных, но не отменяет факт: локальная сеть по умолчанию доверчива на канальном уровне. Если атакующий уже оказался внутри сегмента (подключился к порту, получил доступ через компрометированный ПК или «принёс» мини-коммутатор), он может атаковать механизмы, на которых держится доставка кадров Ethernet и базовая сегментация VLAN.

Эта статья объясняет, как именно атакуют Layer-2, какие предпосылки нужны атакующему и к чему приводят такие атаки. В следующей статье курса мы перейдём к конфигурациям защит (Port Security, DHCP Snooping, Dynamic ARP Inspection и другие), а здесь сосредоточимся на моделях угроз.

Что такое Layer-2 и почему он важен для безопасности

Layer-2 (канальный уровень) в локальной сети отвечает за доставку кадров внутри широковещательного домена (обычно VLAN). На практике это:

Ethernet-кадры и MAC-адреса.

Коммутаторы (switch), которые принимают решение, на какой порт отправить кадр.

VLAN как логическая сегментация одной физической инфраструктуры.

Широковещание и служебные протоколы «соседства».

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

Нет криптографической аутентификации участников.

Можно подменять «сетевую идентичность» на уровне MAC.

Широковещательные сообщения принимаются множеством узлов.

Это делает Layer-2 удобной точкой для атак класса перехват, подмена, обход сегментации и отказ в обслуживании.

!Иллюстрация двух типовых моделей L2-атак: перехват (MITM через ARP) и деградация коммутатора через переполнение MAC-таблицы

Ключевые элементы, которые атакуют на Layer-2

MAC-таблица коммутатора

Коммутатор строит таблицу соответствий MAC-адрес → порт (её часто называют CAM table или FDB). Он «обучается» по исходным MAC-адресам входящих кадров.

Если запись неизвестна, коммутатор может отправить кадр во все порты VLAN (поведение flooding для unknown unicast).

ARP как «склейка» IP и MAC

В IPv4 сети протокол ARP сопоставляет IP-адрес с MAC-адресом внутри локального сегмента. ARP по умолчанию не проверяет, что ответ действительно пришёл от владельца IP.

Полезный первоисточник: RFC 826: An Ethernet Address Resolution Protocol.

DHCP как выдача сетевой конфигурации

DHCP раздаёт IP-адреса и параметры, в том числе адрес шлюза и DNS. Если атакующий подменит DHCP-ответ, он может незаметно изменить маршрут трафика или DNS.

Первичный стандарт: RFC 2131: Dynamic Host Configuration Protocol.

Spanning Tree Protocol (STP) как защита от петель

STP предотвращает L2-петли, выбирая «корневой» коммутатор и блокируя лишние связи. Если атакующий вмешается в STP, он может:

вызвать деградацию сети (постоянные перерасчёты);

попытаться направить трафик через себя за счёт смены топологии.

Для понимания логики STP можно использовать обзор: Cisco: Understanding Spanning Tree Protocol.

Модель нарушителя на Layer-2

Практически полезно различать сценарии по доступу атакующего.

Атакующий уже внутри VLAN

Источники доступа:

скомпрометированный пользовательский ПК;

злонамеренный инсайдер;

«гостевое» устройство, физически подключённое к розетке.

Возможности:

отправлять произвольные Ethernet-кадры и широковещательные пакеты;

менять свой MAC-адрес;

генерировать высокий объём трафика.

Атакующий управляет конфигурацией порта или «договаривается» с коммутатором

Это более сильная позиция. Она появляется, если:

порт ошибочно настроен как trunk;

включены механизмы авто-согласования режимов (в некоторых средах);

есть уязвимости или ошибки в управлении коммутатором.

Тогда появляется шанс атаковать сегментацию VLAN или получить доступ к нескольким VLAN.

Атакующий не обязательно технически продвинут

Часть L2-атак выполняется готовыми инструментами и сводится к простым действиям:

запустить ARP-spoofing;

поднять rogue DHCP;

включить дешёвый коммутатор/точку доступа и «размножить» подключение.

Именно поэтому в локальной сети важны защита портов и предсказуемая конфигурация.

Типовые цели атак на Layer-2

Перехват трафика внутри сегмента для кражи учётных данных, токенов, контента.

Подмена (man-in-the-middle) с возможностью модификации данных.

Обход сегментации VLAN или политик доступа.

Отказ в обслуживании (локальная деградация, «роняние» сегмента, исчерпание ресурсов).

Подготовка бокового перемещения (упрощение дальнейших атак на AD, VoIP, Wi‑Fi контроллеры, SAN-шлюзы).

Классы атак на втором уровне

Разведка и сбор информации в L2-сегменте

Даже без активного «взлома» атакующий внутри VLAN часто может собрать много полезного:

наблюдать широковещание (ARP, DHCP, иногда mDNS/LLMNR);

выявлять IP/MAC соседей, шлюз, DHCP и DNS;

получить сведения о моделях оборудования через служебные протоколы (если они разрешены).

Результат разведки — подготовка к перехвату, подмене или атаке на конкретные узлы.

Подмена идентичности на уровне MAC

Поскольку MAC-адрес легко меняется программно, атакующий может:

имитировать «разрешённый» MAC, если доступ к сети завязан на списки MAC;

обойти примитивные ограничения «по устройствам»;

спровоцировать конфликты и нестабильность (два узла с одним MAC в сети).

Важно: фильтрация по MAC сама по себе не является надёжной защитой, потому что MAC обычно не секрет.

Перехват и подмена трафика через ARP-spoofing (IPv4)

Суть атаки:

жертва верит ARP-ответам без проверки;

атакующий отправляет поддельные ARP-ответы, привязывая IP шлюза к своему MAC;

трафик жертвы к шлюзу начинает идти через атакующего.

Последствия:

перехват незашифрованных протоколов;

попытки downgrade/инъекций, если есть слабые места на уровне приложений;

упрощение кражи учётных данных и токенов (в связке с компрометацией ПК).

Ограничения:

атака обычно работает только внутри одного широковещательного домена (одного VLAN);

для устойчивого MITM атакующему часто нужно ещё обеспечить пересылку трафика дальше, чтобы сеть «не упала» для жертвы.

Rogue DHCP и DHCP starvation

Два близких сценария.

Rogue DHCP:

атакующий поднимает «левый» DHCP-сервер;

клиенты могут получить от него настройки.

Что можно подменить:

адрес шлюза (направить трафик через атакующего);

DNS (перевести пользователей на фишинговые ресурсы или внутренние подделки);

параметры маршрутизации и прокси в зависимости от среды.

DHCP starvation:

атакующий генерирует много запросов с разными MAC;

пул адресов легитимного DHCP истощается;

пользователи теряют возможность получить IP.

Переполнение MAC-таблицы (CAM table flooding)

Суть:

атакующий шлёт кадры с большим количеством поддельных исходных MAC;

коммутатор пытается «обучиться» и переполняет таблицу;

далее неизвестные unicast кадры чаще уходят во flooding по VLAN.

Последствия:

увеличение объёма «лишнего» трафика в сегменте;

упрощение пассивного прослушивания (часть трафика может оказаться на порту атакующего);

деградация производительности.

На современных коммутаторах эффективность зависит от модели, настроек и защит, но как модель угрозы это важно: атакующий пытается превратить коммутатор в поведение, близкое к «общей среде», где проще перехватывать.

Атаки на STP и топологию

Если атакующий может отправлять BPDUs (служебные STP-кадры) и сеть не защищена, возможны:

STP manipulation: попытка «стать root bridge» или изменить выбор путей;

STP instability: частые изменения топологии, вызывающие деградацию.

Последствия:

кратковременные или длительные простои;

непредсказуемые пути трафика;

в ряде дизайнов — возможность направить поток через узел атакующего.

На практике это особенно опасно в сетях с большим числом access-портов и недостаточной L2-гигиеной.

Обход VLAN-сегментации (VLAN hopping)

VLAN hopping — общий термин для попыток «вылезти» из своего VLAN на уровне L2.

Типовые механики, которые обсуждают в контексте моделей угроз:

Switch spoofing: попытка заставить порт работать как trunk (если режимы согласуются автоматически в данной среде).

Double tagging: отправка кадра с двумя VLAN-тегами, чтобы он оказался в другом VLAN при определённой конфигурации native VLAN.

Практическая ценность для атакующего:

доступ к сервисам другого сегмента без маршрутизации и ACL;

приближение к чувствительным зонам (например, management, voice, storage).

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

Локальные петли и «дешёвые» сетевые катастрофы

Иногда L2-инцидент — не сложная атака, а примитивное действие:

пользователь подключил кабель «из розетки в розетку»;

поставили мини-коммутатор без понимания топологии;

подключили два порта коммутатора между собой.

Если защиты от петель и ошибок не настроены, последствия могут быть такими же, как от целенаправленной атаки:

шторм широковещания;

резкий рост нагрузки на коммутаторы;

недоступность сервисов в VLAN.

С точки зрения безопасности это важно, потому что доступность — часть требований к защищённой сети.

Связка Layer-2 атак с компрометацией ПК

Layer-2 атаки особенно опасны, когда атакующий уже получил контроль над пользовательским ПК:

можно незаметно запустить ARP-spoofing изнутри ОС;

проще перехватывать корпоративные протоколы и трафик приложений;

удобнее «прикрываться» легитимным хостом, который уже находится в нужной VLAN.

И наоборот, грамотная защита ПК (EDR, ограничение прав, хостовый firewall) уменьшает шанс, что атака на Layer-2 будет запущена массово и незаметно.

Карта атак: предпосылки, влияние, наблюдаемость

| Атака | Что нужно атакующему | Основной эффект | Типовые признаки в сети | |---|---|---|---| | ARP-spoofing | Быть в одной VLAN с жертвой | MITM, перехват/подмена | Изменение ARP-таблиц, дубликаты ARP, «прыгающий» MAC для IP шлюза | | Rogue DHCP | Доставить DHCP-ответы клиентам | Подмена шлюза/DNS, MITM | Два DHCP-источника, «неправильные» опции DHCP | | DHCP starvation | Генерировать много DHCP-сессий | Отказ в выдаче адресов | Исчерпан пул, всплеск DHCP-трафика | | CAM flooding | Генерировать много разных MAC | Flooding unknown unicast, деградация | Рост неизвестного unicast, нагрузка на коммутатор | | STP manipulation | Отправлять BPDUs в сегмент | Перестройка топологии, деградация | Topology change, смена root, частые перерасчёты | | VLAN hopping | Специфичная конфигурация VLAN/trunk | Выход в другой VLAN | Неожиданная видимость сервисов, аномалии на trunk/портах |

Таблица — не «инструкция», а способ мыслить: любая угроза описывается через предпосылки, эффект и наблюдаемые признаки, которые можно использовать для мониторинга и реагирования.

Что логировать и где искать следы L2-атак

Даже до внедрения специализированных средств мониторинга полезно понимать источники данных:

события коммутаторов (изменения STP, нарушения, ошибки портов);

сообщения о DHCP (особенно при подозрении на rogue DHCP);

сетевые дампы (SPAN/port mirroring) при расследовании;

телеметрия EDR на конечных точках (запуск утилит, странные сетевые паттерны).

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

кто имеет право включать зеркалирование порта;

как быстро можно изолировать порт или VLAN;

как фиксируются артефакты для расследования.

Как эта тема связывается со следующей статьёй

Мы выяснили, что Layer-2 уязвим из-за доверчивых механизмов доставки и «соседства», а атаки чаще всего сводятся к:

подмене (ARP/DHCP);

деградации (CAM flooding, петли, STP);

обходу сегментации (VLAN hopping) при ошибках конфигурации.

В следующей статье мы перейдём от моделей атак к практическим защитам и настройкам коммутаторов: какие функции включать, где ставить границы доверия и как построить Layer-2 так, чтобы перечисленные сценарии либо не работали, либо быстро обнаруживались.

Практическая конфигурация безопасности Layer-2 на коммутаторах

В прошлых статьях курса мы разобрали, почему пользовательские ПК часто становятся точкой входа, а также какие модели атак характерны для Layer-2 (ARP-spoofing, rogue DHCP, CAM flooding, манипуляции STP, VLAN hopping). Теперь переходим к главному практическому вопросу: как настроить коммутаторы так, чтобы эти атаки либо не работали, либо быстро обнаруживались и локализовались.

Важно держать в голове границу ответственности:

ПК-защиты (EDR, least privilege, firewall) уменьшают вероятность, что злоумышленник вообще получит позицию внутри VLAN.

L2-защиты на коммутаторах ограничивают ущерб даже тогда, когда атакующий уже подключён к порту или действует с компрометированного хоста.

!Карта доверия портов и где включаются ключевые L2-защиты

Логика построения защиты на Layer-2

Практическая L2-безопасность почти всегда строится вокруг двух идей:

Чёткая классификация портов: edge (пользователи), uplink (к другим коммутаторам), server (к серверам), voice (телефония), management.

Границы доверия: на большинстве access-портов вы никому не доверяете (untrusted), а доверяете только тем портам, где объективно находятся инфраструктурные устройства (например, uplink к вашему L3-шлюзу и DHCP-серверу).

Это прямо отвечает на угрозы из предыдущей статьи:

rogue DHCP гасится тем, что DHCP-ответы разрешены только с доверенных портов;

ARP-spoofing гасится проверкой ARP по таблице привязок IP–MAC–порт;

STP-атаки гасится тем, что на edge-портах запрещены BPDU;

CAM flooding и штормы снижаются ограничениями и storm-control;

VLAN hopping осложняется жёсткой настройкой trunk и native VLAN.

Базовая гигиена коммутатора: то, что должно быть сделано всегда

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

Цель: порт, в который «воткнутся» без вашего ведома, должен быть либо выключен, либо попадать в изолированную VLAN без доступа к критичным ресурсам.

Типовая практика:

неиспользуемые порты переводятся в специальную parking VLAN;

порт административно выключается (shutdown);

на parking VLAN не должно быть маршрутизации к корпоративным подсетям.

Явно задавайте роль порта

На пользовательских портах:

режим access (не trunk);

отключение автоматических переговоров режима trunk (если платформа это поддерживает);

включение edge-режима STP (PortFast) вместе с защитой (BPDU Guard).

На uplink/trunk портах:

режим trunk задаётся вручную;

список разрешённых VLAN ограничивается до необходимых;

native VLAN выбирается осознанно и обычно не используется для пользовательского трафика.

Усиление VLAN и trunk: защита от ошибок и VLAN hopping

Ограничение VLAN на trunk (VLAN pruning)

Если trunk несёт «все VLAN по умолчанию», то любая ошибка или компрометация в одном месте расширяет область поражения.

Практика:

на trunk портах задавайте allowed VLANs как минимальный набор;

не допускайте «протекания» management/voice/storage VLAN туда, где они не нужны.

Native VLAN и принцип «ничего важного в native»

Многие практики ужесточения исходят из простого правила:

native VLAN не должна совпадать с пользовательской VLAN;

native VLAN не должна содержать чувствительные сервисы.

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

Port Security: ограничение MAC-адресов на access-портах

Port Security ограничивает, какие и сколько MAC-адресов могут появляться на конкретном access-порту.

Это полезно против:

простого обхода «по MAC-фильтру» (не как абсолютная защита, а как усложнение);

подключения мини-коммутатора и «размножения» устройств;

CAM-табличных аномалий на edge;

части сценариев «переезда» атакующего между портами.

Ключевые параметры, которые надо понимать:

maximum MAC: сколько MAC допустимо на порту (часто 1–2 для обычного ПК, 2–3 для сценария IP-телефон + ПК за телефоном);

sticky MAC: коммутатор может «запомнить» первый увиденный MAC и закрепить его в конфигурации;

violation action: что делать при нарушении (логировать, ограничивать, выключать порт).

Ограничение: Port Security не заменяет аутентификацию пользователя/устройства (MAC не является секретом), но как технический барьер и источник событий мониторинга даёт ощутимую пользу.

DHCP Snooping: точка опоры для защиты от rogue DHCP

DHCP Snooping делает две важные вещи:

разделяет порты на trusted и untrusted;

строит таблицу привязок, где фиксируются соответствия вида MAC–IP–VLAN–порт для клиентов, получивших адрес по DHCP.

Это защита от rogue DHCP, потому что:

на untrusted портах блокируются DHCP-ответы (DHCPOFFER/DHCPACK);

DHCP-сервер физически должен находиться за trusted портом.

Практические правила включения:

Включайте DHCP Snooping только на тех VLAN, где есть DHCP-клиенты.

По умолчанию все порты считаются untrusted.

Доверяйте только uplink-портам в сторону легитимного DHCP-сервера или L3-устройства, которое ретранслирует DHCP (DHCP relay).

Включайте rate-limit DHCP на edge-портах, чтобы снижать эффект DHCP starvation.

Связь со следующей защитой критична: таблица DHCP Snooping часто используется как «источник истины» для проверок ARP.

Нормативная база DHCP описана в RFC 2131: Dynamic Host Configuration Protocol.

Dynamic ARP Inspection: защита от ARP-spoofing и MITM в IPv4

Dynamic ARP Inspection (DAI) проверяет ARP-пакеты и блокирует поддельные ARP-ответы.

Идея простая:

клиент не должен заявлять: «IP шлюза теперь на моём MAC»;

коммутатор может сравнить ARP-заявления с таблицей DHCP Snooping (где записано, какой IP выдавался какому MAC на каком порту).

Что важно спроектировать заранее:

DAI включают на VLAN пользователей и других «не доверенных» сегментах;

uplink-порты в сторону шлюза/L3 и DHCP-инфраструктуры обычно отмечают как trusted для DAI;

для устройств со статическим IP (серверы, принтеры, сетевое оборудование) может понадобиться отдельная логика: либо отказ от DAI в этой VLAN, либо статические привязки (зависит от платформы и процесса эксплуатации).

Нормативная база ARP: RFC 826: An Ethernet Address Resolution Protocol.

IP Source Guard: блокировка подмены IP на уровне порта

IP Source Guard использует таблицу привязок (обычно от DHCP Snooping) и ограничивает исходящий трафик на порту:

разрешён только тот IP-адрес (и иногда MAC), который был легитимно получен;

попытка «поднять другой IP» на том же порту будет блокироваться.

Это уменьшает эффективность:

простых попыток выдавать себя за другой хост;

части атак на приложения, где важна IP-идентичность источника.

Ограничение: если в сегменте много статических IP, внедрение становится сложнее организационно.

STP-защиты: PortFast, BPDU Guard, Root Guard и устойчивость к петлям

STP защищает сеть от L2-петель, но сам по себе может стать целью атак или источником аварий из-за ошибок. Поэтому на access-уровне применяют набор защит.

Базовое понимание STP и терминов можно освежить по материалу Cisco: Understanding Spanning Tree Protocol.

PortFast на edge-портах

PortFast ускоряет переход порта в состояние forwarding, что важно для клиентских устройств.

Правило:

PortFast включают на портах, где гарантированно нет коммутаторов (ПК, принтер, телефон).

BPDU Guard

BPDU Guard выключает порт, если на edge-порту обнаружены BPDUs.

Зачем:

если пользователь подключил мини-коммутатор или «умное» устройство, которое начинает говорить STP;

если атакующий пытается манипулировать STP (например, претендовать на роль root bridge).

Root Guard

Root Guard применяется на портах, где вы не хотите допустить появление «корня STP» со стороны соседа.

Типовое место:

порт от распределительного уровня к access-коммутатору, если root должен оставаться на распределительном уровне.

Loop Guard и другие механизмы устойчивости

В некоторых дизайнах полезны дополнительные меры против односторонних отказов и «залипаний» STP-состояний. Конкретный набор зависит от вендора и модели сети, но логика одна: сеть должна быть устойчивой к ошибкам и «самодельным» подключениям.

Storm Control: ограничение широковещания, multicast и unknown unicast

Storm Control ограничивает долю/скорость определённых типов трафика на порту:

broadcast (включая ARP-штормы);

multicast;

unknown unicast (часто растёт при CAM-анномалиях).

Практическая ценность:

снижение эффекта штормов из-за петель и ошибок;

ограничение ущерба от некоторых DoS-сценариев на L2.

Осторожность:

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

802.1X и MAB: аутентификация на порту как усиление модели доверия

Если ваша цель не только блокировать отдельные атаки, но и контролировать, кто вообще может подключаться к сети, то на access-портах используют 802.1X.

Суть:

устройство проходит аутентификацию (обычно через RADIUS);

на основании результата назначается VLAN или политика;

при отсутствии 802.1X на устройстве иногда применяют MAB (проверка по MAC) как fallback.

Практический смысл для L2-безопасности:

уменьшается риск «вставил кабель и оказался в корпоративной VLAN»;

проще разделять гостевые/корпоративные устройства без ручного управления портами.

Ограничение: 802.1X требует инфраструктуры (RADIUS, профили устройств, процессы поддержки), поэтому часто внедряется поэтапно.

Практический шаблон: как собрать защиты в единую конфигурацию

Ниже пример в стиле Cisco IOS, чтобы показать, как функции обычно «складываются» в единый профиль. На других платформах названия команд могут отличаться, но смысл почти всегда совпадает.

Как читать этот шаблон:

ip dhcp snooping vlan 10 означает: строим таблицу соответствий для клиентов VLAN 10 и блокируем DHCP-ответы на untrusted портах.

ip arp inspection vlan 10 означает: включаем проверку ARP в VLAN 10, чтобы осложнить ARP-spoofing.

spanning-tree portfast вместе с bpduguard означает: порт предназначен для конечного устройства, и если там вдруг появился STP, порт будет отключён.

port-security задаёт локальную «рамку» для MAC-адресов на порту.

storm-control и dhcp snooping limit rate уменьшают риск штормов и некоторых DoS-сценариев на edge.

uplink-порт помечен как доверенный, потому что именно через него приходят легитимные DHCP-ответы и проходит инфраструктурный ARP.

Мониторинг и эксплуатация: без этого настройки не дадут эффекта

Технические функции L2-безопасности создают события, которые нужно уметь обрабатывать.

Минимальный набор того, что стоит собирать и разбирать:

нарушения Port Security (какой порт, какой MAC, какое действие применено);

срабатывания DHCP Snooping (попытки DHCP-ответов с untrusted порта, всплески DHCP);

дропы DAI (какие ARP были признаны неверными и на каком порту);

STP-события (Topology Change, появление BPDU на edge);

факты err-disable/port shutdown по защитным причинам.

Практическое правило эксплуатации:

заранее определите, кто и как «поднимает» порт после защитного отключения, и как отличать атаку от ошибки пользователя (например, пользователь подключил мини-коммутатор).

Как эта статья связывается со следующими темами курса

После Layer-2 логично перейти к тем средам, где L2-риски проявляются особенно ярко:

Wi‑Fi: там тоже есть «домен доступа», аутентификация, сегментация, гостевые сети и риски rogue-устройств.

VoIP: voice VLAN, телефоны как «мост» для ПК, требования к QoS и защите сигнализации.

SAN: хотя технологии могут отличаться (например, Fibre Channel), общая идея доверенных сегментов и жёсткого контроля доступа сохраняется.

Если суммировать: защита ПК уменьшает шанс проникновения, а практическая L2-конфигурация делает локальную сеть устойчивой к тому, что проникновение всё же произошло.

Безопасность беспроводных сетей: Wi‑Fi, аутентификация и сегментация

Wi‑Fi в корпоративной локальной сети — это не просто «другая среда передачи». С точки зрения архитектуры доступа Wi‑Fi чаще всего является мостом в тот же Layer‑2 домен, что и проводная сеть: клиент получает IP, ходит к тем же сервисам, использует те же учётные данные, а точка доступа (AP) подключена к коммутатору и транслирует трафик во VLAN.

Из прошлых тем курса важно помнить два вывода:

Из статьи про безопасность пользовательских ПК: даже «правильный Wi‑Fi» не спасает, если конечные устройства заражены и уводят учётные данные.

Из статей про Layer‑2 угрозы и конфигурации: если атакующий оказался в сегменте, он пытается перехватывать/подменять (ARP/DHCP), обходить сегментацию (VLAN hopping при ошибках), или вызывать деградацию (штормы, петли). Wi‑Fi добавляет к этому радио‑уровень, где атакующий может воздействовать на соединение без физического доступа к кабелю.

Цель этой статьи — объяснить, как строится защищённый корпоративный Wi‑Fi вокруг аутентификации, шифрования и сегментации, и какие практические решения закрывают типовые модели атак.

!Как Wi‑Fi «приземляется» в проводную сеть через VLAN и где находятся границы доверия

Базовые понятия Wi‑Fi, которые нужны для безопасности

SSID — имя беспроводной сети (то, что видит пользователь в списке сетей).

BSSID — фактический идентификатор радиоинтерфейса точки доступа (обычно совпадает с MAC‑адресом радиомодуля).

AP (Access Point) — точка доступа, которая принимает Wi‑Fi кадры и передаёт их в проводную сеть.

WPA2/WPA3 — семейства механизмов защиты Wi‑Fi, включающие аутентификацию и шифрование.

PSK — общий пароль на сеть (вариант «один пароль для всех», часто называют WPA2‑Personal/WPA3‑Personal).

802.1X — портовая аутентификация, в Wi‑Fi используется как «Enterprise‑режим» через EAP.

EAP — протокол, с помощью которого выполняются методы аутентификации в 802.1X. Базовое описание: RFC 3748: Extensible Authentication Protocol (EAP).

RADIUS — сервер (и протокол), через который инфраструктура (точки доступа/контроллер) проверяет учётные данные пользователя/устройства в 802.1X.

Модель угроз для корпоративного Wi‑Fi

Wi‑Fi уязвим не только потому, что «кто-то может подключиться». Важнее то, что атакующий может:

Находиться в зоне радиопокрытия и влиять на соединение без доступа в офис.

Попытаться заставить пользователя подключиться к «похожей сети».

Попытаться обойти сегментацию (например, попасть из гостевой зоны в корпоративную) из‑за ошибок проектирования VLAN/ACL.

Типовые угрозы:

Несанкционированный доступ: подключение «чужого» устройства к корпоративной сети.

Evil Twin (ложная точка доступа): атакующий поднимает сеть с тем же SSID, чтобы перехватить попытку подключения или учётные данные.

Rogue AP (несанкционированная точка): сотрудник подключил домашний роутер к корпоративной розетке.

Атаки на доступность: помехи, перегрузка эфира, разрывы соединения.

Ошибки сегментации: гостевая сеть маршрутизируется к корпоративным подсетям, «лишние VLAN» разрешены на trunk к AP, или неверно настроены политики.

Принципиальная развилка: Personal (PSK) против Enterprise (802.1X)

Почему PSK хуже для корпоративной сети

PSK означает, что секрет один на всех. Практические последствия:

Секрет сложно защищать организационно: он неизбежно «расползается».

Уволенный сотрудник потенциально сохраняет доступ, пока пароль не сменили.

Нельзя назначить индивидуальные политики на пользователя (например, разные VLAN).

PSK допустим для ограниченных сценариев, например:

временные сети для подрядчиков при отсутствии инфраструктуры 802.1X;

IoT/устройства, которые не поддерживают 802.1X, при условии жёсткой сегментации.

Почему 802.1X (Enterprise) — базовый стандарт для корпоративного доступа

802.1X даёт то, что важно именно для локальной сети:

Индивидуальная аутентификация пользователя или устройства;

Отзыв доступа точечно (заблокировали учётную запись — доступ пропал);

Назначение политики по роли: VLAN, ACL, ограничения.

Для практического проектирования полезно использовать рекомендации NIST по WLAN:

NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks (WLANs)

Выбор WPA2/WPA3 и требования к криптографии

WPA2‑Enterprise и WPA3‑Enterprise

WPA2‑Enterprise широко поддерживается, но требует аккуратной настройки EAP и проверки сертификатов.

WPA3‑Enterprise усиливает требования к криптографии и в целом предпочтительнее, если поддерживается клиентами и инфраструктурой.

Практическая рекомендация:

Если парк устройств разношёрстный, часто используют смешанный режим (transition), но цель — планово перевести корпоративный SSID на WPA3‑Enterprise, сохранив совместимость там, где это оправдано.

Официальная справка по WPA3 от Wi‑Fi Alliance:

Wi‑Fi Alliance: WPA3

Избегайте «неопределённой» аутентификации

Опасная ошибка в Enterprise‑режиме — когда клиенты не проверяют, кому они отдают учётные данные в 802.1X.

Что это значит на практике:

Клиент должен проверять сертификат сервера (RADIUS/идентичность), иначе повышается риск Evil Twin.

Пользователь не должен «разрешать всё подряд» в диалогах доверия.

Следствие для эксплуатации: безопасность Wi‑Fi — это не только настройки на контроллере, но и профили Wi‑Fi на клиентах (MDM/GPO), где закреплены параметры проверки.

EAP‑методы: что выбрать и почему

EAP — это «контейнер», внутри которого выбирается метод аутентификации. Выбор EAP определяет устойчивость к фишингу и атакам «похожей сети».

Практически часто встречаются:

EAP‑TLS: аутентификация по сертификатам клиента и сервера.

PEAP и EAP‑TTLS: создают защищённый туннель (обычно по сертификату сервера), внутри которого передаются учётные данные (например, логин/пароль).

Рекомендация по уровню зрелости:

Для управляемых корпоративных устройств наиболее сильная модель — EAP‑TLS, потому что она снижает зависимость от пароля и устойчивее к фишингу.

Если EAP‑TLS пока недоступен, то PEAP/TTLS требуют строгого контроля профилей на клиентах и обучения пользователей не «доверять неизвестному сертификату».

Защита управляющих кадров и атаки на доступность

Даже при хорошем шифровании данных соединение можно попытаться «ломать» на уровне управления (сбросы, принудительные переподключения, деградация).

Практическая мера:

Включать защиту управляющих кадров (часто обозначается как 802.11w или MFP/PMF), чтобы усложнить часть атак на разрывы соединений и подмену управляющих сообщений.

Важно: не все клиенты одинаково поддерживают защиту управляющих кадров, поэтому режим (required/capable) выбирают с учётом совместимости.

Сегментация Wi‑Fi: SSID, VLAN и политики доступа

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

Типовая модель сегментации по ролям

Corp (корпоративный доступ): 802.1X, доступ к внутренним сервисам по принципу минимальных привилегий.

Guest (гостевой доступ): изоляция от внутренней сети, выход только в интернет (через firewall/proxy), часто captive portal.

IoT/Devices: отдельный сегмент для устройств (панели, ТВ, датчики), максимально ограниченные направления доступа.

Практическое правило: меньше SSID — проще эксплуатация и меньше «радиошума», но сегментация должна быть достаточной, чтобы не смешивать доверенные и недоверенные классы устройств.

Назначение VLAN динамически (роль вместо «жёсткого SSID»)

В Enterprise‑режиме через RADIUS можно применять модель:

один SSID для сотрудников;

VLAN и политика выдаются после аутентификации на основании группы пользователя/типа устройства.

Плюсы:

меньше SSID;

гибче управление доступом;

проще разворачивать принцип минимальных привилегий.

Риски:

возрастает важность правильной интеграции RADIUS с каталогом (например, AD) и качества атрибутов/правил.

Клиентская изоляция в гостевой сети

Даже если гостям запрещён доступ «внутрь», гостевые клиенты внутри одного сегмента могут атаковать друг друга (сканирование, попытки MITM).

Поэтому для гостевого SSID обычно включают:

изоляцию клиентов (запрет прямого обмена кадрами между клиентами на одном SSID);

фильтрацию межклиентского трафика на шлюзе/контроллере.

Это напрямую связано с темой Layer‑2: вы уменьшаете поверхность для ARP/DHCP‑подмен и локального бокового перемещения внутри гостевого домена.

Как «приземлить» Wi‑Fi в проводной сети безопасно

Точка доступа почти всегда подключена к коммутатору как uplink. Ошибка многих внедрений: рассматривать порт AP как «обычный пользовательский». На практике это инфраструктурный порт, но с особыми рисками.

Ключевые меры на стороне коммутатора (связь с прошлой статьёй про Layer‑2 конфигурацию):

Trunk только там, где он действительно нужен: если AP несёт несколько SSID/VLAN, trunk оправдан; если один SSID и одна VLAN — лучше access.

VLAN pruning: на trunk к AP разрешайте только нужные VLAN.

Native VLAN должна быть «пустой» или служебной и не использоваться для пользовательского трафика.

DHCP Snooping и DAI: проектируйте так, чтобы защита от rogue DHCP и ARP‑spoofing сохранялась и для Wi‑Fi клиентов (обычно через корректную границу trusted/untrusted в направлении к DHCP/шлюзу, а не к клиентам).

Важно: Wi‑Fi клиенты должны оставаться «недоверенными» так же, как и проводные access‑порты.

Rogue AP и «домашний роутер в розетке»

Rogue AP опасен тем, что создаёт «обходной вход» в локальную сеть:

он может раздавать доступ в корпоративную VLAN без контроля 802.1X;

он может создавать второй путь в сеть, обходя сегментацию;

он может быть непредсказуемо настроен (слабый пароль, устаревшая прошивка).

Меры защиты должны быть и организационные, и технические:

политика запрета несанкционированных точек и регулярные проверки;

мониторинг радиосреды (если есть контроллер/система WIDS/WIPS);

802.1X на проводных портах (из предыдущей темы Layer‑2): даже если кто-то подключит «домашнюю» точку, она не должна получить доступ без аутентификации.

Безопасность управления Wi‑Fi инфраструктурой

Сетевое оборудование часто атакуют через плоскость управления.

Минимальный практический стандарт для AP/контроллеров:

отдельный management VLAN для управления точками доступа;

запрет управления из пользовательских и гостевых сегментов;

централизованный учёт и контроль админ‑доступа (минимальные привилегии, MFA где возможно);

регулярные обновления прошивок AP/контроллера;

резервные копии конфигурации и контроль изменений.

Логи и мониторинг: что смотреть, чтобы замечать инциденты

Wi‑Fi инциденты часто выглядят как «странные проблемы связи», поэтому важно иметь наблюдаемость.

Что полезно собирать:

события аутентификации 802.1X на RADIUS (успехи/отказы, причины);

события контроллера/AP (подключения, роуминг, ошибки, изменения конфигурации);

список обнаруженных «чужих» SSID/BSSID в офисе (если есть радиомониторинг);

корреляцию: необычный рост отказов 802.1X, массовые переподключения, аномалии по VLAN.

Связь с темой ПК: EDR‑телеметрия на конечных устройствах помогает понять, не является ли «проблема Wi‑Fi» следствием вредоносной активности (например, попыток MITM или запуска сетевых утилит).

Минимальный практический профиль «защищённого корпоративного Wi‑Fi»

Корпоративный доступ через WPA2‑Enterprise или WPA3‑Enterprise (предпочтительно WPA3 при поддержке).

Управляемые профили подключения на клиентах с проверкой сертификатов (чтобы снижать риск Evil Twin).

По возможности EAP‑TLS для управляемых устройств.

Гостевой доступ изолирован от внутренних ресурсов и, по возможности, с межклиентской изоляцией.

IoT/устройства вынесены в отдельный сегмент с минимальными разрешениями.

На trunk к AP разрешены только необходимые VLAN, native VLAN не используется для «важного» трафика.

Управление AP/контроллером из отдельного management сегмента, с обновлениями и контролем доступа.

Включён сбор логов аутентификации и событий инфраструктуры.

Как эта тема связывается со следующими темами курса

VoIP: часто работает поверх Wi‑Fi или рядом с ним, использует отдельные voice VLAN и чувствителен к доступности и задержкам; ошибки сегментации и подмена сетевых параметров (DHCP/DNS) могут ломать телефонию.

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

Wi‑Fi становится безопасным не «галочкой WPA», а сочетанием: сильная аутентификация, правильная сегментация, корректное приземление в Layer‑2/Layer‑3 и эксплуатационная дисциплина.

Защита VoIP: сигнальный трафик, медиа и QoS-риски

VoIP в локальной сети часто воспринимают как «ещё одно приложение», но по архитектуре это отдельная коммуникационная система со своими протоколами, требованиями к задержкам и типовыми злоупотреблениями. Ошибка в сегментации или доверии (Layer‑2), слабая защита конечных устройств (ПК) или небрежная настройка Wi‑Fi могут превратить телефонию в удобный канал для:

прослушивания разговоров;

подмены вызовов и перехвата управления (call hijacking);

мошенничества с тарификацией (toll fraud);

атак на доступность (DoS), где QoS иногда усиливает эффект.

Эта статья связывает VoIP с предыдущими темами курса:

из темы про ПК: компрометация рабочей станции или софтфона даёт атакующему учётные данные и возможность запустить MITM и перехват медиа;

из тем про Layer‑2 угрозы и конфигурации: ARP‑spoofing, rogue DHCP и ошибки trunk/VLAN критичны для VoIP, потому что телефония обычно работает в тех же коммутаторах и VLAN;

из темы про Wi‑Fi: голос по Wi‑Fi добавляет риски радио‑среды и требует строгой аутентификации и сегментации.

!Карта потоков VoIP и точки применения защит

Из чего состоит VoIP-трафик

В упрощённой модели VoIP состоит из двух разных классов трафика.

Сигнализация: установление, изменение и завершение вызова, регистрация телефона, передача номера, маршрутизация.

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

Наиболее распространённая пара протоколов:

SIP для сигнализации: RFC 3261: SIP: Session Initiation Protocol

RTP для медиа: RFC 3550: RTP: A Transport Protocol for Real-Time Applications

Важно: в реальных внедрениях кроме SIP/RTP встречаются и другие компоненты (например, телефоны могут получать настройки, прошивки и адреса серверов по DHCP и через файлы конфигурации). Поэтому безопасность VoIP всегда затрагивает и инфраструктурные сервисы локальной сети.

Упрощённый поток событий при звонке

Ниже логика процесса без углубления в экзотические варианты.

Телефон получает IP‑адрес и параметры сети (обычно DHCP).

Телефон узнаёт адрес сервера телефонии (IP‑PBX/Call Manager), часто через DHCP‑опции или предварительную настройку.

Телефон проходит регистрацию на сервере (SIP REGISTER) и подтверждает свою «учётную» принадлежность.

При наборе номера происходит обмен SIP‑сообщениями, согласование кодеков и портов.

После согласования начинается передача голоса по RTP между конечными точками или через медиареле (например, SBC).

Ключевой вывод для защиты: даже если сигнализация защищена, незашифрованная медиа может быть перехвачена внутри VLAN при L2‑атаках.

Модель угроз для VoIP в локальной сети

Практически полезно разделять угрозы по тому, что именно атакуют.

Сигнализация

Медиа

Доступность и качество (QoS, задержки, джиттер)

Инфраструктура телефонии (IP‑PBX, SBC, голосовые шлюзы)

Типовые позиции атакующего:

внутри пользовательской сети (например, с компрометированного ПК);

внутри voice VLAN (например, если удалось подключиться к «голосовому» порту или обойти сегментацию);

рядом по радиусу Wi‑Fi (для voice over Wi‑Fi);

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

Общий обзор рисков VoIP систем хорошо суммирован в документе NIST: NIST SP 800-58 Rev.1: Security Considerations for Voice Over IP Systems

Защита сигнального трафика: SIP и связанные риски

Что опасно в незашищённой SIP‑сигнализации

Если SIP идёт без защиты на уровне транспорта и без корректной аутентификации, возникают риски:

подмена и перехват регистрации: атакующий пытается зарегистрироваться как чужой телефон;

перехват управления вызовом: перенаправление, удержание, сброс, перевод вызова через злоумышленника;

утечка метаданных: кто кому звонил, номера, внутренние добавочные, структура маршрутизации;

toll fraud: использование вашей телефонии для платных направлений.

Важно: даже без прослушивания медиа утечка метаданных часто является чувствительной.

Базовые меры для защиты сигнализации

SIP поверх TLS

строгая аутентификация телефонов и пользователей

минимизация доступности SIP с пользовательских сегментов

контроль и фильтрация на пограничных узлах (SBC)

На практике архитектурно часто применяют SBC (Session Border Controller) как точку контроля: нормализация SIP, защита от аномалий, rate‑limit, сокрытие внутренней топологии.

Почему защита SIP без сегментации недостаточна

Даже при использовании TLS для SIP остаются сценарии, где атакующий, оказавшись в голосовом сегменте, может:

атаковать сам сервер телефонии (сканировать сервисы, подбирать учётные данные);

мешать доступности (DoS на SIP порты);

атаковать медиа на уровне RTP, если оно не шифруется.

Поэтому защита сигнализации всегда должна сопровождаться сетевыми границами доступа.

Защита медиа: RTP и шифрование голоса

Почему RTP без шифрования опасен

RTP по определению рассчитан на доставку с минимальными задержками и не включает шифрование как обязательную часть. В локальной сети это означает:

при перехвате трафика (например, через ARP‑spoofing) разговор можно восстановить;

при подмене атакующий может инжектировать или изменять голосовой поток;

при ошибках зеркалирования/мониторинга или компрометации коммутатора голос может утекать неочевидным образом.

Эта часть напрямую связана с темой Layer‑2 атак: ARP‑spoofing и rogue DHCP могут превратить «обычный доступ в VLAN» в устойчивый MITM.

SRTP как базовый инструмент

Для защиты медиа применяют SRTP: RFC 3711: The Secure Real-time Transport Protocol (SRTP)

SRTP обеспечивает:

шифрование содержимого медиа;

контроль целостности;

защиту от повторов в пределах механизма SRTP.

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

Как согласуются ключи для SRTP

Есть несколько подходов, но с точки зрения локальной сети важно понимать риск:

если ключи или параметры для SRTP передаются так, что их можно перехватить (например, в незашифрованной сигнализации), то SRTP теряет смысл;

безопасное согласование ключей часто строится вокруг защищённой сигнализации и/или специальных механизмов.

Один из распространённых вариантов для WebRTC и ряда систем — DTLS‑SRTP: RFC 5764: Datagram Transport Layer Security (DTLS) Extension to Establish Keys for SRTP

Архитектура сегментации VoIP: voice VLAN, управление и доверие

Почему VoIP почти всегда выделяют в отдельный сегмент

Выделение voice VLAN нужно не только для QoS, но и для безопасности:

проще ограничить, кто может общаться с IP‑PBX, шлюзами и службами provisioning;

уменьшается поверхность для L2‑атак со стороны пользовательских ПК;

проще мониторить аномалии (сканирование, необычные направления, всплески SIP).

Типовая сегментация включает:

voice VLAN для телефонов и медиатрафика;

data VLAN для ПК;

management VLAN для управления сетевым оборудованием и, при необходимости, управления телефонией;

отдельные зоны для серверов телефонии (в зависимости от масштаба и модели доверия).

Особый риск: телефон как «мост» для ПК

Распространённая схема: IP‑телефон подключён в розетку, а ПК подключён в порт на телефоне. Телефон при этом фактически участвует в разделении трафика.

Риски:

неправильная настройка порта коммутатора может дать ПК доступ в voice VLAN;

атакующий может подменить теги VLAN или использовать ошибки конфигурации;

можно попытаться обойти контроль доступа, используя «легитимную» физическую точку.

Защита строится комбинацией:

правильной настройки access‑порта с поддержкой voice VLAN на коммутаторе;

802.1X (где возможно) для контроля подключаемых устройств;

L2‑защит из прошлой темы: DHCP Snooping, DAI, Port Security, BPDU Guard.

!Почему схема телефон+ПК требует аккуратной L2-конфигурации

Защита инфраструктурных зависимостей: DHCP, DNS, provisioning

VoIP почти всегда зависит от базовых сервисов локальной сети. Отсюда вытекают практические риски.

Rogue DHCP может выдать телефону неверный шлюз или DNS и направить трафик через атакующего.

Телефон может получить адрес сервера конфигурации и затем скачать настройки, которые раскрывают учётные данные или меняют параметры регистрации.

Подмена DNS может отправить телефон или софтфон на поддельный сервер.

Меры из темы L2‑защиты здесь работают напрямую:

DHCP Snooping уменьшает шанс rogue DHCP внутри сегмента.

Dynamic ARP Inspection (DAI) усложняет ARP‑spoofing и MITM.

IP Source Guard ограничивает подмену IP на порту.

Дополнительно на уровне архитектуры полезно:

ограничить доступ телефонов только к нужным адресам (IP‑PBX, provisioning, NTP, DNS) через ACL/фаервол;

отделить provisioning‑сервисы от пользовательских сегментов;

контролировать изменения конфигураций телефонии и хранение секретов.

QoS в VoIP: зачем нужен и какие появляются риски

Зачем VoIP нужен QoS

Голос чувствителен к:

задержке;

вариации задержки (джиттер);

потерям пакетов.

QoS в локальной сети помогает:

уменьшить задержки и потери для голоса при перегрузках;

обеспечить предсказуемость качества.

Где QoS становится риском безопасности

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

Типовые риски:

приоритизация вредоносного трафика: атакующий помечает свои потоки как «голосовые», и сеть начинает обслуживать их быстрее;

DoS на высоком приоритете: перегрузка очередей, предназначенных для голоса, приводит к деградации телефонии;

размывание границ доверия: если на пользовательских портах разрешено «как пришло, так и передали», QoS-метки становятся каналом обхода политики.

Практика: граница доверия для QoS

Без привязки к конкретному вендору логика обычно такая:

доверять QoS‑маркировке можно только там, где устройство считается управляемым и ожидаемым (например, порт с телефоном);

на пользовательских ПК‑портах QoS‑метки обычно перезаписывают или игнорируют;

на uplink’ах и в ядре сети применяют согласованную политику очередей.

Здесь полезна та же идея, что и в L2‑безопасности: чётко определить trusted и untrusted.

Защита от атак на доступность: SIP/RTP DoS и эксплуатационные меры

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

ограничение скорости (rate‑limit) на границах, где это уместно (особенно на SBC и на L3‑границах);

фильтрация доступа к портам SIP только от нужных узлов;

мониторинг аномалий: всплески регистраций, INVITE, ошибок аутентификации;

выделение ресурсов и контроль очередей QoS;

готовый план локализации: быстро отключить проблемный порт/VLAN, как и в L2‑инцидентах.

Важно связать это с темой «безопасность ПК»: компрометированный ПК внутри сети может генерировать как L2‑атаки, так и SIP‑флуд, поэтому EDR и ограничение прав уменьшают риск внутренних DoS.

Минимальный практический профиль «защищённого VoIP» в локальной сети

Ниже набор, который можно использовать как ориентир при проектировании.

Сегментация телефонии: отдельная voice VLAN и ограничения доступа между VLAN.

Защита L2 на пользовательских и голосовых access‑портах: DHCP Snooping, DAI, Port Security, STP‑защиты.

Защита сигнализации: SIP с аутентификацией, по возможности SIP поверх TLS.

Защита медиа: SRTP и безопасное согласование ключей.

Контроль provisioning и зависимостей: ограничить доступ к сервисам конфигурации, защищать DNS/DHCP, контролировать изменения.

QoS с правильной границей доверия: доверять маркировке только там, где это оправдано.

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

Как эта тема связывается со следующей частью курса

SAN и системы хранения обычно требуют ещё более строгой дисциплины сегментации и контроля доступа, чем VoIP: там цена ошибки часто измеряется масштабом утечки данных или простоя сервисов. Логика, которую мы закрепили на VoIP, напрямую переносится на SAN:

отдельные сегменты и минимально необходимые связи;

чёткие границы доверия;

защита плоскости управления;

мониторинг аномалий и готовность к быстрой изоляции.

Безопасность SAN: изоляция, доступ, шифрование и мониторинг

SAN (Storage Area Network) — это специализированная сеть для доступа серверов к блочным устройствам хранения (дисковым массивам, полкам, виртуализированным LUN). В отличие от «обычной» локальной сети пользователей, SAN часто обслуживает самые критичные данные и самые чувствительные к задержкам рабочие нагрузки (виртуализация, базы данных, кластеры). Цена ошибки здесь обычно выше: неверная изоляция или контроль доступа может привести не просто к компрометации одного ПК, а к массовой утечке, порче данных или остановке сервисов.

Эта статья завершает логическую цепочку курса:

Из темы про ПК: компрометация сервера или админской станции превращается в риск доступа к хранилищам.

Из тем про Layer-2: если SAN построен поверх Ethernet (iSCSI), то ARP/DHCP-подмены, ошибки trunk/VLAN и «доверчивые» L2-сегменты могут ударить по хранилищам.

Из темы про Wi‑Fi: плоскость управления оборудованием хранения и коммутаторов не должна быть доступна через «широкие» зоны доступа.

Из темы про VoIP: мы уже закрепили принцип жёсткой сегментации и границ доверия; для SAN он ещё строже.

!Общая модель изоляции SAN от пользовательских сегментов и выделение отдельного управления

Что именно нужно защищать в SAN

В SAN полезно различать несколько «слоёв», потому что меры контроля на них разные.

Транспорт и коммутация: Ethernet (для iSCSI) или Fibre Channel fabric.

Идентификация инициаторов и целей: кто подключается к кому (сервер-инициатор и порт/таргет СХД).

Экспорт блочных устройств: какие LUN доступны какому хосту.

Плоскость управления: веб/SSH/API доступ к коммутаторам и СХД.

Данные: конфиденциальность и целостность данных в полёте и на диске.

Ключевой принцип SAN-безопасности: доступ к блочным устройствам не должен зависеть от «доверия к локалке». Он должен быть ограничен на нескольких уровнях одновременно.

Типы SAN в корпоративной практике и связанные риски

iSCSI поверх Ethernet

iSCSI — это протокол, который переносит SCSI-команды по IP-сети. Он часто строится на выделенных VLAN и коммутаторах, но физически может быть тем же классом оборудования, что и «обычный» LAN.

Базовый стандарт iSCSI: RFC 3720: Internet Small Computer Systems Interface (iSCSI).

Типовые риски iSCSI, которые пересекаются с темами курса:

риски Layer-2 внутри storage VLAN (ARP-spoofing, rogue DHCP при ошибках дизайна, штормы);

«случайный» маршрут из пользовательской сети в storage VLAN из-за неправильных ACL/маршрутизации;

смешивание трафика данных хранения и трафика управления;

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

Fibre Channel (FC)

Fibre Channel обычно физически и логически отделён от IP-сети. Это плюс для изоляции, но не означает «безопасно само по себе».

Типовые риски FC:

неправильный zoning (слишком широкая видимость устройств);

слабый контроль доступа к управлению FC-коммутаторами;

ошибки эксплуатации, которые приводят к массовому воздействию на fabric.

Изоляция: самый сильный контроль, который вы можете себе позволить

Минимальный стандарт сегментации SAN

Практически устойчивый дизайн включает раздельность по трём направлениям.

Раздельность данных пользователей и данных хранения

Раздельность плоскости управления и плоскости данных

Раздельность путей (redundancy) для отказоустойчивости

Для iSCSI это часто выглядит так:

отдельные storage VLAN (часто два: для путей A и B);

отсутствие маршрутизации между user VLAN и storage VLAN;

доступ к storage VLAN только с определённых серверных интерфейсов;

отдельный management VLAN для СХД и коммутаторов.

Для FC это обычно:

два независимых fabric (fabric A и fabric B);

хосты и СХД имеют по два подключения (в разные fabric);

управление коммутаторами и СХД вынесено в отдельную сеть.

Почему «просто VLAN» недостаточно

Из тем про Layer-2 мы уже знаем, что VLAN — это логическая изоляция, но ошибки конфигурации и неправильные trunk’и могут нарушить границы. Для SAN это особенно критично.

Практические требования к «приземлению» SAN на коммутаторах (для iSCSI и management):

access-порты для хостов и СХД должны быть строго access, а trunk — только там, где он объективно нужен;

trunk должен нести только необходимые VLAN;

защита от L2-подмен (например, DHCP Snooping/DAI) включается осмысленно и тестируется, если storage VLAN использует DHCP (в зрелых средах адреса часто статические, поэтому важнее контроль L3/L4 и физическая изоляция);

storm-control и защита от петель важны не меньше, чем в пользовательских VLAN, потому что «шторм» в storage сегменте быстро превращается в отказ приложений.

Контроль доступа: кто может видеть СХД и какие LUN ему доступны

В SAN почти всегда применяют несколько механизмов контроля. Смысл не в том, чтобы выбрать один «самый сильный», а в том, чтобы ошибки одного слоя не приводили к катастрофе.

Zoning в Fibre Channel

Zoning — это правило на уровне FC-fabric, которое определяет, какие порты (WWPN) вообще могут «видеть» друг друга.

Плюс: ограничивает область видимости и уменьшает риск «лишних» соединений.

Минус: это не финальный контроль доступа к данным, а скорее контроль связности.

Практика:

использовать принцип минимальной видимости: хост видит только нужные порты СХД;

избегать «всех со всеми» зон;

разделять зоны по назначению (кластеры, среды, критичность).

LUN masking / Host mapping на СХД

LUN masking (часто называют host mapping) — это правило на самом массиве, которое определяет, какие LUN экспортируются конкретному хосту или группе хостов.

Это критичный контроль, потому что даже при ошибке в zoning (или в IP-доступе) хост не должен получить чужие тома.

Обычно строится на идентификаторах инициатора (в FC это WWPN, в iSCSI — IQN) и группах хостов.

Аутентификация в iSCSI

В iSCSI поверх IP дополнительно применяют аутентификацию (в зависимости от реализации):

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

Важно понимать границу:

аутентификация в iSCSI не заменяет изоляцию сети;

секреты CHAP должны храниться и ротироваться как учётные данные, иначе их утечка на сервере превращается в «ключ от SAN».

Контроль доступа к плоскости управления

Плоскость управления — один из самых частых источников «большого инцидента» в SAN, потому что через неё можно:

сменить экспорт томов;

отключить порты;

удалить снапшоты;

изменить политику репликации.

Минимальный практический стандарт:

управление СХД и SAN-коммутаторами только из management VLAN;

доступ администратора только через jump-host (bastion) с усиленной аутентификацией;

запрет управления из пользовательских VLAN и тем более из guest;

принцип наименьших привилегий и раздельность ролей (админ СХД не обязан быть админом всего домена);

журналирование действий администраторов.

Шифрование: данные в полёте и данные на диске

Шифрование данных на диске

Для SAN наиболее типичный механизм — шифрование на стороне массива (иногда с аппаратной поддержкой).

Практический смысл:

защищает от утечек при физической утрате дисков, их замене, возврате по гарантии;

снижает риски «офлайн-доступа» к данным.

Ключевой организационный вопрос: управление ключами.

где хранятся ключи;

кто имеет право на операции, связанные с ключами;

что происходит при сбое системы управления ключами.

Шифрование данных в сети

В SAN важно не полагаться на то, что сеть «внутренняя, значит безопасная». Мы уже видели в теме Layer-2, как атаки внутри сегмента могут превратить локальную сеть в среду для перехвата и подмены.

Для iSCSI это означает:

если трафик потенциально может быть перехвачен (ошибка сегментации, SPAN, компрометация порта), появляется смысл в шифровании на более высоком уровне;

в реальности выбор механизма зависит от платформы (вендор СХД, ОС хоста) и требований к производительности.

Практическая рекомендация: если шифрование «в полёте» трудно внедрить в SAN без потерь производительности, тогда усиливайте компенсирующие меры:

физическая изоляция storage-сегмента;

строгий контроль маршрутизации и ACL;

мониторинг аномалий;

минимизация числа узлов, имеющих доступ к storage VLAN.

Доступность и устойчивость: безопасность через предсказуемость

SAN часто ломается не «красивой атакой», а сочетанием ошибки и нагрузки. Поэтому часть мер безопасности здесь — это инженерная дисциплина.

Разделение путей и multipathing

Multipathing — это механизм на хостах, который позволяет использовать несколько путей к одному и тому же LUN.

Практические преимущества для безопасности и устойчивости:

отказ одного коммутатора/линка не превращается в отказ сервиса;

проще изолировать проблемный сегмент (например, fabric A) без полной остановки.

QoS и приоритизация

В отличие от VoIP, где QoS часто строят вокруг классов «голос/не голос», для SAN по Ethernet (iSCSI) риск иной:

если storage и пользовательский трафик смешаны, то перегрузка «обычной» сети может уничтожить производительность дисковой подсистемы;

злоумышленник в user VLAN может создать нагрузку, которая косвенно влияет на storage.

Решение по умолчанию — не «настраивать приоритеты», а не смешивать трафик:

отдельные коммутаторы или отдельные VLAN без маршрутизации;

отдельные uplink’и и порты;

предсказуемая полоса и буферизация.

Мониторинг и аудит: что собирать, чтобы замечать атаки и ошибки

SAN-инциденты часто выглядят как «упала производительность» или «хосты зависают». Поэтому мониторинг должен покрывать и безопасность, и эксплуатацию.

Что мониторить на уровне сети

изменения конфигурации SAN-коммутаторов;

flapping портов (порт постоянно up/down);

ошибки интерфейсов, дропы, перегрузка;

штормы broadcast/multicast (для iSCSI VLAN);

неожиданные MAC/ARP-анномалии в storage VLAN (если это применимо к дизайну).

Что мониторить на уровне СХД

события аутентификации и административных действий;

изменения экспортов томов (host mapping, LUN masking);

создание/удаление снапшотов и политик репликации;

состояние контроллеров, деградации RAID, ошибки дисков;

необычные пики IOPS/latency, которые могут быть как признаком атаки, так и признаком ошибки приложения.

Что мониторить на уровне хостов

появление новых дисков/LUN (особенно если это неожиданно);

ошибки multipath, деградация путей;

новые iSCSI-сессии и изменения конфигурации инициатора;

действия администраторов на серверах, которые могут повлиять на доступ к SAN.

Почему важен аудит изменений

Для SAN типовой «опасный сценарий» — это не только внешняя атака, но и неправильное изменение:

случайно расширили зону видимости;

ошибочно замапили LUN «не тому» хосту;

открыли доступ к управлению из не того сегмента.

Поэтому нужны:

контроль изменений (кто, что, когда изменил);

резервные копии конфигурации и понятная процедура отката;

раздельность ролей, где это возможно.

Минимальный практический профиль «защищённого SAN»

SAN (iSCSI или FC) изолирован от пользовательских сегментов; маршрутизация к storage запрещена по умолчанию.

Плоскость управления СХД и коммутаторами вынесена в отдельный management сегмент, доступ через jump-host.

Контроль доступа сделан на нескольких слоях:

- FC zoning (для FC); - LUN masking/host mapping на СХД; - iSCSI-аутентификация (например, CHAP) там, где это оправдано.

Данные на диске шифруются, а управление ключами оформлено как процесс.

Отказоустойчивость обеспечена раздельными путями (fabric A/B или storage VLAN A/B) и multipathing.

Включён мониторинг сети, СХД и хостов, а также аудит изменений конфигурации.

Как SAN завершает картину курса

Если обобщить весь курс одной мыслью, то она звучит так: локальная сеть становится безопаснее не от одной технологии, а от правильно расставленных границ доверия.

На ПК мы уменьшали вероятность компрометации и кражи учётных данных.

На Layer-2 мы ограничивали «внутрисегментные» атаки и делали порты недоверенными по умолчанию.

В Wi‑Fi мы строили сильную аутентификацию и сегментацию поверх радио‑среды.

В VoIP мы защищали сигнализацию/медиа и дисциплинировали QoS-доверие.

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