Нежелательный пакет 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" выше?