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

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

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, затем отправляет запрос на прокси сервер. Прокси сервер для соблюдения трехуровневой архитектуры сети размещаем в демилитаризованной зоне. Прокси сервер по результату анализа либо разрешает взаимодействие и шлет запрос к указанному сервису в сети интернет, либо возвращает отправителю ответ с указанием причины.

Важно

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

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

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

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

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

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

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

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

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

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

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

Пояснение к схеме

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

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

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

Пояснение

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

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

Пояснения

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

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

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

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

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

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

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

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

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

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

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

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

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

Пояснения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пояснения

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

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

Сетевой мост

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

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

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

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

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

Заключение

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