Сегментация сети для самых маленьких: рабочие станции +12


Ссылки на другие части

Все статьи цикла:

  1. Трехуровневая архитектура;

  2. Рабочие станции (эта статья).

Оглавление

Оглавление

Введение

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

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

Внутренний доступ работников

По статистике основным нарушителем является работник компании. C точки зрения межсетевого экранирования мы должны максимально ограничивать его в доступах. Самый простой способ реализации минимальных привилегий на сетевом уровне - рабочие станции работников помещать в отдельной зоне безопасности. Назовем её - USERS.

USERS - зона безопасности, предназначенная для размещения сетевых сегментов содержащих рабочие станции.

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

Как это выглядит с точки зрения простейшего зонирования:

Сегмент работников
Сегмент работников

Основная угроза

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

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

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

  1. обычные работники (кассиры, операционисты, бухгалтеры, менеджеры, аналитики и т.п.);

  2. привилегированные работники (руководство компании, топ менеджеры и т.п.);

  3. работники с повышенными правами (администраторы ОС, администраторы баз данных, администраторы приложений, DevOps-инженеры, эникейщики/сервис-инженеры, администраторы сетевого оборудования и т.п.).

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

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

Сегментирование рабочих станций работников
Сегментирование рабочих станций работников

В данном случае предполагаем:

  1. кассиры, операционисты, бухгалтеры и директор работают в некой CRM системе и им всем требуется сетевой доступ до нее;

  2. веб приложение позволяет работникам напрямую работать без промежуточного сервера;

  3. доступ от сетевых администраторов не отображен, так как не отображено сетевое оборудование;

  4. эникейщики/сервис-инженеры могут иметь доступ по RDP либо иному протоколу управления на все рабочие станции для их сопровождения.

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

Домен

Поскольку эникейщики это те единственные работники, что имеют доступ в другие сетевые сегменты - это одна из оставшихся крупных точек распространения атаки от которой мы и защищались. Другими являются администраторы системы управления рабочими станциями и учетными записями работников - контроллера домена в случае рабочих станций под управлением операционных систем семейства Windows NT. Завладев учетной записью администратора системы управления учетными записями, злоумышленник сможет под учетной записью администратора системы управления администрировать все то, что мы разрешим в системе. Защита от таких атак в лекции не рассмотрена так как это уже не касается сегментации.

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

Добавим контроллер домена на схему:

Домен контроллер
Домен контроллер

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

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

  1. компрометация рабочей станции эникейщика и дальнейшая атака на все остальные рабочие станции (2);

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

Минимизация горизонтального перемещения
Минимизация горизонтального перемещения

К сожалению, получение прав администратора домена либо другой менее привилегированной учетной записи возможно при помощи других атак. Причиной является слабая защита на других уровнях модели OSI, например, путем реализации атаки Pass-the-hash - дампинг из памяти пароля/хэша пароля подключившегося удаленно работника и дальнейшее подключение к контроллеру домена либо иным рабочим станциям с полученным паролем/хешем пароля в зависимости от способа аутентификации в домене.

Посмотрим как это выглядит:

Атаки с учетом атак на других уровнях модели OSI
Атаки с учетом атак на других уровнях модели OSI
Важно

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

Доступ работников во внешние сети

Существует 2 основных вектора атаки на любую компанию:

  1. серфинг в сети интернет;

  2. пользование сервисом электронной почты.

Серфинг в сети интернет

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

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

Размещение прокси сервера
Размещение прокси сервера

Как видим, браузер вместо того, чтобы направлять наш HTTPS либо HTTP запрос напрямую в сеть интернет, он меняет порт с 443 и 80 на 3128, затем отправляет запрос на прокси сервер. Прокси сервер для соблюдения трехуровневой архитектуры сети размещаем в демилитаризованной зоне. Прокси сервер по результату анализа либо разрешает взаимодействие и шлет запрос к указанному сервису в сети интернет, либо возвращает отправителю ответ с указанием причины.

Важно

Как видим, в схеме допущено нарушение трехуровневой архитектуры сети: изображен доступ из DB в DMZ.

В данном случае вы вольны с учетом оценки рисков основывающейся в том числе на:

  1. наличии иных средств защиты;

  2. уровня зрелости системы защиты и реагирования;

  3. других факторов, например, регламентов, политик, инструкций;

принять решение о возможности нарушения трехуровневой архитектуры сети в случае если один из сетевых устройств к или от которого требуется доступ относится к поддерживающим ИТ - сервисам. Заметили ли вы, что с контроллером домена на самом деле аналогичная ситуация?

Удаленный доступ работников

Для удаленного доступа чаще всего применяется технология VPN. В качестве VPN шлюза может использоваться как сам межсетевой экран с функционалом VPN-шлюза, так и отдельное сетевое устройство. Рассмотрим оба варианта.

Удаленный доступ через VPN-шлюз

VPN-шлюз на межсетевом экране

Поскольку VPN-шлюз может быть реализован на межсетевом экране, рассмотрим схему уровня L3 (схема физического соединения устройств), представим максимальное количество маршрутизаторов и коммутаторов которое только может быть:

2 базовых варианта удаленного доступа при помощи VPN
2 базовых варианта удаленного доступа при помощи VPN
Пояснение к схеме

черными линиями изображены физические провода;
синими стрелками изображены сетевые доступы.

Как видно из схемы, доступ через VPN-канал предполагает удаленное подключение с удаленной рабочей станции, обычно это ноутбук. Подключение выполняется на терминальный сервер (вариант 1) либо на рабочую станцию в сегменте USERS (вариант 2).

Возможен и такой вариант схемы:

Отсутствие пограничного маршрутизатора
Отсутствие пограничного маршрутизатора
Пояснение

Вместо пограничного маршрутизатора имеется только межсетевой экран

И такой вариант схемы:

Сетевой мост при VPN доступе
Сетевой мост при VPN доступе
Пояснения

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

Сетевой мост - это в данном случае не плохое решение. Плохо когда у одного сервера 2 сетевых интерфейса, один используется для доступа к веб приложению запущенному на сервере, а другой к базе данных на этом же сервере. То есть фактически разделения сервиса на два сервера не реализовано, и архитектура сервиса уже не будет трехуровневой, а будет двухуравневой или вообще одноуровневой если еще и веб сервер будет размещен на этом же сервере. Например, при анализе правил межсетевого экранирования видно все необходимые сетевые доступы:

  1. из интернета на IP адрес в DMZ;

  2. от IP в DMZ к IP в APP;

  3. от IP а APP к IP в DB.

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

Отдельный VPN-шлюз

Еще один вариант при котором VPN сервер размещается на отдельном сетевом устройстве:

Удаленный доступ через отдельный VPN шлюз
Удаленный доступ через отдельный VPN шлюз

Как видно, возможно большое количество вариантов подключения и даже другое, которое не предложено. Схема ограничивается лишь вашей фантазией, производительностью сети под нагрузками, DDoS атаками, функционала и функций безопасности используемого сетевого оборудования.

При такой схеме, если основной МЭ ляжет под DDoS атакой, удаленный доступ сохранится через отдельный VPN шлюз.

Именно поэтому на уровень отображения схем c физическими соединениями я в своих статьях не опускаюсь.

VPN-шлюз как отдельное сетевое устройство

Последний рассматриваемый вариант:

Отдельный сетевой VPN-шлюз
Отдельный сетевой VPN-шлюз
Пояснения

Буквами А, Б, В показаны возможные варианты коммутации оборудования.

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

Иные способы удаленного доступа

Могут быть и другие варианты, например, при помощи VDI-инфраструктуры. Оставим данный способ для домашнего изучения, слишком много рисовать :)

Гостевой доступ

Гостевой доступ на инфраструктуре компании

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

В таком случае строится такая логическая схема сети:

Логическая схема гостевого доступа
Логическая схема гостевого доступа

Из схемы следует:

  1. гостевым сетям нужен доступ только в Интернет;

  2. максимум таким сетям возможен доступ только в демилитаризованную зону к каким-то серверам, например, тем что опубликованы в Интернет либо тем, что недоступны из Интернета, но доступны гостям (какие-то демонстрационные комплексы).

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

В данном случае требуется продумать технический механизм невозможности получения работниками доступа к гостевой сети, например, настроив проверку устройства на "корпоративность": если к гостевой сети подключается корпоративное устройство - отклонить подключение. К сожалению, работники будут пробовать строить сетевые мосты - проводом подключаться в сеть компании, а по Wi-Fi в гостевую сеть. Цель простая - иметь доступ к внутренним ресурсам и полный доступ в Интернет в обход прокси сервера.

Учтем DNS-взаимодействие и рассмотрим схему выше на уровнях OSI ниже:

Се
Се
Пояснения

Для гостевой сети настраиваем внешний DNS-сервер, чтобы не анонсировать устройствам наши внутренние DNS-зоны и не раскрывать топологию. Предложение: использовать DNS-сервер от Яндекс, предназначенный для использования детьми.

Как видим, внутрь сети скорее всего потребуется HTTPS к серверам в демилитаризованной зоне.

Сетевой мост

Теперь покажем как выглядит сетевой мост о котором шла речь чуть выше:

Сетевой мост
Сетевой мост

Гостевой доступ на инфраструктуре провайдера

Чуть более безопасным для малых компаний является предоставление Wi-Fi через отдельный канал, предоставленный провайдером:

Отдельная гостевая сеть
Отдельная гостевая сеть

В данном случае, провайдер даже может взять на себя аутентификацию пользователей в гостевой сети, например, по номеру телефона через Captive portal.

Гостевые же устройства будут для сети компании устройствами, идущими из сети Интернет, а не из инфраструктуры компании.

Заключение

Продолжать можно бесконечно, какого примера не хватило вам?




Комментарии (13):

  1. avelor
    /#24985316 / +3

    Спасибо за статью, но чуть включу зануду :))

    Сегментация населения по l2 чудесна.. когда применима :( часто красиво нарисованное ломается о реальность и вагоне исключений, и тут на помощь приходят всякие механизмы, которые условно можно отнести к ngfw - фаерволить не по сетям, но по пользователям (группам в которых пользователь состоит).. да и ngfw поможет (немношк) избавится от легаси-прокси, с реализацией реально прозрачной работы. С работой через mitm или хотя бы по sni.

    А для подключения инженеров к рабочим станциям лучше использовать не доменные учётки, а локальные с уникальными паролями (laps).

    И ещё - стоит обязательно вдумчиво продумывать адресацию, чтобы использовать аггрегацию сетей для классической фильтрации. Например, сегмент users 192.168.0.0/23, в который входит sales с 192.168.0.0/24 и buh 192.168.1.0/24. Вдумчивый адресный план поможет с классическим фаерволеньем без моднейших nac и ngfw систем, или удачно их дополнит.

    • Protos
      /#24985914

      Позанудствую, в огромном количестве компаний России после начала СВО, NGFW более не доступны и ни о каких доступах по группам пользователей к сожалению речь более не идет.

      • avelor
        /#24985932

        ну, есть отечественные вендоры, есть cisco plr для тех, кому близок по духу вольный дух Тортуги%) ну и можно изобретать всякое, например 802.1x c радиусом и атрибутами cisco-av-pair (ессно нужно оборудование с поддержкой этого дела), каптивы..

        • Protos
          /#24990928

          Какой отечественный вендор умеет управление доступами при помощи групп AD?

          • avelor
            /#24990970

            емнип тот же usergate мог (с агентом), ideco - через rpc до контроллеров домена...

  2. dmitrye1
    /#24985792

    Архитектура корпоративных приложений - клиент-сервер, исключение VoIP(там есть и P2P). Соответственно на уровне доступа пользователей мы имеем возможность пропускать IP трафик от пользователя к серверам, пропустить RTP VoIP ( UDP порты > 16k) и icmp для диагностики на всех, запрет на приватные адреса, разрешить остальной трафик (Интернет). IP адреса серверов должны находиться в сети с некой широкой маской, охватывающей все серверные сегменты. Получаем простое стандартное правило фильтрации, применимое для сетевого оборудования уровня для L3 коммутации точно. В итоге взаимодействия между пользовательскими сетевыми сегментами исключены. Если оборудование уровня доступа пользователей имеет возможность фильтрации на физическом порту, то мы исключим опасные межпользовательские взаимодействия даже внутри сегмента. Исключения для сетевиков, безопасники, группы обслуживания АРМ(хотя лучше их пускать через терминальный сервер). Возлагать больше функций на сетевое оборудование уровня пользовательского доступа не стоит, мое мнение( если не вспоминать про 802.1x). Выход в Интернет или защита серверов это другая проблема, тут могут быть ngfw, поднять ipsec/vpn во внутренней сети, мутить с сертификатами...
    Практический результат - все вирусные эпидемии за десятилетия имели минимальное воздействие.

    Если не лень читать. Из прошлого опыта на очень больших масштабах ( более 14к пользователей). Классификация ПК и переключение в разные сетевые сегменты является крайне сложным и трудоемким процессом, постоянно вызывающим нарекания клиентов. На больших масштабах, распределенных командах, востребованности WiFi, текучки кадров, наличие опенспейсов, постоянного перемещения сотрудников и явления всяких прочих исключений это будет мало применимо. Была куча побочных эффектов: сложные коммуникации между командой сетевиков и командой обслуживания ПК, большое количество виланов на сетевом оборудовании уровня доступа, требования пробрасывать вилан из здания в здание для распределенных команд (вот за это сетевики имеют моральное права разок дать в морду за будущие хлопоты и нервы).

  3. iddqda
    /#24986158 / +1

    ИМХО Cybersecurity evangelist (ваша подпись) должен ZeroTrust Network и EndPoint Security проповедовать, а не вот это вот махровое ДМЗ и однообразные, но при этом неграмотные картинки
    Да, картинки неграмотные:

    • коммутатор и маршрутизатор обозначаются одним символом и при этом подключены в произвольном порядке в котором никакой логики не прослеживается

    • пограничный маршрутизатор стоит за файрволом

    • впн концентратор получает от провайдера собственный интернет отдельно от бордера. Наверно и оплачивается отдельно?

    • что это за виды подключения А,Б,В? Да, там ниже есть пояснение, но оно ничего не поясняет

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

    ну и текст тоже не помешает спелчекером полирнуть

  4. inhell
    /#24990914 / +2

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

    • inhell
      /#24991304 / +1

      опа.... эммм

      Прошу прощения сработала автозамена ,)

      под "пресная" прошу читать "прекрасная"

  5. Simpre_falta_algo
    /#24990918

    А в порядке бреда: доступ в интернет с ПК сотрудника с повышенным доступом на внутренние бд и т.п. через его мобильную точку доступа как отражен у вас на схемах?? И где обратная связь? Кто-то отслеживает течение и выпады?

    • Protos
      /#24990922

      через его мобильную точку доступа как отражен у вас на схемах?

      Это к теме межсетевого экранирования не относится, как бы вы отразили это на картинке?

    • Protos
      /#24990926

      Кто-то отслеживает течение и выпады?

      Данные термины мне к сожалению не знакомы

    • evr1ka
      /#24992826

      Уважаемый, можете чуть расшифровать, что такое "Течение" и "Выпады". Заранее спасибо. Логически что-то понятное, но не слышал таких "жаргонизмов" ранее