Skip to content

SYN-SENT userland timeout #15

@SkyperTHC

Description

@SkyperTHC

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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions