Даже не так :) Банк в течение 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 $ — они поднять не смогли.
А вообще, сейчас реально «поднять» данные только с носителей, имеющих физические дефекты (например, головка сгорела), а для данных имеющих логические повреждения (как из примера ранее) — это практически нереально.
Создание образа — это 3/100 от расследования. Реальная проблему взывает аналитика, особенно когда не знаешь что ищет и принесли машину «посмотреть».
В случаях проведения внутреннего расследование (без необходимости передачи данных в суд) анализ делают вообще без образа, прямо на живой системе, в параллель работе пользователя, либо с даунтаймом на час или парочку.
Но опять таки — аналитика, аналитика, аналитика :) вот что нужно.
Объясните мне пожалуйста экономическую эффективность солнечной энергетики.
Как я не считал, получается что «обычная сетевая электроэнергия» дешевле, причем в разы…
При расчете себестоимости солнечной электроэнергии (по 10 летним циклам) я учитывал:
1. Стоимость панелей
2. Ограниченный срок жизни панелей < 10 лет.
3. Необходимость технического обслуживания и чистки панелей (особенно снег зимой).
В отношении экологии — сказать что солнечная энергия это «очень чисто» тоже нельзя. Следует учесть эко-затраты на создание/утилизацию панелей и как минимум использование земли (в данном случае — зона отчуждения ЧАЭС это можно опустить)
В итоге, как вы считаете, есть ли практическая польза от солнечных электростанций в текущих экономических реалиях?
Подскажите, а есть ли PoC-exploit демонстрирующий возможность злонамеренного использования ME?
Без этого очень сложено обосновать IT и бизнесу необходимость выполнения подобных защитных мер.
Исходя из практики использования IT систем, можно сказать что вариант отключения ME подходит только для закрытых систем, то есть систем создаваемых с 0 и с конечным перечнем фирменного софта, рассчитанного на отсутствие ME.
Для компаний-потребителей, тех же Банков, такой вариант мало подойдет, поскольку затраты на минимизацию риска (отключение ME, доработку систем на то чтобы они работали в новых условиях) превысят ожидаемый ущерб от атак связанных с использованием уязвимостей ME. Статистики по взломам через ME пока нет. Данное утверждение поясню на примере — падение метеорита в Датацентр реально — ущерб потеря ДЦ, вероятность реализации риска ~ 0. Ожидаемый ущерб ~ 0.
В тоже время вопрос, какие варианты минимизации негативного влияния ME на безопасность вы можете предложить, не занимаясь отключением ME.
К сожалению ваш стиль изложения и лексикон не позволяет в полной мере понять того что вы хотите сказать. Например ваша фраза
Не раскрывает того, чем и как обнаруживается флудер, и сколько человек должно круглосуточно сидеть и смотреть в коммутаторы чтобы защитить продуктивные среды от 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).
Если у хостера нет ПДн в открытом виде, а хранятся только зашифрованные контейнеры (причем их шифровал сам клиент) то лицензии (ФСТЭК/ФСБ) не нужны.
Итого — у хостера в общем случае должна быть лицензия ФСТЭК России на ТЗКИ и желательно ФСБ России по криптографии
А вообще, сейчас реально «поднять» данные только с носителей, имеющих физические дефекты (например, головка сгорела), а для данных имеющих логические повреждения (как из примера ранее) — это практически нереально.
В случаях проведения внутреннего расследование (без необходимости передачи данных в суд) анализ делают вообще без образа, прямо на живой системе, в параллель работе пользователя, либо с даунтаймом на час или парочку.
Но опять таки — аналитика, аналитика, аналитика :) вот что нужно.
Было бы здорово иметь линки на русские переводы данных книг (при наличии)
Как я не считал, получается что «обычная сетевая электроэнергия» дешевле, причем в разы…
При расчете себестоимости солнечной электроэнергии (по 10 летним циклам) я учитывал:
1. Стоимость панелей
2. Ограниченный срок жизни панелей < 10 лет.
3. Необходимость технического обслуживания и чистки панелей (особенно снег зимой).
В отношении экологии — сказать что солнечная энергия это «очень чисто» тоже нельзя. Следует учесть эко-затраты на создание/утилизацию панелей и как минимум использование земли (в данном случае — зона отчуждения ЧАЭС это можно опустить)
В итоге, как вы считаете, есть ли практическая польза от солнечных электростанций в текущих экономических реалиях?
Без этого очень сложено обосновать IT и бизнесу необходимость выполнения подобных защитных мер.
Для компаний-потребителей, тех же Банков, такой вариант мало подойдет, поскольку затраты на минимизацию риска (отключение ME, доработку систем на то чтобы они работали в новых условиях) превысят ожидаемый ущерб от атак связанных с использованием уязвимостей ME. Статистики по взломам через ME пока нет. Данное утверждение поясню на примере — падение метеорита в Датацентр реально — ущерб потеря ДЦ, вероятность реализации риска ~ 0. Ожидаемый ущерб ~ 0.
В тоже время вопрос, какие варианты минимизации негативного влияния ME на безопасность вы можете предложить, не занимаясь отключением ME.