sandialabs / wiretap

Wiretap is a transparent, VPN-like proxy server that tunnels traffic via WireGuard and requires no special privileges to run.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

SYN-SENT userland timeout

SkyperTHC opened this issue · comments

commented

I'm using https://thc.org/segfault/wireguard with the wiretap v0.3.0 (--simple branch) with WIRETAP_SIMPLE=true ./wiretap_linux_amd64 serve --ipv4-relay 192.168.0.1 --ipv6-relay fd::1 --allowed 192.168.0.1/28,fd::1/125

The Exit Node is a Linux x86_64 running wiretap.
The origin host runs network scans using nmap or masscan.

The userland wiretap process tcp connect keeps the connection for a very long time in state SYN-SENT.
This can cause port exhaustion on the exit node (wiretap) when scanning a non-existing host on the Internet:

┌──(EXIT:Dirt)(root💀sf-BiologyMetal)-[~]
└─# nmap -n -Pn -sS -p- --open 30.31.32.33

and even worse if masscan is used:

┌──(EXIT:Dirt)(root💀sf-BiologyMetal)-[~]
└─# masscan --interface wgExit -p- --range 30.31.32.0/24  --source-ip 192.168.0.3 --banners --rate 1000

It would be desirable for wiretap to close the connection between wiretap and the target (and not forward a RST/FIN to upstream) after 10 seconds. The assumption is that if the target hasn't responded with a SYN-ACK within 10 seconds then the wiretap can 'drop' the connection.

The origin-server may still re-transmit the SYN again and again (in case it's not a masscan/nmap-scan) but in that case and with the original 'forwarding connection' having been closed already, wiretap would detect the re-transmitted SYN as a first SYN from Origin-server and just call Connect() to the target again.....

I added a default timeout of 1 second before uncompleted handshakes are reaped, it's configured with --conn-timeout (commit 08673a9). Thanks for finding these issues!

commented

I added a default timeout of 1 second before uncompleted handshakes are reaped, it's configured with --conn-timeout (commit 08673a9). Thanks for finding these issues!

I'm not reading the source (sorry) but I want to make sure that it is imperative that WT-EXIT on a --conn-timeout does not send a RST or FIN back to the origin-server. It must not.

Instead it should be up to the origin-host (nmap) to re-try the connection by re-transmitting the SYN. The origin-host wont do this if WT-EXIT (wrongfully) sent a FIN/RST. Tthe real target never send a FIN/RST and thus WT-EXIT shall not send a FIN/RST to the origin-host (nmap) either.

thanks for double checking and sorry for being pedantic :>

No worries 😄

That is correct, --conn-timeout (and --catch-timeout) just kills the exit node -> target "connection" so it stops waiting for a SYNACK. No RST is sent back to the origin server.