Curl Sourced DDoS: как обнаружить и как остановить?

Хорошо, сервер Ubuntu, которым я управляю, сегодня стал жертвой DDoS-атаки. Обычно это неприятно, но не так уж и важно. Несколько моментов с высокой нагрузкой на сервер, а потом все проходит. Сегодня все было иначе. Для справки, у меня годами шрамы от атак серверов. Но сегодня все было иначе. Читай дальше.

Решение было решено повторным включением ModSecurity правило, которое предотвращает curl доступ через вызов на чистый IP-адрес. Значение, если имя хоста mygreatsite.com и IP-адрес 123.456.78.90 и у меня есть виртуальный хост для mygreatsite.com и это включено. И ModSecurity активен с правилом, которое предотвращает curl доступ через вызов на чистый IP-адрес, тогда посетитель получит нужный контент при посещении mygreatsite.com, но заблокированы ModSecurity с помощью 403: Forbidden если они попытаются получить доступ к сайту через 123.456.78.90. Отличная проблема решена!

Но пока происходила атака, были ясны три вещи:

1. Процессы Apache через крышу: Загрузка процесса Apache, как показано в Munin был выше крыши и постоянно в 3 раза выше, чем обычно.
2. Не регистрируется соответствующий веб-трафик: Не было соответствующего трафика, зарегистрированного через Apache и отраженного в AWStats. Так продолжалось несколько часов. Это касается всех журналов на всех виртуальных хостах на сервере, включая виртуальный хост по умолчанию, который будет подключен к голому IP-адресу.
3. Нагрузка на сервер была умеренно высокой, но не типичным уровнем атаки: Хотя общая нагрузка на сервер была высокой, она выражалась только однозначными числами - 4, 5, 6, 7 и т. Д. - а не типичным DDoS-атакой, когда нагрузка может увеличиваться в два или даже в три раза, например, 20, 30 и даже 120 (!! !).

Для меня пункт номер 3 был самой необычной частью этой атаки. Я не сталкивался с DDoS-атаками, при которых загрузка сервера была бы в основном эквивалентом дня интенсивного трафика, а не безумной нагрузки на сервер, связанной с атакой.

Кроме того, работает elinks получить Apache server-status из командной строки показал, что пул соединений заполняется как сумасшедший в течение нескольких минут после перезапуска:

elinks http://localhost/server-status?refresh=1

И после всего этого я просто заметил патч безопасности Ubuntu сегодня специально для curl вопросы. И эта конкретная проблема вызвало у меня интерес:

libcurl неправильно проверяет SSL-сертификаты с подстановочными знаками, содержащие буквальные IP-адреса.

Итак, вот вопрос: Что, черт возьми, случилось? Я знаю, как повторно включить ModSecurity Правило остановило атаку, но могло ли это быть каким-либо образом связано с libcurl выпуск? И если да, то как я могу это обнаружить или доказать? И после этого, если проблема была в libcurl- что, как я предполагаю, исходит от вооруженных клиентов, использующих эту уязвимость, - значит ли это, что кто-то может просто сохранить взломанную старую версию curl снова к DDoS? И, написав это, любой хакер может просто загрузить исходный код и пропатчить его, чтобы взломать, так зачем сегодня флуд?

Думаю, это патч для curl заставили больше людей осознать ошибку, а «энтузиазм» скриптовых детишек по всему миру вызвал безумный поток сканирования в течение нескольких часов после обнаружения эксплойта? Но опять же, это меня смущает, потому что это на клиенте curl установить, правильно? Я не могу представить curl на стороне сервера будет жертвой этого.