2

We are deploying in Chinese datacentre, it took us a while to get our account approved with Aliyun (some kind of Amazon AWS).

We are protecting all in and out data transfer but what guarantees that the OS itself hasn't been compromised? How do I check our Ubuntu has the same kernels and libs released by the official Ubuntu. Is there some kind of sfc /scannow command for linux?

Taking note that Chinese run their own mirrors of Ubuntu and all HTTP communications are routed through Government agencies (data gets altered, replaced and censored). Government also does deep packet inspection to block VPN connection. Our server is in Beijing.

Deploying on China's Alibaba copy of Amazon AWS

3
  • 3
    It's an interesting question which, for Ubuntu/Debian at least, doesn't seem to have an easy answer. Oct 23, 2014 at 2:15
  • possible duplicate of Check integrity of Debian system after possible rootkit?
    – neutrinus
    Oct 23, 2014 at 6:01
  • @neutrinus If debsums use the checksum that was created at the time of download then it wouldn't be able to tell if the file was already compromised on the mirror server. Also, it wouldn't be able to tell if the deployed image from the IaaS vendor hasn't been tempered with.
    – James Wong
    Oct 23, 2014 at 8:37

1 Answer 1

1

There is no completely secure way to ensure the server is clean. But there are a few approaches you can take to reduce the risk.

You can reinstall the server. If you know what you are doing, then reinstalling a server remotely is possible. A compromise that survives a reinstall is much harder to pull off than just installing a mostly invisible rootkit would be. So if you perform such a reinstall, your odds improve.

Obviously the reinstall need to be performed using a clean install media. I would use scp to copy the image to the server. If you cannot connect to the server using ssh, then you will have a hard time.

Compare the ssh host key on the server to the public key you see for the server. Some classes of systematic mitm attacks could be revealed this way.

Replace the ssh host key with one that you generated (in case somebody else has a copy of the one that was on the server when you got it).

Use key based logins. If the secret key has been leaked, or if you got the wrong public key in your known hosts mitm attacks would be possible. But some of the mitm attacks which would be made possible by this only works against password based logins and not against key based logins.

If the server has any sort of trusted computing hardware, you might be able to use this to verify the integrity of the installed OS. But this of course cannot give you full protection against scenarios where the hardware itself is compromised.

Things to look out for include the possibility that somebody else has console access to the server as well as the possibility that some of the communication paths inside the server have been bugged (for example a device that passively snoop on SATA communications and can actively inject data during boot would be feasible for a well-funded adversary, and it would be practically impossible to check for remotely.)

Also notice that if you are running on a virtual server, then the host server does have full access to your storage and memory. There is nothing you can do to protect your virtual server if the physical server on which it is hosted has been compromised.

Keep the most sensitive parts of your data away from servers you don't trust. This might mean you have to make it depend on servers you have in other locations for certain tasks. For example for password validation you can probably tolerate the slowdown which would be caused by not letting the server itself see the passwords and instead defer the validation to a server in a trusted location.

1
  • Thanks for the effort of writing this. It is certainly an alternative we will explore. We are looking at Ubuntu's Installation/OverSSH right away.
    – James Wong
    Oct 28, 2014 at 1:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .