Using a divert socket with a TCP connection

[dcole]

Hello,

I was checking out this page about divert sockets:

http://blog.rootshell.be/2010/07/12/packet-inspection-using-divert-sockets/

My question is - can this only be used with SOCK_RAW sockets? I like the idea of being able to use a single socket to sniff incoming TCP connections, because it makes getting to the payload easy with a SOCK_STREAM, however, with a normal SOCK_STREAM I don't know the full source and destination information that is available in the IP header.

Currently I am more or less achieving the same thing with a rdr PF rule instead of the divert PF rule that is listed on that website. This is leading me to have to do a cumbersome pcap_loop to sniff the packets for IP header info and detect whether it was an SSL connection or not, AND a separate process to read the SOCK_STREAM socket - possibly stand up an OpenSSL context. This all seems to work pretty well, but I basically haven't been able to come up with a good way to synchronize that the IP header the pcap_loop is reading actually belongs to the socket read(2) I am doing at any given time. It seems feasible to me that there could be a timing issue here.

 

[expl]

My question is - can this only be used with SOCK_RAW sockets?

Yes, would not make sense to have them of any other type.

I like the idea of being able to use a single socket to sniff incoming TCP connections, because it makes getting to the payload easy with a SOCK_STREAM

Getting payload is not straightforward, but its not hard either if you have some understanding of network protocols.

however, with a normal SOCK_STREAM I don't know the full source and destination information that is available in the IP header.

Its easy to get as well, there are getpeername(2) and getsockname(2) to get source and destination addresses directly from socket descriptor.

Currently I am more or less achieving the same thing with a rdr PF rule instead of the divert PF rule that is listed on that website. This is leading me to have to do a cumbersome pcap_loop to sniff the packets for IP header info and detect whether it was an SSL connection or not, AND a separate process to read the SOCK_STREAM socket - possibly stand up an OpenSSL context. This all seems to work pretty well, but I basically haven't been able to come up with a good way to synchronize that the IP header the pcap_loop is reading actually belongs to the socket read(2) I am doing at any given time. It seems feasible to me that there could be a timing issue here.

I think you misunderstood the purpose of divert sockets, it's designed for packet re-injection not for network evesdropping.

 

[dcole]

In the networking section of the forums, I posted something more concise, after reading your post. The problem I am having is that I am trying to intercept and stop certain packets from going out over my network. I did this by redirecting to an interface, and accepting socket connections on that interface with my SOCK_STREAM. When I do getsockname() on that socket, I get the address of my redirected to interface, instead of the actual real destination the packet was originally destined for.