Add support for transparent proxying on Linux

[alxbl]

This feature adds the ability to tell PyRDP to perform a transparent connection to the server by using the source IP of the client. This cannot be fully supported by PyRDP and relies on firewall configuration to properly route traffic.

The PR adds documentation of an example scenario and configuration, along with the required PyRDP code to create a transparent socket.

[Res260]

Very cool 👍

[obilodeau]

It's well documented and well written (non-invasive).

• It should be documented as incompatible with docker images. It could probably work with --privileged and probably --net=host but lets just say untested or unsupported.

There's one thing I don't understand. Packets meant for 10.2.2.2 are rewritten to hit localhost on the mitm. The process receives them, creates a connection with tansparent mode. So far so good. But what about after? When the process replies to the original host, shouldn't a transparent socket be used there also? Otherwise you can detect in a packet capture that your server is not the one you expect. Am I missing something?

[alxbl]

should be documented as incompatible with docker images.

I remember writing something about that. I can't remember if it was in the code or decided to not include it after, but yes, I agree. I'll clarify.

what about after? When the process replies to the original host, shouldn't a transparent socket be used there also? Otherwise you can detect in a packet capture that your server is not the one you expect. Am I missing something?

The packets coming from the target server (replies) are marked using a PREROUTING rule. Then an ip routing rule is saying that all of the packets marked with that mark must be routed using a custom routing table, which contains a single rule: route through loopback. This effectively forces the packets to hit loopback, and thus the transparent socket opened during the connection receives the data. PyRDP has all of the state to forward back to the client socket.

It is kind of mind-bending, but it works :)

[obilodeau]

I think I wasn't clear enough. I don't see how packets coming back from the MITM to the client are being source rewritten so that to the client it's the real server that replied and not the MITM. I'll diagram it:

             DNAT happens here  +  transparent socket is here
                  +             |
                  |             |
+--------+        v  +--------+ v        +---------+
| Client +--------+->+  MITM  +-+-------->  Server |
|        |           |        |          |         |
|        +<-+--------+        +<---------+         |
+--------+  ^        +--------+          +---------+
            |
            |
            + I don't see how this flow could have the right
              source IP (10.2.2.2). Nothing in the iptable
              rules or the code does anything to do so.

If you don't have a pcap from the client's perspective, I'll checkout the branch and try to create one to verify. Or maybe you can answer me directly too.

[alxbl]

I'm pretty sure it's because the socket is already opened with the intended destination of 10.2.2.2 when being prerouted, so the source IP on replies is set to 10.2.2.2 by the MITM's linux kernel.

here's a PCAP: proxy.tar.gz
10.6.66.24: Client (priv0)
10.2.0.126: Server (qemu0)
10.2.0.1: MITM (Gateway) (qemu0)

Follow streams 2 and 3

I do not have a PCAP from the client's PoV, but feel free to grab one if you want to confirm

[obilodeau]

@alxbl performed another capture from the client's perspective to satisfy my curiosity.

This is good to go!