View previous topic :: View next topic |
Author |
Message |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Wed Dec 23, 2009 5:22 am Post subject: sv_getrealip |
|
|
http://www.fteqw.com/wiki/index.php?title=Sv_getrealip
Quote: | Sv getrealip
From FTE
Jump to: navigation, search
Safer way to retrieve the true IP of clients.
1 (secure, supported by all clients) = Stuffs the client to send a packet back to the server and thus determines the IP from that.
2 (very secure, supported by mQWCL and FTE) = The server will also send an A2A_PING to the retrieved IP and expect A2A_ACK back.
3 (extremely secure, supported by FTE) = Will also require a challenge. |
I'm going to see if I can port this over to NQ.
Some nuisance players have long used proxies to be annoying and evade server banfiles and otherwise ruin games.
Apparently, Spike views this as effective so I'm sold. I'm still in the process of following the code and trying to determine how and why it works and why it is viewed as secure. This has long been a feature of MVDSV.
Looks like it requires client support. Well worth it for certain mods that require balanced teams.
/I won't be working on this until AFTER I port the csqcwinquake modifications over to other engines. |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Wed Dec 23, 2009 7:42 am Post subject: |
|
|
getrealip sucks. frankly.
its only real purpose is so that when you ban a client, you can ban their true ip instead of the quake-specific proxy that they're connecting through.
the fact of the matter is that it requires a cvar on the server to set the server's ip address. there are so many servers out there with a fscked address in there that the end result is that half the servers just end up waiting 5 secs or so extra on every map change before you can connect.
oh, and the ip can be spoofed, too.
the only way to do it 'securely' is to get the client to send a packet to the server, for the server to respond to that ip address with a cookie, and for the client to relay that cookie back to the server either via the quake protocol or via some additional cookie obtained from the quake protocol (like the client's challenge number).
If you don't have those checks then you end up with a situation like in mvdsv where the server genuinely has no way to check the ip the client tells it, meaning the ip can be easily spoofed, and you end up banning your admin's ip instead... Which is fairly amusing tbh, as they can't then rcon to unban.
The mvdsv implementation 'works' by sending a stuffcmd to the client instead of the svc_serverinfo (nq name) to the client if the realip is not yet known. the stuffcmd is basically 'packet $SERVERIP:PORT realip $cookie\ncmd new\n'.
This works because QW clients have a packet command which sends arg2+ to the address arg1. The server matches the cookie to the client and thus knows the source address of the udp packet from the client containing said cookie.
But yeah, that source address is not verified and could be spoofed. You need to send a packet to that ip and make sure a quake client actually responded properly (note: any sane quake client will not respond to a packet from a 'random' address, which is the case when connected via a proxy).
Even if you do get a 'quake client', you need to make sure its the quake client in question, and not the client of someone else that the exploiter is trying to frame.
You need a 4-way handshake to verify the ip and the identity.
mvdsv only provides a 2-way handshake, where the ip can be spoofed.
You'd be able to reliably use a tcp-like 3-way handshake if the client initiated the realip auth, which would require knowing the final server ip (hence why 4-way instead of 3).
Hopefully that explains why I hate realip. _________________ What's a signature? |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Wed Dec 23, 2009 11:01 am Post subject: |
|
|
Why not just use a name and password scenario, and regardless of the ip, a player must be verified via email. and must connect using a name / pw to play. if that name/email addy is banned then they cannot play. |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Wed Dec 23, 2009 11:12 am Post subject: |
|
|
r00k wrote: | Why not just use a name and password scenario, and regardless of the ip, a player must be verified via email. and must connect using a pw to play. if that name/email addy is banned then they cannot play. |
I've got nothing against that.
The servers should not be allowed to know the passwords, but maybe an md5 hash of the passwords.
Sounds like a public key, private key kind of ordeal really .. client should not communicate password to server; server cannot know the password. Client key combined with server key is validated and if combined is valid, password client used was correct. Hmmmm ....
(Note to anyone reading this: some kinds of games like FFA or coop it really doesn't matter if a disruptive player shows up --- you ignore them. Match servers, it is different (CTF, CA, DM) and can ruin the setup of a game.) |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2004 phpBB Group
|