- PVSM.RU - https://www.pvsm.ru -
Данная статья содержит обзор пяти вариантов решения задачи организации доступа к сервисам корпоративной сети из Интернет. В рамках обзора приводится анализ вариантов на предмет безопасности и реализуемости, что поможет разобраться в сути вопроса, освежить и систематизировать свои знания как начинающим специалистам, так и более опытным. Материалы статьи можно использовать для обоснования Ваших проектных решений.
При рассмотрении вариантов в качестве примера возьмем сеть, в которой требуется опубликовать:
В данном варианте все узлы корпоративной сети содержатся в одной, общей для всех сети («Внутренняя сеть»), в рамках которой коммуникации между ними не ограничиваются. Сеть подключена к Интернет через пограничный маршрутизатор/межсетевой экран (далее — IFW).
Доступ узлов в Интернет осуществляется через NAT [2], а доступ к сервисам из Интернет через Port forwarding [3].
Плюсы варианта:
Минусы варианта:
Аналогия с реальной жизнью
Подобную сеть можно сравнить с компанией, где персонал и клиенты находятся в одной общей комнате (open space)
© hrmaximum.ru
Для устранения указанного ранее недостатка узлы сети, доступные из Интернет, помещают в специально выделенный сегмент – демилитаризованную зону (DMZ). DMZ организуется с помощью межсетевых экранов, отделяющих ее от Интернет (IFW) и от внутренней сети (DFW).
При этом правила фильтрации межсетевых экранов выглядят следующим образом:
Плюсы варианта:
Минусы варианта:
Аналогия с реальной жизнью
Данный вариант архитектуры сети похож на организацию рабочей и клиентской зон в компании, где клиенты могут находиться только в клиентской зоне, а персонал может быть как в клиентской, так и в рабочих зонах. DMZ сегмент — это как раз и есть аналог клиентской зоны.
© autobam.ru
Как уже отмечалось ранее, размещение сервера в DMZ никоим образом не улучшает безопасность самого сервиса. Одним из вариантов исправления ситуации является разделение функционала сервиса на две части: Front-End и Back-End [4]. При этом каждая часть располагается на отдельном сервере, между которыми организуется сетевое взаимодействие. Сервера 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.
Плюсы варианта:
Минусы варианта:
Примечания
Аналогия с реальной жизнью
Данный вариант по сути похож на организацию труда, при которой для высоко загруженных работников используют помощников — секретарей. Тогда Back-End будет аналогом загруженного работника, а Front-End аналогом секретаря.
© mln.kz
DMZ это часть сети, доступная из Internet, и, как следствие, подверженная максимальному риску компрометации узлов. Дизайн DMZ и применяемые в ней подходы должны обеспечивать максимальную живучесть в условиях, когда Нарушитель получил контроль над одним из узлов в DMZ. В качестве возможных атак рассмотрим атаки, которым подвержены практически все информационные системы, работающие с настройками по умолчанию:
Большая часть указанных атак (по крайней мере с 1 по 10) базируется на уязвимостях архитектуры современных Ethernet/IP сетей, заключающихся в возможности Нарушителя подделывать в сетевых пакетах MAC и IP адреса. Эксплуатацию данных уязвимостей иногда выделяют в отдельный виды атак:
Поэтому построение системы защиты DMZ начнем с рассмотрения способов защиты от IP и MAC spoofing.
Примечание
Приведенные ниже способы защиты от данных атак не являются единственно возможными. Существуют и другие способы.
Схематически атаки, связанные с подменой MAC адреса, можно проиллюстрировать следующим образом:
Нейтрализацией данной атаки может являться фильтрация MAC-адресов на портах коммутатора. Например, трафик по порту 3 должен проходить только в случае, если в адресе источника или в адресе назначения указан MAC-адрес DE:AD:BE:AF:DE:AD или широковещательный адрес (в некоторых случаях).
Схема атаки IP spoofing похожа на предыдущую, за исключением того, что Нарушитель подделывает не MAC, а IP-адрес. Защита от IP spoofing может быть реализована путем разделения IP-сети DMZ на более мелкие IP-подсети и дальнейшей фильтрацией трафика на интерфейсах маршрутизатора по аналогии с рассмотренной ранее MAC-фильтрацией. Ниже пример дизайна DMZ, реализующего данный принцип:
В DMZ располагается 3 узла:
Для 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. Однако, ее применение порождает риски, защиту от которых мы сейчас рассмотрим.
Для защиты от этой атаки [11] на коммутаторе отключают возможность автоматического согласования типов (trunk / access [20]) портов, а сами типы администратор назначает вручную. Кроме того, организационными мерами запрещается использование так называемого native VLAN [20].
Не смотря на то, что DHCP предназначен для автоматизации конфигурирования IP-адресов рабочих станций, в некоторых компаниях встречаются случаи, когда через DHCP выдаются IP-адерса для серверов, но это довольно плохая практика. Поэтому для защиты от Rogue DHCP Server [9], DHCP starvation [10] рекомендуется полный отказ от DHCP в DMZ.
Для защиты от MAC flood проводят настройку на портах коммутатора на предмет ограничения предельной интенсивности широковещательного трафика (поскольку обычно при данных атаках генерируется широковещательный трафик (broadcast)). Атаки, связанные с использованием конкретных (unicast) сетевых адресов, будут заблокированы MAC фильтрацией, которую мы рассмотрели ранее.
Защита от данного типа атак производится аналогично защите от MAC flood, за исключением того, что фильтрация осуществляется на уровне IP (L3).
Для защиты от данной атаки возможны варианты:
Универсального решения данной проблемы нет, но устоявшейся практикой является внедрение процессов управления уязвимостями ПО (выявление, установка патчей и т.д., например, так [22]), а также использование систем обнаружения и предотвращения вторжений (IDS/IPS).
Как и для предыдущего случая универсального решения данной проблемы нет.
Обычно в случае большого числа неудачных попыток авторизации учетные записи, для избежания подборов аутентификационных данных (например, пароля) блокируют. Но подобный подход довольно спорный, и вот почему.
Во-первых, Нарушитель может проводить подбор аутентификационной информации с интенсивностью, не приводящей к блокировке учетных записей (встречаются случаи, когда пароль подбирался в течении нескольких месяцев с интервалом между попытками в несколько десятков минут).
Во-вторых, данную особенность можно использовать для атак типа отказ в обслуживании, при которых Нарушитель будет умышленно проводить большое количество попыток авторизации для того, чтобы заблокировать учетные записи.
Наиболее эффективным вариантом от атак данного класса будет использование систем IDS/IPS, которые при обнаружении попыток подбора паролей будут блокировать не учетную запись, а источник, откуда данный подбор происходит (например, блокировать IP-адрес Нарушителя).
Плюсы варианта:
Минусы варианта:
Аналогия с реальной жизнью
Если ранее DMZ мы сравнили с клиентской зоной, оснащенной диванчиками и пуфиками, то защищенный DMZ будет больше похож на бронированную кассу.
© valmax.com.ua
Рассмотренные в предыдущем варианте меры защиты были основаны на том, что в сети присутствовало устройство ( коммутатор / маршрутизатор / межсетевой экран), способное их реализовывать. Но на практике, например, при использовании виртуальной инфраструктуры (виртуальные коммутаторы зачастую имеют очень ограниченные возможности), подобного устройства может и не быть.
В этих условиях Нарушителю становятся доступны многие из рассмотренных ранее атак, наиболее опасными из которых будут:
Следующей немаловажной особенностью, которую мы ранее не рассматривали, но которая не перестает быть от этого менее важной, это то, что автоматизированные рабочие места (АРМ) пользователей тоже могут быть источником (например, при заражении вирусами или троянами) вредоносного воздействия на сервера.
Таким образом, перед нами встает задача защитить сервера внутренней сети от атак Нарушителя как из DMZ, так и из внутренней сети (заражение АРМа трояном можно интерпретировать как действия Нарушителя из внутренней сети).
Предлагаемый далее подход направлен на уменьшение числа каналов, через которые Нарушитель может атаковать сервера, а таких канала как минимум два. Первый это правило на DFW, разрешающее доступ к серверу внутренней сети из DMZ (пусть даже и с ограничением по IP-адресам), а второй — это открытый на сервере сетевой порт, по которому ожидаются запросы на подключение.
Закрыть указанные каналы можно, если сервер внутренней сети будет сам строить соединения до сервера в DMZ и будет делать это с помощью криптографически защищенных сетевых протоколов. Тогда не будет ни открытого порта, ни правила на DFW.
Но проблема в том, что обычные серверные службы не умеют работать подобным образом, и для реализации указанного подхода необходимо применять сетевое туннелирование, реализованное, например, с помощью SSH или VPN, а уже в рамках туннелей разрешать подключения от сервера в DMZ к серверу внутренней сети.
Общая схема работы данного варианта выглядит следующим образом:
Использование данного варианта на практике показало, что сетевые туннели удобно строить с помощью OpenVPN [23], поскольку он обладает следующими важными свойствами:
На первый взгляд может показаться, что данная схема излишне усложнена и что, раз на сервере внутренней сети все равно нужно устанавливать локальный межсетевой экран, то проще сделать, чтобы сервер из DMZ, как обычно, сам подключался к серверу внутренней сети, но делал это по шифрованному соединению. Действительно, данный вариант закроет много проблем, но он не сможет обеспечить главного — защиту от атак на уязвимости сервера внутренней сети, совершаемых за счет обхода межсетевого экрана с помощью IP и MAC spoofing.
Плюсы варианта:
Минусы варианта:
Аналогия с реальной жизнью
Основной смысл данного варианта в том, что доверенное лицо устанавливает связь с не доверенным, что похоже на ситуацию, когда при выдаче кредитов Банки сами перезванивают потенциальному заемщику с целью проверки данных.
© comfoson.890m.com
Итак, мы рассмотрели все пять заявленных вариантов организации доступа к сервисам корпоративной сети из Интернет. Какой из них лучше, какой хуже — сказать сложно, поскольку все зависит, в конечном счете, от той информации, которую необходимо защитить, и тех ресурсов, которыми компания располагает для защиты. Если ни ресурсов, ни знаний нет, то оптимальным будет первый вариант. Если же информация очень ценна, то комбинация четвертого и пятого вариантов даст непревзойденный уровень безопасности.
Автор: imbasoft
Источник [25]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/129247
Ссылки в тексте:
[1] Image: https://habrahabr.ru/post/302068/
[2] NAT: https://ru.wikipedia.org/wiki/NAT
[3] Port forwarding: https://en.wikipedia.org/wiki/Port_forwarding
[4] Front-End и Back-End: https://ru.wikipedia.org/wiki/Front_end_%D0%B8_Back_end
[5] TCP SYN Flood: https://ru.wikipedia.org/wiki/SYN-флуд
[6] slow http read: https://webware.biz/?p=3807
[7] CAM-table overflow: http://hakipedia.com/index.php/CAM_Table_Overflow
[8] ARP poisoning: https://ru.wikipedia.org/wiki/ARP-spoofing
[9] Rogue DHCP Server: https://en.wikipedia.org/wiki/Rogue_DHCP
[10] DHCP starvation: http://hakipedia.com/index.php/DHCP_Starvation
[11] VLAN hopping: http://hakipedia.com/index.php/VLAN_Hopping
[12] MAC flood: https://en.wikipedia.org/wiki/MAC_flooding
[13] UDP flood: http://docwiki.cisco.com/wiki/Internetwork_Design_Guide_--_UDP_Broadcast_Flooding
[14] TCP session hijacking: https://ru.wikipedia.org/wiki/TCP_hijacking
[15] TCP reset: https://ru.wikipedia.org/wiki/Атака_TCP_Reset
[16] Атаки на Web-приложения: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
[17] DNS cache poisoning: https://ru.wikipedia.org/wiki/DNS_cache_poisoning
[18] MAC spoofing: http://xgu.ru/wiki/MAC-spoofing
[19] IP spoofing: https://ru.wikipedia.org/wiki/IP-спуфинг
[20] trunk / access: http://xgu.ru/wiki/VLAN_%E2_Cisco
[21] TCP SYN Cookie: https://en.wikipedia.org/wiki/SYN_cookies
[22] так: http://www.ptsecurity.ru/ics/webinar_06mar.pdf
[23] OpenVPN: https://openvpn.net/
[24] сертифицированной криптографии: http://www.cryptocom.ru/products/openvpn.html
[25] Источник: https://habrahabr.ru/post/302068/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.