В этом посте представляю на суд хабрасообществу результаты своих неумелых и несистематических опытов с VMware vSphere 4.1
О работе
Данное исследование я проводил в рамках специального раздела своего дипломного проекта.
Исследовательская часть основывается на переводе стандарта NIST SP 800-125 (см. пост).
Перед специальным разделом была поставлена задача изучить наиболее вероятные угрозы, поэтому была выбрана модель внутреннего нарушителя.
О стенде
Стенд представляет собой кластер из 3 ESX 4.1 серверов, на которых крутятся 4 ВМ (две под Ubuntu 12.10, две под WinServer 2008 R2), имеющие по две vNIC: в общий маршрутизируемый в локальный сегмент лабораторный VLAN и изолированный VLAN.
Из прикладного ПО использовались:
- Wireshark 1.8.7 для Windows
- Пакеты tcpdump и dsniff
Опыты
Sniffing
Первое, чтоя начал исследовать — promiscuous режим виртуального коммутатора. Уже в процессе наткнулся на хорошую исчерпывающую статью на VMware Community. Т.к. оригинал всегда лучше пересказа, рекомендую воспользоваться прямой ссылкой.
MAC spoofing
Физические достаточно «умные» коммутаторы имеют в себе механизмы, предотвращающие атаки типа Подмена MAC-адреса. Это, например, настройки port security в коммутаторах фирмы Cisco Systems, с помощью которых можно жестко прописать разрешенные адреса для каждого порта устройства.
В виртуальной среде есть своя специфика. Все настройки ВМ, в том числе MAC адрес, хранятся в файлах ВМ, изменить которые уполномочен только администратор виртуализированной инфраструктуры. Создавать ВМ и подключать их к группам виртуальных портов, равно как и к VLAN, способен также только он. Кроме того, существует настройка MAC Address Changes – Accept/Reject, разрешающая либо запрещающая гостевым ОС выходить в сеть с адресом, отличным от записанного в файле ВМ (которая, впрочем, по умолчанию разрешает подмену).
Было бы логично запретить изменение адреса, однако, не сложно представить ситуацию, когда заказчику услуги IaaS (Infrastructure as a service – инфраструктура в качестве услуги) понадобится эта возможность (например, для тестирования своего ПО).
Один из вариантов: поступить так же, как с предыдущей угрозой – разделить VLAN на части с различными настройками.
Рассмотрим второй вариант, когда администратор ВВИ по некомпетентности либо в надежде на провидение разработчиков VMware, оставляет настройки по умолчанию (режим Promiscuous для группы портов не включен).
Целевым информационным потоком пусть будет ICMP-обмен между одной из ВМ под Windows с внешним хостом (из локальной сети).
Все, чем должен обладать атакующий: MAC адрес жертвы и права локального администратора гостевой ОС в своей ВМ.
Атака:
sudo su –
ifconfig eth0 down
ifconfig eth0 hw ether NEW_MAC
ifconfig eth0 up
tcpdump –n src host 10.106.30.104
Результат: атакующий перехватывает весь обмен. Кроме того, атаку очень сложно обнаружить. Частота приходящих на атакуемую ВМ запросов не изменилась и равна частоте перехватываемых на атакующей, из чего следует, что виртуальный коммутатор просто дублирует пакеты. Межсетевое взаимодействие машин так же не нарушается. Становится невозможным только прямой обмен между этими ВМ.
MAC flood
Самый «нечистый» эксперимент, проведенный необдуманно, но приведший к интересным последствиям и, безусловно, требующий более подробного исследования.
Каждый физический коммутатор при работе оперирует данными CAM (Content Addressable Memory) или, попросту, таблицей коммутации. Объём её для разных моделей варьируется. Например (данные нагуглены невесть где и не претендуют на научную истину):
- Cisco Catalyst 2960 — до 8000 MAC адресов;
- Cisco Catalyst 3560 — до 12000 MAC адресов;
- Cisco Catalyst 6500 — до 96000 MAC адресов.
При переполнении CAM таблицы, новые записи не смогут добавляться, весь трафик будет проходить на все порты (хотя, в общем случае, коммутаторы могут повести себя по-разному). Атакующий может «прослушать» весь сетевой трафик и получить конфиденциальную информацию.
Для подавления такой атаки, необходимо указать, что на порте коммутатора, к которому подключен пользователь, может быть, к примеру, не больше одного MAC адреса, а в случае если появляется более одного, перевести порт в отключенное состояние и отправить сообщение администратору о нарушении безопасности (например, настройки port security в Cisco).
В VMware существует настройка Forged Transmits – Accept/Reject, но, как уже обсуждалось выше, могут возникнуть ситуации, когда применить её нет возможности. Поэтому и возникает необходимость уточнения возможных последствий подобных атак с целью управления рисками.
Для реализации атаки использовалась программа macof из пакета dsniff.
Сразу скажу о недостатках эксперимента:
- Первый, он же главный: атакующие находились в маршрутизируемом VLAN, атакуемые — в изолированном. Было бы куда правильнее сделать наоборот.
- Второй — недостаток схемы. Из-за использования кластера сложно судить о результатах
Но обо всем по порядку.
С началом атаки сразу возрос пакетный джиттер,
но пока ничего критичного.
Через пару минут консоли ВМ стали заметно «тормозить», отдельные пакеты стали теряться.
Наконец, где-то через 5-7 минут после начала, рухнуло все: перед тем, как отвалилось подключение клиента к vCenter успел заметить сообщения недоступности отдельных ВМ, консоли ВМ не открывались — отказал стоечный коммутатор (Top of Rack).
На практике это означает не только DoS публичного сервиса, но и, возможно, некоторых внутренних служб провайдера, что не может являться допустимым риском, а значит, требуются контрмеры.
Нужно сказать, перехода виртуального коммутатора в режим хаба я не зафиксировал (по крайней мере, VLAN'ы разделялись до последнего).
Из-за вышеописаных недостатков теста, сложно сказать, что именно случилось и что было истинной причиной (по крайней мере, для меня). Буду очень рад, если кто-либо в коментариях (или в л.с.) возмется разложить результат по полочкам.
Это все самое интересное из проделанной мною работы.
Жду обратной связи: пожеланий, советов, исправлений и всего другого. =) Спасибо за внимание.
Автор: valodik
