© Кившенко Алексей, 1880
Данная статья содержит обзор пяти вариантов решения задачи организации доступа к сервисам корпоративной сети из Интернет. В рамках обзора приводится анализ вариантов на предмет безопасности и реализуемости, что поможет разобраться в сути вопроса, освежить и систематизировать свои знания как начинающим специалистам, так и более опытным. Материалы статьи можно использовать для обоснования Ваших проектных решений.
При рассмотрении вариантов в качестве примера возьмем сеть, в которой требуется опубликовать:
- Корпоративный почтовый сервер (Web-mail).
- Корпоративный терминальный сервер (RDP).
- Extranet сервис для контрагентов (Web-API).
Вариант 1. Плоская сеть
В данном варианте все узлы корпоративной сети содержатся в одной, общей для всех сети («Внутренняя сеть»), в рамках которой коммуникации между ними не ограничиваются. Сеть подключена к Интернет через пограничный маршрутизатор/межсетевой экран (далее — IFW).
Доступ узлов в Интернет осуществляется через NAT, а доступ к сервисам из Интернет через Port forwarding.
Плюсы варианта:
- Минимальные требования к функционалу IFW (можно сделать практически на любом, даже домашнем роутере).
- Минимальные требования к знаниям специалиста, осуществляющего реализацию варианта.
Минусы варианта:
- Минимальный уровень безопасности. В случае взлома, при котором Нарушитель получит контроль над одним из опубликованных в Интернете серверов, ему для дальнейшей атаки становятся доступны все остальные узлы и каналы связи корпоративной сети.
Аналогия с реальной жизнью
Подобную сеть можно сравнить с компанией, где персонал и клиенты находятся в одной общей комнате (open space)
© hrmaximum.ru
Вариант 2. DMZ
Для устранения указанного ранее недостатка узлы сети, доступные из Интернет, помещают в специально выделенный сегмент – демилитаризованную зону (DMZ). DMZ организуется с помощью межсетевых экранов, отделяющих ее от Интернет (IFW) и от внутренней сети (DFW).
При этом правила фильтрации межсетевых экранов выглядят следующим образом:
- Из внутренней сети можно инициировать соединения в DMZ и в WAN (Wide Area Network).
- Из DMZ можно инициировать соединения в WAN.
- Из WAN можно инициировать соединения в DMZ.
- Инициация соединений из WAN и DMZ ко внутренней сети запрещена.
Плюсы варианта:
- Повышенная защищённость сети от взломов отдельных сервисов. Даже если один из серверов будет взломан, Нарушитель не сможет получить доступ к ресурсам, находящимся во внутренней сети (например, сетевым принтерам, системам видеонаблюдения и т.д.).
Минусы варианта:
- Сам по себе вынос серверов в DMZ не повышает их защищенность.
- Необходим дополнительный МЭ для отделения DMZ от внутренней сети.
Аналогия с реальной жизнью
Данный вариант архитектуры сети похож на организацию рабочей и клиентской зон в компании, где клиенты могут находиться только в клиентской зоне, а персонал может быть как в клиентской, так и в рабочих зонах. DMZ сегмент — это как раз и есть аналог клиентской зоны.
© autobam.ru
Вариант 3. Разделение сервисов на Front-End и Back-End
Как уже отмечалось ранее, размещение сервера в DMZ никоим образом не улучшает безопасность самого сервиса. Одним из вариантов исправления ситуации является разделение функционала сервиса на две части: Front-End и Back-End. При этом каждая часть располагается на отдельном сервере, между которыми организуется сетевое взаимодействие. Сервера Front-End, реализующие функционал взаимодействия с клиентами, находящимися в Интернет, размещают в DMZ, а сервера Back-End, реализующие остальной функционал, оставляют во внутренней сети. Для взаимодействия между ними на DFW создают правила, разрешающие инициацию подключений от Front-End к Back-End.
В качестве примера рассмотрим корпоративный почтовый сервис, обслуживающий клиентов как изнутри сети, так и из Интернет. Клиенты изнутри используют POP3/SMTP, а клиенты из Интернет работают через Web-интерфейс. Обычно на этапе внедрения компании выбирают наиболее простой способ развертывания сервиса и ставят все его компоненты на один сервер. Затем, по мере осознания необходимости обеспечения информационной безопасности, функционал сервиса разделяют на части, и та часть, что отвечает за обслуживание клиентов из Интернет (Front-End), выносится на отдельный сервер, который по сети взаимодействует с сервером, реализующим оставшийся функционал (Back-End). При этом Front-End размещают в DMZ, а Back-End остается во внутреннем сегменте. Для связи между Front-End и Back-End на DFW создают правило, разрешающее, инициацию соединений от Front-End к Back-End.
Плюсы варианта:
- В общем случае атаки, направленные против защищаемого сервиса, могут «споткнуться» об Front-End, что позволит нейтрализовать или существенно снизить возможный ущерб. Например, атаки типа TCP SYN Flood или slow http read, направленные на сервис, приведут к тому, что Front-End сервер может оказаться недоступен, в то время как Back-End будет продолжать нормально функционировать и обслуживать пользователей.
- В общем случае на Back-End сервере может не быть доступа в Интернет, что в случае его взлома (например, локально запущенным вредоносным кодом ) затруднит удаленное управление им из Интернет.
- Front-End хорошо подходит для размещения на нем межсетевого экрана уровня приложений (например, Web application firewall) или системы предотвращения вторжений (IPS, например snort).
Минусы варианта:
- Для связи между Front-End и Back-End на DFW создается правило, разрешающее инициацию соединения из DMZ во внутреннюю сеть, что порождает угрозы, связанные с использованием данного правила со стороны других узлов в DMZ (например, за счет реализации атак IP spoofing, ARP poisoning и т. д.)
- Не все сервисы могут быть разделены на Front-End и Back-End.
- В компании должны быть реализованы бизнес-процессы актуализации правил межсетевого экранирования.
- В компании должны быть реализованы механизмы защиты от атак со стороны Нарушителей, получивших доступ к серверу в DMZ.
Примечания
- В реальной жизни даже без разделения серверов на Front-End и Back-End серверам из DMZ очень часто необходимо обращаться к серверам, находящимся во внутренней сети, поэтому указанные минусы данного варианта будут также справедливы и для предыдущего рассмотренного варианта.
- Если рассматривать защиту приложений, работающих через Web-интерфейс, то даже если сервер не поддерживает разнесение функций на Front-End и Back-End, применение http reverse proxy сервера (например, nginx) в качестве Front-End позволит минимизировать риски, связанные с атаками на отказ в обслуживании. Например, атаки типа SYN flood могут сделать http reverse proxy недоступным, в то время как Back-End будет продолжать работать.
Аналогия с реальной жизнью
Данный вариант по сути похож на организацию труда, при которой для высоко загруженных работников используют помощников — секретарей. Тогда Back-End будет аналогом загруженного работника, а Front-End аналогом секретаря.
© mln.kz
Вариант 4. Защищенный DMZ
DMZ это часть сети, доступная из Internet, и, как следствие, подверженная максимальному риску компрометации узлов. Дизайн DMZ и применяемые в ней подходы должны обеспечивать максимальную живучесть в условиях, когда Нарушитель получил контроль над одним из узлов в DMZ. В качестве возможных атак рассмотрим атаки, которым подвержены практически все информационные системы, работающие с настройками по умолчанию:
- CAM-table overflow
- ARP poisoning
- Rogue DHCP Server
- DHCP starvation
- VLAN hopping
- MAC flood
- UDP flood
- TCP SYN flood
- TCP session hijacking
- TCP reset
- Атаки на Web-приложения
- Атаки на обход средств аутентификации и авторизацию от имени легитимного пользователя (например, подбор паролей, PSK и т.д.)
- Атаки на уязвимости в сетевых службах, например:
Большая часть указанных атак (по крайней мере с 1 по 10) базируется на уязвимостях архитектуры современных Ethernet/IP сетей, заключающихся в возможности Нарушителя подделывать в сетевых пакетах MAC и IP адреса. Эксплуатацию данных уязвимостей иногда выделяют в отдельный виды атак:
Поэтому построение системы защиты DMZ начнем с рассмотрения способов защиты от IP и MAC spoofing.
Примечание
Приведенные ниже способы защиты от данных атак не являются единственно возможными. Существуют и другие способы.
Защита от MAC spoofing
Схематически атаки, связанные с подменой MAC адреса, можно проиллюстрировать следующим образом:
Нейтрализацией данной атаки может являться фильтрация MAC-адресов на портах коммутатора. Например, трафик по порту 3 должен проходить только в случае, если в адресе источника или в адресе назначения указан MAC-адрес DE:AD:BE:AF:DE:AD или широковещательный адрес (в некоторых случаях).
Защита от IP spoofing
Схема атаки IP spoofing похожа на предыдущую, за исключением того, что Нарушитель подделывает не MAC, а IP-адрес. Защита от IP spoofing может быть реализована путем разделения IP-сети DMZ на более мелкие IP-подсети и дальнейшей фильтрацией трафика на интерфейсах маршрутизатора по аналогии с рассмотренной ранее MAC-фильтрацией. Ниже пример дизайна DMZ, реализующего данный принцип:
В DMZ располагается 3 узла:
- Терминальный сервер (192.168.100.2)
- Почтовый сервер (192.168.100.5)
- Extranet сервер (192.168.100.9)
Для DMZ выделена IP-сеть 192.168.100.0/24, в данной сети выделяются 3 IP-подсети (по числу серверов):
Подсеть 1 — 192.168.100.0/30 для терминального сервера (192.168.100.2)
Подсеть 2 — 192.168.100.4/30 для почтового сервера (192.168.100.5)
Подсеть 3 — 192.168.100.8/30 для почтового сервера (192.168.100.9)
На практике разделение сети на подобные подсети реализуют с помощью технологии VLAN. Однако, ее применение порождает риски, защиту от которых мы сейчас рассмотрим.
Защита от VLAN hopping
Для защиты от этой атаки на коммутаторе отключают возможность автоматического согласования типов (trunk / access) портов, а сами типы администратор назначает вручную. Кроме того, организационными мерами запрещается использование так называемого native VLAN.
Защита от атак, связанных с DHCP
Не смотря на то, что DHCP предназначен для автоматизации конфигурирования IP-адресов рабочих станций, в некоторых компаниях встречаются случаи, когда через DHCP выдаются IP-адерса для серверов, но это довольно плохая практика. Поэтому для защиты от Rogue DHCP Server, DHCP starvation рекомендуется полный отказ от DHCP в DMZ.
Защита от атак MAC flood
Для защиты от MAC flood проводят настройку на портах коммутатора на предмет ограничения предельной интенсивности широковещательного трафика (поскольку обычно при данных атаках генерируется широковещательный трафик (broadcast)). Атаки, связанные с использованием конкретных (unicast) сетевых адресов, будут заблокированы MAC фильтрацией, которую мы рассмотрели ранее.
Защита от атак UDP flood
Защита от данного типа атак производится аналогично защите от MAC flood, за исключением того, что фильтрация осуществляется на уровне IP (L3).
Защита от атак TCP SYN flood
Для защиты от данной атаки возможны варианты:
- Защита на узле сети с помощью технологии TCP SYN Cookie.
- Защита на уровне межсетевого экрана (при условии разделения DMZ на подсети) путем ограничения интенсивности трафика, содержащего запросы TCP SYN.
Защита от атак на сетевые службы и Web-приложения
Универсального решения данной проблемы нет, но устоявшейся практикой является внедрение процессов управления уязвимостями ПО (выявление, установка патчей и т.д., например, так), а также использование систем обнаружения и предотвращения вторжений (IDS/IPS).
Защита от атак на обход средств аутентификации
Как и для предыдущего случая универсального решения данной проблемы нет.
Обычно в случае большого числа неудачных попыток авторизации учетные записи, для избежания подборов аутентификационных данных (например, пароля) блокируют. Но подобный подход довольно спорный, и вот почему.
Во-первых, Нарушитель может проводить подбор аутентификационной информации с интенсивностью, не приводящей к блокировке учетных записей (встречаются случаи, когда пароль подбирался в течении нескольких месяцев с интервалом между попытками в несколько десятков минут).
Во-вторых, данную особенность можно использовать для атак типа отказ в обслуживании, при которых Нарушитель будет умышленно проводить большое количество попыток авторизации для того, чтобы заблокировать учетные записи.
Наиболее эффективным вариантом от атак данного класса будет использование систем IDS/IPS, которые при обнаружении попыток подбора паролей будут блокировать не учетную запись, а источник, откуда данный подбор происходит (например, блокировать IP-адрес Нарушителя).
Итоговый перечень защитных мер по данному варианту:
- DMZ разделяется на IP-подсети из расчета отдельная подсеть для каждого узла.
- IP адреса назначаются вручную администраторами. DHCP не используется.
- На сетевых интерфейсах, к которым подключены узлы DMZ, активируется MAC и IP фильтрация, ограничения по интенсивности широковещательного трафика и трафика, содержащего TCP SYN запросы.
- На коммутаторах отключается автоматическое согласование типов портов, запрещается использование native VLAN.
- На узлах DMZ и серверах внутренней сети, к которым данные узлы подключаются, настраивается TCP SYN Cookie.
- В отношении узлов DMZ (и желательно остальной сети) внедряется управление уязвимостями ПО.
- В DMZ-сегменте внедряются системы обнаружения и предотвращения вторжений IDS/IPS.
Плюсы варианта:
- Высокая степень безопасности.
Минусы варианта:
- Повышенные требования к функциональным возможностям оборудования.
- Трудозатраты во внедрении и поддержке.
Аналогия с реальной жизнью
Если ранее DMZ мы сравнили с клиентской зоной, оснащенной диванчиками и пуфиками, то защищенный DMZ будет больше похож на бронированную кассу.
© valmax.com.ua
Вариант 5. Back connect
Рассмотренные в предыдущем варианте меры защиты были основаны на том, что в сети присутствовало устройство ( коммутатор / маршрутизатор / межсетевой экран), способное их реализовывать. Но на практике, например, при использовании виртуальной инфраструктуры (виртуальные коммутаторы зачастую имеют очень ограниченные возможности), подобного устройства может и не быть.
В этих условиях Нарушителю становятся доступны многие из рассмотренных ранее атак, наиболее опасными из которых будут:
- атаки, позволяющие перехватывать и модифицировать трафик (ARP Poisoning, CAM table overflow + TCP session hijacking и др.);
- атаки, связанные с эксплуатацией уязвимостей серверов внутренней сети, к которым можно инициировать подключения из DMZ (что возможно путем обхода правил фильтрации DFW за счет IP и MAC spoofing).
Следующей немаловажной особенностью, которую мы ранее не рассматривали, но которая не перестает быть от этого менее важной, это то, что автоматизированные рабочие места (АРМ) пользователей тоже могут быть источником (например, при заражении вирусами или троянами) вредоносного воздействия на сервера.
Таким образом, перед нами встает задача защитить сервера внутренней сети от атак Нарушителя как из DMZ, так и из внутренней сети (заражение АРМа трояном можно интерпретировать как действия Нарушителя из внутренней сети).
Предлагаемый далее подход направлен на уменьшение числа каналов, через которые Нарушитель может атаковать сервера, а таких канала как минимум два. Первый это правило на DFW, разрешающее доступ к серверу внутренней сети из DMZ (пусть даже и с ограничением по IP-адресам), а второй — это открытый на сервере сетевой порт, по которому ожидаются запросы на подключение.
Закрыть указанные каналы можно, если сервер внутренней сети будет сам строить соединения до сервера в DMZ и будет делать это с помощью криптографически защищенных сетевых протоколов. Тогда не будет ни открытого порта, ни правила на DFW.
Но проблема в том, что обычные серверные службы не умеют работать подобным образом, и для реализации указанного подхода необходимо применять сетевое туннелирование, реализованное, например, с помощью SSH или VPN, а уже в рамках туннелей разрешать подключения от сервера в DMZ к серверу внутренней сети.
Общая схема работы данного варианта выглядит следующим образом:
- На сервер в DMZ инсталлируется SSH/VPN сервер, а на сервер во внутренней сети инсталлируется SSH/VPN клиент.
- Сервер внутренней сети инициирует построение сетевого туннеля до сервера в DMZ. Туннель строится с взаимной аутентификацией клиента и сервера.
- Сервер из DMZ в рамках построенного туннеля инициирует соединение до сервера во внутренней сети, по которому передаются защищаемые данные.
- На сервере внутренней сети настраивается локальный межсетевой экран, фильтрующий трафик, проходящий по туннелю.
Использование данного варианта на практике показало, что сетевые туннели удобно строить с помощью OpenVPN, поскольку он обладает следующими важными свойствами:
- Кроссплатформенность. Можно организовывать связь на серверах с разными операционными системами.
- Возможность построения туннелей с взаимной аутентификацией клиента и сервера.
- Возможность использования сертифицированной криптографии.
На первый взгляд может показаться, что данная схема излишне усложнена и что, раз на сервере внутренней сети все равно нужно устанавливать локальный межсетевой экран, то проще сделать, чтобы сервер из DMZ, как обычно, сам подключался к серверу внутренней сети, но делал это по шифрованному соединению. Действительно, данный вариант закроет много проблем, но он не сможет обеспечить главного — защиту от атак на уязвимости сервера внутренней сети, совершаемых за счет обхода межсетевого экрана с помощью IP и MAC spoofing.
Плюсы варианта:
- Архитектурное уменьшение количества векторов атак на защищаемый сервер внутренней сети.
- Обеспечение безопасности в условиях отсутствия фильтрации сетевого трафика.
- Защита данных, передаваемых по сети, от несанкционированного просмотра и изменения.
- Возможность избирательного повышения уровня безопасности сервисов.
- Возможность реализации двухконтурной системы защиты, где первый контур обеспечивается с помощью межсетевого экранирования, а второй организуется на базе данного варианта.
Минусы варианта:
- Внедрение и сопровождение данного варианта защиты требует дополнительных трудовых затрат.
- Несовместимость с сетевыми системами обнаружения и предотвращения вторжений (IDS/IPS).
- Дополнительная вычислительная нагрузка на сервера.
Аналогия с реальной жизнью
Основной смысл данного варианта в том, что доверенное лицо устанавливает связь с не доверенным, что похоже на ситуацию, когда при выдаче кредитов Банки сами перезванивают потенциальному заемщику с целью проверки данных.
© comfoson.890m.com
Заключение
Итак, мы рассмотрели все пять заявленных вариантов организации доступа к сервисам корпоративной сети из Интернет. Какой из них лучше, какой хуже — сказать сложно, поскольку все зависит, в конечном счете, от той информации, которую необходимо защитить, и тех ресурсов, которыми компания располагает для защиты. Если ни ресурсов, ни знаний нет, то оптимальным будет первый вариант. Если же информация очень ценна, то комбинация четвертого и пятого вариантов даст непревзойденный уровень безопасности.
Комментарии (19)
maxivanuk
07.06.2016 17:59Очень интересно. Не увидел решения с подключением по VPN. По мне, так это более безопасно. Или предполагается, что есть какие-то ресурсы, которые нужно предоставить не только сотрудникам, но и гостям???
imbasoft
07.06.2016 19:05Про VPN, а точнее Remote Access VPN (если речь о сотрудниках) писать не стал, там свои нюансы. В целом статья про задачу публикации именно конечных сервисов, типа почтовика, корпоративного Web-сайта, Интернет Клиент-Банка и других систем. Если будет интересно про VPN, в части Remote Access (удаленка) или Site-Site (сопряжение офисов) можно про это будет сделать отдельный раздел.
Ivan_83
07.06.2016 18:02+1Видимо писали по брошюрам от МС — весьма поверхностное понимание технологий.
Защита от IP spoofing
Не обязательно сегментировать сеть.
Есть коммутаторы которые могут проверять SRC IP.
Можно на фаерволе/роутере отключить для данного сетевого интерфейса ARP протокол и статикой забить IP-MAC. Разумеется, винда как десктопная ОС тут в пролёте.
Защита от VLAN hopping
На некоторых старых цысках оно вроде как совсем не отключается.
Но вообще включать эту фичу смысла нет, если только ты не провайдер с куче вланов.
У вебсмартов длинка такой фичи часто вообще нет.
Защита от атак, связанных с DHCP
легко лечится управляемым коммутатором: либо включается дхцп сервер скрининг либо пишется ACL делающая тоже самое, там совсем не сложно матчить UDP-DHCP пакеты по оффетам+сигнатурам.
Защита от атак UDP flood
и
Защита от атак TCP SYN flood
Лечится изоляцией флудера, и дальше препарированием.
Туннели в своей сети — идиотизм.
На практике вариант без использования венды и вендорских разводов выглядит так:
Управляемый свич + тазик с фрёй/линухом, хватит и одной сетевухи.
Заводим на свиче управляющий влан, его же на тазике отдельным вланом/интерфейсом, отдельную подсеть на него.
Дальше заводим по влан+интерфейс на тазике под каждый канал инета, каждый сервер ДМЗ (если много то можно и объединять, особенно если им меж друг друга что то активно нужно), и для сегментов внутренней сети.
Дальше настраивается роутинг и фаервол.
Порты сервисов на ДМЗ серверах пробрасываются наружу/внутрь.
Для любителей экстремальной экономии можно сервисы поднимать в виртуалках на самом линухе.
Во фре есть chroot и jail, но там свою нюансы в настройке.
Если нужно выставить в инет какой нибудь стрёмный IIS, то можно попытаться фильтровать к нему запросы проксируя через nginx на роутере/фаерволе.
Итого минимальный конфиг: свич в среднем 10к руб + какой то комп под роутер/фаервол, если на него не вешать виртуалок то хватит и селерона с запасом.
imbasoft
07.06.2016 19:34В области безопасности нет единственно правильных решений. В статье приведены базовые принципы которые можно реализовать практически любыми средствами. Вы приводите ряд других — ок.
К сожалению ваш стиль изложения и лексикон не позволяет в полной мере понять того что вы хотите сказать. Например ваша фраза
Защита от атак TCP SYN flood
Лечится изоляцией флудера, и дальше препарированием.
Не раскрывает того, чем и как обнаруживается флудер, и сколько человек должно круглосуточно сидеть и смотреть в коммутаторы чтобы защитить продуктивные среды от DoS со стороны взломанного сервера из DMZ.
Про тазик с фрей и управляемые свичи и селерон за 10к — возможно в вашем случае это здорово. Хотя я не понял что вы хотели сказать. В тоже время попробуйте ответить на вопросы: Как быть если все сервера «живут» в вирутальной среде? Как вы будете обеспечивать надежность с помощью селерона и одной сетевой карты? Как через одну сетевую карту с кучей VLAN вы будете обеспечить ночной фул бэкап серверной инфраструкртуры на 10 Тб?
Туннели в своей сети — идиотизм.
Почему? Потому что вы так не делали?
Вообще судя по объему комментария, вы неплохо потрудились, было бы здорово если вы приводили аргументы к своим утверждениям.
Но в целом спасибо за коммент.Ivan_83
07.06.2016 22:17Уши венды так и торчат из статьи, хотя бы лечение IP спуфинга одним единственным доступным в винде методом.
Site-to-Site VPN из двух соединений чтобы соединить две сети, потому что винда не умеет вешать маршруты на входящие в RRAS подключения.
Если делать под одному дмз хосту в влане то в фаерволе крутится рейтлимит этих самых TCP SYN или банально включается syn proxy — это когда фаервол сам по сути устанавливает соединение и полностью следит за ним. Хз, есть такое в линухах или нет.
Дальше одним из многих способов можно увидеть либо подозрительный всплеск активности и через SNMP вообще положить порт коммутатора либо ничего не делать, пусть и дальше в пустую долбит роутер/фаер.
Хотел сказать что не обязательно ставить костыльные TMG/ISA от которых толку ноль а денег они стоят, средней паршивости управляемый свич, какой то тазик с фрёй/линухом и прямые руки дадут на порядок больше.
Что значит виртуальная среда?
Можно поставить ещё ххх селеронов рядом, во фрёвом PF есть механизм для горячего резервирования.
Сетевая может быть и на 4 порта собранных в LACP, хотя да, одно соединение будет упираться в гиг, или это может быть 10Г адаптер.
Потому что туннели ничего кроме лишней административной работы и нагрузки CPU не дадут, всё тоже самое легко делается пробросом портов на фаерволе и правилами.
А у вас тут соединяются свои сервера, не ужели в локалке настолько помойка и бардак что к ней нет доверия и никак это нельзя исправить?
Тут по хорошему даже роутер не нужен, хватит L2 свича, а если хочется пускать только определённый протокол на определённый порт то велком писать ACL.
Профитом то что оно будет работать на скорости порта и не потреблять ресурсов вообще.
VPN или проброс портов через ссш нужен когда ты сам вне сети и много данных прокачивать не надо.
Либо это линк через публичные сети и есть требование к приватности и аутентичности.
imbasoft
07.06.2016 23:51Что значит виртуальная среда?
Это значит что используются исключительно виртуальные машины и между ними нет железных девайсов и сетевых устройств в привычном понимании.
Потому что туннели ничего кроме лишней административной работы и нагрузки CPU не дадут, всё тоже самое легко делается пробросом портов на фаерволе и правилами.
Туннель позволяет не открывать порт на сервере и не делать правила на межсетевом экране (проброс портов). Зачем это нужно ответил в статье.
А у вас тут соединяются свои сервера, не ужели в локалке настолько помойка и бардак что к ней нет доверия и никак это нельзя исправить?
Нет помойки, есть информация, стоимость которой весьма высока.
Хочу подчеркнуть важный момент. В статье приводятся только одни из возможных вариантов, они не являются единствено возможными.
Если хочется сравнить несколько вариантов по защищенности то это надо делать на моделе угроз.
Если сравнивать варианты по затратам то лучше это делать по стоимости владения (TCO) в 3 или 5 летней перспективе.
nmk2002
08.06.2016 01:24Туннель позволяет не открывать порт на сервере и не делать правила на межсетевом экране (проброс портов). Зачем это нужно ответил в статье.
Если я правильно понимаю, то у вас создастся динамическое правило на маршрутизаторе пропускающее трафик из DMZ в LAN, как только сервер из LAN попытается создать туннель до сервера в DMZ.
Чем это правило лучше статического правила на такой же пропуск трафика от сервера в DMZ к серверу в LAN?imbasoft
08.06.2016 09:01Динамического правила не создается. Инициация подключений из Внутренней сети в DMZ и так не ограничивается.
nmk2002
08.06.2016 10:09Чтобы пакеты полетели из DMZ в сторону LAN нужно, чтобы маршрутизатор/файрвол их пропускал. Если брать классический файрвол, то вам нужно писать 2 правила: в одну и в другую сторону. Условно как-то так:
allow from LAN-server_IP to DMZ-server_IP TCP port xxxx
allow from DMZ-server_IP to LAN-server_IP TCP port yyyy
Видимо, вы работали с файрволом, который сам видит, какое соединение открывается по разрешенному в одну сторону правилу и автоматически пропускает пакеты в обратную сторону. То есть в нем прописано только первое правило, но фактически, как только сервер из LAN поднял VPN, на файрволе разрешен трафик и от сервера в DMZ до сервера в LAN по конкретному порту. А это равносильно тому же правилу на файрволе.imbasoft
08.06.2016 10:32+1Мы с вами рассуждаем о межсетевых экранов разного типа (поколения).
То что вы говорите — это пакетный фильтр, который принимает решение о транзите трафика только на основании данных заголовков.
В статье и моих коментах я оперирую правилами межсетевых экранов работающих с анализом состояния (stateful firewall) В них правила фильтрации помимо адресов учитывают состояния например new, established, invalid,… примером межсетевого экрана подобного класса является iptables. Поэтому при описании правил и применялась фраза — «разрешить инициацию соединений из внутренней сети в DMZ».
Оба типа межсетевых экранов применяются на практике. Пакетные фильтры используются на магистралях, где важна скорость. Statefull применяются на уровне сегментов корпоративных сетей, где важна защита от обхода с помощью фрагментации
Ivan_83
08.06.2016 01:36+1Влан на виртуалку, этот же влан поднимаем на фаере/роутере, не важно на том же он будет хосте или на отдельном подключённом через управляемый коммутатор.
Все аргументы натянуты.
То что описано выше решает все проблемы с возможным зловредным поведением хостов в ДМЗ.
В случае заражения АРМ внутри сети он всё равно сможет долбить сервер в локалке, поскольку ему разрешено с ним работать, либо не сможет потому что у него туда доступа нет, тут туннели вообще не причём.
У вас в статье вообще практически все проблемы рассмотрены которые давным давно имеют решение, но про эти решения вообще не упоминаете.
L2, L2+L3 и частично L3 проблемы лечатся управляемыми коммутаторами, начиная от средних вебсмартов и выше.
И подмена мака, и арпспуфинг, и подмена IP, и фильтрация левых дхцп и примитивные флуды, даже можно авторизацию 802.1x поврубать на портах, чтобы только свои устройства в сеть пущало.
От свичей же есть SNMP трапы и сислог для оперативного оповещения и реагирования.
Как вы собрались хотя бы найти АРМ который то ли заразился то ли просто порт у него погорел и он начал слать броадкасты с рандомными маками и мусорным содержимым? Или просто стал возвращать все пакеты обратно, эмитируя петлю?
У вас же тупая неуправляемая сеть нарисована, которая ляжет от первой же петли и вы пол дня будете искать вирусы на компах, а потом окажется что кто то перепутал и воткнул оба конца патчкорда в двойную розетку под столом.
Ну да, у вас коммутатор умеет только маки фильтровать, здравствуй начало 200х.
Нейтив влан чем вам помешал?
Весь «хайтек» описанный в статье опоздал лет на 10 точно, тогда это ещё было актуально, а сейчас и возможностей и технологий больше.imbasoft
08.06.2016 09:20В случае заражения АРМ внутри сети он всё равно сможет долбить сервер в локалке, поскольку ему разрешено с ним работать, либо не сможет потому что у него туда доступа нет, тут туннели вообще не причём.
Back connect — технология защиты межсерверных связей. Пример ее использования — связь с сервера приложений (того, что обслуживает клиентов) с сервером баз данных. Сервер БД в данном случае будет инициатором построения туннелей и соответственно не будет иметь открытых портов by design. Почему это важно?
На практике, случаются случаи когда на защиту с помощью сетевых устройств нельзя положится на 100%. Это могут быть случаи когда:- сетевые устройства не находится на поддержке производителя и не обновляются,
- сетевые устройства управляются на аутсорсинге
- квалификация администраторов недостаточна высока.
Другим примером ее использования обеспечение второго контура безопасности для защиты особо важных данных. Про актуальность этих задач можно посмотреть тут.Ivan_83
08.06.2016 13:10+1Нейтив влан чем вам помешал?
Чем плохи открытые порты?
Почему сервер БД не может ходить по обычному TLS?
Почему вы считаете что EOL сетевого оборудование сам по себе проблема?
Если админ низкой квалификации на аутсорсинге то с чего вы взяли что такой конторе вообще нужна какая то безопасность?
Кто там будет поднимать какие то тоннели? Недоадмин на аутсорсе?
Ещё раз: в своей сети использовать тоннели — это моветон от горе-админа.
PS: «Атаки на уязвимости в сетевых службах, например:
Атака на Web-сервер — slow reading
DNS cache poisoning»
Плохой пример. В обоих случаях уязвимости нет, это особенности дизайна протоколов, их стандартное поведение приводящее к проблемам.
imbasoft
08.06.2016 14:08Нейтив влан чем вам помешал?
Довольно подробно описано тут.
Чем плохи открытые порты?
А вот это хороший вопрос. Проблема в том, что сетевая служба ожидающая подключение по порту может содержать уязвимости в коде и быть атакована Нарушителем.
Это можно проиллюстрировать на примере с Heartbleed уязвимостью и Web — приложением проводящим авторизацию на примере форм (Web выбран в только в качестве примера, аналогичная схемы может быть актуальна и для других сервисов).
Здесь неуполномоченные пользователи «отсекаются» авторизацией Web-приложения и вроде бы сервис защищен, но Нарушители могут атаковать непосредственно саму сетевую службу (в данном случае ее компонент — OpenSSL). Дабы не бороться с каждой подобной уязвимостью технология back connect позволяет закрыть сам канал атаки.
Почему вы считаете что EOL сетевого оборудование сам по себе проблема?
Наиболее понятным примером будут ошибки в BMC серверов, для которых нет патчей (не в природе, а для данной модели сервера) и из-за которого приходится этот функционал отключать.Ivan_83
08.06.2016 14:54Там же написано: для транк портов.
Вполне очевидно что транк порты это для магистралей, а аксес порты это для всяких клиентов и серверов в том числе.
Использование транк портов для клиентов — это неправильная конфигурация.
Те ваш бэк коннект фактически эквивалентен пробросу порта на фаере и фильтрации подключений на конечных хостах?
Те сам по себе EOL, без известных проблем, не проблема?
imbasoft
08.06.2016 15:21Те ваш бэк коннект фактически эквивалентен пробросу порта на фаере и фильтрации подключений на конечных хостах?
С точки зрения функционала — да.
С точки зрения безопасности, вариант с межсетевым экраном шлюзового типа (железка то есть) проигрывает, потому как для описания правил фильтрации используются IP-адреса, а они могут быть подменены с помощью IP-spoofing. В тоже время применение локального межестевого экрана в технологии back connect лишено указной проблемы, поскольку он настраивается на фильтрацию в криптографически защищенном соединении (туннеле), в котором не возможна подмена данных.
На практике, back connect следует применять, только там где передается информация особой важности, например передача трафика содержащего аутентификационную информацию, или сведения о переводах денежных средств или управляющие воздействия автоматизированных систем управления технологическими процессами (АСУ ТП).
Более приземленным вариантом может быть защита взаимодействия RO DC c полнофункциональными контролерами домена. В некоторых схема high-security все пользователи авторизуются всегда через RO DC, а администрирование происходит на глубоко спрятанных полнофункциональных контролерах.
Те сам по себе EOL, без известных проблем, не проблема?
Проблема. И заключается она в том, что уязвимости в нем не публикуются, хотя это вовсе не значит что их нет. Пример Windows XP.
nmk2002
Добавлю вариант организации доступа к корпоративным ресурсам с использованием класса продуктов Access Gateway. В этом случае вы ставите фронтом один сервер, который является реверс-прокси для всех остальных ресурсов. Наружу никакие корпоративные ресурсы напрямую не торчат, а становятся доступны только через Access Gateway. Получается как вариант с фрон-эндом, только он тут один для всех ресурсов, а следовательно сокращается количество векторов атак. Обычно Access Gateway обеспечивает не только сам доступ, но и аутентификацию, авторизацию, SSO.
imbasoft
Согласен. С точки зрения логики статьи это Вариант с Front-End. Сам пользовался Microsoft TMG UAG.
nmk2002
Добавил, потому что Access Gateway это все-таки один фронт-энд для разных ресурсов, в т.ч. для тех которые не предполагают наличие фронт-энда. Это сокращает количество серверов, торчащих наружу.
К тому же, если он обеспечивает централизованную аутентификацию, то решается вопрос с разными логинами/паролями от разных систем. Проходишь аутентификацию на единой точке входа, а дальше работает SSO для доступа к бэк-энд ресурсам. И не надо аутентифицироваться отдельно на каждом ресурсе. Плюс можно настроить многофакторную аутентификацию к ресурсам, которые сами по себе это не поддерживают.
Поэтому с точки зрения ИБ этот вариант отличается от публикации разных фронт-эндов от разных приложений.