Вбить в конфиг и сохранить в файл или построить работающую сеть, использующую оборудование и операционные системы реализующие стандартные сетевые технологии?
Как кратко записать маску 255.0.255.0? Например, 255.255.255.0 получаем маску /24, а в вашем случае какая краткая маска получится?
Те ваш бэк коннект фактически эквивалентен пробросу порта на фаере и фильтрации подключений на конечных хостах?
С точки зрения функционала — да.
С точки зрения безопасности, вариант с межсетевым экраном шлюзового типа (железка то есть) проигрывает, потому как для описания правил фильтрации используются IP-адреса, а они могут быть подменены с помощью IP-spoofing. В тоже время применение локального межестевого экрана в технологии back connect лишено указной проблемы, поскольку он настраивается на фильтрацию в криптографически защищенном соединении (туннеле), в котором не возможна подмена данных.
На практике, back connect следует применять, только там где передается информация особой важности, например передача трафика содержащего аутентификационную информацию, или сведения о переводах денежных средств или управляющие воздействия автоматизированных систем управления технологическими процессами (АСУ ТП).
Более приземленным вариантом может быть защита взаимодействия RO DC c полнофункциональными контролерами домена. В некоторых схема high-security все пользователи авторизуются всегда через RO DC, а администрирование происходит на глубоко спрятанных полнофункциональных контролерах.
Те сам по себе EOL, без известных проблем, не проблема?
Проблема. И заключается она в том, что уязвимости в нем не публикуются, хотя это вовсе не значит что их нет. Пример Windows XP.
А вот это хороший вопрос. Проблема в том, что сетевая служба ожидающая подключение по порту может содержать уязвимости в коде и быть атакована Нарушителем.
Это можно проиллюстрировать на примере с Heartbleed уязвимостью и Web — приложением проводящим авторизацию на примере форм (Web выбран в только в качестве примера, аналогичная схемы может быть актуальна и для других сервисов).
Здесь неуполномоченные пользователи «отсекаются» авторизацией Web-приложения и вроде бы сервис защищен, но Нарушители могут атаковать непосредственно саму сетевую службу (в данном случае ее компонент — OpenSSL). Дабы не бороться с каждой подобной уязвимостью технология back connect позволяет закрыть сам канал атаки.
Почему вы считаете что EOL сетевого оборудование сам по себе проблема?
Наиболее понятным примером будут ошибки в BMC серверов, для которых нет патчей (не в природе, а для данной модели сервера) и из-за которого приходится этот функционал отключать.
Мы с вами рассуждаем о межсетевых экранов разного типа (поколения).
То что вы говорите — это пакетный фильтр, который принимает решение о транзите трафика только на основании данных заголовков.
В статье и моих коментах я оперирую правилами межсетевых экранов работающих с анализом состояния (stateful firewall) В них правила фильтрации помимо адресов учитывают состояния например new, established, invalid,… примером межсетевого экрана подобного класса является iptables. Поэтому при описании правил и применялась фраза — «разрешить инициацию соединений из внутренней сети в DMZ».
Оба типа межсетевых экранов применяются на практике. Пакетные фильтры используются на магистралях, где важна скорость. Statefull применяются на уровне сегментов корпоративных сетей, где важна защита от обхода с помощью фрагментации
В случае заражения АРМ внутри сети он всё равно сможет долбить сервер в локалке, поскольку ему разрешено с ним работать, либо не сможет потому что у него туда доступа нет, тут туннели вообще не причём.
Back connect — технология защиты межсерверных связей. Пример ее использования — связь с сервера приложений (того, что обслуживает клиентов) с сервером баз данных. Сервер БД в данном случае будет инициатором построения туннелей и соответственно не будет иметь открытых портов by design. Почему это важно?
На практике, случаются случаи когда на защиту с помощью сетевых устройств нельзя положится на 100%. Это могут быть случаи когда:
сетевые устройства не находится на поддержке производителя и не обновляются,
сетевые устройства управляются на аутсорсинге
квалификация администраторов недостаточна высока.
Другим примером ее использования обеспечение второго контура безопасности для защиты особо важных данных. Про актуальность этих задач можно посмотреть тут.
Это значит что используются исключительно виртуальные машины и между ними нет железных девайсов и сетевых устройств в привычном понимании.
Потому что туннели ничего кроме лишней административной работы и нагрузки CPU не дадут, всё тоже самое легко делается пробросом портов на фаерволе и правилами.
Туннель позволяет не открывать порт на сервере и не делать правила на межсетевом экране (проброс портов). Зачем это нужно ответил в статье.
А у вас тут соединяются свои сервера, не ужели в локалке настолько помойка и бардак что к ней нет доверия и никак это нельзя исправить?
Нет помойки, есть информация, стоимость которой весьма высока.
Хочу подчеркнуть важный момент. В статье приводятся только одни из возможных вариантов, они не являются единствено возможными.
Если хочется сравнить несколько вариантов по защищенности то это надо делать на моделе угроз.
Если сравнивать варианты по затратам то лучше это делать по стоимости владения (TCO) в 3 или 5 летней перспективе.
Если «сперли бабки» с карты надо делать так:
1. В течение 23 часов 50 минут звонить в КЦ (контакт центр), при этом желательно разговор записать, предупредив об этом сотрудника КЦ и попросить его назвать дату и время звонка.
2. В ходе разговора с КЦ детально описать суть оспариваемой транзакции.
3. После разговора с КЦ написать письменное заявление обязательно указав, что вы хотите что бы Банк вернул вам денежные средства.
4. Ждать ответа банка в течение 30 дней по Российским транзакциям и 60 по международным.
5. Если Банк не ответил то обращаемся в ЦБ.
6. Хуже не будет если написать заявление в полицию по факту кражи.
Даже не так :) Банк в течение 30/60 дней будет писать вам ответ о ходе разбирательства (по 161-ФЗ) деньги будут (если будут) возвращены по мере оспаривания транзакции в платежной системе,
В области безопасности нет единственно правильных решений. В статье приведены базовые принципы которые можно реализовать практически любыми средствами. Вы приводите ряд других — ок.
К сожалению ваш стиль изложения и лексикон не позволяет в полной мере понять того что вы хотите сказать. Например ваша фраза
Защита от атак TCP SYN flood
Лечится изоляцией флудера, и дальше препарированием.
Не раскрывает того, чем и как обнаруживается флудер, и сколько человек должно круглосуточно сидеть и смотреть в коммутаторы чтобы защитить продуктивные среды от DoS со стороны взломанного сервера из DMZ.
Про тазик с фрей и управляемые свичи и селерон за 10к — возможно в вашем случае это здорово. Хотя я не понял что вы хотели сказать. В тоже время попробуйте ответить на вопросы: Как быть если все сервера «живут» в вирутальной среде? Как вы будете обеспечивать надежность с помощью селерона и одной сетевой карты? Как через одну сетевую карту с кучей VLAN вы будете обеспечить ночной фул бэкап серверной инфраструкртуры на 10 Тб?
Туннели в своей сети — идиотизм.
Почему? Потому что вы так не делали?
Вообще судя по объему комментария, вы неплохо потрудились, было бы здорово если вы приводили аргументы к своим утверждениям.
Про VPN, а точнее Remote Access VPN (если речь о сотрудниках) писать не стал, там свои нюансы. В целом статья про задачу публикации именно конечных сервисов, типа почтовика, корпоративного Web-сайта, Интернет Клиент-Банка и других систем. Если будет интересно про VPN, в части Remote Access (удаленка) или Site-Site (сопряжение офисов) можно про это будет сделать отдельный раздел.
Друзья, у нас возникла буйная дискуссия по поводу данного метода. Чтобы изложить свою точку зрения комментариев оказалось мало, поэтому подготовил отдельную статью
Эти модули входят в состав устройств через которые компания выходит в интернет...
Подавляющее число компаний в России выходит в Интернет через бытовые роутеры а-ля DlInk или Linux-box, а те кто побогаче ставит Cisco типа ISR 2800. Устройства подобного класса реализуют Statefull firewall не более.
К NGFW относятся устройства уверенно работающие с deep packet inspection например железки Palo Alto которые по заверению производителя могут отличить HTTPS трафик от IE от HTTPS трафика Chrome и т.д. Open Source решения подобного плана, чтобы «скачать из Интернета и работало» ( без необходимости допила и НИОКРа) я не видел.
Как вы будете его настраивать на контроллере домена и куда вас пошлют админы с просьбой поставить туда OpenVPN?
Единственный вариант, когда нужно из DMZ разрешать доступ к контролеру домена внутри сети — это когда RO DC (read only domain controller) из DMZ хочет реплицироваться с полнофункциональным доменом внутри сети. Остальные случаи небезопасны by design. Проблем поставить OpenVPN на контролеры домена я не вижу. Работать он может как сервис, если нормально настроить то и связь устойчиво держит.
И проблема никуда не денется
Back connect туннели не защищают сервера от взлома, они призваны избавить от необходимости создания дыр в DMZ FW (то есть правил, пример которых вы указали) между DMZ и внутренней сетью.
Для защиты процессинга наверняка есть свои решения.
Конечно есть, но это не массовый NGFW. Поэтому просто «анализатор протокола», который есть в массовых решениях позволит вам защитить только массовые протоколы — TCP, HTTP и некоторый ряд других. Но подчеркну еще раз это не универсальное решение.
IPSec.
IPSec в чистом виде для back connect не подойдет. Почему? В нем нет понятия сервера (как компьютера, ожидающего подключения со стороны других компьютеров), туннель строится как по запросу сервера 1 (DMZ), так и по запросу сервера 2 (вн. сеть). Рассмотрим случай когда между сервером 1 и сервером 2 долго нет сетевого обмена и по тайм-ауту (или по другим причинам) туннель упал. Затем сервер 1 понял, что он хочет что-то передать серверу 2 он пытается к нему обратится, но поскольку дыры в DMZ нет — сделать он это не может.
С годами DMZ превращается в решето и теряет эффективность......C какой стати?
Под дырами в DMZ — подразумеваются легитимные «дыры» используемые легальными серверами для легальных целей. В вашем примере (если я вас правильно понял) есть фронт, который стоит в DMZ и есть back который находится внутри сети, причем фронт должен иметь возможность достучаться до бека. Для этого на DMZ FW вы разрешаете хождение трафика между фронтом в DMZ и бэокм внутри сети. Вот это правило я и называю дырой в DMZ.Если сеть растет (становится больше сервисов) таких правил становится все больше и больше.
Опасность дыры в том, взломанные сервера из DMZ могут ими воспользоваться, с помощью IP/MAC спуфинга для атак серверов внутри сети.
туннелирующий back connect… Что-что? Четыре фронта и четыре бекенда — это уже 16 туннелей городить, по четыре на хост? А что вообще даст этот туннель?
Подобный подход позволяет вообще не делать дырок в DMZ (то есть открытия маршрутизации из DMZ ко внутренней сети), а также защитить трафик от перехвата и модификации (ARP spoof и др MiTM-атак).
И как ими централизованно управлять
Не совсем понятно чем вы хотите управлять. Туннель строится на двух точках 1 — сервер в DMZ и 2 — сервер в внутрисети. Если сервер 1 похакан — управлять тунелями не надо, а надо восстанавливать контроль над сервером. Если имеется ввиду оперативная блокировка, то ее можно сделать на DMZ FW полностью заблокировав весь трафик до взломанного сервера.
NGFW, IPS — это устройства, цена покупки которых (не считая подписок на обновления и тех. поддержку) измеряется в килобаксах. Конечно если у вас есть на это деньги — здорово. SSH/VPN туннели (как вариант OpenVPN) — бесплатны. Настройка back connect через SSH — занимает пару часов (практический опыт).
Скажите пожалуйста, в каком из указанных вами устройств производится анализ протокола процессинга платежных карт TIC / TCI? Вопрос риторический :)
Применение SSH/VPN — защищает трафик от изменений при движении по остальной сети.
Актуальна эта угроза или нет можно понять, если сможете точно ответить на вопрос, где физически у вас проходят трассы линий связи. Для организаций находящихся в бизнес центрах, да и еще на разных этажах, это вопрос более чем актуален.
Каким образом броадкаст пакет из одной подсети (10.100.10.0/24) попадает в другую (10.100.11.0/24)?
Как обратится к по MAC в другую IP-подсеть?
Вбить в конфиг и сохранить в файл или построить работающую сеть, использующую оборудование и операционные системы реализующие стандартные сетевые технологии?
Как кратко записать маску 255.0.255.0? Например, 255.255.255.0 получаем маску /24, а в вашем случае какая краткая маска получится?
С точки зрения функционала — да.
С точки зрения безопасности, вариант с межсетевым экраном шлюзового типа (железка то есть) проигрывает, потому как для описания правил фильтрации используются IP-адреса, а они могут быть подменены с помощью IP-spoofing. В тоже время применение локального межестевого экрана в технологии back connect лишено указной проблемы, поскольку он настраивается на фильтрацию в криптографически защищенном соединении (туннеле), в котором не возможна подмена данных.
На практике, back connect следует применять, только там где передается информация особой важности, например передача трафика содержащего аутентификационную информацию, или сведения о переводах денежных средств или управляющие воздействия автоматизированных систем управления технологическими процессами (АСУ ТП).
Более приземленным вариантом может быть защита взаимодействия RO DC c полнофункциональными контролерами домена. В некоторых схема high-security все пользователи авторизуются всегда через RO DC, а администрирование происходит на глубоко спрятанных полнофункциональных контролерах.
Проблема. И заключается она в том, что уязвимости в нем не публикуются, хотя это вовсе не значит что их нет. Пример Windows XP.
Довольно подробно описано тут.
А вот это хороший вопрос. Проблема в том, что сетевая служба ожидающая подключение по порту может содержать уязвимости в коде и быть атакована Нарушителем.
Это можно проиллюстрировать на примере с Heartbleed уязвимостью и Web — приложением проводящим авторизацию на примере форм (Web выбран в только в качестве примера, аналогичная схемы может быть актуальна и для других сервисов).
Здесь неуполномоченные пользователи «отсекаются» авторизацией Web-приложения и вроде бы сервис защищен, но Нарушители могут атаковать непосредственно саму сетевую службу (в данном случае ее компонент — OpenSSL). Дабы не бороться с каждой подобной уязвимостью технология back connect позволяет закрыть сам канал атаки.
Наиболее понятным примером будут ошибки в BMC серверов, для которых нет патчей (не в природе, а для данной модели сервера) и из-за которого приходится этот функционал отключать.
То что вы говорите — это пакетный фильтр, который принимает решение о транзите трафика только на основании данных заголовков.
В статье и моих коментах я оперирую правилами межсетевых экранов работающих с анализом состояния (stateful firewall) В них правила фильтрации помимо адресов учитывают состояния например new, established, invalid,… примером межсетевого экрана подобного класса является iptables. Поэтому при описании правил и применялась фраза — «разрешить инициацию соединений из внутренней сети в DMZ».
Оба типа межсетевых экранов применяются на практике. Пакетные фильтры используются на магистралях, где важна скорость. Statefull применяются на уровне сегментов корпоративных сетей, где важна защита от обхода с помощью фрагментации
Back connect — технология защиты межсерверных связей. Пример ее использования — связь с сервера приложений (того, что обслуживает клиентов) с сервером баз данных. Сервер БД в данном случае будет инициатором построения туннелей и соответственно не будет иметь открытых портов by design. Почему это важно?
На практике, случаются случаи когда на защиту с помощью сетевых устройств нельзя положится на 100%. Это могут быть случаи когда:
Другим примером ее использования обеспечение второго контура безопасности для защиты особо важных данных. Про актуальность этих задач можно посмотреть тут.
Это значит что используются исключительно виртуальные машины и между ними нет железных девайсов и сетевых устройств в привычном понимании.
Туннель позволяет не открывать порт на сервере и не делать правила на межсетевом экране (проброс портов). Зачем это нужно ответил в статье.
Нет помойки, есть информация, стоимость которой весьма высока.
Хочу подчеркнуть важный момент. В статье приводятся только одни из возможных вариантов, они не являются единствено возможными.
Если хочется сравнить несколько вариантов по защищенности то это надо делать на моделе угроз.
Если сравнивать варианты по затратам то лучше это делать по стоимости владения (TCO) в 3 или 5 летней перспективе.
Оператор по переводу денежных средств — Банк. И только Банк обязан вам вернуть баблос, все остальные участники процесса могут только поохать.
А вообще в случае беды — учить наизусть ст. 9 161-ФЗ
1. В течение 23 часов 50 минут звонить в КЦ (контакт центр), при этом желательно разговор записать, предупредив об этом сотрудника КЦ и попросить его назвать дату и время звонка.
2. В ходе разговора с КЦ детально описать суть оспариваемой транзакции.
3. После разговора с КЦ написать письменное заявление обязательно указав, что вы хотите что бы Банк вернул вам денежные средства.
4. Ждать ответа банка в течение 30 дней по Российским транзакциям и 60 по международным.
5. Если Банк не ответил то обращаемся в ЦБ.
6. Хуже не будет если написать заявление в полицию по факту кражи.
К сожалению ваш стиль изложения и лексикон не позволяет в полной мере понять того что вы хотите сказать. Например ваша фраза
Не раскрывает того, чем и как обнаруживается флудер, и сколько человек должно круглосуточно сидеть и смотреть в коммутаторы чтобы защитить продуктивные среды от DoS со стороны взломанного сервера из DMZ.
Про тазик с фрей и управляемые свичи и селерон за 10к — возможно в вашем случае это здорово. Хотя я не понял что вы хотели сказать. В тоже время попробуйте ответить на вопросы: Как быть если все сервера «живут» в вирутальной среде? Как вы будете обеспечивать надежность с помощью селерона и одной сетевой карты? Как через одну сетевую карту с кучей VLAN вы будете обеспечить ночной фул бэкап серверной инфраструкртуры на 10 Тб?
Почему? Потому что вы так не делали?
Вообще судя по объему комментария, вы неплохо потрудились, было бы здорово если вы приводили аргументы к своим утверждениям.
Но в целом спасибо за коммент.
Подавляющее число компаний в России выходит в Интернет через бытовые роутеры а-ля DlInk или Linux-box, а те кто побогаче ставит Cisco типа ISR 2800. Устройства подобного класса реализуют Statefull firewall не более.
К NGFW относятся устройства уверенно работающие с deep packet inspection например железки Palo Alto которые по заверению производителя могут отличить HTTPS трафик от IE от HTTPS трафика Chrome и т.д. Open Source решения подобного плана, чтобы «скачать из Интернета и работало» ( без необходимости допила и НИОКРа) я не видел.
Единственный вариант, когда нужно из DMZ разрешать доступ к контролеру домена внутри сети — это когда RO DC (read only domain controller) из DMZ хочет реплицироваться с полнофункциональным доменом внутри сети. Остальные случаи небезопасны by design. Проблем поставить OpenVPN на контролеры домена я не вижу. Работать он может как сервис, если нормально настроить то и связь устойчиво держит.
Back connect туннели не защищают сервера от взлома, они призваны избавить от необходимости создания дыр в DMZ FW (то есть правил, пример которых вы указали) между DMZ и внутренней сетью.
Конечно есть, но это не массовый NGFW. Поэтому просто «анализатор протокола», который есть в массовых решениях позволит вам защитить только массовые протоколы — TCP, HTTP и некоторый ряд других. Но подчеркну еще раз это не универсальное решение.
IPSec в чистом виде для back connect не подойдет. Почему? В нем нет понятия сервера (как компьютера, ожидающего подключения со стороны других компьютеров), туннель строится как по запросу сервера 1 (DMZ), так и по запросу сервера 2 (вн. сеть). Рассмотрим случай когда между сервером 1 и сервером 2 долго нет сетевого обмена и по тайм-ауту (или по другим причинам) туннель упал. Затем сервер 1 понял, что он хочет что-то передать серверу 2 он пытается к нему обратится, но поскольку дыры в DMZ нет — сделать он это не может.
Под дырами в DMZ — подразумеваются легитимные «дыры» используемые легальными серверами для легальных целей. В вашем примере (если я вас правильно понял) есть фронт, который стоит в DMZ и есть back который находится внутри сети, причем фронт должен иметь возможность достучаться до бека. Для этого на DMZ FW вы разрешаете хождение трафика между фронтом в DMZ и бэокм внутри сети. Вот это правило я и называю дырой в DMZ.Если сеть растет (становится больше сервисов) таких правил становится все больше и больше.
Опасность дыры в том, взломанные сервера из DMZ могут ими воспользоваться, с помощью IP/MAC спуфинга для атак серверов внутри сети.
Подобный подход позволяет вообще не делать дырок в DMZ (то есть открытия маршрутизации из DMZ ко внутренней сети), а также защитить трафик от перехвата и модификации (ARP spoof и др MiTM-атак).
Не совсем понятно чем вы хотите управлять. Туннель строится на двух точках 1 — сервер в DMZ и 2 — сервер в внутрисети. Если сервер 1 похакан — управлять тунелями не надо, а надо восстанавливать контроль над сервером. Если имеется ввиду оперативная блокировка, то ее можно сделать на DMZ FW полностью заблокировав весь трафик до взломанного сервера.
Скажите пожалуйста, в каком из указанных вами устройств производится анализ протокола процессинга платежных карт TIC / TCI? Вопрос риторический :)
Применение SSH/VPN — защищает трафик от изменений при движении по остальной сети.
Актуальна эта угроза или нет можно понять, если сможете точно ответить на вопрос, где физически у вас проходят трассы линий связи. Для организаций находящихся в бизнес центрах, да и еще на разных этажах, это вопрос более чем актуален.