human after all
І при цьому вимкнути сервер, то флуд переростає в Unicast-флуд і поширюється на всі віртуальні інтерфейси на сервері, в деяких випадках на весь vlan, Якщо я вас правильно зрозумів, мається на увазі unknown unicast flood.
Подальші поради, не знаючи топологію мережі, давати важко.
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-пристроях, швидше за все їх два)
Резюмуючи, на вашому місці я б:
1) розібрався з трафіком, наведеними в дампі, з настройками DNS-сервера
2) дозволив би тільки необхідний для роботи проекту трафік за допомогою ACL на обладнанні ДЦ
3) налаштував би чіткий моніторинг вашого сервера
Практично впевнений, що після реалізації пп. 1), 2) спостерігається проблема б зникла. Навіть якщо немає - варіанти я привів (зміна L2-налаштувань обладнання ДЦ, зміна схеми підключення)
UPD2:
Фільтрувати ніякої трафік не можна тому, що це не наш трафік, а трафік в сторону клієнта, який орендував VDS. З цієї ж причини, кого-то блокувати не можна для вхідних пакетів, Не розумію, чому не можна фільтрувати клієнтський трафік. Так роблять практично всі. Коли на сервер, орендований за 100 доларів на місяць, приходить 10 гігабіт / c трафіку і більше, як правило, трафік до нього блокується з тієї простої причини, що витрати на трафік перевищують доходи від клієнта. Крім того, часто такий трафік загрожує самій інфраструктурі. Ви задали питання щодо анти-DDoS. Що це, якщо не фільтрація трафіку?
Далі, думаю, вам варто переробити схему аплинка, це найбільш просте і потенційно ефективне рішення. Так, щоб сервер був підключений до маршрутизатора L3-інтерфейсом і потім Маршрутізірованний (а не Брідж) трафік до клієнта. Я уявляю собі, як би це виглядало у випадку з L3-комутатором, але тут напевно виявляться невідомі мені нюанси реалізації підтримки мережі в Linux. Рекомендую схему перед застосуванням досконально протестувати.