Freebsd encrypted file system

I guess ecryptfs on linux works by storing the file system's encryption key on disk, encrypted with the user's password, and having the login program launch a procedure using the password to decrypt the stored key and mount the file system.

The ZFS filesystem supports full file system encryption. Although I'm not sure, if you can unlock it from SSH, because without the password, the operating system doesn't even boots up. Click to expand Only since v. The dataset via geli which sits under the FS.

You must log in or register to reply here. If Return is pressed at the password prompt, the prompt will turn echo on and display what is typed. This can be useful when attempting to type in a password by hand from a printout.

At this point, generate the one-time password to answer this login prompt. This must be done on a trusted system where it is safe to run opiekey 1. This command needs the iteration count and the seed as command line options. Use cut-and-paste from the login prompt on the machine being logged in to. Sometimes there is no access to a trusted machine or secure connection.

In this case, it is possible to use opiekey 1 to generate a number of one-time passwords beforehand. For example:. The -n 5 requests five keys in sequence, and 30 specifies what the last iteration number should be. Note that these are printed out in reverse order of use. The really paranoid might want to write the results down by hand; otherwise, print the list. Each line shows both the iteration count and the one-time password. Scratch off the passwords as they are used. Refer to opieaccess 5 for more information on this file and which security considerations to be aware of when using it.

If no rules in opieaccess are matched, the default is to deny non-OPIE logins. It can be configured to provide logging support, return messages, and connection restrictions for the server daemons under the control of inetd. Refer to tcpd 8 for more information about TCP Wrapper and its features. TCP Wrapper should not be considered a replacement for a properly configured firewall. Instead, TCP Wrapper should be used in conjunction with a firewall and other security enhancements in order to provide another layer of protection in the implementation of a security policy.

Unlike other implementations of TCP Wrapper, the use of hosts. The default configuration in FreeBSD is to allow all connections to the daemons started with inetd. Basic configuration usually takes the form of daemon : address : action , where daemon is the daemon which inetd started, address is a valid hostname, IP address, or an IPv6 address enclosed in brackets [ ] , and action is either allow or deny. TCP Wrapper uses a first rule match semantic, meaning that the configuration file is scanned from the beginning for a matching rule.

When a match is found, the rule is applied and the search process stops. TCP Wrapper provides advanced options to allow more control over the way connections are handled. In some cases, it may be appropriate to return a comment to certain hosts or daemon connections. In other cases, a log entry should be recorded or an email sent to the administrator.

Other situations may require the use of a service for local connections only. This is all possible through the use of configuration options known as wildcards, expansion characters, and external command execution. Suppose that a situation occurs where a connection should be denied yet a reason should be sent to the host who attempted to establish that connection. That action is possible with twist. When a connection attempt is made, twist executes a shell command or script.

An example exists in hosts. In this example, the message "You are not allowed to use daemon name from hostname. This is useful for sending a reply back to the connection initiator right after the established connection is dropped. Any message returned must be wrapped in quote " characters. It may be possible to launch a denial of service attack on the server if an attacker floods these daemons with connection requests.

Another possibility is to use spawn. Like twist , spawn implicitly denies the connection and may be used to run external shell commands or scripts. Unlike twist , spawn will not send a reply back to the host who established the connection. For example, consider the following configuration:. In this example, all connection requests to Sendmail which have an IP address that varies from its hostname will be denied:.

When adding new configuration lines, make sure that any unneeded entries for that daemon are commented out in hosts. Kerberos is a network authentication protocol which was originally created by the Massachusetts Institute of Technology MIT as a way to securely provide authentication across a potentially hostile network.

The Kerberos protocol uses strong cryptography so that both a client and server can prove their identity without sending any unencrypted secrets over the network.

Kerberos can be described as an identity-verifying proxy system and as a trusted third-party authentication system. After a user authenticates with Kerberos, their communications can be encrypted to assure privacy and data integrity. The only function of Kerberos is to provide the secure authentication of users and servers on the network.

It does not provide authorization or auditing functions. It is recommended that Kerberos be used with other security methods which provide authorization and audit services. The current version of the protocol is version 5, described in RFC Several free implementations of this protocol are available, covering a wide range of operating systems. MIT continues to develop their Kerberos package.

It is commonly used in the US as a cryptography product, and has historically been subject to US export regulations. The Heimdal Kerberos implementation was explicitly developed outside of the US to avoid export regulations.

In Kerberos users and services are identified as "principals" which are contained within an administrative grouping, called a "realm". Use real domain names when setting up Kerberos, even if it will run internally.

This avoids DNS problems and assures inter-operation with other Kerberos realms. The Key Distribution Center KDC is the centralized authentication service that Kerberos provides, the "trusted third party" of the system.

It is the computer that issues Kerberos tickets, which are used for clients to authenticate to servers. As the KDC is considered trusted by all other computers in the Kerberos realm, it has heightened security concerns. Direct access to the KDC should be limited. While running a KDC requires few computing resources, a dedicated machine acting only as a KDC is recommended for security reasons.

In this example, the KDC will use the fully-qualified hostname kerberos. For large organizations that have their own DNS servers, the above example could be trimmed to:. Next, create the Kerberos database which contains the keys of all principals users and hosts encrypted with a master password. To create the master key, run kstash and enter a password:. Once the master key has been created, the database should be initialized.

The Kerberos administrative tool kadmin 8 can be used on the KDC in a mode that operates directly on the database, without using the kadmind 8 network service, as kadmin -l. This resolves the chicken-and-egg problem of trying to connect to the database before it is created. Lastly, while still in kadmin , create the first principal using add. Stick to the default options for the principal for now, as these can be changed later with modify. While there will not be any kerberized daemons running at this point, it is possible to confirm that the KDC is functioning by obtaining a ticket for the principal that was just created:.

The version from the KDC can be used as-is, or it can be regenerated on the new system. This is the main part of "Kerberizing" a service - it corresponds to generating a secret shared between the service and the KDC. The secret is a cryptographic key, stored in a "keytab". It must be transmitted to the server in a secure fashion, as the security of the server can be broken if the key is made public. It is very important that the keytab is transmitted to the server in a secure fashion: if the key is known by some other party, that party can impersonate any user to the server!

Using kadmin on the server directly is convenient, because the entry for the host principal in the KDC database is also created using kadmin. Of course, kadmin is a kerberized service; a Kerberos ticket is needed to authenticate to the network service, but to ensure that the user running kadmin is actually present and their session has not been hijacked , kadmin will prompt for the password to get a fresh ticket.

See the section titled "Remote administration" in info heimdal for details on designing access control lists. Instead of enabling remote kadmin access, the administrator could securely connect to the KDC via the local console or ssh 1 , and perform administration locally using kadmin -l.

The keytab can then be securely copied to the server using scp 1 or a removable media. At this point, the server can read encrypted messages from the KDC using its shared key, stored in krb5.

It is now ready for the Kerberos-using services to be enabled. After making this change, sshd 8 must be restarted for the new configuration to take effect: service sshd restart. Copy the file in place securely or re-enter it as needed. Test the client by using kinit , klist , and kdestroy from the client to obtain, show, and then delete a ticket for an existing principal.

Kerberos applications should also be able to connect to Kerberos enabled servers. If that does not work but obtaining a ticket does, the problem is likely with the server and not with the client or the KDC. When testing a Kerberized application, try using a packet sniffer such as tcpdump to confirm that no sensitive information is sent in the clear. Various Kerberos client applications are available. Users within a realm typically have their Kerberos principal mapped to a local user account.

Occasionally, one needs to grant access to a local user account to someone who does not have a matching Kerberos principal. ORG may need access to the local user account webdevelopers. Other principals may also need access to that local account. For example, if the following. Refer to ksu 1 for more information about. The major difference between the MIT and Heimdal implementations is that kadmin has a different, but equivalent, set of commands and uses a different protocol.

Client applications may also use slightly different command line options to accomplish the same tasks. If all the computers in the realm do not have synchronized time settings, authentication may fail. The error message for unresolvable hosts is not intuitive: Kerberos5 refuses authentication because Read req failed: Key table entry not found. Some operating systems that act as clients to the KDC do not set the permissions for ksu to be setuid root.

This means that ksu does not work. This is a permissions problem, not a KDC error. The principal can then use kinit -l to request a ticket with a longer lifetime.

When running a packet sniffer on the KDC to aid in troubleshooting while running kinit from a workstation, the Ticket Granting Ticket TGT is sent immediately, even before the password is typed. This is because the Kerberos server freely transmits a TGT to any unauthorized request. When a user types their password, it is not sent to the KDC, it is instead used to decrypt the TGT that kinit already obtained.

If the decryption process results in a valid ticket with a valid time stamp, the user has valid Kerberos credentials. This second layer of encryption allows the Kerberos server to verify the authenticity of each TGT. Host principals can have a longer ticket lifetime. If the user principal has a lifetime of a week but the host being connected to has a lifetime of nine hours, the user cache will have an expired host principal and the ticket cache will not work as expected.

When setting up krb5. The format used in krb5. Since Kerberos is an all or nothing approach, every service enabled on the network must either be modified to work with Kerberos or be otherwise secured against network attacks.

This is to prevent user credentials from being stolen and re-used. An example is when Kerberos is enabled on all remote shells but the non-Kerberized POP3 mail server sends passwords in plain text. The KDC is a single point of failure. By design, the KDC must be as secure as its master password database. The KDC should have absolutely no other services running on it and should be physically secure. The danger is high because Kerberos stores all passwords encrypted with the same master key which is stored as a file on the KDC.

A compromised master key is not quite as bad as one might fear. The master key is only used to encrypt the Kerberos database and as a seed for the random number generator. As long as access to the KDC is secure, an attacker cannot do much with the master key. If the KDC is unavailable, network services are unusable as authentication cannot be performed.

This can be alleviated with a single master KDC and one or more slaves, and with careful implementation of secondary or fall-back authentication using PAM.

Kerberos allows users, hosts and services to authenticate between themselves. It does not have a mechanism to authenticate the KDC to the users, hosts, or services. This means that a trojaned kinit could record all user names and passwords.

It provides an encryption transport layer on top of the normal communications layer, allowing it to be intertwined with many network applications and services. OpenSSL is often used to encrypt authentication of mail clients and to secure web based transactions such as credit card payments. If selected, the port will add support using OpenSSL from the base system. Another common use of OpenSSL is to provide certificates for use with software applications.

Certificates can be used to verify the credentials of a company or individual. There is a cost associated with obtaining a signed certificate and using a signed certificate is not mandatory as certificates can be self-signed.

However, using an external authority will prevent warnings and can put users at ease. This section demonstrates how to create and use certificates on a FreeBSD system. To generate a certificate that will be signed by an external CA, issue the following command and input the information requested at the prompts. This input information will be written to the certificate. At the Common Name prompt, input the fully qualified name for the system that will use the certificate.

If this name does not match the server, the application verifying the certificate will issue a warning to the user, rendering the verification provided by the certificate as useless. Other options, such as the expire time and alternate encryption algorithms, are available when creating a certificate. A complete list of options is described in openssl 1. This command will create two files in the current directory. The certificate request, req.

The second file, cert. If this falls in the hands of others, it can be used to impersonate the user or the server. Alternately, if a signature from a CA is not required, a self-signed certificate can be created.

First, generate the RSA key:. Use this key to create a self-signed certificate. Follow the usual prompts for creating a certificate:. This will create two new files in the current directory: a private key file cert.

Permissions of are appropriate for these files and can be set using chmod. One use for a certificate is to encrypt connections to the Sendmail mail server in order to prevent the use of clear text authentication. Some mail clients will display an error if the user has not installed a local copy of the certificate.

Refer to the documentation included with the software for more information on certificate installation. In FreeBSD After saving the edits, restart Sendmail:. It allows two or more hosts to communicate in a secure manner by authenticating and encrypting each IP packet of a communication session.

Encapsulated Security Payload ESP : this protocol protects the IP packet data from third party interference by encrypting the contents using symmetric cryptography algorithms such as Blowfish and 3DES. Authentication Header AH : this protocol protects the IP packet header from third party interference and spoofing by computing a cryptographic checksum and hashing the IP packet header fields with a secure hashing function.

This is then followed by an additional header that contains the hash, to allow the information in the packet to be authenticated. IP Payload Compression Protocol IPComp : this protocol tries to increase communication performance by compressing the IP payload in order to reduce the amount of data sent. IPsec supports two modes of operation. The first mode, Transport Mode , protects communications between two hosts. This rest of this chapter demonstrates the process of setting up an IPsecVPN between a home network and a corporate network.

In the example scenario:. The gateway on each network has at least one external IP address. The internal addresses of the two networks can be either public or private IP addresses. However, the address space must not collide.

For example, both networks cannot use Book menu. Table of Contents Synopsis Synopsis File systems are an integral part of any operating system. The difference between native and supported file systems. Which file systems are supported by FreeBSD. If the FreeBSD version is less than This command can be used to extract all of the audio tracks, with each track written to a separate WAV file in the current working directory:. A device name does not need to be specified if there is only one CD device on the system.

Refer to the cdda2wav manual page for instructions on how to specify a device and to learn more about the other options available for this command. Make sure that 2,0 is set appropriately, as described in Burning a CD. This format is write once. A single layer recordable DVD can hold up to 4,,, bytes which is actually 4.

A distinction must be made between the physical media and the application. Before choosing the type of media, ensure that both the burner and the DVD-Video player are compatible with the media under consideration. To perform DVD recording, use growisofs 1. This support is not needed if the burner uses the USB interface. Since growisofs 1 is a front-end to mkisofs , it will invoke mkisofs 8 to create the file system layout and perform the write on the DVD.

This means that an image of the data does not need to be created before the burning process. Refer to mkisofs 8 for more details. For the initial session recording, -Z is used for both single and multiple sessions. Using -dvd-compat indicates that the disk will be closed and that the recording will be unappendable.

The write speed should be detected and automatically set according to the media and the drive being used.

Refer to growisofs 1 for example usage. In order to support working files larger than 4. This is required only when creating an ISO image file or when writing files directly to a disk.

Otherwise it will look as if it contains corrupted files. When an ISO image already contains large files, no additional options are required for growisofs 1 to burn that image on a disk.

If an image of the DVD-Video file system already exists, it can be burned in the same way as any other image. This option implies the -dvd-compat growisofs 1 option. It is recommended to let growisofs 1 take care of this automatically whenever appropriate.

Instead, write over the previous recording like this:. This operation consists of merging a new session to the existing one as it is not considered to be multi-session writing. The same mkisofs 8 options used to burn the initial session should be used during next writes. However, a non-virgin DVD-RW in sequential format needs to be blanked before writing a new initial session.

One should instead use restricted overwrite mode with any DVD-RW as this format is more flexible than the default of incremental sequential. To append some data to a previous recording, use -M with growisofs 1.

However, if data is appended on a DVD-RW in incremental sequential mode, a new session will be created on the disc and the result will be a multi-session disc. Instead, overwrite the disc with -Z. It is also possible to grow an existing ISO file system written on the disc with -M. The result will be a one-session DVD.

The result will be a single-session disc. Use this method to add data after an initial write on these types of media. Since some space on the media is used between each session to mark the end and start of sessions, one should add sessions with a large amount of data to optimize media space. In this example, the whole disk space will be formatted with a standard UFS2 file system:.

The DVD device, acd0 , must be changed according to the configuration. A floppy disk needs to be low-level formatted before it can be used.

This is usually done by the vendor, but formatting is a good way to check media integrity. To low-level format the floppy disk on FreeBSD, use fdformat 1. When using this utility, make note of any error messages, as these can help determine if the disk is good or bad.

After low-level formatting the disk, create a disk label as it is needed by the system to determine the size of the disk and its geometry. To write the disk label, use bsdlabel 8 :. The floppy is now ready to be high-level formatted with a file system. The disk is now ready for use. These file systems are implemented as user space programs which interact with the fusefs 5 kernel module via a well defined interface. Before using a FUSE file system we need to load the fusefs 5 kernel module:.

Use sysrc 8 to load the module at startup:. Suppose a USB disk is plugged in. The disk partition information can be viewed with gpart 8 :. Implementing a backup plan is essential in order to have the ability to recover from disk failure, accidental file deletion, random file corruption, or complete machine destruction, including destruction of on-site backups. The backup type and schedule will vary, depending upon the importance of the data, the granularity needed for file restores, and the amount of acceptable downtime.

Some possible backup techniques include:. Archives of the whole system, backed up onto permanent, off-site media. This provides protection against all of the problems listed above, but is slow and inconvenient to restore from, especially for non-privileged users.

File system snapshots, which are useful for restoring deleted files or previous versions of files. Typically, a mix of backup techniques is used. For example, one could create a schedule to automate a weekly, full system backup that is stored off-site and to supplement this backup with hourly ZFS snapshots. In addition, one could make a manual backup of individual directories or files before making file edits or deletions. This section describes some of the utilities which can be used to create and manage backups on a FreeBSD system.

These utilities work at the disk block level, below the abstractions of the files, links, and directories that are created by file systems. Unlike other backup software, dump backs up an entire file system and is unable to backup only part of a file system or a directory tree that spans multiple file systems.

Instead of writing files and directories, dump writes the raw data blocks that comprise files and directories. The default parameters assume a backup to a 9-track tape, rather than to another type of media or to the high-density tapes available today.

These defaults must be overridden on the command line. It is possible to backup a file system across the network to a another system or to a tape drive attached to another computer. While the rdump 8 and rrestore 8 utilities can be used for this purpose, they are not considered to be secure. Instead, one can use dump and restore in a more secure fashion over an SSH connection. Several built-in utilities are available for backing up and restoring specified files and directories as needed.

A good choice for making a backup of all of the files in a directory is tar 1. Switches can be used to instead specify the name of a backup file. When creating a backup file, make sure that the backup is not saved to the same directory that is being backed up. To restore the entire backup, cd into the directory to restore into and specify the name of the backup.

Note that this will overwrite any newer versions of files in the restore directory. When in doubt, restore to a temporary directory or specify the name of the file within the backup to restore. There are dozens of available switches which are described in tar 1. This utility also supports the use of exclude patterns to specify which files should not be included when backing up the specified directory or restoring files from a backup.

To create a backup using a specified list of files and directories, cpio 1 is a good choice. Unlike tar , cpio does not know how to walk the directory tree and it must be provided the list of files to backup. For example, a list of files can be created using ls or find.

A backup utility which tries to bridge the features provided by tar and cpio is pax 1. Over the years, the various versions of tar and cpio became slightly incompatible.

While tape technology has continued to evolve, modern backup systems tend to combine off-site backups with local removable media. In FreeBSD, mt is used to control operations of the tape drive, such as seeking through files on a tape or writing tape control marks to the tape. For example, the first three files on a tape can be preserved by skipping past them before writing a new file:.

This utility supports many operations. Refer to mt 1 for details. To write a single file to tape using tar , specify the name of the tape device and the file to backup:.

To backup a UFS file system, use dump. The FreeBSD Ports Collection provides many third-party utilities which can be used to schedule the creation of backups, simplify tape backup, and make backups easier and more convenient. In addition to regular backups, it is recommended to perform the following steps as part of an emergency preparedness plan. Store this printout and a copy of the installation media in a secure location.

Should an emergency restore be needed, boot into the installation media and select Live CD to access a rescue shell. This rescue mode can be used to view the current state of the system, and if needed, to reformat disks and restore data from backups. Next, test the rescue shell and the backups. Make notes of the procedure.

Store these notes with the media, the printouts, and the backups. These notes may prevent the inadvertent destruction of the backups while under the stress of performing an emergency recovery. For an added measure of security, store the latest backup at a remote location which is physically separated from the computers and disk drives by a significant distance.

In addition to physical disks, FreeBSD also supports the creation and use of memory disks. In FreeBSD, the md 4 driver is used to provide support for memory disks. When using a custom kernel configuration file, ensure it includes this line:. To mount an existing file system image, use mdconfig to specify the name of the ISO file and a free unit number. Then, refer to that unit number to mount it on an existing mount point. Once mounted, the files in the ISO will appear in the mount point.

This example attaches diskimage. Notice that -t cd was used to mount an ISO format. If a unit number is not specified with -u , mdconfig will automatically allocate an unused memory device and output the name of the allocated unit, such as md4. Refer to mdconfig 8 for more details about this command and its options. When a memory disk is no longer in use, its resources should be released back to the system.

First, unmount the file system, then use mdconfig to detach the disk from the system and release its resources. To continue this example:. To determine if any memory disks are still attached to the system, type mdconfig -l. FreeBSD also supports memory disks where the storage to use is allocated from either a hard disk or an area of memory.

The first method is commonly referred to as a file-backed file system and the second method as a memory-backed file system. Both types can be created using mdconfig. To create a new memory-backed file system, specify a type of swap and the size of the memory disk to create. Then, format the memory disk with a file system and mount as usual.

This example creates a 5M memory disk on unit 1. That memory disk is then formatted with the UFS file system before it is mounted:. To create a new file-backed memory disk, first allocate an area of disk to use. This example creates an empty 5MB file named newimage :. Next, attach that file to a memory disk, label the memory disk and format it with the UFS file system, mount the memory disk, and verify the size of the file-backed disk:.

It takes several commands to create a file- or memory-backed file system using mdconfig. FreeBSD also comes with mdmfs which automatically configures a memory disk, formats it with the UFS file system, and mounts it.

For example, after creating newimage with dd , this one command is equivalent to running the bsdlabel , newfs , and mount commands shown above:. If the unit number is not specified, mdmfs will automatically select an unused memory device.

For more details about mdmfs , refer to mdmfs 8. UFS snapshots allow a user to create images of specified file systems, and treat them as a file. Snapshot files must be created in the file system that the action is performed on, and a user may create no more than 20 snapshots per file system. Active snapshots are recorded in the superblock so they are persistent across unmount and remount operations along with system reboots.