Кто-то недавно решил показать мне POC нового метода отказа в обслуживании с использованием SYN / TCP, который он выяснил. Я думал, что это полная чушь, но после того, как он объяснил ему о SYN-SYN / ACK-RST, он лишил меня дара речи. Он сказал мне: «Что, если сервер, который вы используете для обмана с отправкой пакетов SYN / ACK, не может получить пакет RST?»
Я понятия не имею. Он утверждает, что сервер продолжит попытки отправлять пакеты SYN / ACK, и что скорость пакетов будет продолжать расти.
Есть ли правда в этом? Кто-нибудь может уточнить?
Видимо, это работает так:
Он подменяет IP-адрес SYN-пакета на IP-адрес цели. Затем он отправляет SYN-пакет на несколько случайных серверов.
Все они, конечно же, отвечают своим пакетом SYN / ACK на целевой IP.
Как мы знаем, цель отвечает RST
НО каким-то образом он удерживает цель от отправки RST или мешает случайным серверам его обрабатывать
При этом очевидно, что серверы будут продолжать попытки отправлять пакеты SYN / ACK, производя эффект «снежного кома».
Как вы знаете, поток пакетов «попытка открыть порт» должен работать следующим образом:
Версия с «закрытым портом» проста:
И если дальний конец не возвращает пакеты RST, что является чрезвычайно распространенной конфигурацией межсетевого экрана:
И под чрезвычайно распространенным я имею в виду чрезвычайно распространенный. Все TCP-стеки должны обрабатывать этот случай, поскольку он настолько распространен.
Вариант, который предложил кто-то:
«Атака», которую он ловко обнаружил, - это SYN флуд атака и известна с начала 1990-х гг. Благодаря брандмауэрам, блокирующим пакеты RST, эти серверы не будут знать, что нужно закрыть соединение, поэтому они действительно будут повторно передавать пакет SYN / ACK на основе обычного времени повторной попытки TCP. Однако все современные TCP-стеки включают в себя некоторую настраиваемую защиту от SYN-флуда.
Это по-прежнему в некоторой степени эффективный метод атаки, хотя основной вред, который он наносит, заключается в том, что устройство защиты периметра перегружается слишком большим количеством пакетов, которые невозможно отслеживать. SYN / ACK без SYN следует очень дешево отбросить, но если их будет достаточно, это может привести к перегрузке брандмауэра.
Syn Cookies эффективно остановить эту атаку. Сервер отвечает SYN / ACK и забывает об этом. Если ACK получен, он повторно инициализирует поток на основе порядкового номера TCP. В Linux это можно включить, добавив:
net.ipv4.tcp_syncookies = 1
в /etc/sysctl.conf
Но, когда его забивают более 10к машин, я думаю, сервер все равно будет отключен.