Installation with Whole Disk Encryption
-
@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.
-
@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.
-
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.
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. :)
-
"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
-
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.
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.
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.
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.
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.
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.
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
;-) -
@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. -
This post is deleted! -
@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 ;-) -
@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 ;-) -
@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
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.
-
This post is deleted!
