Нежелательный TCP-пакет RST с Scapy

Чтобы понять, как работает TCP, я попытался создать свой собственный TCP SYN / SYN-ACK / ACK (на основе учебника: http://www.thice.nl/creating-ack-get-packets-with-scapy/).

Проблема в том, что всякий раз, когда мой компьютер получает SYN-ACK от сервера, он генерирует пакет RST, который останавливает процесс подключения.

Я пробовал на OS X Lion и на Ubuntu 10.10 Maverick Meerkat, оба сбросили соединение. Я нашел это: http://lkml.indiana.edu/hypermail/linux/net/0404.2/0021.html, не знаю, причина ли в этом.

Кто-нибудь может сказать мне, в чем может быть причина? И как избежать этой проблемы?

Спасибо.


python networking tcp scapy
person user1177093    schedule 30.01.2012    source источник
comment
Я думаю, что этот фрагмент кода делает эту проблему более очевидной: ans = scapy.all.sr1(generate_tcp_syn_pkt()); ack_pkt = generate_tcp_ack_pkt(ans); scapy.all.send(ack_pkt)   -  person diabloneo    schedule 26.09.2013
comment
Как вы решили эту проблему для OS X?   -  person user1505986    schedule 08.11.2015

Ответы (3)


arrow_upward
32
arrow_downward

В статье, которую вы процитировали, это довольно ясно сказано ...

Поскольку вы не завершаете полное рукопожатие TCP, ваша операционная система может попытаться взять на себя управление и начать отправку пакетов RST (сброса), чтобы избежать этого, мы можем использовать iptables:

iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 192.168.1.20 -j DROP

По сути, проблема в том, что scapy работает в пользовательском пространстве, и ядро ​​Linux первым получит SYN-ACK. Ядро отправит RST, потому что у него не будет открытого сокета на соответствующем номере порта, прежде чем у вас будет возможность сделать что-нибудь с scapy.

Решение (как упоминается в блоге) состоит в том, чтобы защитить ваше ядро ​​от отправки пакета RST.

person This    schedule 06.02.2012
comment
Есть решение без IPTables? Я действительно не могу изменить конфигурацию iptables на своей машине. Кроме того, я хотел бы также отправить RST из моей реализации (создание собственного потока TCP для целей тестирования) - person KillianDS; 10.12.2012

arrow_upward
6
arrow_downward

Статья в блоге, цитируемая в других ответах, не совсем верна. Дело не только в том, что вы не завершаете трехстороннее рукопожатие, но и в том, что IP-стек ядра не знает, что происходит соединение. Когда он получает SYN-ACK, он отправляет RST-ACK, потому что это неожиданно. Получение первого или последнего действительно не входит в это. Стек получает SYN-ACK - это проблема.

Использование IPTables для отбрасывания исходящих RST пакетов - распространенный и допустимый подход, но иногда вам нужно отправить RST из Scapy. Более сложный, но очень работоспособный подход - пойти ниже, генерируя и отвечая на ARP с MAC, отличным от хоста. Это позволяет вам иметь возможность отправлять и получать что угодно без какого-либо вмешательства со стороны хоста.

Ясно, что это больше усилий. Лично я использую этот подход (в отличие от метода отбрасывания RST) только тогда, когда мне действительно нужно отправить RST самому.

person David Hoelzer    schedule 13.05.2016

arrow_upward
5
arrow_downward

У меня нет ответа, отличного от iptables, но проблему сброса можно исправить. Вместо того, чтобы пытаться отфильтровать исходящий сброс в таблице фильтров, отфильтруйте все входящие пакеты от цели в необработанной таблице. Это предотвращает даже обработку возвращаемых пакетов от цели ядром, хотя scapy по-прежнему их видит. Я использовал следующий синтаксис:

iptables -t raw -A PREROUTING -p tcp --dport <source port I use for scapy traffic> -j DROP

Это решение заставляет меня использовать один и тот же исходный порт для моего трафика; не стесняйтесь использовать свой собственный iptables-fu для идентификации возвращаемых пакетов вашей цели.

person Jeremy Dover    schedule 17.12.2013