Verifying server software integrity?
What a great question. I think this is one of the things that divides the games industry- do you centralise your servers to keep control over them, but then suffer from lack of flexibility to gamer needs and be accused of ruling with an iron fist or do you give control over to the gamer population and run the risk of malicious or tainted servers.
Three thoughts occur to me- none are ideal, but might be of use.
Announce configs to clients- this won't put off major compromise of the server but will increase the effort required from the malicious party.
Go down the route of trust and reputation, and have gamer rate servers whether they think they are honest or not. This also has issues, and rep can be gamed too but it is another option.
Provide the server software as a module you can query (a la punkbuster and valve's own checks) and disable on inconsistencies. Again, it has been proven again and again that this type of thing will be broken at some point as someone analyses the code to understand what response to send back, and it will annoy server owners, but it will also increase the effort required from the malicious party.
It seems highly unlikely that you'll be able to be confident of answers that you get directly from the server you don't trust. Seems like you need a third party to vouch for it. E.g. find a way to get a cloud service provider to attest to the fact that the operator has loaded a given iso image on some standard hardware and has subsequently only communicated with it thru a certain port which is tied to a well-constrained configuration interface. I've wondered before if any of the cloud providers do that....
In principle, there are technical solutions. You could make sure your servers all contain a TPM, and use remote attestation to have the server attest to each client that it is running the legitimate server-side software.
However, in practice there are significant engineering challenges, which may make this approach not terribly realistic, or more expensive than it's worth in your setting. For instance, clients now need to have a way of obtaining the master list of what versions of software are authorized; servers need to be programmed to use the TPM hardware (which is a bit of a specialty operation); schemes need to be devised to ensure that the integrity of the server software cannot be compromised after attestation; and other challenges. This all sounds like an engineering and management hassle of major proportions.
Unfortunately, TPMs' remote attestation capabilities are not widely used today, so you can't build on the efforts and experience of others. So, if you wanted to take this approach, you'd be on the bleeding edge. Sounds like the kind of thing that would make a program manager run screaming.
Therefore, I probably wouldn't recommend this approach to a small independent software vendor, even though in principle I suspect it could probably be made to provide reasonably decent security against the kind of threat you mention (if you had unlimited resources).