Ru-Board.club
← Вернуться в раздел «В помощь системному администратору»

» Риски использования Hyper-V

Автор: progmike
Дата сообщения: 25.03.2013 13:43
Копипаст обсуждения из темы про Kerio Control

Речь про риски/предпочтения по установке файервола Kerio Control (или любого другого) в виде виртуальной машины под управлением Hyper-V. Параллельные виртуальные машины - контроллер домена, веб-сервер и т.д.

coder666: кратко: аргументы в пользу виртуализации в целом
[more]1. Удобная миграция в последующем на другой сервер
2. Экономия на железе для второго, третьего... и т.д. компа
3. Сокращение занимаемой площади
4. Уменьшение коммуникаций
5. Банальная экономия электроэнергии

Продолжать?[/more]

stinger996669: кратко: Установка прикладного файрвола на hyper-v это дырища
[more]Установка прикладного файрвола на hyper-v это даже не дыра, это дырища в информационной безопасности.
Если простой сервера на минуту может оцениваться убытками для компании даже хотя бы в десятки у.е. то кому нужны все эти ваши 5 пунктов + "продолжать?"...
Лучше уж файрвол вообще не ставить - мороки меньше + все те же вышеперечисленные 5 пунктов + нет потраченного времени на поиски в форумах. [/more]

stinger996669: кратко: я не против Hyper-V, я против установки файрвола на сервере с Hyper-V
[more]
Цитата:
О боже какой маразм!


Цитата:
Чем тебе так сильно неугодила эта УДОБНАЯ технология? Неумение пользоватся не значит что


Ребят Вы мой постскриптум читали ??? Я специально подчеркнул, что я не против Hyper-V, я против установки файрвола на сервере с Hyper-V. Корпоративный файрвол - это обязательно выделенное устройство (машина), которая стоит перед серверами.
Маразм ставить Корпоративный файвол на машину, на которой бегают другие сервисы, так как при падении самого файвола слетают все остальные критичные сервисы.

Еще раз, если ставить Керио на Hyper-V, то лучше ничего другого на этот Hyper-V не ставить, это неправильно и опасно.
Я сам активно и успешно юзаю эту технологию у меня 2 сервера виртуализации, на которых, в обшем, 8 различных серверов. Эти 2 сервера Hyper-V стоят за Керио.

И кто сказал, что для Appliance версии нужен обязательно мощный сервер???

С каких пор машина с нижеследуюшими параметрами считается мощной, офигеваю.

CPU: 500 MHz
Memory: 1 GB RAM
Hard drive: 8 GB HDD space for OS, product, logs and statistics data
Network interface: 2 Ethernet (10/100/1000 Mbit)
П.С. Имеется ввиду не Hyper-V вообще, а именно Керио на Hyper-V !!! [/more]

progmike: кратко: мой наезд, сори
[more]
Цитата:
Маразм ставить Корпоративный файвол на машину, на которой бегают другие сервисы, так как при падении самого файвола слетают все остальные критичные сервисы.

Простите, Вы бредите. Или не знаете принципов виртуализации. Описанная Вами ситуация не возможна.

Цитата:
Еще раз, если ставить Керио на Hyper-V, то лучше ничего другого на этот Hyper-V не ставить

Не понял Ваш совет - ставить сервер виртуализации, что бы виртуализированть не более одного файервола??

Цитата:
Я сам активно и успешно юзаю эту технологию у меня 2 сервера виртуализации, на которых, в обшем, 8 различных серверов.

И что, зависание любой одной виртуальной машины приводит к краху всех других? Вы не умеете их готовить (с)

Kerio Control (как любой другой продукт аналогичного назначения) прекрасно работают под Hyper-V и не создают никакой опасности для производительности любого количества (по возможностям железа, ессно) других виртуальных машин.

Опасность взлома виртуальной машины с Kerio Control и получение доступа к другим виртуальным машинам вероятно на столько же, на сколько вероятен взлом отдельной железки с Kerio Control.
[/more]

stinger996669: кратко: описание рисков взлома файервола
[more]
Цитата:
Простите, Вы бредите. Или не знаете принципов виртуализации. Описанная Вами ситуация не возможна.

Уважаемый, я где-нибудь написал "зависание"?
Я рассматриваю данный пример в ракурсе информационной безопасности. Не надо разводить демагогию.
Под словом падение я подразумеваю, взлом. Если зломушленнику каким либо образом удастся взломать машину с Hyper-V с файрволом, он автоматически получает доступ к другим виртуальным машинам. Он может их просто остановить (в лучшем случае). Если сервер виртуализации находится за выделенным файрволом, то у сисадмина хотя-бы остается время для контрмер.

Цитата:
Не понял Ваш совет - ставить сервер виртуализации, что бы виртуализированть не более одного файервола??

Я привел пример, что у меня в организации стоит выделенный Appliance firewall Kerio, а серверы виртуализации, отдельно за ним. Фронт Энд файрвол на Виндовс я не поставлю, несмотря на все свое уважение к данной системе, так как виндовс более подвержен уязвимостям по сравнению с *NIX системами.

Цитата:
И что, зависание любой одной виртуальной машины приводит к краху всех других? Вы не умеете их готовить (с)

Никак не приводит. Скорее всего Вы меня привратно поняли.

Еще раз я против установки виртуального файрвола только из за соображений Информационной безопасности, а не по причине прерывания бизнесс процессов изза криворукости админа.

С уважением.
[/more]

progmike: кратко: риски взлома есть, но проигрыша Hyper-V нет
[more]Возможно где-то действительно не правильно понял...

Но это

Цитата:
Если зломушленнику каким либо образом удастся взломать машину с Hyper-V с файрволом, он автоматически получает доступ к другим виртуальным машинам.

не правда. Сервер с ролью Hyper-V может вообще не иметь сетевых адаптеров (назначенных для ОС - все адаптеры только для виртуалок)

Цитата:
Если сервер виртуализации находится за выделенным файрволом, то у сисадмина хотя-бы остается время для контрмер.

Ровно столько же времени, сколько и после взлома виртуализированного файервола.
[/more]

stinger996669: кратко: В случае с выделенным компом злоумышленник взламывает файервол, но это еще не значит что он получит доступ домену или другим службам
[more]
Цитата:
Сервер с ролью Hyper-V может вообще не иметь сетевых адаптеров (назначенных для ОС - все адаптеры только для виртуалок)

Совершенно согласен, но в данном примере у нас не этот случай, ветка же все-таки для Керио и тут у нас как минимум один выделенный сетевой адаптер который выходит в Интернет.

Конкретизирую пример, фактически у нас тут получается так:

Машина с Хайпер-Ви:
На ней виртуалки:
1. Керио (тут уже требуется внешняя линия для интернета)
2. Можно на вторую поставить Веб-Сервер
3. Почтовый сервер
4. RODC (я сюда первичный домен бы не поставил)

Честно говоря для меня составить эту схему сложно, потому что я себе такую схему даже не представляю, я сторонник выделенного файрвола. Или приведу более извратный пример, который я реально видел.

У человека, моего коллеги, в одной Кредитной Организации (!) в Косово на приличном сервере был Хайпер-Ви с такой конфигурацией.

1. Форефронт ТМГ
2. SQL 2005 со всеми кредитными данными клиентов (!!!)
3. Домен Контроллер
4. Файл сервер
х. на всех машинах были и другие сервисы

Представляете, что может произойти если на такую машину пойдет самая DDoS атака. Про более серьезные атаки молчу. Для первого примера, риску подвергается почтовый сервер организации, лично для моей организации это сверхкритично. Второе полетит веб сервер и если компания предоставлят веб услуги да и еще под контролем гос. регулятора - то это вообще хана котенку.

Помимо всего, для Виндовсов есть куча эксплойтов, злоумышленник может получть доступ к такой машине в обход файрвола. Если злоумышленнику теоретически удастся взломать такую машину, он сразу получает доступ к критичной информации например к личным данным клиентов.

В случае с выделенным Appliance-ом он взламывает систему Керио, но это еще не значит что он сразу и с наскока получит доступ домену или другим службам, имеющим свою собственную систему авторизации. Есть одно НО - я учитываю, что Керио не введен в домен и через него злоумышленник не получит доступа к каталогу юзеров.



Цитата:
Ровно столько же времени, сколько и после взлома виртуализированного файервола.


Насколько я знаю все известные эксплойты для Керио Appliance приводили к отказу работы системы. Если я не ошибаюсь то это приведет отказу выхода условной компании во внешнюю сеть, это уже серьезный сигнал для сетевого администратора, чтоб принять контрмеры.

В конце концов есть куча Best Practice примеров от серьезных компаний и ни в одним я еще не видел чтоб Файрвол работал на виртуальной машине с другими критичными "сервисами" (читай машинами) на одном сервере виртуализации. Любой уважающий себе ИТ аудит отметит такую конфигурацию как опасную для бизнесс процессов. [/more]

progmike: кратко: аргументы за безопасность виртуальной среды
[more]Я так не думаю и не согласен почти по всем пунктам.

1. Сервер MS Windows с ролью Hyper-V (хост) настраивает все сетевые адаптеры в трёх вариантах:
- внешняя - доступ виртуальных машин к физическому устройству (сетевой плате)
- внутренняя - сеть между всеми виртуальными машинами и хостом
- часная - сеть только между виртуальными машинами.

При этом, "внешние" сетевые адаптеры могут быть подключены к хосту (реальной машине), либо нет.

Вопрос: если Kerio Control в Hyper-V имеет две сетевые, среди которых:

а) внешняя, подключенная к сетевому адаптеру "Интернет", и НЕ подключенная к хосту;
б) внешняя, подключенная к сетевому адаптеру "Локальная", она же подключена ко все остальным виртуалкам, и НЕ подключена к хосту,

чем такое построение отличается от выделенного сервера под файервол, если учесть, что при отдельномй машине с Kerio Control, машинка с Hyper-V и критичными серверами находится в одной подсети (в моем примере хост с Hyper-V вообще изолирован) ?

2. Произведённая DDoS атака на файер (если, конечно, он не умеет от неё защищаться) приведет к пожиранию ресурсов и отказу в обслуживании (в нашем случае - отказ к доступу в интернет).

Если виртуальной машине с Kerio Control жёстко назначен лимит ресурсов (например, не более 50% времени процессора + относительно низкий приоритет) - DDoS может привести к отказу доступа в интернет (как и на реальной машине), но не сможет положить остальные виртуальные машины.

Кроме того не стоит забывать про встроенный IDS, который должен справиться с DDoS

3. Если будет использован эксплойт, и злоумышленник получит доступ к консоли Kerio Control (допустим), он в равной степени сможет произвести атаку как по внешней сети на виртуальные сервера, так и по физической сети (в случае выделенного сервера) - на все рядом стоящие сервера (включая Hyper-V).

Выходит, что в случае (3) сервер с Hyper-V вообще не пострадает при использовании Kerio Control в виде виртуальной машины. Это даст возможность, например, использовать резервные копии виртуалок для восстановления (и, кстати, очень быстрого) всех виртуальных машин.
Если же Kerio Control находится на выделенном сервере, он (в случае взлома) подвергает опасности сам хост Hyper-V. И в случае тотального взлома, и хост, и критичные сервисы, оказываются не рабочими.

4. На счёт вводить Kerio Control в состав домена или нет - тож мимо. На машине с контролом (в не зависимости от аппаратной части) не хранится пароль доступа к сервисам каталогов. Только хеш. Максимум, что сможет получить злоумышленник - списки доменных пользователей и компов. Воспользоваться списками будет крайне сложно, если учётная запись, с которой введён Kerio в домен является ограниченной "только для чтения" (например), поскольку и сервера в домене, и рабочие станции имеют собственные средства проверки подлинности и последние заплатки уязвимостей (в идеале, конечно же).[/more]

stinger996669: кратко: по всем 4 пунктам не могу сказать что Вы неправы, но и не убедил)
[more]Во всяком случае свою идею я довел.

На эту тему можно спорить очень долго и не менее нудно. Я могу привести достаточно контрдоводов по всем 4 пунктам, НО ... это уже будет демагогия и притом с моей стороны.

по всем 4 пунктам не могу сказать что Вы неправы. Но как Вы правильно заметили в самом конце - "в идеале конечно же" все это применимо ко всем Вашим контрдоводам. Так написано во всех характеристиках продуктов и это конечно же имеет место быть.
Неизвестные атаки и уязвимости никто не отменял. Заплатки и обновления на шаг позади. Бывают ситуации от которых никто не застрахован. А в нашем деле лучше перестраховаться, чем посыпать голову пеплом после.

Я отталкиваюсь от двух принципов.

Первый принцип: Файрвол должен быть обособлен от остальных машин в сети. Это показывают Best Practices как от самого Microsoft так и от Cisco, да и сами Кериоты советуют также.

Второй принцип:У Винды как системы все же больше уязвимостей чем у Линукса. Если бы это было не так, зачем тогда Кериоты отказались от Виндовс версии и проталкивают свой Эплайнс? Помимо всего они специально создали "железный" вариант Керио, это о чем то говорит.
[/more]

Уважаемые знатоки! Поделитесь, пожалуйста, мнениями по данному вопросу
Автор: stinger996669
Дата сообщения: 25.03.2013 14:05
Для начала и в пользу своей точки зрения выставляю две статьи с непоследний ресурсов рунета.

http://www.oszone.net/9193/

и

http://www.cnews.ru/reviews/free/virtualization/article/defence.shtml

Далее постараюсь добавить Best practices на русском.
Автор: asd_13
Дата сообщения: 28.05.2013 13:05

Цитата:
в пользу своей точки зрения выставляю две статьи


Мне кажется, что это не совсем правомерно, ведь интерфейс входа один, а следовательно, если на нем настроены средства защиты, значит они работают для всего траффика (т.е. представим себе трубу, входящую в многоквартирный дом и на ней установим фильтр, фильтроваться будет вся вода, входящая в дом и распределятся по квартирам)

а в случае со всяким внешним активным оборудованием так и вовсе проблем возникнуть не должно, ведь они стоят на этапе еще не доходя до сервера.

Так же взломщик получая доступ к гостевой системе, не получает доступ ко всем аппаратным устройствам, а получает доступ к виртуальным устройствам, т.о. он получает доступ не ко всем траффику ходящему по физическим портам, а только к траффику гостевой системы, я не исключаю конечно возможности обхода этого и нахождения дырок, потенциальная возможность всегда остается и даже аппаратные средства не защищают на 100%

Страницы: 1

Предыдущая тема: PRTG 12 перенос настроек на другой сервер


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.