Friday Facts #149 - Deep down in multiplayer

Regular reports on Factorio development.
goncalor
Manual Inserter
Manual Inserter
Posts: 4
Joined: Wed Mar 02, 2016 2:08 am
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by goncalor » Sat Jul 30, 2016 12:33 pm

Blubberbub wrote: Image
If I understand the blog post and this diagram correctly the new connection handshake is an improvement but might still be attacked. Consider the following attack workflow:
  1. the attacker sends a connection request with a (random) client ID and a spoofed IP address
  2. the server replies to the spoofed IP with the client ID and the server ID
  3. the attacker intercepts the reply (ant therefore now knows the server ID)
  4. the attacker sends the server a "connection reply confirm" with the client and server IDs
  5. the server sends the client a "connection accept"
  6. heartbeats are now sent to the attacked client
I believe this is a valid attack (of course I might be wrong about some detail). And easy to pull of at a LAN at least.

The cornerstone of this attack is of course the ability of the attacker to intercept replies from the server to the client. This is easy on a LAN. In the end this might not be a concern on a WAN as it seems to me considerably more difficult to intercept packages. But even if it's difficult it might be possible and could be taken into account (even if it's not a priority) on how this handshake it designed. If this is indeed a problem, my take on it would probably be to encrypt the handshake.

---

On a different note,
As the peer-to-peer network model is being removed
Is more info available about what the peer-to-peer was being used for? Why is it being removed? Centralising seems to be going a step back, but I can't have a sound opinion since I don't know what the P2P was used for.

self-same-spot
Inserter
Inserter
Posts: 34
Joined: Fri Mar 04, 2016 11:50 am

Re: Friday Facts #149 - Deep down in multiplayer

Post by self-same-spot » Sat Jul 30, 2016 12:37 pm

.
Last edited by self-same-spot on Thu Nov 24, 2016 11:09 am, edited 1 time in total.

Blubberbub
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sat Jul 30, 2016 8:29 am
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by Blubberbub » Sat Jul 30, 2016 1:16 pm

goncalor wrote: The cornerstone of this attack is of course the ability of the attacker to intercept replies from the server to the client. This is easy on a LAN. In the end this might not be a concern on a WAN as it seems to me considerably more difficult to intercept packages. But even if it's difficult it might be possible and could be taken into account (even if it's not a priority) on how this handshake it designed. If this is indeed a problem, my take on it would probably be to encrypt the handshake.
I don't think you can really intercept and read packets on the internet reliable, if you are not the NSA. The problem i see is, that if the server-id is not different for every client you don't even need to intercept any packets. But lets hope they are aware and thought about that.

Zeblote
Filter Inserter
Filter Inserter
Posts: 972
Joined: Fri Oct 31, 2014 11:55 am
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by Zeblote » Sat Jul 30, 2016 1:18 pm

If the server id is randomized, won't you have to store it until the connection times out? What happens if someone sends thousands of connection requests to the server at once? If you refuse to start more connections after a few pending ones you can effectively render a server useless by spamming it.

wwdragon
Long Handed Inserter
Long Handed Inserter
Posts: 91
Joined: Sun Jun 28, 2015 12:16 am
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by wwdragon » Sat Jul 30, 2016 2:36 pm

Blog is getting technical.

Yay for flowcharts! :-)

goncalor
Manual Inserter
Manual Inserter
Posts: 4
Joined: Wed Mar 02, 2016 2:08 am
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by goncalor » Sat Jul 30, 2016 6:53 pm

Zeblote wrote:If the server id is randomized, won't you have to store it until the connection times out? What happens if someone sends thousands of connection requests to the server at once? If you refuse to start more connections after a few pending ones you can effectively render a server useless by spamming it.
This (in conjunction with Blubberbub's randomised ID rationale) is a very good point.

Zeblote
Filter Inserter
Filter Inserter
Posts: 972
Joined: Fri Oct 31, 2014 11:55 am
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by Zeblote » Sat Jul 30, 2016 8:21 pm

I'm thinking the server id could be a hash of a secret generated on server start + the source ip/port of the connecting client, then it doesn't have to be stored and can't be guessed either.

Ali
Manual Inserter
Manual Inserter
Posts: 2
Joined: Sun Jul 17, 2016 6:43 pm
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by Ali » Sat Jul 30, 2016 9:56 pm

it's very lovely to theorize and have the attention. but as an average joe what does all that drawing mean ? i dont understand ...
Can you please cut the technical Jargon and tell us in percentages and numbers how much this will help with loading times and lag issues ?

vtx
Fast Inserter
Fast Inserter
Posts: 150
Joined: Tue Jun 28, 2016 9:48 am
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by vtx » Sun Jul 31, 2016 4:34 am

goncalor wrote:
Blubberbub wrote: If I understand the blog post and this diagram correctly the new connection handshake is an improvement but might still be attacked. Consider the following attack workflow:
  1. the attacker sends a connection request with a (random) client ID and a spoofed IP address
  2. the server replies to the spoofed IP with the client ID and the server ID
  3. the attacker intercepts the reply (ant therefore now knows the server ID)
  4. the attacker sends the server a "connection reply confirm" with the client and server IDs
  5. the server sends the client a "connection accept"
  6. heartbeats are now sent to the attacked client
I believe this is a valid attack (of course I might be wrong about some detail). And easy to pull of at a LAN at least.

The cornerstone of this attack is of course the ability of the attacker to intercept replies from the server to the client. This is easy on a LAN. In the end this might not be a concern on a WAN as it seems to me considerably more difficult to intercept packages. But even if it's difficult it might be possible and could be taken into account (even if it's not a priority) on how this handshake it designed. If this is indeed a problem, my take on it would probably be to encrypt the handshake.

---

On a different note,
As the peer-to-peer network model is being removed
Is more info available about what the peer-to-peer was being used for? Why is it being removed? Centralising seems to be going a step back, but I can't have a sound opinion since I don't know what the P2P was used for.
This form of security is called "security through obscurity". What mean P2P for network layer that mean every player are interconnected, so an potential attacker only need to connect to the server to know everyone IP and then he can spoof one. In a Server network layer every players are only connected to the server( only the server know every IP player ), so you only know your own IP and the server IP. The attacker will have to guess the IP of one player as well of is id, good luck!
Ali wrote:it's very lovely to theorize and have the attention. but as an average joe what does all that drawing mean ? i dont understand ...
Can you please cut the technical Jargon and tell us in percentages and numbers how much this will help with loading times and lag issues ?
It's exactly what they said : the lag of others will not affect your gameplay and you'll continue to play uninterupted for a new player who load the game. As a side effect this method should support more than 4 players as everyone only talk to one person ( server ) instead of having everyone talking to everyone to keep sync who quicly overload the network.

For the network
Old method use O(n^2)
New method will use O(n)
check for yourself first diagram on this page http://bigocheatsheet.com/

Fricken Hamster
Manual Inserter
Manual Inserter
Posts: 1
Joined: Sat Jul 30, 2016 11:51 pm
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by Fricken Hamster » Sun Jul 31, 2016 7:02 am

goncalor wrote:
Blubberbub wrote: Image
If I understand the blog post and this diagram correctly the new connection handshake is an improvement but might still be attacked. Consider the following attack workflow:
  1. the attacker sends a connection request with a (random) client ID and a spoofed IP address
  2. the server replies to the spoofed IP with the client ID and the server ID
  3. the attacker intercepts the reply (ant therefore now knows the server ID)
  4. the attacker sends the server a "connection reply confirm" with the client and server IDs
  5. the server sends the client a "connection accept"
  6. heartbeats are now sent to the attacked client
I believe this is a valid attack (of course I might be wrong about some detail). And easy to pull of at a LAN at least.

The cornerstone of this attack is of course the ability of the attacker to intercept replies from the server to the client. This is easy on a LAN. In the end this might not be a concern on a WAN as it seems to me considerably more difficult to intercept packages. But even if it's difficult it might be possible and could be taken into account (even if it's not a priority) on how this handshake it designed. If this is indeed a problem, my take on it would probably be to encrypt the handshake.
.
It is a big step up.
What you are talking about should be considered an entirely different man in the middle attack that would be magnitudes more difficult to pull off than the original attack. Even without TLS I doubt it would be worth the effort for a single machine to launch a DDOS. Furthermore, if a server is on a local network with a malicious entity, there would probably be more dangerous attack vectors to worry about.

I'm interested in the server synchronization step. It seems to be where the server simulation is run. I wonder how much of the game state is saved on the server.

kovarex
Factorio Staff
Factorio Staff
Posts: 7384
Joined: Wed Feb 06, 2013 12:00 am
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by kovarex » Sun Jul 31, 2016 1:12 pm

Blubberbub wrote:
Loewchen wrote:
Blubberbub wrote:So if the attacker knows the server ID, he/she can still run the same attack by sending 2 instead of 1 packet to the server? Or is the server ID random and different for every player?
The attacker can't respond as he fakes the victims IP or he would DDOS himself ;).
He would get one packet send to the victim for 1 packet sent by himself instead of 700 for 1.
Why would the attacker not be able to respond if he knows the response?
  • Attacker connects to server by himself and figures out the server-id.
  • Attacker sends first spoofed packet with client-id
  • Server sends first response to victim. Will probably be discarded.
  • Attacker waits a little
  • Attacker sends second spoofed packet with client-id + server-id
  • Server starts sending a lot of data to the victim
I might not have been clear. The serverID is randomly picked per every connection request, so this trick won't work. This is the reason, why I chose this approach instead of one constant sessionID.

Man in the middle can still be used, but as it is much harder to achieve, and the worst case scenario is just sending invalid packets to someone (not stealing private data or something like that with https and similar), I consider this to be good enough.

User avatar
Killkrog
Long Handed Inserter
Long Handed Inserter
Posts: 73
Joined: Thu Jun 09, 2016 1:04 pm
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by Killkrog » Sun Jul 31, 2016 7:46 pm

I love your technical FFFs kovarex!

As a fellow programmer, it's always interesting to see others thinking processes.
Also, I'm taking my hat of to your decision to remake the MP part from scratch. That must be an ugly piece of work.

posila
Factorio Staff
Factorio Staff
Posts: 3632
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by posila » Sun Jul 31, 2016 10:43 pm

Fricken Hamster wrote:I wonder how much of the game state is saved on the server.
All of it. Server runs the full simulation as clients do.
I think it wouldn't need to run the simulation after rewrite, but then it would have to get the map from clients whenever somebody would join. Which might be a problem when all clients disconnect.

Olipro
Burner Inserter
Burner Inserter
Posts: 7
Joined: Sat May 28, 2016 1:28 am
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by Olipro » Mon Aug 01, 2016 2:30 am

My suggestion for avoiding DDoS facilitation via an amplification attack would be to incorporate a nonce and hash in the initial client payload with a requirement that X number of leading bits in the hash be zero (however many it takes for the average computer to compute in a few hundred ms) - this will render it computationally prohibitive to utilise game servers as an attack vector.

Ghoulish
Filter Inserter
Filter Inserter
Posts: 327
Joined: Fri Oct 16, 2015 8:40 am

Re: Friday Facts #149 - Deep down in multiplayer

Post by Ghoulish » Tue Aug 02, 2016 3:36 pm

Interesting read, and forum thoughts, as usual. Little above my pay grade though! Great to be kept up to date with the tick-tock of development.
See the daily™ struggles with my Factory! Say hello :D https://www.twitch.tv/fruityrob

Ali
Manual Inserter
Manual Inserter
Posts: 2
Joined: Sun Jul 17, 2016 6:43 pm
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by Ali » Thu Aug 04, 2016 3:19 am

When is this going to get implemented ?

roy7
Filter Inserter
Filter Inserter
Posts: 334
Joined: Fri Dec 12, 2014 4:24 pm
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by roy7 » Fri Aug 05, 2016 4:04 pm

Do we know if this will launch in some version of 0.13.x once ready, or will it wait for 0.14.0?

kovarex
Factorio Staff
Factorio Staff
Posts: 7384
Joined: Wed Feb 06, 2013 12:00 am
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by kovarex » Fri Aug 05, 2016 10:07 pm

roy7 wrote:Do we know if this will launch in some version of 0.13.x once ready, or will it wait for 0.14.0?
It will wait for 0.14

NoPantsMcDance
Filter Inserter
Filter Inserter
Posts: 478
Joined: Fri Jul 17, 2015 6:56 pm
Contact:

Re: Friday Facts #149 - Deep down in multiplayer

Post by NoPantsMcDance » Fri Aug 05, 2016 11:08 pm

kovarex wrote:
roy7 wrote:Do we know if this will launch in some version of 0.13.x once ready, or will it wait for 0.14.0?
It will wait for 0.14
/me cries to himself and crawls back into his hole until 0.14 comes out.
Looking for a multiplayer server? Check out my servers Vanilla Server

Post Reply

Return to “News”

Who is online

Users browsing this forum: No registered users