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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Се

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

Сетевой мост

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

Сетевой мост

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

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

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

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

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

Заключение

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

© Habrahabr.ru