Installation with Whole Disk Encryption



  • Possible?  If not, planned?  If not, why not?



  • In 2.4.



  • So do you plan on entering the encryption password on each boot?
    I personally don't see the use case on a firewall?



  • @heper:

    So do you plan on entering the encryption password on each boot?
    I personally don't see the use case on a firewall?

    I asked about Full Disk Encryption (such as with GELI) a few years ago and got similar feedback.  For me in a personal environment, I'm OK with the inconvenience of having to enter a password with each boot if it means that physical theft or physical access to a powered-down pfSense appliance makes it harder to access the contents of the disk, including all configuration of firewall, packages, state tables, VPN private keys and passwords, pfSense Certificate root key and all server private keys, etc.  That stuff is pretty sensitive – and I almost want to take my PKI off the pfSense box and onto its own offline machine under lock and key just so I don't have my root key in an online edge device that's literally interfacing with the WAN.  Full Disk Encryption would make credential theft and other forensics more difficult to an attacker who gets physical entry to my home.

    (No, nothing nefarious to hide, just anal about defense-in-depth and enjoy experimenting with increased security.)

    Edit:  Now that I think about it, I'm not worried so much about firewall config or things like that.  I'm more worried about credentials theft:  passwords and private keys.


  • Rebel Alliance Developer Netgate

    Look at the 2.4 installer (once you pick ZFS):

    Granted you'll have to give it a passphrase and then enter that passphrase at every boot, so it's really not well-suited for an unattended role, but it does work. Super simple to setup.

    You can also encrypt swap for even greater security.

    Bear in mind, you will lose performance due to the encryption overhead when hitting the disk/swap.

    EDIT: Swapped screenshot, added detail.



  • @jimp:

    Bear in mind, you will lose performance due to the encryption overhead when hitting the disk/swap.

    I'm not well-versed on BSD encryption, but would a CPU's AES-NI be able to help in this department?  Hopefully we'd be able to fine tune geli and specify AES-128-XTS or AES-256-XTS or whatever.

    Either way, thanks for adding swap and disk encryption.  Really looking forward to 2.4.



  • Also note that OpenZFS (which is what FreeBSD uses) has no support for a built-in encryption. Encryption is done using the GELI system and the kind of setups you get with ZFS on top of GELI are not for newbies, you absolutely have to know what you're dealing with or you will hose your system sooner or later when something needs attention either on GELI level or ZFS level and you make a simple mistake.


  • LAYER 8 Global Moderator

    I am just curious what exactly would be on your "firewall" that warrants disk level encryption?  I just do not see the point to it at all..  So you think someone is going to steal your firewall and view your firewall rules?

    So someone on your location, normally firewalls should be in a locked room that only authorized people have access too.. Normally with some sort of logging and or camera's of who is the room/dc etc..

    Disk encryption is zero protection against a compromised system that is online.  It prevents someone from reading the disk that has physical access to the disk..  I just do not see what would be on the disks in a firewall that would require whole disk encryption?  Lets say someone stole your firewall.. What does it get them?  That your worried about at such a level that you should just encrypt the whole disk??



  • It's a fad among the younger hacker community that are now oh so worried about someone stealing their computer and learning of all their dirty secrets. It will pass.

    Seriously speaking there is very little sensitive information on a pfSense system assuming you don't try to use it as general purpose server but only as a firewall/router and possible as a proxy/cache and/or IDs system which are what it's designed for.



  • @kpa:

    Seriously speaking there is very little sensitive information on a pfSense system

    The Root CA's private key isn't considered sensitive?
    VPN private keys aren't considered sensitive?
    Private keys for 802.1x and RADIUS aren't considered sensitive?

    A UTM box is a jack-of-all-trades, and with that convenience comes the insecurity of hosting a lot more sensitive information on an online system.


  • Rebel Alliance Developer Netgate

    @kpa:

    Also note that OpenZFS (which is what FreeBSD uses) has no support for a built-in encryption. Encryption is done using the GELI system and the kind of setups you get with ZFS on top of GELI are not for newbies, you absolutely have to know what you're dealing with or you will hose your system sooner or later when something needs attention either on GELI level or ZFS level and you make a simple mistake.

    If you keep a proper config backup that's not a concern. If it breaks, it's either hardware or you can wipe+reload+restore and be on your way. There is no  need to diagnose or repair in that fashion here.

    @kpa:

    Seriously speaking there is very little sensitive information on a pfSense system assuming you don't try to use it as general purpose server but only as a firewall/router and possible as a proxy/cache and/or IDs system which are what it's designed for.

    Biggest concern is CA/Cert data, especially if you are hosting a site for your company through HAProxy. There could also be some concern about credentials stored in the configuration (e.g. PPPoE login for the ISP). Encrypted disks also stops people from working around a password-protected console.

    Honestly though if the box was stolen, even with encrypted disks, I'd still be getting certs reissued or rebuilding the CA, changing passwords, etc. It's not about the work involved but about mitigating potential risks.

    I doubt I'd ever run with encrypted disks on a firewall, but if someone wants to, more power to 'em.



  • @johnpoz:

    I am just curious what exactly would be on your "firewall" that warrants disk level encryption?  I just do not see the point to it at all..  So you think someone is going to steal your firewall and view your firewall rules?

    The firewall config and firewall rules aren't really all that juicy.  What's more sensitive are the private keys for various functions:  root CA and private key, site-to-site and remote access VPN private keys, VPN passwords, server private keys generated by the internal Certificate manager.

    @johnpoz:

    So someone on your location, normally firewalls should be in a locked room that only authorized people have access too.. Normally with some sort of logging and or camera's of who is the room/dc etc..

    Disk encryption is zero protection against a compromised system that is online.  It prevents someone from reading the disk that has physical access to the disk..  I just do not see what would be on the disks in a firewall that would require whole disk encryption?  Lets say someone stole your firewall.. What does it get them?  That your worried about at such a level that you should just encrypt the whole disk??

    Heh, you said about the same things in 2014:  install pfsense on full encrypted hard

    In an enterprise scenario, physical access is much more controlled.  You're preaching to the choir.  And in an enterprise environment, we wouldn't have the root CA on a firewall appliance but in its own PKI with its own levels of security.  And in an enterprise environment, it'd be unnecessary or overkill or woefully inconvenient to enable FDE on a pfSense install because it'd require physical access to the datacenter or co-lo (or I guess exposing IPMI a bit more via a separate VPN), which means lots of downtime.  This is obvious.  Nobody here is arguing against this use case.

    But in a SOHO environment, physical security can be much different.  Can you genuinely not see the use case in a SOHO environment for those who are OK with the extra inconvenience for the added physical security?  And in a SOHO environment, a lot more people will use the built-in certificate manager and have a ton of private keys there.  In a SOHO environment, physical access to the pfSense appliance and physical theft of the box is much more likely to occur than in a datacenter or co-lo.

    There's a very large userbase for the pfSense community, including a legion of home users who see the value of pfSense (and eventually become ambassadors in the workplace).  There's a lot of reasons out there for FDE.  :)


  • LAYER 8 Global Moderator

    "but there's a lot of reasons out there for FDE."

    Not seeing it.. Not on a firewall.. For sure not in a soho or home setup.  In a soho setup sure the CA might be used to sign the certs for use of their vpn connectivity.. Might be used to sign the certs for their local servers.. I use it for this as example..

    The device is still in my home, so is a thief going to come in, steal my pfsense.. And then I would restore my CA from backup and continue to use it, I don't think so!  Lets say they got my PPPoE login – who gives a shit I say.. This is used to auth that I am a legit user to my ISP.. Hey ISP my firewall was stolen, had my PPPoE password on it - could you change it please ;)

    And as you say in an enterprise makes no sense either.

    I remember previous conversations about this topic sure, and while it might of been answered to your satisfaction even in this thread.  The reason I ask again is none of it makes any real sense to me..

    For starters.. especially in soho/home setup.. Reboot of said firewall, lets say power loss.. And now someone had to put in the freaking password so the thing can boot..  Can not even do a remote upgrade now either.  I have been known to update my pfsense while remote.. I have one in a branch office, locked room - It is just being used for non sla guest access on the wifi network, etc.  I just upgrade it off hours since if it dies there is no sla to contend with.  But now if it was using FDE I would have to make sure someone (maybe even me) was on site and they would need to enter the FDE password (possible not IT person)...  I need to upgrade its bios which requires hard power off, which is being a pain figure out when someone will be on site to be able to power cycle it for me, etc.  It would be just lovely if someone would have to be on site and know the password on case of power loss, etc.  I personally think keeping the code updated, with the ability of hands off remote update any possible perceived security increase that a FDE might bring.

    I think I brought these points even in the previous conversations.. It seems to me beating a dead freaking horse.. Just make zero sense to me is all for FDE on a firewall..  Do devices like Palo Alto or Cisco support encryption?  And require a boot password like a FDE does?  If so wow what a mess that would be when there is a DC power outage.. No they are not suppose to happen - but they do..  Yeah its shit storm when it happens.. It would just be even more so now that someone has to go manually enter the password to boot the device.

    Hey if you want it - go for it..  But also part of the reason I bring up the other point of view.. Is so that the vast community of pfsense, with yes many new to the whole thing sort of users don't get it in their heads hey these guys are talking FDE on the forum.. This must be the greatest thing since sliced bread - I must be unsecure if I don't do it, etc.

    I am guess same mind as jimp - this is for sure something I would never do.. And hey if you want the burden with no added benefit have it at.. But I will still post my opinion that is just pointless..

    Nor do I care if it gets me smites.. Which looks like it might have..  Hmmm



  • @johnpoz:

    I have one in a branch office, locked room - It is just being used for non sla guest access on the wifi network, etc.

    In this use case (Guest Wi-Fi access, no SLA, no urgency), why would FDE be used?  It's the perfect use case for not using FDE.  Seems like you're setting up a strawman.  Nobody here is arguing that a configuration such as this one should be encrypted.

    @johnpoz:

    I just upgrade it off hours since if it dies there is no sla to contend with.  But now if it was using FDE I would have to make sure someone (maybe even me) was on site and they would need to enter the FDE password (possible not IT person)…  I need to upgrade its bios which requires hard power off, which is being a pain figure out when someone will be on site to be able to power cycle it for me, etc.  It would be just lovely if someone would have to be on site and know the password on case of power loss, etc.  I personally think keeping the code updated, with the ability of hands off remote update any possible perceived security increase that a FDE might bring.

    Kind of the same reasoning.  This is a perfect use case against FDE where it's in a branch office and you'd have to get a random non-IT person on the phone and walk them through it and reveal the password.  Nobody is arguing that this would be wise.

    @johnpoz:

    I think I brought these points even in the previous conversations.. It seems to me beating a dead freaking horse.. Just make zero sense to me is all for FDE on a firewall..  Do devices like Palo Alto or Cisco support encryption?

    Keywords bolded.  You keep using this phrase "on a firewall."  And I agree with you.  If the appliance is just functioning as a firewall, there's really no added value or tangible security in encrypting the disk and a whole lot of added inconvenience.

    But that's the strawman:  Nobody is arguing for FDE on just a firewall.  The use case is for those who make it a jack-of-all-trades appliance with lots more creds (keys, passwords) stored in the clear.  Or a ton of caching that's stored on the disk that could be used against the users after doing forensics.

    @johnpoz:

    And require a boot password like a FDE does?  If so wow what a mess that would be when there is a DC power outage.. No they are not suppose to happen - but they do..  Yeah its shit storm when it happens.. It would just be even more so now that someone has to go manually enter the password to boot the device.

    Right, so more uses cases and more strawman arguments.  Nobody here has said that it would be a good idea in these scenarios.  And what kind of datacenter doesn't have UPS and generators anyways?  Yes, I agree with you.  Preaching to the choir.  But then again, nobody here is saying that this example is a good use case for FDE.

    @johnpoz:

    Hey if you want it - go for it..  But also part of the reason I bring up the other point of view.. Is so that the vast community of pfsense, with yes many new to the whole thing sort of users don't get it in their heads hey these guys are talking FDE on the forum.. This must be the greatest thing since sliced bread - I must be unsecure if I don't do it, etc.

    I would suggest to those who are new to pfSense to really evaluate their use case and environment and threat model and determine if disk or swap encryption would be beneficial to them or their organization.  I agree with you:  New users/admins shouldn't blindly turn every setting "on" just because it seems cool.  pfSense isn't a NAS and isn't a traditional server per se but just a Swiss Army knife network security appliance.  But then again, if a user is taking on this project (whether home, small business, or larger environment), they probably already have the knowledge to not just go in guns blazing.  I mean, this isn't targeted towards n00bs buying their random Belkins to watch YouTube at home.

    @johnpoz:

    I am guess same mind as jimp - this is for sure something I would never do.. And hey if you want the burden with no added benefit have it at.. But I will still post my opinion that is just pointless..

    Look, I think we're mostly in agreement.  It's a very narrow use case to implement FDE on a network security appliance, but as the capabilities and packages grow and as pfSense becomes more of a jack-of-all-trades single device, there is more justification for encryption for those who understand it.  I think it's a great feature and selling point even.

    @johnpoz:

    Nor do I care if it gets me smites.. Which looks like it might have..  Hmmm

    Wasn't me.  I'm not a heavy poster here, so the "smite" thing is hilarious.  Whatever.  :)

    Next project:  full disk encryption on Phillips Hue light bulbs!  Because you can never be too loose with your lumens…. (April Fool's)



  • @jimp
    Hi..., How can I remove passphrase when os is booting?
    I tried this command but , nothing happened :
    geli configure -B prov
    ;-)


  • LAYER 8 Global Moderator

    @finger79 said in Installation with Whole Disk Encryption:

    pfSense becomes more of a jack-of-all-trades single device

    Huh? Where is that in the roadmap.. It not a everything box - its a firewall. If the user goes about having it serve up websites and freaking serve up files.. That is not the design goal..

    If you want a box to do everything - install some hosting VM software on the hardware... Use your FDE here, and run pfsense as a VM...

    "How can I remove passphrase when os is booting"

    Wouldn't that just defeat the whole freaking purpose of FDE...



  • @johnpoz
    Thank you so much, But i don't agree with you, because If we use a VM for firewall , performance and maintaining will be low. hence, I'd rather whole disk Encryption without using passphrase! but How can I implement it?
    PS : I used geom_eli_passphrase_prompt="NO" in /boot/loader.conf and geli configure -B prov but nothing happened.


  • Galactic Empire

    This post is deleted!

  • LAYER 8 Global Moderator

    @harika1258 said in Installation with Whole Disk Encryption:

    VM for firewall , performance and maintaining will be low

    Nonsense, not if sized correctly.. And encryption without a passphrase is NOT encrypted now is it... It would be utterly pointless..

    There are thousands and thousands of people running pfsense on VM.. All different flavors, esxi, zen, hyper-v, etc. etc. I ran it on VM for years. But my OLD n40l microserver could not handle the 500/50 internet speed so had a choice update to box that could do it with pfsense as vm. Or go with hardware - I went with the sg4860.. Which I do believe can run esxi on... Maybe at aomepoint will try that.



  • @johnpoz
    OK, all -right . I don't use any VM solutions. ;-)
    do you have another solution? I mean , I want to encrypt partitions with ZFS without entering passphrase every time when os is booting ;-)


  • LAYER 8 Global Moderator

    @harika1258 said in Installation with Whole Disk Encryption:

    I want to encrypt partitions with ZFS without entering passphrase every time when os is booting

    Then there is ZERO point to the encryption in the first place... What is it protecting??? The whole problem of FDE on something like a router is that it needs intervention for boot..

    If there is no passphrase, then when it boots the encryption is just unlocked. Like a zipfile without a password on it - anyone can open it. You put a password on the zip file and you have to know the password to unlock it.



  • @johnpoz
    if someone has physical access to appliance who can move the appliance 's hard drive to another system (computer with Windows os) to view and does everything.
    I want to protect it in this case.
    although I want, when pfsense is booting, we don't need any passphrase.
    just want to protect files in attaching to machine who running windows OS ;-)


  • LAYER 8 Global Moderator

    @harika1258 said in Installation with Whole Disk Encryption:

    just want to protect files in attaching to machine who running windows OS

    So your wanting to protect it from idiot users? Why would I move the HDD to another system when I would just get the info off the thing while I have physical access to it??

    I really think you need to do some research on what FDE actually protects you from..

    So your scenario your wanting to protect against.. Windows not going to read a zfs anyway ;) Be it encrypted or not. And what appliance are you using exactly... Mine doesn't even have a HDD they could take out...



  • This post is deleted!


  • @johnpoz 0_1529990347180_Untitled.png
    As you know, in windows OS, by UFS Explorer you can see partition that is set up with ZFS.
    I use Nexcom Appliance ....



  • Your adding normally non-existing issues : a system that runs virtual appliances shouldn't be made accessible by ordinary users, except for the services they offer remotely.
    Only an 'admin' should access such a systems directly.



  • I'm not quite sure I understand arguing against FDE with the justification "it's just a firewall" when this simple firewall has a robust package management system which features an impressive catalog of packages.

    I personally use pfSense as a firewall, a dynamic DNS client to NoIP (which requires credentials), and a tinc (keys!) server to tie other pfSense boxes together. I see people leveraging pfSense for much heavier workloads so I definitely see the argument for FDE.

    I also see that FDE is a PITA because, at boot, you have to either be physically present to enter credentials, share said credentials with somebody who's present, or expose IPMI (if you have it) to gain virtual KVM access to it.

    Would it be possible to see something like dracut-crypt-ssh make its way into the feature list? I use it on everything as a backup for when tang/clevis isn't working in a predominantly CentOS-based environment. It would be quite handy to have pfSense have a similar functionality whereby it boots dropbear on a specific port, protected with a preconfigured keypair, that goes away once pfSense is fully booted. Just my $.02.



  • FDE is a PITA that is only useful if you're in an environment where there is a significant risk that someone will steal your disk so they can mount it elsewhere and look for prizes. Most people are not in that environment, and even if they were, there is usually nothing on the firewall that would be of any use to an attacker. Your mileage may vary, of course. Nobody else should have physical access to the box except you or other IT admins. Certainly not users.