если в поле flags tcp заголовка выставлен флаг rst значит требуется
Каждый TCP пакет несёт заголовок и в нем есть биты завершения соединения:
Хорошо это или плохо, так как красный сигнал не предвещает ничего хорошего? Все, конечно же, зависит от ситуации, когда они происходят.
TCP RST ACK – это нормальный и предусмотренный RFC 793 процесс разрыва соединения, но если их много и это оказывает влияние на производительность приложения и пользователей, то это бесспорно повод задуматься. Как всегда дьявол кроется в деталях и необходимо задать себе несколько вопросов.
В каком месте общения между устройствами происходит TCP Reset?
Если TCP Reset происходит в начале соединения, то это тоже не проблема для пользователя. На примере ниже мы запрашиваем файл с облака, но его уже там нет. Поэтому клиент дважды попытался его получить и оба раза сервер ответил TCP IP Reset.
Если TCP Reset происходит в середине процесса передачи данных, то потребуется дополнительный анализ, так как это может быть проблема на сервере, в приложении или даже клиенте. Пользователь запросил данные через браузер и затем закрыл его, не дожидаясь ответа. В данном случае будет однозначно отправлен TCP Reset.
Почему TCP RST отправлен сразу после SYN?
Причин может быть также несколько. Обычно это означает, что порт, по которому пытаются открыть соединение, недоступен. Сервер отключен, сервер занят или такой порт закрыт. Поэтому происходит сброс SYN и все.
Кто отправил TCP RST ACK?
Важно также понимать кто инициатор разрыва соединения. Клиент, сервер, сетевое оборудование внутри собственной инфраструктуры или на пути от провайдера (см. TTL, а также IP адрес отправителя). На все эти вопросы мы можем получить ответ, анализируя трафик с помощью анализатора протоколов.
Что вызывает отправку флага TCP/IP reset (RST)?
Я пытаюсь понять, почему мое приложение TCP/IP-соединение продолжает икать каждые 10 минут (точно, в течение 1-2 секунд). Я побежал Wireshark и обнаружил, что после 10 минут бездействия другой конец отправляет пакет с установленным флагом reset (RST). Поиск Google сообщает мне: “флаг reset означает, что получатель запутался и поэтому хочет прервать соединение”, но это немного меньше деталей, которые мне нужны. Что может быть причиной этого? И возможно ли, что за это отвечает какой-то маршрутизатор, или это всегда будет происходить из другой конечной точки?
Изменить: Есть маршрутизатор (в частности, Linksys WRT-54G), расположенный между моим компьютером и другой конечной точкой – есть ли что-нибудь, что я должен искать в настройках маршрутизатора?
“Маршрутизатор” может делать что угодно – особенно NAT, что может включать в себя любое количество ошибок, связанных с трафиком…
Одна из причин, по которой устройство отправит RST, будет отвечать на получение пакета для закрытого сокета.
Трудно дать твердый, но общий ответ, потому что все возможные извращения были посещены на TCP с момента его создания, и всевозможные люди могут вставлять RST в попытке блокировать трафик. (Например, некоторые “национальные брандмауэры” работают, например.)
Запустите пакетный сниффер (например, Wireshark) также на одноранговом узле, чтобы узнать, является ли он партнером, который отправляет RST или кто-то посередине.
Я потратил довольно много времени на устранение этой проблемы. Ни одно из предлагаемых решений не работало.
Оказалось, что наш системный администратор по ошибке назначил один и тот же статический IP-адрес двум несвязанным серверам, принадлежащим к разным группам, но сидящим в одной сети. Конечные результаты периодически прерывались соединениями vnc, браузер, который нужно было обновлять несколько раз, чтобы получить веб-страницу, и другие странные вещи.
Некоторые брандмауэры делают это, если соединение простаивает в течение x минут. Некоторые интернет-провайдеры устанавливают свои маршрутизаторы для этого по различным причинам.
В этот день и возраст вам нужно будет изящно обрабатывать (восстанавливать при необходимости) это условие.
Если маршрутизатор выполняет NAT, особенно маршрутизатор с низким доходом с небольшим количеством ресурсов, он будет стареть сначала в самых старых сеансах TCP. Для этого он устанавливает флаг RST в пакете, который эффективно сообщает принимающей станции (очень беззастенчиво) закрыть соединение. это делается для экономии ресурсов.
RST отправляется стороной, выполняющей активное закрытие, потому что это сторона, которая отправляет последний ACK. Поэтому, если он получает FIN со стороны, выполняющей пассивное закрытие в неправильном состоянии, он отправляет RST-пакет, который указывает другую сторону, что произошла ошибка.
Следует помнить, что многие сетевые экраны Linux netfilter неправильно настроены.
Если у вас есть что-то вроде:
then packet reordering can result in the firewall considering the packets invalid и thus generating resets which will then break otherwise healthy connections.
затем переупорядочение пакетов может привести к тому, что межсетевой экран сочтет пакеты недействительными и, таким образом, произведет сброс, что в противном случае нарушит работоспособные соединения.
Изменение порядка передачи особенно вероятно в беспроводной сети.
Вместо этого это должно быть:
В основном, когда у вас есть:
за ним сразу следует:
Лучше отбросить пакет, чем генерировать протокол, нарушающий сброс протокола TCP. Сброс лучше, когда они, безусловно, правильная вещь для отправки… так как это устраняет таймауты. Но если есть шанс, что они недействительны, они могут причинить такую боль.
Описание ТСР-заголовка
TCP-отправитель передает каждый сегмеит в одном IP-пакете вместе с ТСР-за- головком. Как показано на рис. 5.8, TCP-заголовок состоит из следующих полей.
Рис. 5.8. Формат ТСР-сегмеита
• Номер порта источника (source port) (16 бит). 16-битный помер порта, ассоциированный с ТСР-отправителем. IP-адрес отправителя содержится в IP-заголовке.
• Номер порта получателя (destination port) (16 бит). 16-битный помер норга, ассоциированный с ТСР-получателем. IP-адрес получателя содержится в IР-за- головке.
• Порядковый номер (sequence number) (32 бита). 32-битпый порядковый номер идентифицирует позицию первого байта сегмепта, содержащегося в пакете. Получатель использует порядковый номер для идентификации местоположения сегмепта в потоке байтов и реорганизации сегментов, поступающих не в том порядке. Перед передачей первого сегмента отправитель выбирает начальный порядковый номер, который представляет пачало упорядоченного байтового потока. Порядковые номера для всех сегментов строятся относительно этого начального порядкового номера.
• Номер подтверждения (acknowledgement number) (32 бита). Для подтверждения получения данных TCP-заголовок содержит 32-битпый помер подтверждения. Это поле указывает на следующий байт, который ожидается получателем, и корректно только в том случае, если флаг ACK установлен в 1. Когда приложение А передает данные приложению В, TCP-заголовок содержит порядковый помер каждого сегмента, и пакеты от В к А подтверждают получение этих сегментов.
• Длина заголовка (header length) (4 бита). 4-битная Длина заголовка указывает на количество 32-бигпых слов в TCP-заголовке. Заголовок обычно имеет длину 20 байтов, что соответствует пяти 32-битным словам. Более длинным заголовок может быть в случае использования отправителем опций TCP, которые содержат дополнительную управляющую информацию.
• Зарезервировано (6 бит). 6-битпое поле зарезервировано для будущего использования.
• Флаги TCP (TCP flags) (8 битов). TCP-заголовок также содержит 8-битное поле с шестыо 1-битными флагами. Эти флаги соответствуют различным управляющим действиям:
– URG. Флаг URG (флаг срочности) инструктирует TCP-получателя обратиться к части сегмента, идентифицируемой 16-бигпым полем указателя срочности в ТСР-заголовке.
– ACK. Флаг ACK (подтверждения) устанавливается при отправке подтверждения. Если флаг ACK установлен, 32-битное поле подтверждения указывает, сколько данных было получено отправителем. В пачале передачи данных ТСР-отиравитель почти всегда устанавливает бит ACK.
– PSH. Флаг PSH (форсированной отправки) указывает, что ТСР-получа- тель должен немедленно передать входящие данные сокету приложения.
– RST. Флаг RST (сброс) устанавливается при разрыве ТСР-соединения.
– SYN. Флаг SYN (синхронизации) устанавливается при установлении TCP-соединения. Если флаг SYN установлен, значение в иоле порядкового номера идентифицирует начальный порядковый помер.
FIN. Флаг FIN (окончания передачи) устанавливается, когда отправитель закончил передачу данных. При чтении принимающим приложением из сокета FIN преобразуется в символ конца файла.
Флаги SYN, ACK, FIN и RST будут подробнее обсуждаться далее в этом разделе. На практике большинство операционных систем не предоставляет для отправляющего приложения возможность установки флага PSH, а для ТСР-полу- чателя — возможность реакции на этот флаг. Флаг URG применяется для уведомления интерактивных приложений, таких как Telnet, о наличии управляющих символов (например, ctrl-C), которые могут повлиять на обработку предыдущих байтов в потоке.
• Окно приема (receiver windows) (16 битов). 16-битпое поле окпа приема содержит число дополнительных байтов, которые получатель может принять, помимо подтвержденных на данный момепт данных. Чтобы избежать переполнения входного буфера, TCP-отправитель не должен передавать данные, объем которых превышает размер окпа приема.
• Контрольная сумма TCP (TCP checksum) (16 битов). 16-битная контрольная сумма помогает TCP-получателю обнаруживать поврежденные пакеты.
В отличие от контрольной суммы IP-заголовка, контрольная сумма TCP распространяется и на заголовок, и на данные. Контрольная сумма дает возможность получателю выявить, был ли ТСР-сегмент поврежден во время передачи но сети. Отправитель вычисляет контрольную сумму массива из заголовка и данных. Получатель пересчитывает контрольную сумму и сравнивает ее со значением в заголовке TCP. Если результаты различаются, получатель отвергает поврежденный накет. Получатель не подтверждает получение поврежденного пакета. Следовательно, отправитель должен повторно передать не поступившие данные.
• Указатель срочных данных (urgent pointer) (16 битов). Если флаг URG установлен, 16-битпый указатель срочпых данных обращает впимапие получателя на определенную часть входных данных (например, символ ctrl-C, который прерывает передачу данных). 16-битпый указатель срочных данных идентифицирует последний байт срочных данных как целочисленное смещение от порядкового номера в ТСР-заголовке.
IP-заголовок содержит некоторую информацию, необходимую для ТСР-соеди- пегшя, включая IP-адреса отправителя и получателя, а также размер пакета. Размер IP-пакета представляет собой сумму длип IР-заголовка, TCP-заголовка и TCP-сегмента. Длина IP-заголовка включается в IP-заголовок, а длина ТСР-заго- ловка включается в ТСР-заголовок.
Рис. 5.9. Четыре сегмента в ТСР-соединспии (третий сегмент утерян)
При поступлении пакета получатель определяет диапазон байтов, занимаемый TCP-сегментом, основываясь на его порядковом номере и длипе. Предположим, что отправитель пачал с исходного порядкового номера 4500 и передает данные 100-байтпыми сегментами, как показано на рис. 5.9. Порядковый помер 4500 соответствует открытию ТСР-соединения. Первый сегмент имеет порядковый номер 4501 и длину 100, и занимает байты с 4501 по 4600. Второй сегмент имеет порядковый помер 4601 и длину 100, и т.д. Допустим, что В получает первый, второй и четвертый сегменты; третий 100-байтный сегмент был утерян или задержап. Поскольку В было иолучено только 200 последовательных байтов потока, подтверждающий пакет от В к А будет иметь помер подтверждения, равный 4701 (4501+200). Номер байта 4701 представляет собой порядковый помер следующего байта, который В ожидает получить. Важно отметить, что поле порядкового номера соответствует передаче сегмента, а поле номера подтверждения соответствует получению данных. Приложения А и В могут передавать данные друг другу одновременно. Для любого пакета значения полей порядкового номера и номера подтверждения не взаимосвязаны, поскольку они не отпосягся к одному и тому же направлению передачи.
Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.
Как работает атака TCP Reset
Атака TCP reset выполняется при помощи одного пакета данных размером не более нескольких байт. Подменённый спуфингом TCP-сегмент, созданный и переданный атакующим, хитростью заставляет двух жертв завершить TCP-соединение, прервав между ними связь, которая могла быть критически важной.
Эта атака имела последствия и в реальном мире. Опасения её использования вызвали внесение изменений в сам протокол TCP. Считается, что атака является важнейшим компонентом Великого китайского файрвола («Золотого щита»), который используется китайским правительством для цензурирования Интернета за пределами Китая. Несмотря на её впечатляющую биографию, для понимания механизмов этой атаки необязательно обладать глубокими знаниями работы TCP. Разумеется, понимание её тонкостей способно многому научить вас об особенностях реализации протокола TCP, и, как мы вскоре убедимся, вы даже сможете провести эту атаку против себя при помощи одного только ноутбука.
Как атака TCP reset используется в Великом файрволе?
Великий файрвол (Great Firewall, GFW) — это комплекс систем и техник, используемых китайским правительством для цензурирования Интернета для внутренних китайских пользователей. GFW активно блокирует и разрывает соединения с серверами внутри и снаружи страны, а также пассивно отслеживает Интернет-трафик запрещённого контента.
Чтобы не позволить пользователям даже подключаться к запрещённым серверам, GFW использует такие техники, как DNS pollution и IP blocking (обе они стоят отдельных статей). Однако иногда файрволу GFW требуется позволить совершить соединение, но затем разорвать его посередине. Например, это необходимо, если требуется выполнить медленный, отложенный анализ подключения, допустим, его корреляцию с другими действиями. Или это используется, если файрволу нужно проанализировать данные, которыми обменивались в процессе соединения, а затем использовать эту информацию, чтобы принять решение о его продолжении или блокировке. Например, может быть разрешён трафик на новостной веб-сайт, но цензурированы видео, содержащие запрещённые ключевые слова.
Для этого GFW необходимы инструменты, способные прерывать уже установленные соединения. Один из таких инструментов — это атака TCP reset.
Как работает атака TCP reset?
При атаке TCP reset нападающий разрывает соединение между двумя жертвами, отправляя одной или обеим фальшивые сообщения, приказывающие им немедленно прервать соединение. Такие сообщения называются сегментом сброса TCP. При обычной работе без участия злоумышленника компьютеры отправляют сегменты сброса TCP, когда они получают неожиданный TCP-трафик и хотят, чтобы отправитель прекратил его передавать.
Атака TCP reset злонамеренно эксплуатирует этот механизм, хитростью заставляя жертв преждевременно завершить TCP-соединения, отправляя им фальшивые сегменты сброса. Если фальшивый сегмент сброса изготовлен правильно, то получатель примет его за настоящий сегмент и закроет соединение со своей стороны, прерывая дальнейшую передачу информации по этому соединению. Чтобы продолжить обмен данными, жертвы могут попытаться создать новое TCP-соединение, но у атакующего может быть возможность сбросить и это новое соединение. К счастью, поскольку для сборки и отправки поддельного пакета атакующему нужно время, атаки сбросом по-настоящему эффективны только против долговременных соединений. Кратковременные соединения. например, используемые для передачи небольших веб-страниц, обычно успевают выполнить своё предназначение к тому времени, когда у атакующего появится возможность их сбросить.
Отправка фальшивых TCP-сегментов в каком-то смысле является лёгким процессом, потому что ни TCP, ни IP не имеют никаких собственных способов проверки личности отправителя. Существует расширение IP под названием IPSec, обеспечивающее аутентификацию, однако оно используется не так широко. Интернет-провайдеры должны отказывать в передаче IP-пакетов, которые поступают с очевидно ложного IP-адреса, но, как утверждается, такая проверка выполняется очень посредственно. Всё, что может получатель — принять исходный IP-адрес и порт внутри пакета или сегмента за чистую монету, и по возможности использовать для идентификации отправителя более высокоуровневые протоколы, например TLS. Однако поскольку пакеты сброса TCP являются частью самого протокола TCP, их невозможно проверить при помощи этих высокоуровневых протоколов.
Несмотря на простоту отправки фальшивых сегментов, изготовление фальшивого сегмента и выполнение успешной атаки TCP reset всё равно может быть сложной задачей. Чтобы понять, почему так происходит, нам нужно разобраться в работе протокола TCP.
Как работает протокол TCP
Задача протокола TCP — отправка получателю точной копии блока данных. Например, если мой сервер передаёт по протоколу TCP вашему компьютеру HTML, то стек TCP вашего компьютера (часть его операционной системы, занимающаяся обработкой TCP) должна вывести мой HTML точно в том же виде и порядке, в котором его отправил мой сервер.
Однако мой HTML не передаётся по Интернету в таком идеально упорядоченном виде. Он разбивается на множество небольших фрагментов (называемых TCP-сегментами), каждый из которых по отдельности передаётся по Интернету и воссоздаётся в переданном порядке стеком TCP вашего компьютера. Этот восстановленный вывод называется потоком TCP. Каждый TCP-сегмент передаётся в собственном IP-пакете, однако для понимания атаки нам не нужно знать никаких подробностей об IP.
Преобразование сегментов в поток требует внимательности, потому что Интернет ненадёжен. TCP-сегменты могут теряться. Они могут приходить не по порядку, отправляться дважды, повреждаться и испытывать множество других злоключений. Поэтому задача протокола TCP заключается в обеспечении надёжной передачи данных по ненадёжной сети. TCP выполняет эту задачу, требуя от обеих сторон соединения сохранения тесного контакта между друг другом и постоянной передачи сведений о том, какие блоки данных были получены. Это позволяет отправителям понять, какие данные получатель ещё не принял, и повторно передавать те данные, которые были утеряны.
Чтобы понять, как работает процесс, нам нужно разобраться, как отправители и получатели используют порядковые номера TCP для разметки и отслеживания данных, переданных по TCP.
Порядковые номера TCP
Каждый байт, переданный по TCP-соединению, имеет порядковый номер, назначаемый ему отправителем. Принимающие машины используют порядковые номера для перемещения получаемых данных в исходный порядок.
Когда две машины договариваются о TCP-соединении, каждая машина отправляет другой случайный начальный порядковый номер. Это порядковый номер, который машина назначит первому отправленному ею байту. Каждому последующему байту назначается порядковый номер предыдущего байта плюс 1. TCP-сегменты содержат TCP-заголовки, которые являются метаданными, прикреплёнными к началу сегмента. Порядковый номер первого в теле сегмента байта включается в TCP-заголовок этого сегмента.
Следует заметить, что TCP-соединения являются двунаправленными, то есть данные могут передаваться в обе стороны и каждая машина в TCP-соединении действует и как отправитель, и как получатель. Из-за этого каждая машина должна назначать и обрабатывать собственный независимый набор порядковых номеров.
Подтверждение получения данных
Когда машина получает TCP-сегмент, она сообщает отправителю сегмента, что он был получен. Получатель делает это при помощи отправления сегмента ACK (сокращение от «acknowledge» — «подтверждение»), содержащего порядковый номер следующего байта, который он ожидает получить от отправителя. Отправитель использует эту информацию, чтобы понять, что получатель успешно получил все остальные байты до этого номера.
Сегмент ACK обозначается наличием флага ACK и соответствующего номера подтверждения в TCP-заголовке сегмента. В протоколе TCP есть всего 6 флагов, в том числе и (как мы вскоре увидим) флаг RST (сокращение от «reset» — «сброс»), обозначающий сегмент сброса.
Примечание: протокол TCP также позволяет использовать выборочные ACK, которые передаются, когда получатель получил некоторые, но не все, сегменты в интервале номеров. Например, «Я получил байты 1000-3000 и 4000-5000, но не 3001-3999». Для упрощения я не буду рассматривать выборочные ACK в нашем обсуждении атак TCP reset.
Если отправитель передаёт данные, но не получает ACK для них в течение определённого интервала времени, то он предполагает, что данные были утеряны, и отправляет их повторно, давая им те же самые порядковые номера. Это означает, что если получатель принимает одни и те же байты дважды, то он тривиальным образом использует порядковые номера для избавления от дубликатов без нарушения потока. Получатель может принимать дублирующиеся данные, потому что исходный сегмент был получен позже, уже после того, как был отправлен повторно, или потому, что исходный сегмент был успешно получен, но соответствующий ACK потерялся на пути к отправителю.
Пока такие дублирующиеся данные встречаются достаточно редко, вызываемые ими избыточные траты ресурсов не приводят к проблемам. Если все данные рано или поздно добираются до получателя, а соответствующие им ACK доходят до отправителя, то TCP-соединение справляется со своей работой.
Выбор порядкового номера для фальшивого сегмента
При создании ложного сегмента RST злоумышленнику нужно дать ему порядковый номер. Получателей вполне устраивает, что нужно принимать сегменты с непоследовательными порядковыми номерами и самостоятельно соединять их в нужном порядке. Однако их возможности ограничены. Если получатель принимает сегмент с порядковым номером, который «слишком» выбивается из порядка, то он отбрасывает такой сегмент.
Следовательно, для успешной атаки TCP reset требуется правдоподобный порядковый номер. Но что считается таким номером? Для большинства сегментов (хотя, как мы увидим позже, не для RST ), ответ определяется размером TCP-окна.
Размер TCP-окна
Представьте древний компьютер начала 1990-х, подключённый к современной гигабитной волоконно-оптической сети. Сверхбыстрая сеть может передавать данные этому престарелому компьютеру с потрясающей скоростью, быстрее, чем машина сможет их обработать. Это будет нам мешать, потому что TCP-сегмент нельзя считать полученным, пока получатель не сможет его обработать.
У компьютеров есть TCP-буфер, в котором новые прибывшие данные ожидают обработки, пока компьютер работает над данными, прибывшими до них. Однако этот буфер имеет ограниченный размер. Если получатель неспособен справиться с объёмом передаваемых ему сетью данных, то буфер переполнится. Когда буфер полностью заполнен, у получателя нет другого выбора, кроме как избавляться от избыточных данных. Получатель не отправляет ACK для отброшенных данных, поэтому отправителю приходится повторно отправлять их, когда в буфере получателя найдётся свободное место. Не важно, с какой скоростью сеть может передавать данные, если получатель не успевает с ними справляться.
Представьте чрезмерно ретивого друга, который отправляет вам на почту целый поток из писем быстрее, чем вы сможете его прочитать. Внутри вашего почтового ящика есть определённое буферное пространство, но после его переполнения все непоместившиеся письма выпадут на землю, где их съедят лисы и другие твари. Другу придётся повторно отправлять сожранные письма, а пока у вас будет время на получение его предыдущих сообщений. Отправка слишком большого количества писем или объёма данных, который получатель неспособен обработать — пустая трата энергии и канала передачи.
Каждая из сторон TCP-соединения уведомляет другую о размере своего окна в процессе установки связи (handshake), выполняемой при открытии соединения. Кроме того, размеры окон могут динамически изменяться в процессе соединения. Компьютер с большим TCP-буфером может объявить о большом размере окна, чтобы максимизировать пропускную способность. Это позволяет общающейся с ним машине постоянно передавать данные по TCP-соединению, не приостанавливаясь и не ожидая подтверждения. Компьютер с маленьким TCP-буфером может быть вынужден заявить о маленьком размере окна. Иногда отправители полностью заполняют окно и оказываются вынужденными ждать, пока какие-то из сегментов не будут подтверждены. Из-за этого страдает пропускная способность, но это необходимо, чтобы TCP-буферы не переполнялись.
Размер TCP-окна — это жёсткое ограничение на объём передаваемых неподтверждённых данных. Мы можем использовать его для вычисления максимально возможного порядкового номера (который в показанном ниже уравнении я обозначил как max_seq_no ), который отправитель может отправить в текущий момент времени:
max_seq_no = max_acked_seq_no + window_size
В случае большинства TCP-сегментов это правило даёт нам интервал приемлемых порядковых номеров. Однако, как было сказано ранее, накладываемые на сегменты RST ограничения ещё строже, чем ограничения для обычных сегментов передачи данных. Как мы вскоре увидим, это сделано для усложнения проведения разновидности атаки TCP reset под названием «атака TCP reset вслепую» (blind TCP reset attack).
Приемлемые порядковые номера для сегментов RST
Обычные сегменты принимаются, если их порядковый номер находится в интервале от следующего ожидаемого порядкового номера и этого номера плюс размер окна. Однако пакеты RST принимаются только тогда, когда их порядковый номер точно равен следующему ожидаемому порядковому номеру. Вернёмся к предыдущему примеру, в котором получатель отправил номер подтверждения 15 000. Чтобы пакет RST был принят, его порядковый номер должен быть точно равен 15 000. Если получатель получает сегмент RST с порядковым номером, не равным 15 000, то он не примет его.
Атаки TCP reset вслепую
Выполняем атаку TCP reset против себя
Примечание: я тестировал этот процесс на OSX, но получил несколько комментариев, что в Linux он не работает нужным образом.
Теперь мы знаем всё о выполнении атаки TCP reset. Атакующий должен:
1. Установка TCP-соединения между двумя окнами терминала
2. Сниффинг трафика
Мы напишем выполняющую сниффинг трафика атакующую программу при помощи scapy — популярной сетевой библиотеки Python. Эта программа использует scapy для считывания данных, передаваемых между двумя окнами терминала, хотя и не является частью соединения.
Этот фрагмент кода приказывает scapy выполнять сниффинг пакетов в интерфейсе lo0 и фиксировать подробности о всех пакетах как часть нашего TCP-соединения. Вызов имеет следующие параметры:
3. Отправка фальшивых пакетов RST
Теперь мы готовы к проведению полномасштабной атаки. Настройте TCP-соединение в соответствии с этапом 1. Запустите атакующую программу из этапа 2 в третьем окне терминала. Затем введите какой-нибудь текст в одном из терминалов TCP-соединения. В терминале, на котором вы вводили текст, TCP-соединение внезапно и загадочно прервётся. Атака выполнена!