Мы с вами рассуждаем о межсетевых экранов разного типа (поколения).
То что вы говорите — это пакетный фильтр, который принимает решение о транзите трафика только на основании данных заголовков.
В статье и моих коментах я оперирую правилами межсетевых экранов работающих с анализом состояния (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 — защищает трафик от изменений при движении по остальной сети.
Актуальна эта угроза или нет можно понять, если сможете точно ответить на вопрос, где физически у вас проходят трассы линий связи. Для организаций находящихся в бизнес центрах, да и еще на разных этажах, это вопрос более чем актуален.
VLAN под каждый сервер — уменьшит возможность использования дырок в DMZ другими серверами, но возможность использования будет зависеть от сетевого оборудования и средств виртуализации которыми вы пользуетесь. VPN/SSH — универсальное бесплатное решение.
Анализатор протокола — это здорово, но какой протокол вы собираетесь анализировать? TCP/HTTP? Анализатор протоколов очень узкоспециализированное решение, как универсальное решение его рассматривать нельзя.
Я бы сказал, что указанное вами решение — альтернативно и имеет свои плюсы и минусы.
Вынос сервера в DMZ — пол дела. Большую проблему составляют обращения серверов из DMZ внутрь сети. Обычно для этого на DMZ-FW открывают маршрутизацию с конкретного IP:Port сервера в DMZ к конкретному IP:Port серверу внутри сети — то есть делают дырку в DMZ. С годами DMZ превращается в решето и теряет эффективность.
Для того, чтобы не делать дыры в DMZ-FW (по крайней мере радикально снизить их количество), связь между сервером в DMZ и сервером внутри сети делают через туннелирующий back connect, который может быть построен в виде VPN или SSH туннеля, где инициатором является сервер внутри сети.
Не указана необходимость регистрации в Котлонадзоре как оператора по обработке ПДн.
Про лицензии очень расплывчато написали.
Если персональные данные (ПДн) передаются хостеру (VDS) в открытом виде и хостер занимается их защитой. то нужна лицензия ФСТЭК России на техническую защиту конфиденциальной информации.
Если хостер шифрует ПДн клиента (например для хранения в защищенных контейнерах) и это является частью предоставляемых услуг, то нужна лицензия ФСБ России по криптографии (ПП 313).
Если у хостера нет ПДн в открытом виде, а хранятся только зашифрованные контейнеры (причем их шифровал сам клиент) то лицензии (ФСТЭК/ФСБ) не нужны.
Итого — у хостера в общем случае должна быть лицензия ФСТЭК России на ТЗКИ и желательно ФСБ России по криптографии
В свое время, пытались RAID-60 массив восстановить, а точнее один файл (снапшот виртуалки), обратились в специализированную компанию, были готовы заплатить ~20k $ — они поднять не смогли.
А вообще, сейчас реально «поднять» данные только с носителей, имеющих физические дефекты (например, головка сгорела), а для данных имеющих логические повреждения (как из примера ранее) — это практически нереально.
То что вы говорите — это пакетный фильтр, который принимает решение о транзите трафика только на основании данных заголовков.
В статье и моих коментах я оперирую правилами межсетевых экранов работающих с анализом состояния (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 — защищает трафик от изменений при движении по остальной сети.
Актуальна эта угроза или нет можно понять, если сможете точно ответить на вопрос, где физически у вас проходят трассы линий связи. Для организаций находящихся в бизнес центрах, да и еще на разных этажах, это вопрос более чем актуален.
VLAN под каждый сервер — уменьшит возможность использования дырок в DMZ другими серверами, но возможность использования будет зависеть от сетевого оборудования и средств виртуализации которыми вы пользуетесь. VPN/SSH — универсальное бесплатное решение.
Анализатор протокола — это здорово, но какой протокол вы собираетесь анализировать? TCP/HTTP? Анализатор протоколов очень узкоспециализированное решение, как универсальное решение его рассматривать нельзя.
Я бы сказал, что указанное вами решение — альтернативно и имеет свои плюсы и минусы.
Вынос сервера в DMZ — пол дела. Большую проблему составляют обращения серверов из DMZ внутрь сети. Обычно для этого на DMZ-FW открывают маршрутизацию с конкретного IP:Port сервера в DMZ к конкретному IP:Port серверу внутри сети — то есть делают дырку в DMZ. С годами DMZ превращается в решето и теряет эффективность.
Для того, чтобы не делать дыры в DMZ-FW (по крайней мере радикально снизить их количество), связь между сервером в DMZ и сервером внутри сети делают через туннелирующий back connect, который может быть построен в виде VPN или SSH туннеля, где инициатором является сервер внутри сети.
Поясню. У каждого хостера, позиционирующего себя в области услуг хостинга ПДн.
Про лицензии очень расплывчато написали.
Если персональные данные (ПДн) передаются хостеру (VDS) в открытом виде и хостер занимается их защитой. то нужна лицензия ФСТЭК России на техническую защиту конфиденциальной информации.
Если хостер шифрует ПДн клиента (например для хранения в защищенных контейнерах) и это является частью предоставляемых услуг, то нужна лицензия ФСБ России по криптографии (ПП 313).
Если у хостера нет ПДн в открытом виде, а хранятся только зашифрованные контейнеры (причем их шифровал сам клиент) то лицензии (ФСТЭК/ФСБ) не нужны.
Итого — у хостера в общем случае должна быть лицензия ФСТЭК России на ТЗКИ и желательно ФСБ России по криптографии
А вообще, сейчас реально «поднять» данные только с носителей, имеющих физические дефекты (например, головка сгорела), а для данных имеющих логические повреждения (как из примера ранее) — это практически нереально.