Comments 23
Добавлю вариант организации доступа к корпоративным ресурсам с использованием класса продуктов Access Gateway. В этом случае вы ставите фронтом один сервер, который является реверс-прокси для всех остальных ресурсов. Наружу никакие корпоративные ресурсы напрямую не торчат, а становятся доступны только через Access Gateway. Получается как вариант с фрон-эндом, только он тут один для всех ресурсов, а следовательно сокращается количество векторов атак. Обычно Access Gateway обеспечивает не только сам доступ, но и аутентификацию, авторизацию, SSO.
Согласен. С точки зрения логики статьи это Вариант с Front-End. Сам пользовался Microsoft TMG UAG.
Добавил, потому что Access Gateway это все-таки один фронт-энд для разных ресурсов, в т.ч. для тех которые не предполагают наличие фронт-энда. Это сокращает количество серверов, торчащих наружу.
К тому же, если он обеспечивает централизованную аутентификацию, то решается вопрос с разными логинами/паролями от разных систем. Проходишь аутентификацию на единой точке входа, а дальше работает SSO для доступа к бэк-энд ресурсам. И не надо аутентифицироваться отдельно на каждом ресурсе. Плюс можно настроить многофакторную аутентификацию к ресурсам, которые сами по себе это не поддерживают.
Поэтому с точки зрения ИБ этот вариант отличается от публикации разных фронт-эндов от разных приложений.
К тому же, если он обеспечивает централизованную аутентификацию, то решается вопрос с разными логинами/паролями от разных систем. Проходишь аутентификацию на единой точке входа, а дальше работает SSO для доступа к бэк-энд ресурсам. И не надо аутентифицироваться отдельно на каждом ресурсе. Плюс можно настроить многофакторную аутентификацию к ресурсам, которые сами по себе это не поддерживают.
Поэтому с точки зрения ИБ этот вариант отличается от публикации разных фронт-эндов от разных приложений.
Очень интересно. Не увидел решения с подключением по VPN. По мне, так это более безопасно. Или предполагается, что есть какие-то ресурсы, которые нужно предоставить не только сотрудникам, но и гостям???
Про VPN, а точнее Remote Access VPN (если речь о сотрудниках) писать не стал, там свои нюансы. В целом статья про задачу публикации именно конечных сервисов, типа почтовика, корпоративного Web-сайта, Интернет Клиент-Банка и других систем. Если будет интересно про VPN, в части Remote Access (удаленка) или Site-Site (сопряжение офисов) можно про это будет сделать отдельный раздел.
UFO just landed and posted this here
В области безопасности нет единственно правильных решений. В статье приведены базовые принципы которые можно реализовать практически любыми средствами. Вы приводите ряд других — ок.
К сожалению ваш стиль изложения и лексикон не позволяет в полной мере понять того что вы хотите сказать. Например ваша фраза
Не раскрывает того, чем и как обнаруживается флудер, и сколько человек должно круглосуточно сидеть и смотреть в коммутаторы чтобы защитить продуктивные среды от DoS со стороны взломанного сервера из DMZ.
Про тазик с фрей и управляемые свичи и селерон за 10к — возможно в вашем случае это здорово. Хотя я не понял что вы хотели сказать. В тоже время попробуйте ответить на вопросы: Как быть если все сервера «живут» в вирутальной среде? Как вы будете обеспечивать надежность с помощью селерона и одной сетевой карты? Как через одну сетевую карту с кучей VLAN вы будете обеспечить ночной фул бэкап серверной инфраструкртуры на 10 Тб?
Почему? Потому что вы так не делали?
Вообще судя по объему комментария, вы неплохо потрудились, было бы здорово если вы приводили аргументы к своим утверждениям.
Но в целом спасибо за коммент.
К сожалению ваш стиль изложения и лексикон не позволяет в полной мере понять того что вы хотите сказать. Например ваша фраза
Защита от атак TCP SYN flood
Лечится изоляцией флудера, и дальше препарированием.
Не раскрывает того, чем и как обнаруживается флудер, и сколько человек должно круглосуточно сидеть и смотреть в коммутаторы чтобы защитить продуктивные среды от DoS со стороны взломанного сервера из DMZ.
Про тазик с фрей и управляемые свичи и селерон за 10к — возможно в вашем случае это здорово. Хотя я не понял что вы хотели сказать. В тоже время попробуйте ответить на вопросы: Как быть если все сервера «живут» в вирутальной среде? Как вы будете обеспечивать надежность с помощью селерона и одной сетевой карты? Как через одну сетевую карту с кучей VLAN вы будете обеспечить ночной фул бэкап серверной инфраструкртуры на 10 Тб?
Туннели в своей сети — идиотизм.
Почему? Потому что вы так не делали?
Вообще судя по объему комментария, вы неплохо потрудились, было бы здорово если вы приводили аргументы к своим утверждениям.
Но в целом спасибо за коммент.
Что значит виртуальная среда?
Это значит что используются исключительно виртуальные машины и между ними нет железных девайсов и сетевых устройств в привычном понимании.
Потому что туннели ничего кроме лишней административной работы и нагрузки CPU не дадут, всё тоже самое легко делается пробросом портов на фаерволе и правилами.
Туннель позволяет не открывать порт на сервере и не делать правила на межсетевом экране (проброс портов). Зачем это нужно ответил в статье.
А у вас тут соединяются свои сервера, не ужели в локалке настолько помойка и бардак что к ней нет доверия и никак это нельзя исправить?
Нет помойки, есть информация, стоимость которой весьма высока.
Хочу подчеркнуть важный момент. В статье приводятся только одни из возможных вариантов, они не являются единствено возможными.
Если хочется сравнить несколько вариантов по защищенности то это надо делать на моделе угроз.
Если сравнивать варианты по затратам то лучше это делать по стоимости владения (TCO) в 3 или 5 летней перспективе.
Туннель позволяет не открывать порт на сервере и не делать правила на межсетевом экране (проброс портов). Зачем это нужно ответил в статье.
Если я правильно понимаю, то у вас создастся динамическое правило на маршрутизаторе пропускающее трафик из DMZ в LAN, как только сервер из LAN попытается создать туннель до сервера в DMZ.
Чем это правило лучше статического правила на такой же пропуск трафика от сервера в DMZ к серверу в LAN?
Динамического правила не создается. Инициация подключений из Внутренней сети в DMZ и так не ограничивается.
Чтобы пакеты полетели из 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 по конкретному порту. А это равносильно тому же правилу на файрволе.
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 по конкретному порту. А это равносильно тому же правилу на файрволе.
Мы с вами рассуждаем о межсетевых экранов разного типа (поколения).
То что вы говорите — это пакетный фильтр, который принимает решение о транзите трафика только на основании данных заголовков.
В статье и моих коментах я оперирую правилами межсетевых экранов работающих с анализом состояния (stateful firewall) В них правила фильтрации помимо адресов учитывают состояния например new, established, invalid,… примером межсетевого экрана подобного класса является iptables. Поэтому при описании правил и применялась фраза — «разрешить инициацию соединений из внутренней сети в DMZ».
Оба типа межсетевых экранов применяются на практике. Пакетные фильтры используются на магистралях, где важна скорость. Statefull применяются на уровне сегментов корпоративных сетей, где важна защита от обхода с помощью фрагментации
То что вы говорите — это пакетный фильтр, который принимает решение о транзите трафика только на основании данных заголовков.
В статье и моих коментах я оперирую правилами межсетевых экранов работающих с анализом состояния (stateful firewall) В них правила фильтрации помимо адресов учитывают состояния например new, established, invalid,… примером межсетевого экрана подобного класса является iptables. Поэтому при описании правил и применялась фраза — «разрешить инициацию соединений из внутренней сети в DMZ».
Оба типа межсетевых экранов применяются на практике. Пакетные фильтры используются на магистралях, где важна скорость. Statefull применяются на уровне сегментов корпоративных сетей, где важна защита от обхода с помощью фрагментации
UFO just landed and posted this here
В случае заражения АРМ внутри сети он всё равно сможет долбить сервер в локалке, поскольку ему разрешено с ним работать, либо не сможет потому что у него туда доступа нет, тут туннели вообще не причём.
Back connect — технология защиты межсерверных связей. Пример ее использования — связь с сервера приложений (того, что обслуживает клиентов) с сервером баз данных. Сервер БД в данном случае будет инициатором построения туннелей и соответственно не будет иметь открытых портов by design. Почему это важно?
На практике, случаются случаи когда на защиту с помощью сетевых устройств нельзя положится на 100%. Это могут быть случаи когда:
- сетевые устройства не находится на поддержке производителя и не обновляются,
- сетевые устройства управляются на аутсорсинге
- квалификация администраторов недостаточна высока.
Другим примером ее использования обеспечение второго контура безопасности для защиты особо важных данных. Про актуальность этих задач можно посмотреть тут.
Нейтив влан чем вам помешал?
Довольно подробно описано тут.
Чем плохи открытые порты?
А вот это хороший вопрос. Проблема в том, что сетевая служба ожидающая подключение по порту может содержать уязвимости в коде и быть атакована Нарушителем.
Это можно проиллюстрировать на примере с Heartbleed уязвимостью и Web — приложением проводящим авторизацию на примере форм (Web выбран в только в качестве примера, аналогичная схемы может быть актуальна и для других сервисов).
Здесь неуполномоченные пользователи «отсекаются» авторизацией Web-приложения и вроде бы сервис защищен, но Нарушители могут атаковать непосредственно саму сетевую службу (в данном случае ее компонент — OpenSSL). Дабы не бороться с каждой подобной уязвимостью технология back connect позволяет закрыть сам канал атаки.
Почему вы считаете что EOL сетевого оборудование сам по себе проблема?
Наиболее понятным примером будут ошибки в BMC серверов, для которых нет патчей (не в природе, а для данной модели сервера) и из-за которого приходится этот функционал отключать.
Те ваш бэк коннект фактически эквивалентен пробросу порта на фаере и фильтрации подключений на конечных хостах?
С точки зрения функционала — да.
С точки зрения безопасности, вариант с межсетевым экраном шлюзового типа (железка то есть) проигрывает, потому как для описания правил фильтрации используются IP-адреса, а они могут быть подменены с помощью IP-spoofing. В тоже время применение локального межестевого экрана в технологии back connect лишено указной проблемы, поскольку он настраивается на фильтрацию в криптографически защищенном соединении (туннеле), в котором не возможна подмена данных.
На практике, back connect следует применять, только там где передается информация особой важности, например передача трафика содержащего аутентификационную информацию, или сведения о переводах денежных средств или управляющие воздействия автоматизированных систем управления технологическими процессами (АСУ ТП).
Более приземленным вариантом может быть защита взаимодействия RO DC c полнофункциональными контролерами домена. В некоторых схема high-security все пользователи авторизуются всегда через RO DC, а администрирование происходит на глубоко спрятанных полнофункциональных контролерах.
Те сам по себе EOL, без известных проблем, не проблема?
Проблема. И заключается она в том, что уязвимости в нем не публикуются, хотя это вовсе не значит что их нет. Пример Windows XP.
У меня три основных претензии к материалу:
1. Небезопасные способы представляются как возможные,
2. Отсутствует описание и защита автором разделения сети на зоны безопасности (спектр и назначение которых не ограничиваются dmz, trusted и untrusted),
3. Используется спорный вводящий в заблуждение оборот: «В области безопасности нет единственно правильных решений». Я не знаю, что происходит в оторванной от сетевого сегмента безопасности, но в сетевой сфере есть некоторый набор best practices. Любое решение, предлагающее поведение вразрез с best practices, должно быть доказано и проверено.
1. Небезопасные способы представляются как возможные,
2. Отсутствует описание и защита автором разделения сети на зоны безопасности (спектр и назначение которых не ограничиваются dmz, trusted и untrusted),
3. Используется спорный вводящий в заблуждение оборот: «В области безопасности нет единственно правильных решений». Я не знаю, что происходит в оторванной от сетевого сегмента безопасности, но в сетевой сфере есть некоторый набор best practices. Любое решение, предлагающее поведение вразрез с best practices, должно быть доказано и проверено.
Можно более конкретно, как разделы или утверждения вызывают претензии?
1. Небезопасные способы представляются как возможные.
Суть: не имеет смысла рассказывать о решении, которое не предлагает минимальный уровень безопасности.
Аналогия: ехать на машине со спущенными колесами можно, не мыть руки/продукты перед едой можно — в обоих случаях есть примеры ситуаций, когда сказанное будет верным. Это, однако, не относится к нормальной эксплуатации автомобиля и усредненному способу приема пищи.
Вариант №1 использовался когда-то, особенно когда не было необходимости что-то «публиковать». Сервера в нем не защищены от рабочих станций, а станции — от серверов. (В open plan клиенты и сотрудники не находятся в одном помещении, по крайней мере, это не является классическим определением).
Вариант №3 в предложенном виде — иллюзия безопасности. Бэк-энд находится в ситуации из вар.№1. Если вернуться к классической схеме (вариант №2) с двухуровневой фильтрацией, возникает вопрос: а правда ли уровень защиты внутри DMZ и внутри trusted зоны должны принципиально отличаться? Оправдано ли это для не-военных применений (а для военных, в свою очередь, возникнет вопрос: 1) в каком порядке ставить устройства, 2) что делать при компрометации внутреннего уровня, когда внешний еще, вроде бы, не был взломан публично?).
Вариант №4 — первая попытка помочь (кстати, кому? перечислены знания уровня CCNA) делом, однако я сейчас прочитал следующую фразу и удивился:
Что касается остальной части списка рекомендаций — именно с этого и стоило начать. Некоторые пункты спорные, чего-то не хватает (я не буду углубляться в подробности — в комментариях есть практически все, что должно было попасть в статью), но именно это было бы пособием по подключению.
Аналогия: вы можете начать объяснять ребенку, приучая к вилке, что раньше люди ели руками. А до этого ели ртом, и не с тарелки. Это никак не поможет вам приучить ребенка к вилке.
Статья же у вас не историческая, а рекомендательная. Если будете начинать историческую, попробуйте составить список RFC, на которые будете ссылаться. Ссылки на RFC сильно дисциплинируют и придают серьезность и ценность даже условно «легкому» чтению.
Вариант №5. Общая схема работы: вы поднимаете туннель в DMZ, а затем отправляете запросы из DMZ вовнутрь защищенного сегмента. Что вы собрались фильтровать на сервере внутри защищенного сегмента? 'drop table' отфильтруете? Я понимаю, что вы делаете, но не понимаю, зачем. Посыл «маршрутизаторов/коммутаторов может не быть / они могут быть не такими, как надо» ложен: нужное оборудование должно быть.
Заключение.
Я, кажется, начинаю понимать проблематику: вы предлагаете выбор между решением с нулевой стоимостью и решением с ненулевой стоимостью. Решение с нулевой стоимостью (в этом конкретном случае) приносит нулевую пользу. Консультация с нулевой пользой репутационно отрицательная. Решение с ненулевой и высокой стоимостью при соответствующем обосновании, даже не будучи востребованным, не может принести отрицательную репутацию.
2. Отсутствует описание и защита автором разделения сети на зоны безопасности.
Суть: объяснить широкому кругу читателей основные понятия современных реалий, не погружаясь в «непрофильный актив» — CAM overflow и проч. Не все понимают, зачем нужны зоны; почему нельзя просто написать много правил адрес-адрес или подсеть-подсеть. Большинство не настраивало сложные экраны а) с нуля б) самостоятельно. Почему бы не подарить радость знания? Казалось бы, просится из статьи для неподготовленного читателя.
3. Суть третьей претензии частично оформлена выше в подробном описании первых двух. Вы прикрываете отсутствие сложного материала и спорные решения утверждением, что нет единственно правильных решений.
Да, их нет, но не в описываемых примерах.
Стали бы вы советовать эти схемы заказчику с 30 офисами и 10 точками присутствия, включающими собственные сервера? А что бы стали? Вот это, вероятно, нашло бы более широкую аудиторию.
Таких заказчиков в мире много тысяч, и ваше решение может быть реализовано у одного из них. Стоит лишь предложить.
//Собственно, получился дайджест предыдущих комментариев к посту.
p.s. пардон, я отвечал на вопрос «какие», а не «как». Но оставлю как есть.
Суть: не имеет смысла рассказывать о решении, которое не предлагает минимальный уровень безопасности.
Аналогия: ехать на машине со спущенными колесами можно, не мыть руки/продукты перед едой можно — в обоих случаях есть примеры ситуаций, когда сказанное будет верным. Это, однако, не относится к нормальной эксплуатации автомобиля и усредненному способу приема пищи.
Вариант №1 использовался когда-то, особенно когда не было необходимости что-то «публиковать». Сервера в нем не защищены от рабочих станций, а станции — от серверов. (В open plan клиенты и сотрудники не находятся в одном помещении, по крайней мере, это не является классическим определением).
Вариант №3 в предложенном виде — иллюзия безопасности. Бэк-энд находится в ситуации из вар.№1. Если вернуться к классической схеме (вариант №2) с двухуровневой фильтрацией, возникает вопрос: а правда ли уровень защиты внутри DMZ и внутри trusted зоны должны принципиально отличаться? Оправдано ли это для не-военных применений (а для военных, в свою очередь, возникнет вопрос: 1) в каком порядке ставить устройства, 2) что делать при компрометации внутреннего уровня, когда внешний еще, вроде бы, не был взломан публично?).
Вариант №4 — первая попытка помочь (кстати, кому? перечислены знания уровня CCNA) делом, однако я сейчас прочитал следующую фразу и удивился:
DMZ разделяется на IP-подсети из расчета отдельная подсеть для каждого узла.Подсети /30 или /31? v4 или v6? А если серверов много? Ну как «много» — больше, чем /23 делённая на /30 — всего-то 128 шт. А функциональных зон тоже по количеству подсетей или нет? — если нет, зачем подсеть на сервер? (Почему /23 — потому что попробуйте столько найти, если всё, что у вас есть — /29 от провайдера, а сотня серверов — почему бы и нет для небольшого enterprise).
Что касается остальной части списка рекомендаций — именно с этого и стоило начать. Некоторые пункты спорные, чего-то не хватает (я не буду углубляться в подробности — в комментариях есть практически все, что должно было попасть в статью), но именно это было бы пособием по подключению.
Аналогия: вы можете начать объяснять ребенку, приучая к вилке, что раньше люди ели руками. А до этого ели ртом, и не с тарелки. Это никак не поможет вам приучить ребенка к вилке.
Статья же у вас не историческая, а рекомендательная. Если будете начинать историческую, попробуйте составить список RFC, на которые будете ссылаться. Ссылки на RFC сильно дисциплинируют и придают серьезность и ценность даже условно «легкому» чтению.
Вариант №5. Общая схема работы: вы поднимаете туннель в DMZ, а затем отправляете запросы из DMZ вовнутрь защищенного сегмента. Что вы собрались фильтровать на сервере внутри защищенного сегмента? 'drop table' отфильтруете? Я понимаю, что вы делаете, но не понимаю, зачем. Посыл «маршрутизаторов/коммутаторов может не быть / они могут быть не такими, как надо» ложен: нужное оборудование должно быть.
Заключение.
Какой из них лучше, какой хуже — сказать сложно— нет, не сложно. №4 лучше.
все зависит, в конечном счете, от той информации, которую необходимо защитить, и тех ресурсов, которыми компания располагает для защиты— верно, но не до конца. Зависит экономическое обоснование. Практически не зависит выбор схемы защиты, поскольку схема защиты у вас в статье ровно одна: поставить за firewall в отдельную зону.
Если ни ресурсов, ни знаний нет, то оптимальным будет первый вариант.— если ни ресурсов, ни знаний нет, надо найти ресурсы и купить знания. Если нечего продать, чтобы получить знания, возможно, защищать тоже ничего не надо и бизнес тоже открывать не стоит. Но мы же для успешных людей стараемся, верно?
Если же информация очень ценна— пожалуй, «Если» тут лишнее. Информация очень ценна.
Я, кажется, начинаю понимать проблематику: вы предлагаете выбор между решением с нулевой стоимостью и решением с ненулевой стоимостью. Решение с нулевой стоимостью (в этом конкретном случае) приносит нулевую пользу. Консультация с нулевой пользой репутационно отрицательная. Решение с ненулевой и высокой стоимостью при соответствующем обосновании, даже не будучи востребованным, не может принести отрицательную репутацию.
2. Отсутствует описание и защита автором разделения сети на зоны безопасности.
Суть: объяснить широкому кругу читателей основные понятия современных реалий, не погружаясь в «непрофильный актив» — CAM overflow и проч. Не все понимают, зачем нужны зоны; почему нельзя просто написать много правил адрес-адрес или подсеть-подсеть. Большинство не настраивало сложные экраны а) с нуля б) самостоятельно. Почему бы не подарить радость знания? Казалось бы, просится из статьи для неподготовленного читателя.
3. Суть третьей претензии частично оформлена выше в подробном описании первых двух. Вы прикрываете отсутствие сложного материала и спорные решения утверждением, что нет единственно правильных решений.
Да, их нет, но не в описываемых примерах.
Стали бы вы советовать эти схемы заказчику с 30 офисами и 10 точками присутствия, включающими собственные сервера? А что бы стали? Вот это, вероятно, нашло бы более широкую аудиторию.
Таких заказчиков в мире много тысяч, и ваше решение может быть реализовано у одного из них. Стоит лишь предложить.
//Собственно, получился дайджест предыдущих комментариев к посту.
p.s. пардон, я отвечал на вопрос «какие», а не «как». Но оставлю как есть.
Замысел статьи был показать «эволюцию» совершенствования мер защиты, где каждый новый вариант усиливает предыдущие, причем усиливает не просто так, а для защиты от конкретных угроз.
Все без исключения перечисленные варианты встречаются на практике. Даже «ненавистный» вариант 1.
Вариант 3 — по сути рекомендация Микрософт при публикации Exchange. Было бы здорово сегментировать и внутреннюю сеть (для защиты Back-End от АРМов сотрудников), но это на мой взгляд выходило за рамки данной статьи.
Вариант 4 — гайд для админов и работников ИБ при обосновании выбора защитных мер.
Разбиение сетей на подсети указано как принцип. Если публикуемых серверов много, выделите для них большего размера, например /16 (поскольку выход серверов Интернет в рассматриваемой статье базируется на DstNAT, сервера имеют внутренние адреса, вы можете по своему усмотрению управлять адресацией).
Вариант 5 — помимо прочих описанных в статье и комментариях случаев подходит для сетей компаний со сложной системой взаимоотношением владельцев, когда например инфраструктурой управляют люди лояльность которых вызывает сомнения, но на ситуацию повлиять нельзя.
Данный вариант показывает что можно построить безопасную сеть только с помощью серверов, без привлечения инфраструктурного оборудования. На back-end фильтруется (отбрасывается) все кроме целвых протоколов. Например, если back-end — СУБД, то оставляется только протокол взаимодействия с СУБД. Данный вариант был успешно внедрен на практике, для защиты платежных систем.
Безусловно, все рассмотренные меры внедрялись и показали свою работоспособность.
По ходу работы я видел большое количество реальных сетей (в то числе федеральных с десятками офисов по всей географии страны) и честно сказать ситуация с безопасностью была там «не очень», что собственно и натолкнуло меня написать данный гайд.
А, вообще, огромное спасибо за анализ, любая конструктивная критика помогает совершенствоваться.
Все без исключения перечисленные варианты встречаются на практике. Даже «ненавистный» вариант 1.
Вариант 3 — по сути рекомендация Микрософт при публикации Exchange. Было бы здорово сегментировать и внутреннюю сеть (для защиты Back-End от АРМов сотрудников), но это на мой взгляд выходило за рамки данной статьи.
Вариант 4 — гайд для админов и работников ИБ при обосновании выбора защитных мер.
Разбиение сетей на подсети указано как принцип. Если публикуемых серверов много, выделите для них большего размера, например /16 (поскольку выход серверов Интернет в рассматриваемой статье базируется на DstNAT, сервера имеют внутренние адреса, вы можете по своему усмотрению управлять адресацией).
Вариант 5 — помимо прочих описанных в статье и комментариях случаев подходит для сетей компаний со сложной системой взаимоотношением владельцев, когда например инфраструктурой управляют люди лояльность которых вызывает сомнения, но на ситуацию повлиять нельзя.
Данный вариант показывает что можно построить безопасную сеть только с помощью серверов, без привлечения инфраструктурного оборудования. На back-end фильтруется (отбрасывается) все кроме целвых протоколов. Например, если back-end — СУБД, то оставляется только протокол взаимодействия с СУБД. Данный вариант был успешно внедрен на практике, для защиты платежных систем.
Стали бы вы советовать эти схемы заказчику с 30 офисами и 10 точками присутствия
Безусловно, все рассмотренные меры внедрялись и показали свою работоспособность.
По ходу работы я видел большое количество реальных сетей (в то числе федеральных с десятками офисов по всей географии страны) и честно сказать ситуация с безопасностью была там «не очень», что собственно и натолкнуло меня написать данный гайд.
А, вообще, огромное спасибо за анализ, любая конструктивная критика помогает совершенствоваться.
Sign up to leave a comment.
Обзор вариантов организации доступа к сервисам корпоративной сети из Интернет