Announcement

Collapse
No announcement yet.

Client-Server handshake

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Client-Server handshake

    Could anyone comment as to whether the lack of a true client-server handshake will be remedied in UT2K4?

    I lost 6 of my favourite servers a few days ago, because some of them were being used in a DDoS attack. I am not a happy bunny

    ML :cry:

    #2
    I thought this problem was fixed in a bunch of patches for most Unreal-based engine games. Even for UT a new patch was issued. Still, I didn't understand how they could fix this wíth a server-side-only patch.

    Are you sure your servers were running the latest patch ?

    Comment


      #3
      Nope it's not fixed....

      http://www.ataricommunity.com/forums...hreadid=322259

      ML

      Comment


        #4
        It's not possible.

        Originally posted by MandyLifeboats
        Could anyone comment as to whether the lack of a true client-server handshake will be remedied in UT2K4?
        It's not possible to have a more stringent check because it would break compatibility with third-party server browsers.

        Epic has already updated servers to limit the frequency of traffic they send to such clients. It's not really possible to do more unless you are willing to sacrifice performance and invalidate all current server browsers.

        Comment


          #5
          Re: It's not possible.

          Originally posted by hughbackov
          It's not possible to have a more stringent check because it would break compatibility with third-party server browsers.

          Epic has already updated servers to limit the frequency of traffic they send to such clients. It's not really possible to do more unless you are willing to sacrifice performance and invalidate all current server browsers.
          TBH, I'm not really interested in 3rd party server browsers, all I'm interested in is a game that isn't such a soft target.

          Unreal engine based games are amongst the most compromised of all, simply because there seems to be a lack of willingness to....

          (i) Acknowledge the problem is a GENUINE problem.

          (ii) Do anything meaningful about it.

          Quake engine based games don't have this problem, it is not a problem that can't be fixed.

          DDoS attacks on UT engine based servers are reaching critical mass. Something has to be done, and now!!!

          ML

          Comment


            #6
            It's not that big of a problem.

            Originally posted by MandyLifeboats
            Unreal engine based games are amongst the most compromised of all
            First, let's be honest here. No Unreal server is being "compromised" at all. All that is happening is the server is sending normal traffic to an IP which really doesn't belong to a game client or server browser. If the server is set to not send frequent reponses to the same IP, the problem is basically moot. If a handshake were implemented, it would not improve the situation since there is nothing stopping a client for sending a handshake packet to a server regardless of whether the source header is forged. The server would still respond to this initiate connection handshake packet. This could also increase overall bandwdith used by the server because every successful connection would require more packets than it does now with no handshake.

            (i) Acknowledge the problem is a GENUINE problem.
            Again it is not much of a problem because there is no way to discern between connection and serverinfo requests from genuine clients and nonexistant ones without the server sending come type of response packet. And, any response packet sent from the server could be used as a DOS attack on the IP to which it is sent IF the server sends it too frequently.

            Quake engine based games don't have this problem, it is not a problem that can't be fixed.
            Actually they do including Quake III, but it's a little different variation of the same principle.

            DDoS attacks on UT engine based servers are reaching critical mass.
            Again these attacks are not directed AT the UT server. They are using the UT server to send its normal traffic to a destination that is not really a client. But, again there is no differencece from this traffic and the traffic generated if I set my Gamespy browser to legitimately give me continuous serverinfo updates from your server. Simply set the server to respond infrequently to these requests and that will mitigate the problem. The only real solution is to block all requests altogether, and if you do that you might as well take the server down.

            Comment


              #7
              Re: It's not that big of a problem.

              Originally posted by hughbackov
              A lot of stuff
              I'm not sure you realise the seriousness of this problem. The 6 servers I mentioned were all run by the same guy. He found out he was being used in a DDoS attack, he pulled the plug on all of his servers. Who can blame him?

              This is a problem that is common to all Unreal engine based games. I just want to know if Epic are working on a fix to this problem, because I can only see it getting worse.

              ML

              Comment


                #8
                There is no good solution.

                Originally posted by MandyLifeboats
                I'm not sure you realise the seriousness of this problem. The 6 servers I mentioned were all run by the same guy.
                ONE GUY can't configure his servers properly and suddenly it's a widespread problem?!

                He found out he was being used in a DDoS attack, he pulled the plug on all of his servers. Who can blame him?
                Someone like me who understands the problem and how to mitigate it can certainly blame him. The fact is if you put up a server, you have to expect that clients will contact it. There is nothing unusual about a client who requests a connection or info too frequently. It can happen both legitimately or illegitimately. If your server is sending information out too frequently, then simply cut it back.

                I just want to know if Epic are working on a fix to this problem, because I can only see it getting worse.
                I doubt it since there is no good solution. There is no real way to tell whether the source IP address in a UDP packet is forged. Having a handshake will just cause the server to send more packets to each client without stopping it from sending handshakes to forged IP addresses. The only workable solution is to simply reduce the frequency with which the same client can connect or retrieve serverinfo.

                Comment


                  #9
                  switch to tcp and use ssl for everything
                  dammit we want certificates!!

                  Comment


                    #10
                    TCP opens a whole other can of worms.

                    Originally posted by _ut=n00b_
                    switch to tcp and use ssl for everything
                    dammit we want certificates!!
                    I know you are being facetious, but the fact is if that were done, then the game servers themselves would become very vulnerable to syn flood and other such TCP-based attacks. Plus, performance would also suck as the game server would have to wait on the querying clients. Certificates aren't the answer here since it is not the security of the information that is the problem. The problem is simply that the server is sending game information to an IP address which is not really a querying client.

                    I think the real reason there is no good solution to this problem is because there simply isn't one. The best I can think of is to reduce the frequency of attempted connections and serverinfo queries. Sure, if serverinfo were turned off entirely, it would reduce the amount of traffic a server sends out (including in a DOS attack), but it would probably discourage clients from connecting to the server at all since they couldn't see the maps and players on it before joining.

                    Comment


                      #11
                      dont worry, it was a total joke. I realize that is not in any way a plausible answer. I understand this stuff enough to know exactly what you are talking about, and i agree there is no real way to fix this "problem." ALthough you could have some sort of simple server side client verification when someone tried to do a map/player etc check on the server, and then have that client validated according to the server. But i am speaking out my *** again.

                      Comment


                        #12
                        Of course there must be a solution.

                        Is this problem being discussed somewhere, where technical people are around ? Preferably some that are responsible for the actual implementation in games ? I'd be happy to try and help design a robust server-query protocol. Just discussing the problem amongst gamers isn't going to help.

                        Simple analysis:
                        Why do hackers use this approach for their attacks ? Take that away, and they will leave the games alone.

                        As far as I understand, attacks via UT servers are done for 2 reasons:
                        1) hide the true IP address of the attacker
                        2) amplify the amount of data being sent

                        I agree you can't solve 1). All protocols with 2-way traffic are vulnerable to this problem to some extent. Adding a handshake of some sort might reduce the attack to a single packet per attempt. Attackers can abuse the handshake, but they can't abuse the rest of query protocol.

                        If you can't abuse more than a single packet per attempt, then attackers will use multiple attempts. Well, this can be protected against by using the per-IP-query-counter. Don't allow more than x queries per IP per minute.

                        But to solve 2) is a bit easier. If you use some form of a handshake, just make sure that the initial reply packet is not larger than the initial query packet. Or even better, make it smaller. That way the amplification effect is completely gone. You can do this using a simple protocol like this:

                        1) client->server query request packet, udp + 32 bytes UT data
                        2) server->client query accept packet, udp + 8 bytes UT data
                        3) client->server query continue packet, udp + 8 bytes UT data
                        4) server->client anwer packet, udp + unlimited data about the server

                        You can use the extra bytes in handshake for some form of cryptographic challenge/response stuff, so the attackers can't guess what bytes to reply. (And prevent the mistake of initial TCP implementations where TCP spoofers could guess the Initial Sequence Number used by the victim).

                        And while we are at it, I would love to see the query protocol to the master server use some kind of "country" or "continent" concept. When I query for servers, 999 out of 1000 times, I only want to see servers in Europe. Should be very easy to integrate. I think the gamespy protocol already has a field in it.


                        So, with a simple handshake in the query protocol you can reduce the amounts of packets and the size of packets. If you make the query packets at least twice the size of the handshake-reply packets, then attackers will find other protocols to abuse. Of course this would cause an incompatibility issue, where gamers will not see all servers while everyone switches over.

                        Am I missing something ?

                        Comment


                          #13
                          Yes, you are missing a few things.

                          Originally posted by LittleFlower
                          Am I missing something ?
                          Yes, you are missing a few things. I already suggested above the problems to your solution. First, you just broke compatibility with every server browser which can query UT and UT2003 servers. Second, by implementing a handshake for server queries, you just added at least one additional incoming and outgoing packet for each query transaction. Yes, this does not sound like much additional bandwidth and processing on the server, but on a server getting a huge amount of queries that also has limited bandwidth, it can certainly take its toll. Third, server queries don't generate "unlimited" response data from the server. Assuming the server admin didn't write a book for his MOTD, the amount of information returned from one server is not that large especially if there are not many players on it. Finally, the main problem with your solution is that it really doesn't remove game servers as a target. Hackers use game servers for DDOS attacks simply because there are so many of them and because they will send back at least one response packet to a spoofed IP address. If all servers limited the frequency of queries and successive commands from a single IP then that would be sufficient to stop DDOS attacks on serious targets since there are not enough game servers to bring down an Internet host or site with decent bandwidth in a single pass.

                          I don't think the tradeoffs in compatibility and performance caused by implementing a handshake justify the negligible benefit of implementing it. A better solution which doesn't break compatibility and actually improves server performance is to simply limit the frequency of successive queries and connection commands from a single client.

                          Comment


                            #14
                            Use pings and hops instead.

                            Originally posted by LittleFlower
                            And while we are at it, I would love to see the query protocol to the master server use some kind of "country" or "continent" concept. When I query for servers, 999 out of 1000 times, I only want to see servers in Europe. Should be very easy to integrate. I think the gamespy protocol already has a field in it.
                            Ping and hops are much better indicators of server proximity and performance than physical geography which can have little to do with the virtual location of a server.

                            Comment


                              #15
                              a d00d on adsl 100 miles away running a server for people on his block will have a much slower connection than someone running a t1 hookup farther away

                              Comment

                              Working...
                              X