How to stop this CHEAT - HACKED DEDI SERVER

[MoGas]

ok, soo we can stop the plan to come back with a dedicated server for FC2 again....?!

[159th_Viper]

ok, soo we can stop the plan to come back with a dedicated server for FC2 again....?!

 

Why?

 

He cannot be in two places at once. You don't see the 159th yanking our server off the public domain at the first signs of adversity now do you? Look at it this way - if he is busy giving us a hard time then your server will be fine and visa versa...........

 

It's the way that one deals with adversity that sets us apart from the molluscs :thumbup:

[Boberro]

I see here we go again :D

 

I must admit I've not seen a game yet, where 1 person can ruin all other people fun of the playing.

 

I hope that makes ED manufacturing FC 3 faster and faster, before people will fly away from the FC2 to other games.

[Phantom]

I don't think taking your dedi of public server is the answer. Instead better monitoring of whos doing what and how there doing it is needed. Leave the servers up, let him come to us, and let's get some possitive ideas inplace to moniter his/her actions. And stop it once and for all.

[159th_Viper]

......I must admit I've not seen a game yet, where 1 person can ruin all other people fun of the playing......

 

I see you have not played Battlefield 3 yet then :D

 

I got stabbed *repeatedly* in an Abrams one day on Firestorm......go figure that one :music_whistling:

[Cali]

I see you have not played Battlefield 3 yet then :D

 

I got stabbed *repeatedly* in an Abrams one day on Firestorm......go figure that one :music_whistling:

 

Stabbed you through the tank, damn that's a good knife!

[Snoopy]

Stabbed you through the tank, damn that's a good knife!

 

A lightsaber maybe :D

[Cali]

A lightsaber maybe :D

 

Or that damn plasma sword thing in Halo, that my sons kills me with all the time!

[july865]

just to clarify. this is ONLY for FC2, and not A10-C or BS servers?

[159th_Viper]

just to clarify. this is ONLY for FC2, and not A10-C or BS servers?

 

Correct.

[ALDEGA]

I must admit I've not seen a game yet, where 1 person can ruin all other people fun of the playing.

Countless multiplayer games have been ruined by hackers/cheaters ...

[Boberro]

Yes, but here is only 1 person (so far we know). All others are too hmm "mature" to waste time for things like this.

 

I know other games - Crysis as example. But here we have 1 kid who easily outmanoeuvres company and many other people - that I haven't seen yet.

[ALDEGA]

It's only "one" because (s)he didn't share the hack ... Developers need to get it right all time, a hacker only needs to find one hole.

Large companies like Microsoft have large resources yet people keep finding many security vulnerabilities in their products. You expect a small company like ED to be different?

[RIPTIDE]

It's not his up address we need...............its his home address so we can kick him in the nuts.

I'd make him my girlfriend for an hour or so.

[Pilotasso]

Rip..you sometimes worry me :D LOL

[Sn0w_Lynx]

it seems what he has done is figured out your rcon login, so when he joins he has the server run some sort of custom mission .lua he has locally on his computer. so you should fix your administrative rights on your server and disable remote console commands

[Moa]

Here is what I hope for Flaming Cliffs 3:

 

a) all packets received by the server are dropped unless:

1) the server has an established connection to an authenticated user at the sending IP address, or

2) the packet is a *valid* request for authorization.

 

b) all accepted packets are inspected for correctness. Both format is checked (to prevent mismatches in stated sizes etc which could cause null pointer crashes or buffer overruns) and basic validity in terms of game logic (does the packet request an illegal missile launch either by number of missiles launched or missile type, etc).

 

In this way a hacker cannot exploit the game even if they do hide behind proxies (the current situation). At the moment a player can "board the aircraft without showing their passport". This is not a good security model.

 

Even if a hacker somehow gets through this you will always have their authenticated ID. Then you can ban their ass on the authentication server without putting the onus for security on the individual game servers. Problem solved. Permanently.

 

Yes, you need additional CPU to inspect the packets. Run this on one CPU core and hand off the valid packets to the other core (running the game). Then with the core doing sound you'll still have cores 'twiddling their thumbs' with idleness.

 

The server should never trust the clients. This security model makes it so.

Edited March 24, 2012 by Moa

[HiJack]

Was just on the 159'th in a good run and the server crashed. Shit, looks like offline FC2 or FSX is the sim at the moment :(

[Cali]

Was just on the 159'th in a good run and the server crashed. Shit, looks like offline FC2 or FSX is the sim at the moment :(

 

Did it crash because of the hacker or it just crashed, there is a difference.

[c0ff]

Here is what I hope for Flaming Cliffs 3:

 

a) all packets received by the server are dropped unless:

1) the server has an established connection to an authenticated user at the sending IP address, or

2) the packet is a *valid* request for authorization.

Present since LockOn-1. However, without any encryption.

Encrypted in FC3.

 

b) all accepted packets are inspected for correctness. Both format is checked (to prevent mismatches in stated sizes etc which could cause null pointer crashes or buffer overruns) and basic validity in terms of game logic (does the packet request an illegal missile launch either by number of missiles launched or missile type, etc).

Additional hooks for ServMan-like tool will be provided.

 

Even if a hacker somehow gets through this you will always have their authenticated ID. Then you can ban their ass on the authentication server without putting the onus for security on the individual game servers. Problem solved. Permanently.

Requiring permanent connection to master-server greatly helps here.

 

 

Yes, you need additional CPU to inspect the packets. Run this on one CPU core and hand off the valid packets to the other core (running the game). Then with the core doing sound you'll still have cores 'twiddling their thumbs' with idleness.

Network transport runs in a separate thread since LO-1.

 

The server should never trust the clients. This security model makes it so.

Security and usability (effectiveness) are in inversely proportional relationship.

[Speed]

Additional hooks for ServMan-like tool will be provided.

 

I like the sound of this! :thumbup:

[Moa]

Thanks for replying c0ff.

 

Last weekend I heard second-hand about attacks on a server during the weekend. I presume this server had the recent patch (although I could be wrong). The hack was apparently even able to log in to the server and post taunts.

 

My own server appeared to be attacked as well (I'm still sorting through the evidence to see if it was coincidence or not). This server was patched.

 

If the packets from an unknown source are being dropped I can't see how these attacks are possible - there is something missing from the picture - unless the user authorization scheme has been compromised (!?).

 

Also, encrypting normal traffic is not required for the scheme I outlined to work. Only the initial handshake needs encryption, and even then you wouldn't need TLS, just mutual authentication with some randomly generated text (nonce protected, of course) and the rule that connections cannot be established without master server authentication. That would be enough to set up the internal 'firewall rules' within the application. If you are not an authenticated client your packets should be dropped.

 

It didn't appear that was happening pre-patch. Packets were being parsed by the server even from non-authenticated sources, which could cause the server instance to fall over. Those malformed packets should have been dropped before they got to that stage. I haven't checked post-patch but the fact there was chaos last weekend means things still don't appear to be water-tight.

 

Thanks for the efforts of yourself and your colleagues to improve the security of the game. Unfortunately the way the servers advertise themselves on the master server list means we can't write our own filtering proxies unless you also do port-forwarding, which not everyone can do (I thought about writing such a proxy last weekend).

Edited March 26, 2012 by Moa

[Moa]

Requiring permanent connection to master-server greatly helps here.

 

While we're talking, this 'requirement' means you will never have a reliable system. It is better to not have this as a design goal. The software ought to be built assuming that the connection can be temporarily interrupted. The internet is unreliable (for very many reasons) and the software must take this into account.

 

Authentication over the unreliable internet is a very well known problem for internet-scale applications. Generally they have a time-limited session token of some sort. Once you have authenticated you remain authenticated until your session token expires. Of course, servers can expire a token at any time so they still have control, it just means the client doesn't need continuous connectivity.

 

Before expiration the client software can either kick you off (old style and hostile) or attempt to re-authenticate on your behalf in the background. For example you could have a 1 hour session token that tried to re-authenticate in the background after 30 minutes and re-tried every 5 minutes or so until successful or the 1 hour session was up. Plenty of 'enterprise' applications are built to work this way (I know, I've written some).

 

Using sessions also takes the load off the authentication servers. Meaning they can be *very cheap* virtual machines - which allows you to have more of them for redundancy.

 

Of course, for reliability you'll have several authentication servers in geographically diverse areas (eg. California, Singapore, Frankfurt). If one server cannot be reached then the others are tried (in a DNS-like fashion). Not only will this give you reliability (no more 'players can't connect because the single master server is down' stuff) but it also allows you to pull authentication servers down for maintenance or upgrades while the others stay up. The geographic diversity is necessary because undersea cables can be snagged or significant earthquakes can happen (California!) taking a whole area out. So you need to spread your servers around a bit.

 

Doing this is very reliable, cheap, and good for players (they can always connect no matter what Internet storms there may be). Rather than provisioning your own servers/VMs you can also use services like Amazon's EC2 which is pretty cheap and scales well with variable load.

 

This post is not intended to tell ED how to run their business, I'm just passing on what I've learned about how other outfits with international customers run theirs.

Edited March 26, 2012 by Moa
typos

[ALDEGA]

The server should never trust the clients. This security model makes it so.

Security and usability (effectiveness) are in inversely proportional relationship.

An increase in security doesn't necessarily reduce usability.

 

I remember a poorly designed website where customers could order products.

The total amount of the order was calculated in the browser (javascript) and sent back to the server using a hidden field (input type=hidden) ... This allowed people to order stuff for free by modifying the values in their browser.

The server should not have trusted the client to "provide" the total amount, instead calculating the price itself using the product numbers and quantities as specified by the client. Another example is adding an additional product with a negative quantity, thereby reducing the total amount of the order ... Client input must be validated!

 

I think this is what Moa meant.

[c0ff]

Client input must be validated!

I suggest you to write a validator for A10C flight model.

 

Actually, what I want to say is that server has to trust its clients to some extent.

Yes, client input must be validated, but it can't be done with 100% robustness.

 

I suggest to avoid making broad statements about security and focus on a real problems.

Edited March 27, 2012 by c0ff