7

I'm trying to use Pcap.Net to open a tcp connection.

I'm sending following package:

SYN packet

The server is responding with:

SYN-ACK

After this, Windows on its own sends the reset packet:

RST

Why is this happening, and how do I block this behavior?

I'm doing this on Windows 7

Mike Pennington
  • 41,899
  • 19
  • 136
  • 174
Arsen Zahray
  • 24,367
  • 48
  • 131
  • 224

3 Answers3

8

As Mr Harris says, you can use WinDivert to do what you want. E.g. to just do the TCP handshake, you can write something like the following:

// TCP handshake using WinDivert:
HANDLE handle = DivertOpen("inbound && tcp.SrcPort == 80 && tcp.Syn && tcp.Ack", 0, 0, 0);
DivertSend(handle, synPacket, sizeof(synPacket), dstAddr, NULL);
...
DivertRecv(handle, synAckPacket, sizeof(synAckPacket), &srcAddr, &length);
...
DivertSend(handle, ackPacket, sizeof(ackPacket), dstAddr, NULL);
...

The DivertRecv() function redirects the server response into user space before it is handled by the Windows TCP/IP stack. So no pesky TCP RST will be generated. DivertSend() injects packets.

This is the main differences between WinDivert and WinPCAP. The latter is merely a packet sniffer, whereas the former can intercept/filter/block traffic.

WinDivert is written in C so you'd need to write your own .NET wrapper.

(usual disclosure: WinDivert is my project).

Basil
  • 1,001
  • 7
  • 9
4

Essentially, the problem is that scapy runs in user space, and the windows kernel will receive the SYN-ACK first. Your windows kernel will send a TCP RST because it won't have a socket open on the port number in question, before you have a chance to do anything with scapy.

The typical solution (in linux) is to firewall your kernel from receiving an RST packet on that TCP port (12456) while you are running the script... the problem is that I don't think Windows firewall allows you to be this granular (i.e. looking at TCP flags) for packet drops.

Perhaps the easiest solution is to do this under a linux VM and use iptables to implement the RST drops.

Mike Pennington
  • 41,899
  • 19
  • 136
  • 174
  • sounds interesting; but I do want to be able to reset the connection myself. – Arsen Zahray Oct 22 '12 at 13:01
  • This doesn't prevent you from sending a reset, it prevents you from receiving a reset before you are ready for one. When you want to close the connection, you can remove the iptables rule – Mike Pennington Oct 22 '12 at 15:53
2

Either by using Boring Old Winsock to make a TCP connection to the server, rather than constructing your own TCP-over-IP-over-Ethernet packets and sending them to a server, or by somehow convincing the Windows Internet protocol stack to ignore the SYN+ACK (and all subsequent packets) you get from the server, so that it doesn't see the SYN+ACK from the server, notice that no process has tried to set up a TCP connection from 192.168.1.3:12456 to 192.168.1.1:80 using the standard in-kernel networking stack (i.e., nobody's tried to set it up using Boring Old Winsock), and send back an RST to tell the server that there's nobody listening at port 12456 on the machine.

You might be able to do the latter using WinDivert. It does not itself appear to have a .NET wrapper, so you might have to look for one if you're going to use .NET rather than Boring Old Unmanaged C or Boring Old Unmanaged C++.

  • any way I can tell windows to ignore all incoming packets instead of actively refusing connection? – Arsen Zahray Oct 22 '12 at 11:19
  • As I said, you might be able to do it with WinDivert. I've never used it, so I don't know precisely *how* you'd do that. –  Oct 22 '12 at 11:41