Назад | Перейти на главную страницу

Что произойдет, если сервер никогда не получит пакет RST?

Кто-то недавно решил показать мне POC нового метода отказа в обслуживании с использованием SYN / TCP, который он выяснил. Я думал, что это полная чушь, но после того, как он объяснил ему о SYN-SYN / ACK-RST, он лишил меня дара речи. Он сказал мне: «Что, если сервер, который вы используете для обмана с отправкой пакетов SYN / ACK, не может получить пакет RST?»

Я понятия не имею. Он утверждает, что сервер продолжит попытки отправлять пакеты SYN / ACK, и что скорость пакетов будет продолжать расти.

Есть ли правда в этом? Кто-нибудь может уточнить?

Видимо, это работает так:

Он подменяет IP-адрес SYN-пакета на IP-адрес цели. Затем он отправляет SYN-пакет на несколько случайных серверов.
Все они, конечно же, отвечают своим пакетом SYN / ACK на целевой IP.
Как мы знаем, цель отвечает RST
НО каким-то образом он удерживает цель от отправки RST или мешает случайным серверам его обрабатывать
При этом очевидно, что серверы будут продолжать попытки отправлять пакеты SYN / ACK, производя эффект «снежного кома».

Как вы знаете, поток пакетов «попытка открыть порт» должен работать следующим образом:

  1. SYN ->
  2. <- SYN / ACK
  3. ACK ->

Версия с «закрытым портом» проста:

  1. SYN ->
  2. <- RST

И если дальний конец не возвращает пакеты RST, что является чрезвычайно распространенной конфигурацией межсетевого экрана:

  1. SYN ->
  2. [Время проходит]
  3. SYN ->
  4. [Время проходит]
  5. SYN ->
  6. [Время проходит]

И под чрезвычайно распространенным я имею в виду чрезвычайно распространенный. Все TCP-стеки должны обрабатывать этот случай, поскольку он настолько распространен.

Вариант, который предложил кто-то:

  1. [Поддельный источник] SYN ->
  2. <- SYN / ACK
  3. [Время проходит]
  4. <- SYN / ACK
  5. [Время проходит]
  6. <- SYN / ACK

«Атака», которую он ловко обнаружил, - это 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к машин, я думаю, сервер все равно будет отключен.