И при этом выключить сервер, то флуд перерастает в Unicast-флуд и распространяется на все виртуальные интерфейсы на сервере, в некоторых случаях на весь vlan,
Если я вас правильно понял, подразумевается unknown unicast flood.
Ваш хост имеет адрес 109.XX.XX.XX.53? Какой именно трафик распространяется на весь влан - подобный указанному в дампе или, может быть, arp-запросы?
Я с libvirt не работал, но мысли касательно вашей ситуации такие. Есть некий маршрутизатор (устройство или виртуальная сущность), на котором активен IP-адрес из одного префикса ("подсети") с 109.XX.XX.XX.53. На нем есть arp-таблица, где IPv4-адресу 109.XX.XX.XX.53 соответствует некий MAC-адрес aaaa-bbbb-cccc (подразумевается использование ethernet). На (виртуальном) коммутаторе/бридже этому MAC-адресу соответствует некий виртуальный интерфейс.
Когда вы хост выключаете, возможны два варианта:
1) в таблице коммутатора исчезает запись, ставящая в соответствие MAC-адресу aaaa-bbbb-cccc некий виртуальный интерфейс. В таком случае будет наблюдаться unknown unicast flood, а именно трафик, подобный указанному на приведенном вами дампе, будет направляться во все интерфейсы коммутатора (хотя, могут быть нюансы, связанные с виртуализацией). Для решения проблемы вы можете или задать статическое соответствие MAC-адреса aaaa-bbbb-cccc нужному интерфейсу, или, если есть такая возможность, зафильтровать трафик, предназначенный для хоста с MAC-адресом aaaa-bbbb-cccc на время, пока соответствующий сервер неактивен, или фильтровать трафик на 109.XX.XX.XX.53 на вышестоящем оборудовании
2) в arp-таблице маршрутизатора исчезает запись, ставящая в соответствие IPv4-адресу 109.XX.XX.XX.53 MAC-адрес aaaa-bbbb-cccc. В таком случае маршрутизатор будет слать некоторое количество широковещательных arp-запросов. Количественные характеристики зависят от реализации, как именно это сделано в libvirt, трудно предполагать.
Что можно сделать со стороны активного оборудования, чтобы избежать подобных проблем в автоматическом режиме?
Не понимаю вашего фокуса именно на активном оборудовании. На мой взгляд, конструктивнее сначала попытаться решить проблему на уровне виртуализации. Представляется, что среда виртуализации предоставляет более удобные инструменты для автоматизации (т.е. различные скрипты и/или API). Если вышеописанное (установку статической записи в таблицу соответствия MAC-адрес <-> интерфейс коммутатора; установку фильтрующей записи в ту же таблицу, см. cisco-аналог mac address-table static MACADDRESS vlan VLANID drop; фильтрацию на основе L3-данных) не получится реализовать на сервере виртуализации, можно попытаться фильтровать трафик до 109.XX.XX.XX.53 на вышестоящем оборудовании, но сомневаюсь, что это можно будет удобно автоматизировать.
Дальнейшие советы, не зная топологию сети, давать затруднительно.
UPD:В примере, имелось ввиду, что 109.XX.XX.XX - это IP, 53 это порт,
Извините, проглядел. Вот именно поэтому я не люблю вывод tcpdump и предпочитаю оперировать дампом в виде pcap-файлов.
Я наблюдаю две проблемы:
1) мусорный трафик на один из ваших хостов
2) флуд (умножение) этого трафика на все ваши виртуальные сервера
Касательно первой проблемы есть вопросы. Как вы используете DNS-сервер? Как фильтруется доступ к нему? Если никак, то почему? Разрешены ли рекурсивные запросы? Если да, то желательно заблокировать их обработку, кроме того случая, когда вы точно знаете, что именно делаете. Я подозреваю, в данном случае имеет место попытка атаки 94.41.XX.XX при помощи вашего сервера (dns reflection attack, точнее можно будет сказать, если вы предоставите дамп трафика в формате .pcap, tcpdump -i -s 65535 -w ). Если гипотеза окажется верна, то есть вероятность, что такой мусорный трафик прекратится через некоторое время после того, как вы выключите обработку рекурсивных запросов.
Вообще говоря, я бы на вашем месте запретил бы весь трафик, кроме трафика вашего сервиса и управленческого (ssh, snmp и т.д.) трафика при помощи списков доступа (ACL) на активном оборудовании (на ближайших к вашему оборудованию L3-устройствах, скорее всего их два)
Теперь по второй проблеме.
сетевые инженеры Дата-центра говорят, что установили настройку для влана и свичей в ДЦ "mac-address-table aging-time = 14400"
Именно это, на мой взгляд, и вносит наиболее весомый вклад в проблему. При выключении вашего сервера коммутатор ДЦ еще 4 часа будет слать вам адресованный серверу трафик. Значение 14400 выбрано, скорее всего, с целью избежать проблем рассогласованности arp-таблицы и таблицы MAC-адресов при импользовании ECMP и FHRP (довольно распространенная проблема в ДЦ-окружении). Именно такое значение по умолчанию имеет срок жизни arp-записи в устройствах cisco, если мне не изменяет память.
Одно из возможных решений - снижение срока жизни записи таблицы MAC-адресов. Это возможно, если в ДЦ вам предоставлен отдельный коммутатор или если вам предоставлен отдельный влан (частая схема в ДЦ), и при этом оборудование ДЦ поддерживает изменение срока жизни записи таблицы MAC-адресов в зависимости от влана (cisco catalyst, если не ошибаюсь, это могут, в зависимости от версии IOS).
Второй вариант - при выключении виртуального сервера автоматически создавать соответствующее правило ebtables или статическую запись в таблице MAC-адресов виртуального бриджа, запрещающее трафик до него (думаю, в той или иной степени это реализуемо). Третий вариант - удаление записи таблицы MAC-адресов коммутатора ДЦ по запросу через какой-либо API на данный момент предстает малореальным. Кроме того, можно подумать о реорганизации схемы подключения вашего сервера к оборудованию провайдера с использованием двух L3-линков. В таком случае на вас не влияют L2-настройки оборудования ДЦ (сроки жизни записей arp-таблицы, таблицы mac-адресов), и ваш маршрутизатор (виртуальный) будет отбрасывать трафик до хоста, для которого нет ARP-записи (т.е. для выключенного).
Вы писали касательно описанного мною выше варианта:
Ситуацию спасает просьба о блокировке атакуемого IP на активном оборудовании, либо можно при помощи ebtables запретить форвардинг пакетов на атакуемый ip-адрес, тогда трафик будет идти просто на основной интерфейс физического сервера, не затрагивая виртуальные сервера. Оба варианта не являются выходом поскольку требуют постоянного присутствия как сетевых инженеров в ДЦ, так и приносят проблемы на физическом сервере, потому и хотелось бы узнать возможно ли в автоматическом режиме со стороны сетевого оборудования избегать таких проблем.
Я пока не понял, к каким проблемам на физическом сервере приводит фильтрация трафика при помощи ebtables. Необходимо понимать, что либо этот трафик (вредоносный, мусорный) каким-то образом фильтрует ДЦ (для этого он сначала должен по каким-то критериям этот злонамеренный трафик выявить, и не факт что его критерии совпадут с вашими), скорее всего за дополнительные деньги (услуга anti-DDoS), либо этот трафик доходит до оборудования под вашим управлением, и тогда уже вы его фильтруете так, как сочтете необходимым.
Резюмируя, на вашем месте я бы:
1) разобрался с трафиком, приведенным в дампе, с настройками DNS-сервера
2) разрешил бы только необходимый для работы проекта трафик при помощи ACL на оборудовании ДЦ
3) настроил бы внятный мониторинг вашего сервера
Практически уверен, что после реализации пп. 1), 2) наблюдаемая проблема бы исчезла. Даже если нет - варианты я привел (изменение L2-настроек оборудования ДЦ, изменение схемы подключения)
UPD2:Фильтровать никакой трафик нельзя потому, что это не наш трафик, а трафик в сторону клиента, который арендовал VDS. По этой же причине, кого-то блокировать нельзя для входящих пакетов,
Не понимаю, почему нельзя фильтровать клиентский трафик. Так делают практически все. Когда на сервер, арендуемый за 100 долларов в месяц, приходит 10 гигабит/c трафика и больше, как правило, трафик до него блокируется по той простой причине, что расходы на трафик превышают доходы от клиента. Кроме того, часто такой трафик угрожает самой инфраструктуре. Вы задали
вопрос касательно анти-DDoS. Что это, если не фильтрация трафика?
Далее, думаю, вам стоит переделать схему аплинка, это наиболее простое и потенциально эффективное решение. Так, чтобы сервер был подключен к маршрутизатору L3-интерфейсом и затем маршрутизировал (а не бриджил) трафик до клиента. Я представляю себе, как бы это выглядело в случае с L3-коммутатором, но тут наверняка проявятся неизвестные мне нюансы реализации поддержки сети в Linux. Рекомендую схему перед применением досконально протестировать.
