Announcement

Collapse
No announcement yet.

Client-Server handshake

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

    #16
    Re: Use pings and hops instead.

    Originally posted by hughbackov
    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.
    I am aware of that. Thank you very much.
    And hops are not much of an indication either, imnsho.

    Still, when I play UT, and I query servers, I still only want to see servers that are on my continent (Europe). I think this is true for 99.99% of the time when a player queries for servers. When you take the speed of light into consideration, a US server (or Asian or Pacific of African server) will never give me a ping which I consider playable. And I don't know any of the players there, so I don't even want to play there. I just don't want to know about their existence.

    Basically it is a waste of bandwidth for my PC to query those servers. And the amount of query packets on my **** adsl upstream connection causes slight congestion, which makes the pings less acurate. (Unless the queries take netspeed into account, AND we get asymmetrical netspeed for us poor ADSL and cable users). Having a small clue about who my PC needs to query can make queries 3 times more efficient.

    Just filtering on ping doesn't give the same advantages. It still wastes bandwidth. Plus, if for instance, I filter on ping under 150, I might not see some server that is on a temporily congested path. And because the query protocol is a single query/response, one of my popular servers might get filtered out, and it looks to me like it is down. This behaviour only encourages me to click "refresh servers" multiple times, where once would have been enough.

    Comment


      #17
      Re: Yes, you are missing a few things.

      Originally posted by hughbackov
      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.
      I know how painful this is, but sometimes when you need to change a protocol, you can't prevent incompatibility issues.

      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.
      The impact in scalability is at most a factor of 2. Twice as many packets, and maybe twice as much data. Although the extra data is a lot less than a factor of 2. IMHO when looking as scaling issues (as we do here), you need to look at the order of the change, not the absolute value. Adding a handshake of O(2) is not the big deal. It would be bad if was O(n) or O(n^2) or something.

      Do we have any idea how many queries a server gets on average ? Depending on game ? (UT vs UT2003 vs America's Army vs ...) Depending on gametype ? (DM vs CTF vs BR vs ...) That would be interesting data.

      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.
      I just did a little testing with the servers in my favorites (60 servers). I used qstat to generate queries, and tcpdump to look at the packets. (Using Linux). I see query packets all have 8 bytes of data in a UDP frame. Which makes the total packet size 20+8+8 = 36 bytes. I see most of the replies in the range of 700-1100 bytes. Replies do not only include player info and motd, but also things like mutators configured, gamespeed, passwd/no passwd, etc, etc. Granted, this is UT, not UT2003. But I guess new games will only have more info to carry.

      So when you send a 36 byte packet to a gameserver, the server will send 900 bytes to the target host. That is a factor of 25 amplification. I think that is considerable. This factor is what attracts the bad guys. If you have 6 Mbps of bandwidth to send attacks over, you can multiple to 150 Mbps, and fill the target's OC-3/STM-1. Not good. Do you still think amplification is not a big deal ?

      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.
      Agreed.
      But so do many many many other protocols. Example, ICMP. Do you want ICMP to limit replies ? (Some implementations actually do limit icmp replies per second). How about TCP segments. Just send some random TCP segment with a faked source IP address to a reflector host, and the reflector will send a TCP RST to the victim. Send any packet to a firewall, and the firewall will send a ICMP dest unreachable. Using a reflector to spoof your IP for DOS attacks is a problem in all protocols. And one you can't fix easily.

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

      First of all, if you want to limit the amount of replies per IP address, the server needs to keep track of which IP addresses recently have sent a query. That is a source for denial-of-service attacks to the UT server itself. Just send a million queries from different faked IP addresses, and the server will start using a few MBs of memory to keep that list. Managing that list will cost CPU time as well.

      Secondly, what if multiple IP addresses behind the same connection are targeted ? Suppose a website has a OC-3 (155 Mbps) and is part of a /24 behind that OC-3. Now you can DDOS all 254 IP addresses behind that OC-3. A quick glance showed me there are about 5000 UT and UT2003 servers. Suppose you limit queries to 1 per every 10 seconds per IP address. That means that every second, 500 servers can send a 900 byte packet to each IP address. That's 3.6 Mbps. Now they target 250 different IP addresses in the same /24. That's 250 * 3.6 Mbps = 900 Mbps. That's enough to fill a OC-12 and some more.

      You can apply the "distributed" in DDOS to more aspects than just the number of attacking hosts.

      I don't think the tradeoffs in compatibility and performance caused by implementing a handshake justify the negligible benefit of implementing it.
      Taking away the multiplication factor is the most important thing, IMHO. Once you fix this with a handshake, in the future game developers will never need to deal with this problem again.

      Using a handshake, with some cryptography based on the source IP address has the benefits that:
      - it works regardless of how many servers we will get on the Internet
      - servers don't need to waste memory on query-history
      - servers will not be subject to DOS themselves
      - amplification is gone
      Drawback:
      - amount of query packets is doubled
      - amount of query data is slightly increased
      - server needs to waste some more cpu cycles on a cryptographic challenge/response

      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.
      It's not as simple as you state. Keeping such a list has scalability implications for the server. And it doesn't solve the "distributed" variant when attacking a link, in stead of a single host.

      Comments are welcome again.

      Too bad we are wasting our time here, as developers are probably not reading this .....

      Comment


        #18
        stop whining, especially about wasting query time on servers you dont want to play on, and poor adsl and cable users:weird: what exactly is the alternative to adsl or cable?

        Comment


          #19
          Originally posted by _ut=n00b_
          stop whining, especially about wasting query time on servers you dont want to play on, and poor adsl and cable users:weird: what exactly is the alternative to adsl or cable?
          You are the one that is whining.

          All I try to do here is try and solve a real problem. We are happy to hear you analysis and your proposed solutions. If you don't have any, please get the fok out of this thread.

          There are loads of alternatives to the current techniques of adsl and cable. The issue is not purely technical, but more political. I'd be happy to discuss that with you, but not in this thread. Please stay on topic.

          Comment


            #20
            Re: Re: Yes, you are missing a few things.

            Originally posted by LittleFlower
            Using a handshake, with some cryptography based on the source IP address has the benefits that:
            - servers will not be subject to DOS themselves
            yes they will, they always will, there is no way to protect yourself against a DOS

            Comment


              #21
              Re: Re: Re: Yes, you are missing a few things.

              Originally posted by El_Muerte_[TDS]
              yes they will, they always will, there is no way to protect yourself against a DOS
              OK, let me rephrase myself: using a (cheap) cryptographic handshake will not add *yet another* way to do a DOS attack against a UT server itself. Keeping a list of all recently connected IP addresses does add a new way to DOS attack a UT server.

              And of course, you can still use old ways of DOS attacking any box, so there is no difference there.

              Comment


                #22
                The problem doesn't justify the changes.

                Originally posted by LittleFlower
                I know how painful this is, but sometimes when you need to change a protocol, you can't prevent incompatibility issues.
                I don't think the need is great enough to warrant just how huge a change this would be given how many programs and websites exists which get and display Unreal game stats. Yes, if there were websites and other large hosts being shutdown from these attacks I would agree on the urgency of making some changes. However, both UT and UT2003 have been updated to limit query frequency by default, and this appears to be sufficient in practice.

                So when you send a 36 byte packet to a gameserver, the server will send 900 bytes to the target host. That is a factor of 25 amplification. I think that is considerable. This factor is what attracts the bad guys. If you have 6 Mbps of bandwidth to send attacks over, you can multiple to 150 Mbps, and fill the target's OC-3/STM-1. Not good. Do you still think amplification is not a big deal ?
                First, although you are correct about the amplification of a single packet, your assumption that a target's OC-3 could be saturated by an attack using UT and UT2003 servers is specious for two reasons. First, there are simply not enough UT and UT2003 game servers running at any one time to generate this much traffic. According to Gamespy, there are fewer than 6000 servers running (which includes UT2003, UT, and America's Army). If every one of these servers sent one query response packet of 1K (using your figure) to a single host, this would only be ~47Mbits of bandwidth (6000 servers x 1024 bytes/server x 8 bits/byte). So, this would certainly not take down an OC-3. Yes, that is still theoretically a lot of bandwidth, however with the frequency of query restrictions in place, even if every single one of these 6000 servers did send a response packet to the same host, this flow of data would NOT be continuous. In addition, the host being attacked would have to allow UDP packets in at its routers, and since UDP traffic is not usually used for web hosts, incoming UDP traffic is usually blocked at commercial sites and could be easily blocked in case of attack if not already. Quite frankly, there are much better ways to perform a DDOS attack, and that is why UT game servers are not commonly used for such attacks.

                First of all, if you want to limit the amount of replies per IP address, the server needs to keep track of which IP addresses recently have sent a query. That is a source for denial-of-service attacks to the UT server itself. Just send a million queries from different faked IP addresses, and the server will start using a few MBs of memory to keep that list. Managing that list will cost CPU time as well.
                While this is a seemingly valid point, I doubt the CPU cycles used for managing such a list would be that great. Second, the server could limit the number of incoming queries it would accept and track to keep the list of querying hosts to a manageable size. That would eliminate the problem of exhausting the server's RAM on such a list. Finally, as for maintaining a list making a server susceptible to a DOS attack, that is really a moot point. Even without such tracking, any host which could send "millions" of queries to a game server and sustain it would likely saturate the server's bandwidth anyway.

                Taking away the multiplication factor is the most important thing
                I don't think it is worth the tradeoff in server bandwidth due to how rare the DDOS problem with game servers is. If your change is implemented EVERY game server will suffer to some degree and compatibility will be broken. If just the frequency limit is used along with a cap on the total number querying hosts, there will be no drawbacks for any game server and compatibility will be preserved. Could a DDOS attack utilizing game servers still take place? Sure, but with these limits its effects would be minimal, and it would be easy to defend against since the traffic would not be continuous, and it would be easy to block since it is all of the same type.

                Using a handshake, with some cryptography based on the source IP address has the benefits that:...
                - servers will not be subject to DOS themselves
                I don't follow your reasoning on this one. Any server connected to the Internet can technically have its bandwidth saturated with traffic. The only way to mitigate the problem for game servers is to limit the frequency of queries from a single host and to limit the number of hosts which can query the server per some time interval or in total.

                Too bad we are wasting our time here, as developers are probably not reading this .....
                Screw the developers! It is not a waste to me since I enjoy the discussion.

                Comment


                  #23
                  Pings and hops are still best.

                  Originally posted by LittleFlower
                  I am aware of that. Thank you very much.
                  And hops are not much of an indication either, imnsho.
                  Actually the combination of hops and pings is what is the best indicator of how close the server really is to you.

                  When you take the speed of light into consideration, a US server (or Asian or Pacific of African server) will never give me a ping which I consider playable.
                  I don't find that to be true in my case. I live in the central U.S., and for some games I get better performance from Barry's World servers in the U.K. than I get from U.S. servers. A server's physical geography can be misrepresentative of its speed and reliability.

                  Comment


                    #24
                    Re: The problem doesn't justify the changes.

                    Originally posted by hughbackov
                    I don't think the need is great enough to warrant just how huge a change this would be given how many programs and websites exists which get and display Unreal game stats. Yes, if there were websites and other large hosts being shutdown from these attacks I would agree on the urgency of making some changes.
                    Security issues are never a big deal, until the time has arrived someone is actively abusing a bug. I am sure Microsoft thought the bug in their SQL software was a minor issue, until the Slammer worm arrived. I am sure that Valve didn't care much more about security than the average company. It's better to be prepared. Remember Murphy. If Unreal servers are a security risk, some day they will be abused.

                    Breaking compatibility is not nice. But it also not the end of the world.

                    However, both UT and UT2003 have been updated to limit query frequency by default, and this appears to be sufficient in practice.
                    Anyone who knows what the max frequency is ? I've done some testing with my UT favorites, and it seems most of the servers respond again within a few seconds. I'm not sure howmany run patched servers. But it doesn't look good to me.

                    First, although you are correct about the amplification of a single packet, your assumption that a target's OC-3 could be saturated by an attack using UT and UT2003 servers is specious for two reasons. First, there are simply not enough UT and UT2003 game servers running at any one time to generate this much traffic. According to Gamespy, there are fewer than 6000 servers running (which includes UT2003, UT, and America's Army).
                    If you work on a solution on the Internet, you better make sure your solution scales well into the future. Online gaming gained unbelievable popularity over the last few years. Who says it ain't possible that there will hunderds of thousands of servers within a few years ? CounterStrike is up there already ...

                    If every one of these servers sent one query response packet of 1K (using your figure) to a single host, this would only be ~47Mbits of bandwidth (6000 servers x 1024 bytes/server x 8 bits/byte). So, this would certainly not take down an OC-3.
                    I tried to explain this before, but I was maybe not clear. Suppose you want to take out a host at 100.1.1.1. Now in 99% of the cases it is safe to assume that that 100.1.1.1 will be part of a /24. On a /24 there are 254 IP addresses. So my army of attacking hosts will send fake query packets that will look like they are from 100.1.1.1, 100.1.1.2, 100.1.1.3. Now UT servers all over the world will generate a 48 Mbps stream to 100.1.1.1, another stream of 48 Mbps to 100.1.1.2 and a third stream of 48 Mbps to 100.1.1.3. You can be pretty sure those 3 streams will congest the OC-3 between the Internet and your target 100.1.1.1. Note that network topologies are usually a little more complex. A hacker can use that complexity to his advantage, automated software inside the UT server can not prevent that.

                    If UT servers limit queries to one per IP per 10 seconds, than still, you can generate 6000/10*1K*8 = 4.8 Mbps per IP address. Tricking UT servers to send 4.8 Mbps to each IP address out of a /24 will generate over 1 Gbps. And the most terrible thing (imho) is that you only need enough attack power to generate 40 Mbps. If you have 254 comprised hosts generating traffic, each host to 1 IP address, than each host needs only 160 Kbps upstream. I bet there are enough hackers out there that have 250 dormant hacked hosts around, with 160 Kbps upstream average.

                    I'm not a hacker. And I have no army of compromised hosts. But give me a few days, and I will give you source code to run on 250 boxes that will generate 1 Gbps in a DDOS attack. It's a piece of cake.

                    And I don't know of any other protocol that will me allow to do this. As I've said a few times before, the amplification in the gamespy protocol is *the* thing that will attract hackers.

                    Yes, that is still theoretically a lot of bandwidth, however with the frequency of query restrictions in place, even if every single one of these 6000 servers did send a response packet to the same host, this flow of data would NOT be continuous.
                    Sorry, I don't understand this. If my army of attacking PCs clock the queries at the right time, the result will be a continous stream of replys going to the target.

                    In addition, the host being attacked would have to allow UDP packets in at its routers, and since UDP traffic is not usually used for web hosts, incoming UDP traffic is usually blocked at commercial sites and could be easily blocked in case of attack if not already.
                    I would make my fake queries look like they come from UDP port 53. That's DNS. Most firewalls will let all UDP packets destined for port 53 through. If not, lots of problems will surface. (There are even loads of sites that let through traffic *originated* at UDP 53. That's a huge hole). Even if you temporarily block all UDP 53, that would be a DOS in itself.

                    Quite frankly, there are much better ways to perform a DDOS attack, and that is why UT game servers are not commonly used for such attacks.
                    I'd be interested to hear which other protocols multiply attack traffic by 25.

                    While this is a seemingly valid point, I doubt the CPU cycles used for managing such a list would be that great.
                    I can't give you a number. But worstcase lookups on all kinds of datastructures can be pretty bad (O(n)). A hacker can manipulate the lookups to be worst case by sending fake queries in the right order.

                    Second, the server could limit the number of incoming queries it would accept and track to keep the list of querying hosts to a manageable size. That would eliminate the problem of exhausting the server's RAM on such a list.
                    At first I thought that this would not be good enough. If you start pruning your list at e.g. 10k IP addresses, than I can start sending extra queries to make the server quickly forget about the IP addresses I am targetting. However, if I have the attacking power to do that, I can use those 10k packets for worse kinds of DOS attacks. Let me think about this.

                    Still, you can restrict queries only by limited amount of time. Even 10 seconds is noticable when someone clicks a browser twice (esp on a small list, like your favorites). You can't increase this interval too much. But if the number of servers on the internet is increasing, the problem gets worse. And note, I have already shown you can multiple 40 Mbps into 1 Gbps with today's 6000 servers and today's 10 second interval.

                    Finally, as for maintaining a list making a server susceptible to a DOS attack, that is really a moot point. Even without such tracking, any host which could send "millions" of queries to a game server and sustain it would likely saturate the server's bandwidth anyway.
                    Agreed.

                    I don't think it is worth the tradeoff in server bandwidth due to how rare the DDOS problem with game servers is. If your change is implemented EVERY game server will suffer to some degree and compatibility will be broken.
                    IMHO this is just a disaster waiting to happen. Normally I am not so worried about security issues. But amplification of 25x is just too nice to be ignored. Even amplification of 10x. Or 2x.

                    Note that UT has already broken network compatibility between the CD version and 436. And UT2003 will also break network compatibility in a next patch. And other games seem to do this much more often. It's not the end of the world.

                    If just the frequency limit is used along with a cap on the total number querying hosts, there will be no drawbacks for any game server and compatibility will be preserved. Could a DDOS attack utilizing game servers still take place? Sure, but with these limits its effects would be minimal,
                    40 Mbps -> 1 Gbps. Today.

                    and it would be easy to defend against since the traffic would not be continuous, and it would be easy to block since it is all of the same type.
                    Blocking requires cooperation of your ISP. 1 Gbps of 8kb packets is 125 Kpps. Not sure if all routers can filter at that speed. Some sites can not block port 53 easily. But I agree that in most cases filtering at the ISP router can take care of the issue.

                    Still, these problems should better be prevented at the root, not ignored because there are band-aids.

                    I don't follow your reasoning on this one. Any server connected to the Internet can technically have its bandwidth saturated with traffic. The only way to mitigate the problem for game servers is to limit the frequency of queries from a single host and to limit the number of hosts which can query the server per some time interval or in total.
                    My point was that if you limit queries/interval/host, than you need to keep state on a box. In general if a hacker can influence that state on that box, he has another way to do DOS attacks against that box. It might be a moot point, as there are already many more ways to do a DOS attack against UT servers. But it would be nice if we could elimate those vulnerabilities, in stead of adding new ones.

                    Screw the developers! It is not a waste to me since I enjoy the discussion.
                    Cool. Let me know how you are gonna deal with the 40 Mbps -> 1 Gbps problem.

                    Comment

                    Working...
                    X