Support RakNet Cookies

[Kas-tle]

Changes

Network

• Geyser will now send cookie during the initial establishment of the RakNet connection to prevent responding to packets with a spoofed source IP
• Note this currently pulls from jitpack of my own Network repo pending the merge of Support cookies CloudburstMC/Network#38 Merged.

Configuration

• System properly Geyser.RakOfflinePacketLimit is removed as Network has removed rate limiting before the RakNet connection is in online mode

Logging

• Logging of connection attempts is now considered debug instead of info, as given that the source IP is now validated early on, there is no longer much reason to notify users of spam connections
• In order to mitigate the issue of increased difficulty troubleshooting cases where outgoing traffic is not reaching the client introduced by this change in logging, Geyser Dumps will now include a field for connectionAttempts that is incremented whenever Geyser receives a RakNet connection

For Hosts and DDoS Mitigation Providers

This PR makes a change to the initial RakNet handshake. If you or your DDoS mitigation service listens in on this in a way that expects it to conform to a specific format, you will need to adjust those systems to account for this. If Geyser does not recieve the correct cookie from the client, it will provide no further response.

More specifically, the security boolean in (S -> C) Open Connection Reply 1 will now be set to true, have an added 4 byte int cookie directly after, and expect the client to reply with the 4 byte cookie cookie immediately following magic field in (C -> S) Open Connection Request 2. The client will also include a boolean immediately after the 4 byte cookie set to false to indicate that it does not support RakNet encryption.

Documentation of this change has also been updated on the RakNet page of wiki.vg (https://wiki.vg/Raknet_Protocol) to include these optional fields and specify their usage.

We have already given the major DDoS mitigation providers mentioned on our wiki (TCPShield, Infinity Filter, CosmicGuard, NeoProtect, and Pufferfish) advanced notice regarding this change, so no action should be needed for users of these services by the time this is merged.

Attached are packet dumps showing the initial connection with and without this change. These can be viewed in Wireshark:
cookie_pcaps.zip

[Kas-tle]

You can download test builds from the Checks Tab:

[MossCG]

Tested.
Now geyser will only send a packet back to source IP.
Can I make a video/article to notice geyser users update their geyser version to the latest?
After 2.2.3 version released or this PR merged.
Video/article will be publish on bilibili(www.bilibili.com) or twitter(maybe?)

[onebeastchris]

@MossCG The DOS attack issue was resolved here - this PR just goes a step further with using a cookie to verify that the sender and recipient match to prevent spoofing.

If you wish to inform others, please link the following CVE for detailed information:
GHSA-6h3m-c6fv-8hvh
All Geyser builds #478 or later are no longer affected by this specific issue.

[Kas-tle]

@MossCG just wanted to clarify in your wireshark screenshot that we are not actually encrypting the RakNet connection with this PR (the connection after login during game play is already encrypted, not using RakNet's builtin encryption scheme). There was an issue in wireshark where it would incorrectly think that the RakNet connection was encrypted based on the first packet requesting security, but this is disabled in the next packet since the Bedrock client does not support full encryption. I had to PR to wireshark to fix this, which was merged: https://gitlab.com/wireshark/wireshark/-/merge_requests/15123. Not sure when it will make it to release. (Just in case you do end up making a post and used that).

[enderLuoxh]

Has this problem been completely resolved? The latest version of Geyser that I am currently using has the same issue, which can be viewed as # 4918

[onebeastchris]

To our knowledge, yes. Please present your findings that makes you think otherwise in that issue or reach out via discord.

[enderLuoxh]

The latest version I am currently using still has this issue. Geyser sends a large number of data packets to a player's IP, causing the VPS's upstream bandwidth to run to full capacity, resulting in delayed disconnection for all players. After a while, it will automatically disappear. This situation can occur dozens of times a day. Perhaps the cookie verification fixed and added by Geyser did not work?

目前我用的最新版仍有这个问题，geyser会向某个玩家的IP发送大量数据包，以至于使VPS的上行带宽跑满，玩家全部延迟掉线，过会又会自动消失，这个情况一天可以出现几十次，也许是geyser修复并添加了的cookie验证没起作用?

[onebeastchris]

The cookie verification prevents replies to connections that aren't fully established, but won't do much else after. Please provide more info on the issue you made (logs, a geyser dump, if possible some image showing the network spikes) - but not here on the PR. Thanks!