Сказ про то, как Avito может за-DoS-ить прокси сервер Cisco WSA

Эта небольшая история про то, как произвольный, криво работающий, сайт в Интернете может свести с ума прокси сервер Cisco WSA, который позиционируется как решение класса "кровавый энтерпрайз". Последующее повествование будет идти от лица моего коллеги, работающего в Телеком блоке и обнаружившего ниже описанную аномалию.

Обратил внимание на то, что в конце Января появился странный трафик в ночное время на WAN-интерфейсе Cisco WSA, направленном в сторону резервного Интернет-провайдера.
Ровные "зубья пилы", входящего и исходящего трафика 10-40 Мбит.

При этом на другом сервере Cisco WSA, подключенном WAN-интерфейсом к основному Интернет-провайдеру, ничего подобного нет - ровный трафик в районе 1 Мбита.

Самое любопытное, что на LAN-интерфейсе со стороны ЛВС у Cisco WSA трафика почти нет, то есть весь этот трафик приходит и уходит на внешнем интерфейсе WSA, отражаясь как-будто зеркало.

Пытаясь понять что происходит, в ночное время снял дамп трафика с порта коммутатора и обнаружил жёсткий клинч между сайтом Avito и сервером Cisco WSA, который, как позже выяснилось, длился уже неделю.
Сервер WSA пытался установить TCP-соединение по порту 443 к хосту 146.158.54.5 (один из веб-узлов Avito, socket.avito.ru), на что хост ответил стандартным SYN ACK, но установил при этом размер окна соединения в 0.
То есть данные передавать пока нельзя и надо ждать пока размер окна увеличится.
На это WSA отправляет подтверждение приёма этого ответа ACK.
Но веб-узел Avito продолжает бесконечно отправлять повторные SYN ACK с нулевым окном, а WSA отправляет на это ACK.
В итоге соединение в недоустановленном состоянии, данные отправлять нельзя и 60 байт туда и обратно гоняются в пустую в бесконечном цикле, что и формирует 10-40 Мбит мусорного трафика.

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

Очевидно, что здесь имеет место быть какая-то кривая конфигурация веб-сервера Avito и это приводит к серьёзной мусорной утилизации канала.

В начале этой недели ситуация повторилась уже сразу на двух разных серверах Cisco WSA, подключенных к разным Интернет-провайдерам. Произошёл аналогичный клинч при работе с веб-узлом Avito 146.158.52.2

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

Стало очевидно, что теперь такое списать на "вспышки на Солнце" не получится и нужно принимать меры по предотвращению подобной ситуации в дальнейшем. Вопрос, заданный тех.поддержке Cisco по январскому случаю два месяца назад так и остался без решения. А предлагаемое ими обходное решение во всех подобных непонятных ситуациях с периодической перезагрузкой серверов WSA адекватным решением считать довольно трудно.

Было решено на брандмауэре маршрутизатора, который стоял между Интернетом и Cisco WSA фиксировать превышение рейта SYN/АСК пакетов и блокировать такой трафик.

Для логирования трафика в правилах форвардинга трафика в iptables на пограничном маршрутизаторе было написано правило:

iptables -I FORWARD -i bond0.100 -p tcp --tcp-flags SYN,ACK SYN,ACK -m hashlimit --hashlimit-name avitodos --hashlimit-mode srcip --hashlimit-above 100/sec --hashlimit-burst 50 -m limit --limit 1/sec --limit-burst 1 -j LOG --log-prefix "syn_ack_dos "

То есть, на входящем из Интернета интерфейсе (в нашем случае это bond0.100) фильтруем трафик с флагами SYN+ACK, у которого скорость более 100 пакетов в секунду с одного SRC IP.
Если условия выполняются, то пишем в журнал событие (не более одного сообщения в секунду).

Это правило позволило в течение нескольких дней понять, будут срабатывания не связанные с проблемным веб-узлом Avito (чтобы исключить поломку сессий при работе с другими Интернет-узлами).
Анализ логов за пару дней показал, что кроме хостов Avito подобной аномалии при работе с другими Интернет-хостами не наблюдается, поэтому правило можно расширить временной блокировкой подобных соединений.
В итоге получилось пару таких правил:

iptables -I FORWARD -i bond0.100 -p tcp --tcp-flags SYN,ACK SYN,ACK -m hashlimit --hashlimit-name avitodos --hashlimit-mode srcip --hashlimit-above 100/sec --hashlimit-burst 50 -m limit --limit 1/sec --limit-burst 1 -j LOG --log-prefix "syn_ack_dos " -m recent --name avito --set

iptables -I FORWARD -m recent --name avito --rcheck --seconds 120 -j DROP

Для блокировки подобного отловленного мусорного трафика можно использовать модуль iptables recent.
Мы можем добавить правило блокировки проблемного IP-адреса, например, на 2 минуты.
Блокировка всех входящих пакетов на 2 минуты нужна для того, чтобы таймаут TCP-сессии сработал и данная некорректная сессия разорвалась между удалённым веб-узлом и сервером WSA.

Использование указанных iptables правил на пограничном маршрутизаторе между Cisco WSA и Интернетом решило описанную проблему.

Судя по логам, сегодня снова был "пойман за руку" веб-узел Avito (146.158.54.2) и наш маршрутизатор выполнил DROP вредительских пакетов (33 пакета было прибито, прежде чем Avito угомонился)
Ложных срабатываний для других веб-узлов зафиксировано до текущего момента не было, то есть выбранный рейт 100pps вполне подходит для правила iptables.

Из этой истории можно сделать много разных и интересных выводов. Но мне хочется, чтобы помимо этих выводов, данная история стала очередным звоночком для тех, кто косо смотрит в сторону решений на базе свободного программного обеспечения, полагая что неуправляемый Squid древней версии с навешенной сверху эмблемой Cisco - это лучше, чем самостоятельно развёрнутый, обновляемый и управляемый Squid на базе Linux.