usb key for encrypted zfs hdd

[ovidius]

@nollipfsense not as a secure login to pfsense. If you encrypt the zfs when you start the box it asks a passphrase in order to continue boot. After the passphrase is typed the box boots normally. Then the laptops they have with them can connect to the company's network. They login to the company's network and work. So the usb is the key not login but to allow the box to boot. The whole idea is that if they have to sever connection they just destroy the usb and turn the box off. No more the 5 seconds to do it. Also they don't have any kind of passwords for the box and after the boot up process the usb ca be removed. It's needed only for boot.

[johnpoz]

@ovidius said in usb key for encrypted zfs hdd:

he only thing they can do with the pfsense box they have with them is to turn it on and off.

You kill the connection at the other end. You have 2 points in any connection A and B..

If you don't want B to connect to A - then you just stop it at A..

If you don't want billy calling you, do you make sure billy phone has your number blocked.. Or do you just block his number in your phone ;)

[ovidius]

@johnpoz and how do I know that I need to sever connection? The user on the ground knows better than me if the connection needs to be severed. What is faster? Trying to find a way to call back home to tell me to cut the connection or just unplug the box? Also. If the user needs to reestablish connection when he/she thinks that is okay to do it, it can be done at his/her convenience. Another point. If the box is stolen its unusable except if the user is so idiot to leave the usb on after the boot proccess is completed and despite the instructions he/she has to remove it. If someone gets access to the box and tries to steal it he needs to take it out of power. So when they try to reconnect not working. If they try to connect with another machine other than the certified user also they will be declined. There are multiple measures to assure security. This is just one more. Anyway. I don't understand why are we still talking about why I am I doing this and not, if you want to ofcourse, help me do it.

[johnpoz]

@ovidius ok maybe I am not understanding the requirement here..

Your boss wants "make that connection can be disabled right away"

Right away to me is at your end, just kill the connection.. Seems way easier than having someone at the remote site reboot the pfsense box?

I am trying to help you.. Just because user thinks solution X is the answer, quite often that is not the best solution.. So discussing the other options to solve a problem can be quite useful normally.. Because maybe user didn't think it all the way through, or has blinders on once they think they found a solution to problems or other ways to solve the problem.

The XY Problem.

But you have your heart set on some sort of usb key to auth to your pfsense and nothing else - then I won't be able to help you, I have never even looked into such a thing because I have never had such a use case where it would make any sense.. And I still don't see how your use case makes any sense.

If this had a valid use case - I would think the other firewall makers would have it implemented - which if they do I am sure not aware of.. Does Juniper or Palo or Cisco provide such a solution?

But your complicated scenario can for sure cause an outage, what if the pfsense box reboots - and nobody is there that knows where this usb key is, or what if that usb key gets lost or damaged.. And now they can not boot pfsense..

Good luck - lots of smart people here, maybe someone can help you with your scenario..

[ovidius]

@johnpoz no my boss' requirement was "the machines that making the connection to be disabled right away". He doesn't want just the connection severed. He wants the machine also unusable. If you read my initial answer to you, you'll see that this is the thing that I told you from the beginning. Also the need is for the connecrion to be severed according to the users judgement so that the connection can be up to the last possible moment. I hope that I satiafied your curiosity. Do you, please, have anything to say that can help me?

[ovidius]

@johnpoz for the comments you added. Just because nobody thought of it before doesn't make it wrong. It makes it new. Second I just understood that you didn't understand what I want to do. I don,t want to authenticate users in any pfsense box with the usb key. The usb key will exist only to allow the boot sequence to proceed. Nobody will log in or sign in with this usb key.
So I believe that your reference to the other firewall makers is wrong and thats because of the nature of pfsense. Pfsense is based on freeBSD. So from what I have seen a solution like this can be implemented in freBSD machines and in TrueNAS. I was asking here because Iwanted to see if someone has done something similar. To conclude the requirements are:

1. Remote users have to have site to site connection with HQ at any time they need.
2. Remote users have the authority to sever the connection with HQ and not the HQ with few exceptions that are not important now.
3. The machines that are used for the site to site connection have to be totally unusable if stolen or lost.
4. No user has access directly, by ssh or with webconfigurator the pfsense box they carry with them for the connection. They don't have any credentials to so. They just plug it to the power, connect wan to internet and a laptop or a switch to lan. That's it. Nothing else. All other jobs are done with the laptop/s of the user/s
5. The cost must be kept as low as possible

Also some things that are also in force:

1. pfsense box is not to boot unsupervised by one of the appropriate users.
2. If the pfsense box is to be left alone or unsupervised the procedure is to turn it off
3. The users may be idiots but they are trained capable idiots that follow procedures so its not likely the case to leave pfsense boot unsupervised, leave the usb on it after boot or loose the usb.
4. In the unlikely case they lose the usb there is a protocol to replace the passphrase in a very timely manner in a secure way.

So with this parameters can you propose a different solution than the one we are proposing. From the start I am telling you that specialised devices that cannot be bought or replaced in any pc selling store are out of question. So I would like your opinion. As you said by talking we can find solutions. This is my solution with the parameters I have got.

[stephenw10]

There's nothing included in pfSense to do that. It might be possible using a custom install but there's a pretty good chance anything installed like that would not upgrade cleanly.

There are few Google hits for similar setups.
https://forums.freebsd.org/threads/zfs-boot-from-usb.45880/

I would not recommend doing that.

Steve

[ovidius]

@stephenw10 thank you for your answer but I suspect that my English is not as good as I thought because what I get from your answers is that you don't understand what I want to do. Pfsense when it is installed can have both installation partition and swap partition encrypted. This is done with GELI. NO CUSTOM INSTALL. After that when you boot it asks for the passphrase you input on installation. I am just asking if it is possible to avoid typing the passphrase by having a USB key holding a key that unlocks GELI in a similar fashion with this:
https://tqdev.com/2022-luks-with-usb-unlock

I thought since Linux and FreeBSD have common roots there would be something similar that could be done.
I didn't go to freebsd forum because I thought that if there was something distinctly different from the rest of freeBSD I would find it here.

[NollipfSense]

@ovidius said in usb key for encrypted zfs hdd:

https://tqdev.com/2022-luks-with-usb-unlock

I would encourage you to try it on a non-productive install and see whether you can perfect it before moving to a productive environment...sounds promising. Please report back on your effort good or bad. BTW, it seems that the author used a secured USB key.

[ovidius]

@nollipfsense where did you see that he used a secured USB key. In step 3 he creates a key file, in step 4 he finds the USB with lsblk, and in step 5 copies the key file in the USB. After that he creates the script that searches for the USB on boot. After that the USB is not referred at all. So I don't think that he uses a secure USB, just a simple USB key.

Also about reporting back I might or I might not. After all my scenario does not have a valid use case and is not making sense.

Anyway thanks for the answers

[johnpoz]

@ovidius said in usb key for encrypted zfs hdd:

After all my scenario does not have a valid use case

Preventing a vpn connection by keeping the pfsense from booting because the hdd is encrypted an needs a password to boot is the crazies solution to a very simple problem that is for sure.

If you don't want site B to connect to site A via vpn - then just deny it at site A with a click..

But you have fun..

[ovidius]

@johnpoz man you just continue. Have you even read the big post I sent with the requirements? I can't deny it from HQ. I have to have communication lines always open. The cutting off must be done by the user on point B and the machine has to be made unusable. So instead of be stubborn and just ridiculing someone you don't know try to be helpful and give an answer along the requirements given. If you can't offer anything at least don't sabotage the conversation with unneeded comments like this one. Unfortunately some of us have requirements on how to do some things that don't coincide with the common wisdom or common practice. So we need something out of the box. If you have something to offer it will be welcomed. Otherwise please don't prevent someone with an idea to help by posting only your opinions that what we are doing is wrong. Thank you

[stephenw10]

Is the encryption actually necessary here or are you simply using that prevent it booting without the key?

You could otherwise do something like set the machine to only boot from USB and then have a bootloader on the USB drive that references the main drive.

[ovidius]

@stephenw10 the requirement is not to just prevent the boot without the key. The requirement is the device to be made totally unusable if stolen or lost. If I use the solution you are proposing even if the system will not boot without the key, the disk will be readable so I don't cover the second requirement.

Beyond that I think that the proposed solution is more complicated to implement at least for me. To have the bootloader in a usb means I have to do a custom install. If I just encrypt the disk its just a normal install just ticking options during installation process. Aso if I have the disk encrypted and the key just copied to a USB stick if the key for some reason is lost I can send in another secure way just the key file and the end user can copy it to USB that he/she can buy or find anywhere and use it(that is just an example). When I saw the article I sent I thought that a similar process would not be so much more difficult in FreeBSD than in Linux. It seems it's not.

[NollipfSense]

@ovidius said in usb key for encrypted zfs hdd:

where did you see that he used a secured USB key.

By showing this he implies it as an option.

@ovidius said in usb key for encrypted zfs hdd:

Also about reporting back I might or I might not. After all my scenario does not have a valid use case and is not making sense.

That's just how forum works and it not intended to discourage but more to dare you to do it...please do!

[johnpoz]

@nollipfsense said in usb key for encrypted zfs hdd:

That's just how forum works

Exactly -- I see no possible reason why anyone would do such a thing. I see no valid use case for it, I have no desire to help anyone go down such a path to be honest.

But you have fun, and for sure report back on it - I like a Rube Goldberg solution to stuff.. How can I complicate this beyond comprehension for what could be done with a click.. And take someone literately 5 seconds to accomplish.. But hey lets turn it into a thing that could take my network down because the power went out and nobody there that knows the password to the router, or the usb with the key on is locked it bobs office and he is on vacation in aruba..

[stephenw10]

Mmm, I agree this problem is usually solved using, for example, certs at the server end.

What you're proposing doesn't seem that unreasonable if the solution must be something at the client end. However I'm not sure anything like that exists in FreeBSD.
I wonder if something similar exists for a BIOS level disk decryption? I expect it probably does.

Is it only the VPN connection that must be disabled? For example if you had the required certs stored on a USB drive such that the firewall would boot but could never connect to the VPN without the key, would that suffice?

Steve

[johnpoz]

@stephenw10 seems like a solution to a problem that doesn't exist.

Why would you try and block access at site B to site A, when you can just do it at site A.. My phone analogy of stopping someone from calling you.

I have a company network and I don't want a remote site to be able to login - ie they all got fired or something. Why would the solution be reboot and the device at that site and prevent it from booting?

Clearly there most be something lost in translation or something - that solution makes no sense to me..

If I don't want site B to vpn in, or I don't want user Z to login - then site A I just don't let them login.. Change their login, disable their cert, block their IP.. There are multiple ways to accomplish it at site A all of which literally take a few seconds to do..

I could see encrypting the drive if your worried about billy taking the box home and getting info he shouldn't have or something.. But to prevent vpn access.. Why would you do it it the remote site, when it can just be done at the home location, ie HQ or the DC location for the company, etc.. Then again if the box was stolen or taken home by someone - just change the info that was on the box, passwords, certs, etc. so they are no longer valid.. I having a hard time for encryption of a firewall hdd in any scenario - there is just nothing on there that warrants the complexity that comes with that, when all that is for is protection of data at rest.. I could see that on you device that could get lost, say a laptop.. That might get left on a train or bus or something and fall into the wrong hands..

For that matter - how the company having access to the remote site, which should be a given in any vpn setup - and the IT at the company just turning it off remotely on the remote site..

This for sure seems like a XY problem to me - someone came up with a solution, and is just unwilling to think it through that hey that is not a good solution to the problem trying to solve. Just tell me how to do it what I asked.

https://xyproblem.info/

The XY problem is asking about your attempted solution rather than your actual problem. This leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help.

    User wants to do X.
    User doesn't know how to do X, but thinks they can fumble their way to a solution if they can just manage to do Y.
    User doesn't know how to do Y either.
    User asks for help with Y.
    Others try to help user with Y, but are confused because Y seems like a strange problem to want to solve.
    After much interaction and wasted time, it finally becomes clear that the user really wants help with X, and that Y wasn't even a suitable solution for X.

The problem occurs when people get stuck on what they believe is the solution and are unable step back and explain the issue in full.

A better question might of been - how do I prevent site B from vpn to site A on moments notice..

[ovidius]

You still don't or don't want to understand the requirement. I have a company and I want a remote site to be always able to connect to the HQ site unless the remote site and the personnel at the remote site decide that they must stop the connection. If there is such case where the remote site stops the connection for any given reason (probably a physical security one) the personal at site B MUST have the capability to totally make the pfsense box unusable. So the requirement is not for the HQ (site A) to cut the connection (that as pointed so many times is very easy) but to give the site B personel the option to cut the connection securely according the situation and their needs and judgment. So no its not an XY problem. You just perceive it as one. There were a series of requirements given and according those requirements a solution must be found. So boss set requirements Technician tries to find solution Technician forms a theory on how to resolve requirements Technician needs help on how to make theory practice Technician asks for help in forum

So instead of trying to make the problem fit your solution find a solution for the given problem.

[ovidius]

@stephenw10 no its not only the VPN connection that has to be disabled but the whole client box. That's why I went with the disk encryption. Even if someone manages to break GELI encryption it will take some time, enough time to make any data he gets (if he gets anything at all) from the disk about my HQ network obsolete as I would have blocked the connection. While searching for a solution I found this which suggests that what I want to do can be done
https://www.truenas.com/community/threads/zfs-encryption-usb-auto-unlock-and-mount-with-pass-phrase-as-i-do-with-gli.96517/.

I am trying to implement it but if you read it and have a better idea I am always open to suggestion for a simpler solution