Physical Security Improvements

MattMeyer

I've gotten a bit of an itch today and focused on ways to improve the physical security of my device. I'd like to propose a few recommendations that I'd like to see added to 2.4.

I have enabled the "Password protect the console menu" option so anyone with physical access to the system could not make changes. In my case, I run pfSense as a VM in a cloud hosting facility and any cloud admin essentially has "physical" access to the console. It needed protection from snooping eyes. However, I noticed that after the system boots, you can still see the startup lines from /etc/pfSense-rc. I'd prefer that to be cleared so once the box has completed the boot process the only thing in the screen is a login. Simple fix. In /etc/gettytab:

change

P|Pc|Pc console:\
        :ht:np:sp#9600:

to

P|Pc|Pc console:\
        :ht:np:sp#9600:\
        :cl=\E[H\E[2J:

After enabling the "Password protect the console menu" option, the screen does not clear the menu options after logout (0). You can still see the system name, IP, OS, etc. There is no reason anyone needs to know this is a pfSense box and I would prefer the screen to clear after pressing "0" on the menu screen. Again, simple fix. In /etc/rc.initial:

change

exit && exit && logout

to

clear && exit && exit && logout

Finally, and this is because I have no trust in any cloud provider, every admin has physical access to the whole system. They can clone it and extract any information from the box, including all private keys, etc. The only solution is to encrypt the file system. I can confirm that manually partitioning the system at install is possible with zfs and geli. Now, I don't know how easy this would be to make this wizard-based before 2.4 is ready to ship, but it is possible and I'll be glad to write up a HOW-TO article upon the 2.4 release. This may also be useful for the paranoid person with hardware appliances with low physical security and don't mind typing in a password at each boot. Ideally, there would be TPM integration so no passwords are required, but that is something to do another day.

Thanks for reading.

phil.davis

For point (3), I can see how that is useful for someone in a small office or home without physical security of the hardware. Every time it boots, a password/key has to be entered that will decrypt the disk partition/s.

In a cloud hosted environment, that would mean that every time the VM is restarted a password would have to be entered. When the user restarts it themselves, and they have access to their VM console, then they can do that - and it is up to them to decide if they want the extra security in return for the inconvenience.

But what about when the datacentre has a "restart" for some reason? Or fails over the VM to another physical server in a way that restarts it? The VM would be sitting there waiting for a password/key. Any way I can think of for automating that at the data centre means that the data centre has the password/key stored somewhere.

MattMeyer

Hey Phil,

Yeah, it's a real drag that someone would have to enter the password each time the VM is rebooted. If the VM could take advantage of virtual TPM that may be a way around it, but I'm not aware of a cloud provider supporting TPM in a VM, nor have I ever tried to set up a zpool using the key stored in the TPM. Sounds like a fun challenge, though!

For the ROBO environments, it is peace of mind knowing someone could walk off with the router/firewall and get nothing. But again, you have the additional step of typing in a password on boot. Time will fix this, I'm sure.

Harvy66

@MattMeyer:

Hey Phil,

Yeah, it's a real drag that someone would have to enter the password each time the VM is rebooted. If the VM could take advantage of virtual TPM that may be a way around it, but I'm not aware of a cloud provider supporting TPM in a VM, nor have I ever tried to set up a zpool using the key stored in the TPM. Sounds like a fun challenge, though!

For the ROBO environments, it is peace of mind knowing someone could walk off with the router/firewall and get nothing. But again, you have the additional step of typing in a password on boot. Time will fix this, I'm sure.

Time cannot fix that last problem. Time can give you more options with a sliding scale of security vs convenience trade-off. It's a fundamental issue like DRM. How do you let the client see the data but not keep the data? You can't. You can make them jump through hoops, some of those hoops you may be able to control.

What would probably work is some sort of "remote dongle", where you have some hardware device that you physically control and the client, your remove VM, requires remote access to that dongle in order to do a challenged response. Then all you need to do is disable the dongle/service/etc when you find your VM has been stolen.

Of course it means you trust your VM. If someone stole your VM, moved it to their datacenter, and fired it up without you disabling your remote auth service, then you'll just let it start up as normal, decrypting the data.

MattMeyer

Time cannot fix that last problem.

I merely meant that over time we will find a way to solve it, not in the literal sense. :)

Harvy66

@MattMeyer:

Time cannot fix that last problem.

I merely meant that over time we will find a way to solve it, not in the literal sense. :)

Cannot be solved, it's a fundamental issue. Like I said, we may find some in-betweens that are convenient, but the actual issues will never be solved because it's impossible to solve.

You're asking, "Can we let the host know a secret without it knowing the secret?". The answer is no. What you can do it tell the host how to obtain a one-time use secret that you control.

This is why I used DRM as an analogy. "How can we let the end user access something with out accessing it". Obscurification is the best you can get.

If the host has all of the information needed to run your VM, then there's nothing you can do to stop them. You can obscurifiy some of that data, but the data is there. Only a matter of time.