Нежелательный пакет RST TCP с 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, как reset соединение. Я нашел это: http://lkml.indiana.edu/hypermail/linux/net/0404.2/0021.html, я не знаю, является ли это причиной.

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

Спасибо.

Ответ 1

Процитированная статья делает это довольно ясным...

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

что окна альтернативы iptables??

Также кто-нибудь узнал, есть ли способ из scapy-скрипта решить проблему "RST" выше?