How do you protect your server at the datacenter from physical access by unauthorized personal?

Considering protection against malware (keylogger and trojans) and having data- and OS integrity?

Is it even possible?


The first step would be using a secure facility that carefully controls access. Beyond that, locking the rack is probably one of the best bets. Super glue in control ports works well too as long as you know you won't need to use or change the port. Chasis locks, etc. A lot of it really comes down to trusting the data center to provide that outer layer of security though. Unattended hardware in a room someone else has access to can be broken in to if someone really wants to.

While it won't prevent physical access, you can also do thing like log chasis intrusions (if you have the sensor for it) and any changes in hardware state. These can also be worked around by a careful attacker with knowledge of your hardware though.

If you really need full control, then you need full control of the physical environment as well.

  • That or you can always try a land mine in front of the server rack and a shotgun in the cabinet with the trigger tied to the door. ;) Mar 13 '14 at 13:47
  • Seriously, is there no way to secure the server other than McGuyver style? What about Trusted-Computing? Full Disk Encryption? Virtualization? Dedicated Crypto-Hardware? Is there no imaginable way? Mar 13 '14 at 14:36
  • @user3200534 - those don't secure from PHYSICAL access. They secure data and processes. A running server must have keys in RAM and if you have physical access it is conceivable to pull that data out of the hardware in flight while decrypted (including potentially pulling the keys themselves). When someone has complete physical control of your running box, as you use it, you are done. Mar 13 '14 at 14:37
  • Full disk encryption is invaluable for protecting data at rest but does almost nothing for data in flight other than make an extra hoop to jump. Mar 13 '14 at 14:40
  • If RAM is not secure place to hold the keys, why not instead store the keys in some sort of TPM or other crypto-chip? Is it even necessary to store the keys locally? Would it be possible to use a safe highly encrypted hardware tunnel to other machine that sends the keys directly into the crypto-hardware that performs the operations? Mar 13 '14 at 14:45

Depends on the data center itself (size, setup), setup you choose and SLA with data center. Basically the options are physical controls and organizational controls.

  • Physical: you have your own rack or area in the data center with a lock that noone can access without the key
  • Organizational: you do not have your own physical access but the data center restricts access to your servers by not allowing any unauthorized access (i.e., people you authorized to access your server) This could be with security guards, access control such as badges or biometric scans etc maintained by the data center.

Of course data center personnel will still have access (unless you also put your own racks there).


Standard physical access control

Sensitive servers benefit from the same controls that work for any other sensitive items:

  • Authorised personnel only - the room with the server should have limited access, enforced by electronic badge locks and/or physical guards.
  • Know who and when had access - the entry mechanism should know who entered and when, so that means personalised badges as opposed to physical keys or keycodes; if guards are used, then a log should be kept of who entered and when; and of course video monitoring should show the faces of those entering, which matters in the case of a stolen/borrowed badge.
  • Access only when necessary - the room with the server should be usually empty, not with people doing 'business as usual' all the time.
  • Compartmentalized access - someone with access to the data center should not have access to all the data center. A common approach used in e.g. multi-tenant data centers is to have the data center operator handle the abovementioned security rules for everyone, but have a physical lock on your rack so that someone co-locating with you can't casually access your rack. They might break the lock, but that would be detectable and together with the access control measures result in inevitable arrest of that person.

Server specific controls

  • Offsite logging - you want an append-only logging service that is not at the same location as your server; so a physical compromise of the server can't easily be done at the same time as removing the logs.
  • Constant monitoring - if someone physically restarts your server, which is a requirement for some attacks, you want to immediately know that. Together with the abovementioned monitoring this will allow you to know who did that, if it was your authorised operator with a valid reason.
  • Monitoring of racks - since your rack hardware should change only rarely, you can monitor for physical attacks by two cheap video cameras (one at the front, one at the back of the rack) and standard change-sensing video software; there should be no movement there except when your administrators install new or replacement hardware.

Detection instead of prevention

As you may have noticed, the measures listed above don't actually prevent a determined attacker or malicious insider from taking your server, however, they ensure that any such action or attempt is likely to be detected and linked to the person doing that. Usually this is sufficient to deter potential attackers or malicious insiders.

However, if the potential gain is high enough - if the attacker can gain millions or more from a single successful compromise (as opposed to causing you loss of millions or more, which is a much lower barrier), then a standard approach is to ensure that any such actions are impossible even for a single authorised person, requiring cooperation of multiple insiders or compromising multiple people. This has the drawback of making normal operations much more cumbersome and expensive.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.