Factorio Forums

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.

.

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.

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.

Blog is getting technical.

Yay for flowcharts!

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.

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.

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 ?

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/

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

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.

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.

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.

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.

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.

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.

When is this going to get implemented ?

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

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

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.