Спойлер: Open vSwitch версий меньше 1.11 уязвим перед атакой вида «flow flood», позволяющей злоумышленнику прервать работу сети отправкой относительно небольшого потока пакетов в адрес любой виртуальной машины. Версии 1.11 и старше проблеме не подвержены. Большинство серверов с OVS до сих пор используют OVS 1.4 или 1.9 (LTS-версии). Администраторам таких систем настоятельно рекомендуется обновить систему на более новую версию OVS.
Лирика: Прошло уже больше полутора лет с момента, когда я впервые сумел воспроизвести эту проблему. В рассылке OVS на жалобу сказали, что «в следующих версиях исправят» — и исправили, пол-года спустя. Однако, это исправление не коснулось LTS-версии, а значит, большинство систем, использующих OVS, всё так же уязвимо. Я пытался несколько раз связаться с Citrix'ом (т.к. он использует самую уязвимую версию OVS в составе Xen Server — в тот момент это был мой основной продукт для эксплуатации), но никакой внятной реакции не последовало. Сейчас у администраторов есть возможность устранить проблему малой кровью, так что я решил опубликовать описание очень простой в воспроизведении и крайне запутанной и в диагностике проблемы — проблеме «flow congestion», она же «flow flood attack», она же «странная неведомая фигня, из-за которой всё работает странно». Раньше в комментариях и в рассылках про эту проблему я уже несколько раз писал, но у меня ни разу не хватало пороху полностью описать проблему на русском языке так, чтобы суть проблемы была понятна обычному айтишнику. Исправляюсь.
Следующая строчка hping3 -i u10 virtual.machine.i.p
нарушает работоспособность хоста виртуализации, где запущена виртуальная машина. И не только хоста виртуализации — любую систему, работающую на Open vSwitch версий меньше 1.11. Я делаю особый упор на версиях 1.4.3 и 1.9, потому что они являются LTS-версиями и используются чаще всего.
Более суровая версия того же вызова, на этот раз с нарушением правил пользования сетью: hping3 --flood --rand-source virtual.machine.i.p
. Соотношение исходящего трафика (~10-60Мбит/с) и (потенциальной) пропускной способности интерфейса жертвы (2x10G, соотношение по доступной полосе атакующий/атакуемый порядка 1:300-1:1000) позволяет говорить именно про уязвимость, а не про традиционную DoS атаку флудом, забивающем каналы аплинков до нерабочего состояния.
Симптомы со стороны хоста виртуализации: неожиданные задержки при открытии соединений, рост потребления CPU процессом ovs-vswitchd до 100%, потеря пакетов для новых или малоактивных сессий. Если используется OVS 1.4, то процесс ovs-vswitchd не только съедает свои 100% CPU, но и начинает подъедать память и делает это со скоростью до 20 мегабайт в минуту, пока к нему не приходит добрый дедушка OOM и не проводит воспитательную беседу.
В отличие от обычных проблем с сетью, запущенные пинги с большой вероятностью «прорвутся», и как только flow с ними попадёт в ядро, ping работать будет без малейших нареканий, а вот новые соединения будет уже не установить. Это сильно затрудняет диагностику проблемы, потому что психологическое «пинги есть — сеть работает» изжить очень сложно. Если к этому добавить, что «прорвавшаяся» ssh-сессия на хост будет продолжать работать так же без особых затруднений, то убедить администратора в том, что проблема с сетью со стороны хоста будет крайне и крайне сложно. Если флуд на интерфейс превышает некоторый порог (~50-80Мб/с), то любая адекватная сетевая активность прекращается. Но коварство описанной проблемы состоит в том, что значительная деградация сервиса происходит при значительно меньших нагрузках, при которых канонические средства диагностики сети рапортуют «всё в порядке».
Пользуясь случаем хочу извиниться перед si14, который о странности с сетью у лабораторных виртуалок говорил, но не мог мне доказать их наличие, а я «видел», что у меня всё хорошо, и потребовалось больше года, пока я, наконец, не только сам заподозрил неладное, но и смог найти однозначный краш-тест.
В случае XenServer ситуация с OVS осложняется тем, что локальный management-трафик так же идёт через бридж Open vSwitch, а все бриджи обслуживаются одним процессом ovs-vswitchd, то есть счастливый администратор даже не сможет посмотреть на эти симптомы — его просто не пустят по ssh. А если пустят — то см выше, про «проблем нет». Поскольку трафик NAS/SAN так же идёт через бридж, то даже после исчезновения причин, виртуальные машины с большой вероятностью останутся в нерабочем состоянии. В этом случае симптомы проблемы — «неожиданное зависание, начавшееся с лагов и потери пакетов».
Описание уязвимости с точки зрения «production manager'а» — любой школьник с 10-50 мегабитным каналом на ADSL может положить всю ферму серверов виртуализации с десятигигабитными портами, если с них хотя бы одна виртуалка «смотрит» интерфейсом в интернет. И правила/ACL внутри виртуалки практически не помогут. Аналогичное может устроить любой пользователь любой виртуалки, даже лишённой доступа в интернет.
Техническое описание проблемы
Читать полностью »