Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SYN-SENT userland timeout #15

Closed
SkyperTHC opened this issue May 23, 2023 · 3 comments
Closed

SYN-SENT userland timeout #15

SkyperTHC opened this issue May 23, 2023 · 3 comments
Assignees

Comments

@SkyperTHC
Copy link

SkyperTHC commented May 23, 2023

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.....

@luker983
Copy link
Contributor

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!

@SkyperTHC
Copy link
Author

SkyperTHC commented Jun 1, 2023

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 :>

@luker983
Copy link
Contributor

luker983 commented Jun 1, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants