“If you have paranoia, this does not mean that you are not being watched.” © Popular wisdom
After reading the post
How I introduced the first rule of doing business in Russia , I had this question:
What to do if a company develops a software product (SaaS), and in the development process it is necessary to use local develop and stage servers? What will happen if the “attacker” gets physical access to the disks and how not to give him all the source codes of the projects? And if we roll out the code to the battlefield through scripts, Chef or Puppet, then we also give all access to the combat sites.
')
The answer is obvious: encrypt everything of value. But as we all know, encryption options are mass. Starting from encrypting individual files and creating cryptocontainers (for example, TrueCrypt) and ending with full disk encryption.
You can say "so you yourself break the rule and keep your local servers in the office?". And I agree, but with a reservation. For a comfortable development, the closer the source, the better, and given the speed of the Internet for legal entities in the regions, which can be obtained for reasonable money, keep develop and stage servers somewhere far away will lead to excruciating pain. Here I am talking about a scheme where there are no source codes on the development machines. All code lies on the network develop server. And in general, ping out and ping in local gigabit are a little different things.
So let's get down to encryption.
Given: server on FreeBSD.
Task: Encrypt all partitions.
Encryption schemes
What are the encryption options?
- File system encryption (for example, ZFS)
- Third-party encryption
- The standard FreeBSD mechanisms for any gbde and geli filesystem.
Let us specify the conditions that our scheme should satisfy:
- Transparent full disk encryption
- No external storage for key storage or kernel boot
- Minimum hardware requirements
We can say that the second paragraph reduces the cryptographic strength of the system, because we voluntarily refuse encryption keys (leaving only the password) and discard the flash drive, which can be quickly pulled out of the server if necessary.
That's right, but if we use virtualization, then in general, we need a flash drive for each virtual machine, which is a little sad.
ZFS for its work requires a lot of resources, which contradicts the third paragraph of conditions.
So we choose the most versatile and native option for the system, namely, encryption of partitions using geli. Read more about geli in the handbook.
Note:When using this scheme, you need to make sure that there is a console access to the server. In the case of remote servers, there must be a KVM or equivalent. This is due to the fact that when booting the system will ask for the password for the encrypted partition!
Preparation and installation of the system
First we need an operating system image (I used a FreeBSD 9.1 x64 image). Boot and run the installation.
Starting with FreeBSD 9, the familiar sysinstall was replaced by bsdinstall. This fact makes the installation with disk encryption a little easier, mainly because the loaded environment is easier to use than in previous versions of the system, for example, the required kernel modules are loaded automatically.
- In the "Welcome" menu, select "Install"
- Choosing a keyboard layout
- Specify the host name
- Select the required system components. (I add the source codes, due to the fact that you still need to rebuild the kernel anyway)
- Next in the "Partitioning" menu, select "Shell"
Disk partitioning
The disk that we use to install the system 'da0'. We will use GPT markup.
Kernel modules are loaded automatically when we need them, so we can skip loading the geli module and go straight to partitioning the disk and creating a crypto partition. Here is what we need to do:
- Create a GPT partitioning scheme
- Create boot block
- Create and format boot partition
- Create a swap partition (if needed), and yes, it will also be encrypted
- Create and initialize the primary encrypted partition.
- Format the encrypted partition
- Mount file systems in / mnt
- Continue installation
1. Creating a boot block
To begin, delete all partitions and create a GPT partitioning scheme:
# gpart destroy -F da0 # gpart create -s gpt da0
2. Create a boot block
Create a partition with the type “freebsd-boot” and the size of 64Kb and install the bootloader.
Important:currently, the partition should not be larger than 512K. This is due to the limitations of the bootloader code.
# gpart add -t freebsd-boot -s 64k –l gpboot da0 # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0
3. Create and format the boot partition
Boot partition of 1 gigabyte in size and tag boot
# gpart add -t freebsd-ufs -s 1g -l boot da0
Create a file system on the partition. The –U flag enables soft-update on the partition. Use soft-update or not you decide. There are arguments both for and against.
# newfs -U gpt/boot
4. Creating a swap partition
Create a partition size of 4 gigabytes
# gpart add -t freebsd-swap -l swap –s 4g da0
5. Creating and initializing an encrypted volume
For the rest of the space we create the main section.
# gpart add -t freebsd-ufs -l enc da0
Note: this is not ufs volume, this is geli volume
Initialize geli volume
# geli init -b gpt/enc
Geli will ask for a password to access the section.
We connect the ciphered section
# geli attach gpt/enc
6. Format the encrypted volume
# newfs -U gpt/enc.eli
Please note, here we specify '.eli'!
7. Mount file systems in / mnt
Mount the encrypted volume
# mount /dev/gpt/enc.eli /mnt
Since we have a separate boot partition, we need the / boot directory to be written to our boot partition when installing.
# mkdir /mnt/boot2 # mount /dev/gpt/boot /mnt/boot2 # mkdir /mnt/boot2/boot # cd /mnt # ln -s boot2/boot boot
We make a copy of the service information geli for possible recovery. For now, put them in a specially created folder, and after installing the system, it is recommended to transfer these files to external media.
# mkdir gelibackups # cp /var/backups/* gelibackups
8. Continue installation
# exit
After that, the installation process will start. Time to drink a cup of coffee, tea or other beverages.
After installation, we will be asked to enter the root password, configure the network, create users.
When you see “Manual Configuration” on the screen, you will be prompted to open “Shell” to make changes to the newly installed system. We agree. This action will provide us with a chroot console for our installed system.
Configuration files
The files that we need to edit are fstab (5), loader.conf (5) and rc.conf (5).
loader.conf
# vi /boot/loader.conf
Add the following lines:
geom_eli_load="YES" vfs.root.mountfrom="ufs:/dev/da0p4.eli"
Note:if you did not create a swap partition, then the encrypted volume will probably be ad0p3.eli. You should also enclose the path to the GPT section in the second line in quotes, if this is not done, the file will not be processed correctly by the system.
fstab
# vi /etc/fstab
Add the following lines:
/dev/gpt/enc.eli / ufs rw,noatime 1 1 /dev/gpt/boot /boot2 ufs rw,noatime 1 1 /dev/gpt/swap.eli none swap sw 0 0
rc.conf
# vi /etc/rc.conf
To encrypt the swap partition, add the following line from the handbook:
geli_swap_flags="-e blowfish -l 128 -s 4096 -d"
At this setting is over.
In the console type:
# exit
and select "Reboot".
The goal is achieved. We received a fully encrypted disk information from which you can not get without knowing the password.
Now, when the system boots into the console, you will be prompted to enter a password for encrypted partitions. In our case, this is the root partition.
The following resources were used to write this article:
FreeBSD HandbookInstalling FreeBSD 9.0 with encrypted root fs (all ufs)Disk Setup On FreeBSD