Как работает атака TCP Reset

[@Pochemuk]

Все же мне кажется, что слово byte в оригинале статьи имело значение не «байт», а «кусок», «фрагмент», «сегмент».

Т.е. не «Каждый байт, переданный по TCP-соединению, имеет порядковый номер, назначаемый ему отправителем», а «Каждый сегмент данных ...».

[@AC130]

В протоколе TCP sequence number нумерует октеты — блоки из 8 бит.

[@Pochemuk]

Не совсем так. Sequence number не нумерует байты (каждый байт), а как бы подсчитывает их. А нумерует именно сегменты данных. Только эта нумерация не является сквозной — идет скачками.

Возможно, что это терминологическая путаница, всего лишь. Только в таком изложении может показаться, что передача идет побайтно и каждому переданному байту присваивается номер.

[@Groosha]

У меня, наверное, глупый вопрос, но я его всё же задам: а что если обязать клиент и сервер игнорировать TCP Reset? Понятно, что это часть протокола, но всё же: пусть и сервер, и клиент отказываются обрабатывать сегменты с флагом RST. Чем это грозит, кроме некоторого процента несброшенных соединений, которые сами отвалятся по таймауту, если источник RST был нормальным, не атакующим?

Эта атака имела последствия и в реальном мире. Опасения её использования вызвали внесение изменений в сам протокол TCP.

Каких изменений?

[@KateChrom]

Возможно, высоконагруженные системы не имеют возможности ждать таймаута

[@apkotelnikov]

Автору неплохо бы почитать про absolute sequence number и чем он отличается от relative sequence number, ну или хотя-бы смотреть в байтовые значения этих полей. Да, если получить хотя бы один пакетик из сессии, то TCP RST атака пройдёт по сценарию автора. А без пакета, эта атака практически безвредна для конечных хостов (если ёмкости канала хватило), но вот межсетевому экрану она доставляет массу приятностей в виде логирования миллионов out of state «попаданий» (hits). Не припомню, чтобы на моей памяти, кто то включал логирование OOS. Очередная «пугалка» :-(

[@apkotelnikov]

Поправка, в последнем предложении «выключал логирование OOS» конечно же.

[@zabbius]

Ого, RST пакет уже атакой стал. Вообще, им пользуются все, кому не лень, мобильные провайдеры например, если у вас кончился интернет не дропают пакеты, а шлют RST сразу после хендшейка, чтобы вы быстрее видели, что нету у вас интернета. Кстати, если поюзать несколько полей в SYN/ACK в качестве полезной нагрузки, то через них можно в этом случае затунелиться.

[@micho1973]

Статья-то переводная. И, похоже, написана ради тех абзацев в которых рассказывается по китайцев.

[@zzzzzzzzzzzz]

Не совсем понятно, зачем злодеям разрывать уже установленное соединение, если речь идёт о цензуре. В подавляющем большинстве случаев поверх этого соединения будет ходить HTTPS, который особо не поанализируешь. (Разве что они голый HTTP так надеются выцепить...)

[@jok40]

Некто поднял vpn, запустил браузер и лазит по каким-то сайтам. По каким — неизвестно. Как это узнать? Порвать ему vpn-канал. При этом его браузер начнёт ломиться на сайты напрямую — до тех пор, пока vpn не поднимется снова. Таким образом можно узнать IP сайтов и их доменные имена — если, конечно, клиент не использует dnssec — что в настоящее время всё ещё мало распространено.

[@apkotelnikov]

Некто поднял VPN. Если его «порвали» при помощи RST, это SSL VPN, что большая редкость. Но даже в этом случае разорвать TCP соединение, послав RST, это надо быть «везунчиком», я уже выше писал. Вероятность угадать sequence number менее 1/2^34. Ну и «разорванный» VPN не равно отсутствию туннельного интерфейса и маршрута на него, даже в случае SSL VPN.

[@jok40]

Я отвечал на вопрос — «зачем?» Это был просто пример выгоды, которую можно получить от разрывания tcp-канала. Опять же, думаю, что китайцам, про которых упоминается в статье, нет никакой необходимости рвать канал таким сложным способом. Они же трафик сквозь себя прогоняют, а не наблюдают его со стороны.

[@Goldgsm]

спасибо за статью!