Factorio Forums

Ratzap wrote:Technically it wasn't on a Friday but we'll let you off.

Actually it was - according to the forum time stamp Kovarex's post was at 22:50 UTC on Friday 29th July.

But as most of us are on daylight saving time at the moment it may have appeared that the post was on Saturday.

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?

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.

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

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 package with client-id
• Server sends first response to victim. Will probably be discarded.
• Attacker waits a little
• Attacker sends second spoofed package with client-id + server-id
• Server starts sending a lot of data to the victim

If the attacker would connect himself he would get his own clientID but he would need the clientID of the victim which he can not get as it is sent to the victims IP.

Loewchen wrote: If the attacker would connect itself he would get his own clientID but he would need the clientID of the victim which he can not get as it is sent to the victims IP.

The image suggests, that the client presents its client-id to the server. (I would like to URL it, but apparently that starts a download of the image which is inconvenient...)

The attack is only prevented if there is secret information send from the server to the client in the Connection Reply packet. But from the text and diagram it looks like there is only the client-id (which is send from the client to the server in the Connection Request, so the attacker can choose one) and the server-id (which is presumably the same for all clients on the server).

EDIT:

The client first generates (randomly) his id, and sends it to the server as part of the request. The server generates his unique random id as well, and sends it back to the client.

The client id is randomly chosen by the attacker, so it does not add anything to the ddos prevention. The wording of "his unique random id" suggests, that the id is unique to the server. For the prevention to work the server id has to be different and unique for every client and not unique for every server. Maybe its just a wording issue. I hope it is.

the ability to have the server bind to a specific ip and not 0.0.0.0 would be great

Blubberbub wrote:

Loewchen wrote: If the attacker would connect itself he would get his own clientID but he would need the clientID of the victim which he can not get as it is sent to the victims IP.

The image suggests, that the client presents its client-id to the server.

Indeed, that would make it necessary for the ServerID to be unique between the clients.

This is a really interesting read. There is just one thing that keeps puzzling me. Is there not a good framework out there that you don't have to write and maintain that code yourself? It's not like this is the first multiplayer game. The latency hiding seems to be the only thing that has game-specific aspects as it sort of needs to roll-back state. The rest just feels completely generic to almost all games that don't exclusively simulate the world on the server.

Please, kovarex, at least stop thinking about multiplayer when you ride your bike and *CONCENTRATE ON THE TRAFFIC*!

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.