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

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

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

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

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

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

Источник

2 ответа

Как вы знаете, поток пакетов "попытка открыть порт" должен работать так:

  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 Flood, известная с начала 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 000+, сервер все равно будет отключен.

Источник
Другие вопросы по тегам