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

Does udp2raw support SPA? #506

Closed
mxmkeep opened this issue Jan 23, 2024 · 2 comments
Closed

Does udp2raw support SPA? #506

mxmkeep opened this issue Jan 23, 2024 · 2 comments

Comments

@mxmkeep
Copy link

mxmkeep commented Jan 23, 2024

One of the purposes of using the UDP protocol is service hiding(avoiding port scanning), which using SPA(Single Packet Authorization) mechanism.
So can udp2raw support SPA?
For example, the client adds a specical tcp option into SYN packet, and the server checks it.
If it does not match, do not reply SYN-ACK, just drop it to avoid the port being scanned.

@wangyu-
Copy link
Owner

wangyu- commented Jan 31, 2024

no, in the current version no such mechanism in the SYN.

For example, the client adds a special tcp option into SYN packet, and the server checks it.
If it does not match, do not reply SYN-ACK, just drop it to avoid the port being scanned.

Is there an existing software that has implemented this feature? I wonder how practical it is

problems that might arise in this method:

  1. how is the compatibility ofspecial tcp option
  2. even if this is implemented. How to prevent replay attack of the SYN packet without synchronized clock?

@mxmkeep
Copy link
Author

mxmkeep commented Feb 20, 2024

Is there an existing software that has implemented this feature?

No, but there are similar ones, such as TOA(tcp option address) feature originated from LVS full-nat mode, then commonly used to bypass client real ip for proxy project.
https://github.com/ucloud/ucloud-toa

  1. how is the compatibility ofspecial tcp option

Yes, the tcp option may be drop or replaced by the cloud vendor, depending on the choice of option code

  1. even if this is implemented. How to prevent replay attack of the SYN packet without synchronized clock?

It just add one more checking logic when receive SYN packet, if this logic be bypassed, the orignal checking logic of program is still in effect.

@mxmkeep mxmkeep closed this as completed Mar 21, 2024
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