diff --git a/documentation/content/en/books/handbook/audit/_index.adoc b/documentation/content/en/books/handbook/audit/_index.adoc index 0c25670f22..e76b9b6b36 100644 --- a/documentation/content/en/books/handbook/audit/_index.adoc +++ b/documentation/content/en/books/handbook/audit/_index.adoc @@ -1,459 +1,459 @@ --- title: Chapter 19. Security Event Auditing part: Part III. System Administration prev: books/handbook/mac next: books/handbook/disks description: FreeBSD security event auditing supports reliable, fine-grained, and configurable logging of a variety of security-relevant system events, including logins, configuration changes, and file and network access tags: ["audit", "terms", "configuration", "guide", "audit trails"] showBookMenu: true weight: 23 params: path: "/books/handbook/audit/" --- [[audit]] = Security Event Auditing :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 19 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/audit/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[audit-synopsis]] == Synopsis The FreeBSD operating system includes support for security event auditing. Event auditing supports reliable, fine-grained, and configurable logging of a variety of security-relevant system events, including logins, configuration changes, and file and network access. These log records can be invaluable for live system monitoring, intrusion detection, and postmortem analysis. FreeBSD implements Sun(TM)'s published Basic Security Module (BSM) Application Programming Interface (API) and file format, and is interoperable with the Solaris(TM) and Mac OS(R) X audit implementations. This chapter focuses on the installation and configuration of event auditing. It explains audit policies and provides an example audit configuration. -After reading this chapter, you will know: +Read this chapter to learn: * What event auditing is and how it works. * How to configure event auditing on FreeBSD for users and processes. * How to review the audit trail using the audit reduction and review tools. -Before reading this chapter, you should: +Before reading this chapter: * Understand UNIX(R) and FreeBSD basics (crossref:basics[basics,FreeBSD Basics]). * Be familiar with the basics of kernel configuration/compilation (crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]). * Have some familiarity with security and how it pertains to FreeBSD (crossref:security[security,Security]). [WARNING] ==== The audit facility has some known limitations. Not all security-relevant system events are auditable and some login mechanisms, such as Xorg-based display managers and third-party daemons, do not properly configure auditing for user login sessions. The security event auditing facility is able to generate very detailed logs of system activity. On a busy system, trail file data can be very large when configured for high detail, exceeding gigabytes a week in some configurations. Administrators should take into account the disk space requirements associated with high volume audit configurations. For example, it may be desirable to dedicate a file system to [.filename]#/var/audit# so that other file systems are not affected if the audit file system becomes full. ==== [[audit-inline-glossary]] == Key Terms The following terms are related to security event auditing: * _event_: an auditable event is any event that can be logged using the audit subsystem. Examples of security-relevant events include the creation of a file, the building of a network connection, or a user logging in. Events are either "attributable", meaning that they can be traced to an authenticated user, or "non-attributable". Examples of non-attributable events are any events that occur before authentication in the login process, such as bad password attempts. * _class_: a named set of related events which are used in selection expressions. Commonly used classes of events include "file creation" (fc), "exec" (ex), and "login_logout" (lo). * _record_: an audit log entry describing a security event. Records contain a record event type, information on the subject (user) performing the action, date and time information, information on any objects or arguments, and a success or failure condition. * _trail_: a log file consisting of a series of audit records describing security events. Trails are in roughly chronological order with respect to the time events completed. Only authorized processes are allowed to commit records to the audit trail. * _selection expression_: a string containing a list of prefixes and audit event class names used to match events. * _preselection_: the process by which the system identifies which events are of interest to the administrator. The preselection configuration uses a series of selection expressions to identify which classes of events to audit for which users, as well as global settings that apply to both authenticated and unauthenticated processes. * _reduction_: the process by which records from existing audit trails are selected for preservation, printing, or analysis. Likewise, the process by which undesired audit records are removed from the audit trail. Using reduction, administrators can implement policies for the preservation of audit data. For example, detailed audit trails might be kept for one month, but after that, trails might be reduced in order to preserve only login information for archival purposes. [[audit-config]] == Audit Configuration User space support for event auditing is installed as part of the base FreeBSD operating system. Kernel support is available in the [.filename]#GENERIC# kernel by default, and man:auditd[8] can be enabled by adding the following line to [.filename]#/etc/rc.conf#: [.programlisting] .... auditd_enable="YES" .... Then, start the audit daemon: [source,shell] .... # service auditd start .... Users who prefer to compile a custom kernel must include the following line in their custom kernel configuration file: [.programlisting] .... options AUDIT .... === Event Selection Expressions Selection expressions are used in a number of places in the audit configuration to determine which events should be audited. Expressions contain a list of event classes to match. Selection expressions are evaluated from left to right, and two expressions are combined by appending one onto the other. crossref:audit[event-selection,Default Audit Event Classes] summarizes the default audit event classes: [[event-selection]] .Default Audit Event Classes [cols="1,1,1", frame="none", options="header"] |=== | Class Name | Description | Action |all |all |Match all event classes. |aa |authentication and authorization | |ad |administrative |Administrative actions performed on the system as a whole. |ap |application |Application defined action. |cl |file close |Audit calls to the `close` system call. |ex |exec |Audit program execution. Auditing of command line arguments and environmental variables is controlled via man:audit_control[5] using the `argv` and `envv` parameters to the `policy` setting. |fa |file attribute access |Audit the access of object attributes such as man:stat[1] and man:pathconf[2]. |fc |file create |Audit events where a file is created as a result. |fd |file delete |Audit events where file deletion occurs. |fm |file attribute modify |Audit events where file attribute modification occurs, such as by man:chown[8], man:chflags[1], and man:flock[2]. |fr |file read |Audit events in which data is read or files are opened for reading. |fw |file write |Audit events in which data is written or files are written or modified. |io |ioctl |Audit use of the `ioctl` system call. |ip |ipc |Audit various forms of Inter-Process Communication, including POSIX pipes and System V IPC operations. |lo |login_logout |Audit man:login[1] and man:logout[1] events. |na |non attributable |Audit non-attributable events. |no |invalid class |Match no audit events. |nt |network |Audit events related to network actions such as man:connect[2] and man:accept[2]. |ot |other |Audit miscellaneous events. |pc |process |Audit process operations such as man:exec[3] and man:exit[3]. |=== These audit event classes may be customized by modifying the [.filename]#audit_class# and [.filename]#audit_event# configuration files. Each audit event class may be combined with a prefix indicating whether successful/failed operations are matched, and whether the entry is adding or removing matching for the class and type. crossref:audit[event-prefixes,Prefixes for Audit Event Classes] summarizes the available prefixes: [[event-prefixes]] .Prefixes for Audit Event Classes [cols="1,1", frame="none", options="header"] |=== | Prefix | Action |+ |Audit successful events in this class. |- |Audit failed events in this class. |^ |Audit neither successful nor failed events in this class. |^+ |Do not audit successful events in this class. |^- |Do not audit failed events in this class. |=== If no prefix is present, both successful and failed instances of the event will be audited. The following example selection string selects both successful and failed login/logout events, but only successful execution events: [.programlisting] .... lo,+ex .... === Configuration Files The following configuration files for security event auditing are found in [.filename]#/etc/security#: * [.filename]#audit_class#: contains the definitions of the audit classes. * [.filename]#audit_control#: controls aspects of the audit subsystem, such as default audit classes, minimum disk space to leave on the audit log volume, and maximum audit trail size. * [.filename]#audit_event#: textual names and descriptions of system audit events and a list of which classes each event is in. * [.filename]#audit_user#: user-specific audit requirements to be combined with the global defaults at login. * [.filename]#audit_warn#: a customizable shell script used by man:auditd[8] to generate warning messages in exceptional situations, such as when space for audit records is running low or when the audit trail file has been rotated. [WARNING] ==== Audit configuration files should be edited and maintained carefully, as errors in configuration may result in improper logging of events. ==== In most cases, administrators will only need to modify [.filename]#audit_control# and [.filename]#audit_user#. The first file controls system-wide audit properties and policies and the second file may be used to fine-tune auditing by user. [[audit-auditcontrol]] ==== The [.filename]#audit_control# File A number of defaults for the audit subsystem are specified in [.filename]#audit_control#: [.programlisting] .... dir:/var/audit dist:off flags:lo,aa minfree:5 naflags:lo,aa policy:cnt,argv filesz:2M expire-after:10M .... The `dir` entry is used to set one or more directories where audit logs will be stored. If more than one directory entry appears, they will be used in order as they fill. It is common to configure audit so that audit logs are stored on a dedicated file system, in order to prevent interference between the audit subsystem and other subsystems if the file system fills. If the `dist` field is set to `on` or `yes`, hard links will be created to all trail files in [.filename]#/var/audit/dist#. The `flags` field sets the system-wide default preselection mask for attributable events. In the example above, successful and failed login/logout events as well as authentication and authorization are audited for all users. The `minfree` entry defines the minimum percentage of free space for the file system where the audit trail is stored. The `naflags` entry specifies audit classes to be audited for non-attributed events, such as the login/logout process and authentication and authorization. The `policy` entry specifies a comma-separated list of policy flags controlling various aspects of audit behavior. The `cnt` indicates that the system should continue running despite an auditing failure (this flag is highly recommended). The other flag, `argv`, causes command line arguments to the man:execve[2] system call to be audited as part of command execution. The `filesz` entry specifies the maximum size for an audit trail before automatically terminating and rotating the trail file. A value of `0` disables automatic log rotation. If the requested file size is below the minimum of 512k, it will be ignored and a log message will be generated. The `expire-after` field specifies when audit log files will expire and be removed. [[audit-audituser]] ==== The [.filename]#audit_user# File The administrator can specify further audit requirements for specific users in [.filename]#audit_user#. Each line configures auditing for a user via two fields: the `alwaysaudit` field specifies a set of events that should always be audited for the user, and the `neveraudit` field specifies a set of events that should never be audited for the user. The following example entries audit login/logout events and successful command execution for `root` and file creation and successful command execution for `www`. If used with the default [.filename]#audit_control#, the `lo` entry for `root` is redundant, and login/logout events will also be audited for `www`. [.programlisting] .... root:lo,+ex:no www:fc,+ex:no .... [[audit-administration]] == Working with Audit Trails Since audit trails are stored in the BSM binary format, several built-in tools are available to modify or convert these trails to text. To convert trail files to a simple text format, use `praudit`. To reduce the audit trail file for analysis, archiving, or printing purposes, use `auditreduce`. This utility supports a variety of selection parameters, including event type, event class, user, date or time of the event, and the file path or object acted on. For example, to dump the entire contents of a specified audit log in plain text: [source,shell] .... # praudit /var/audit/AUDITFILE .... Where _AUDITFILE_ is the audit log to dump. Audit trails consist of a series of audit records made up of tokens, which `praudit` prints sequentially, one per line. Each token is of a specific type, such as `header` (an audit record header) or `path` (a file path from a name lookup). The following is an example of an `execve` event: [.programlisting] .... header,133,10,execve(2),0,Mon Sep 25 15:58:03 2006, + 384 msec exec arg,finger,doug path,/usr/bin/finger attribute,555,root,wheel,90,24918,104944 subject,robert,root,wheel,root,wheel,38439,38032,42086,128.232.9.100 return,success,0 trailer,133 .... This audit represents a successful `execve` call, in which the command `finger doug` has been run. The `exec arg` token contains the processed command line presented by the shell to the kernel. The `path` token holds the path to the executable as looked up by the kernel. The `attribute` token describes the binary and includes the file mode. The `subject` token stores the audit user ID, effective user ID and group ID, real user ID and group ID, process ID, session ID, port ID, and login address. Notice that the audit user ID and real user ID differ as the user `robert` switched to the `root` account before running this command, but it is audited using the original authenticated user. The `return` token indicates the successful execution and the `trailer` concludes the record. XML output format is also supported and can be selected by including `-x`. Since audit logs may be very large, a subset of records can be selected using `auditreduce`. This example selects all audit records produced for the user `trhodes` stored in [.filename]#AUDITFILE#: [source,shell] .... # auditreduce -u trhodes /var/audit/AUDITFILE | praudit .... Members of the `audit` group have permission to read audit trails in [.filename]#/var/audit#. By default, this group is empty, so only the `root` user can read audit trails. Users may be added to the `audit` group in order to delegate audit review rights. As the ability to track audit log contents provides significant insight into the behavior of users and processes, it is recommended that the delegation of audit review rights be performed with caution. === Live Monitoring Using Audit Pipes Audit pipes are cloning pseudo-devices which allow applications to tap the live audit record stream. This is primarily of interest to authors of intrusion detection and system monitoring applications. However, the audit pipe device is a convenient way for the administrator to allow live monitoring without running into problems with audit trail file ownership or log rotation interrupting the event stream. To track the live audit event stream: [source,shell] .... # praudit /dev/auditpipe .... By default, audit pipe device nodes are accessible only to the `root` user. To make them accessible to the members of the `audit` group, add a `devfs` rule to [.filename]#/etc/devfs.rules#: [.programlisting] .... add path 'auditpipe*' mode 0440 group audit .... See man:devfs.rules[5] for more information on configuring the devfs file system. [WARNING] ==== It is easy to produce audit event feedback cycles, in which the viewing of each audit event results in the generation of more audit events. For example, if all network I/O is audited, and `praudit` is run from an SSH session, a continuous stream of audit events will be generated at a high rate, as each event being printed will generate another event. For this reason, it is advisable to run `praudit` on an audit pipe device from sessions without fine-grained I/O auditing. ==== === Rotating and Compressing Audit Trail Files Audit trails are written to by the kernel and managed by the audit daemon, man:auditd[8]. Administrators should not attempt to use man:newsyslog.conf[5] or other tools to directly rotate audit logs. Instead, `audit` should be used to shut down auditing, reconfigure the audit system, and perform log rotation. The following command causes the audit daemon to create a new audit log and signal the kernel to switch to using the new log. The old log will be terminated and renamed, at which point it may then be manipulated by the administrator: [source,shell] .... # audit -n .... If man:auditd[8] is not currently running, this command will fail and an error message will be produced. Adding the following line to [.filename]#/etc/crontab# will schedule this rotation every twelve hours: [.programlisting] .... 0 */12 * * * root /usr/sbin/audit -n .... The change will take effect once [.filename]#/etc/crontab# is saved. Automatic rotation of the audit trail file based on file size is possible using `filesz` in [.filename]#audit_control# as described in crossref:audit[audit-auditcontrol, The audit_control File]. As audit trail files can become very large, it is often desirable to compress or otherwise archive trails once they have been closed by the audit daemon. The [.filename]#audit_warn# script can be used to perform customized operations for a variety of audit-related events, including the clean termination of audit trails when they are rotated. For example, the following may be added to [.filename]#/etc/security/audit_warn# to compress audit trails on close: [.programlisting] .... # # Compress audit trail files on close. # if [ "$1" = closefile ]; then gzip -9 $2 fi .... Other archiving activities might include copying trail files to a centralized server, deleting old trail files, or reducing the audit trail to remove unneeded records. This script will be run only when audit trail files are cleanly terminated. It will not be run on trails left unterminated following an improper shutdown. diff --git a/documentation/content/en/books/handbook/boot/_index.adoc b/documentation/content/en/books/handbook/boot/_index.adoc index 92a300d167..b8fe0c7e7c 100644 --- a/documentation/content/en/books/handbook/boot/_index.adoc +++ b/documentation/content/en/books/handbook/boot/_index.adoc @@ -1,454 +1,454 @@ --- title: Chapter 15. The FreeBSD Booting Process part: Part III. System Administration prev: books/handbook/config next: books/handbook/security description: An introduction to the FreeBSD Booting Process, demonstrates how to customize the FreeBSD boot process, including everything that happens until the FreeBSD kernel has started, probed for devices, and started init tags: ["boot", "boot process", "device hints", "x86", "amd64", "MBR", "GPT", "UEFI", "bsdlabel", "boot0", "Single-User Mode", "Multi-User Mode"] showBookMenu: true weight: 19 params: path: "/books/handbook/boot/" --- [[boot]] = The FreeBSD Booting Process :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 15 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/boot/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[boot-synopsis]] == Synopsis The process of starting a computer and loading the operating system is referred to as "the bootstrap process", or "booting". FreeBSD's boot process provides a great deal of flexibility in customizing what happens when the system starts, including the ability to select from different operating systems installed on the same computer, different versions of the same operating system, or a different installed kernel. This chapter details the configuration options that can be set. It demonstrates how to customize the FreeBSD boot process, including everything that happens until the FreeBSD kernel has started, probed for devices, and started man:init[8]. This occurs when the text color of the boot messages changes from bright white to grey. -After reading this chapter, you will recognize: +Read this chapter to learn: * The components of the FreeBSD bootstrap system and how they interact. * The options that can be passed to the components in the FreeBSD bootstrap in order to control the boot process. * The basics of setting device hints. * How to boot into single- and multi-user mode and how to properly shut down a FreeBSD system. [NOTE] ==== This chapter only describes the boot process for FreeBSD running on x86 and amd64 systems. ==== [[boot-introduction]] == FreeBSD Boot Process Turning on a computer and starting the operating system poses an interesting dilemma. By definition, the computer does not know how to do anything until the operating system is started. This includes running programs from the disk. If the computer can not run a program from the disk without the operating system, and the operating system programs are on the disk, how is the operating system started? This problem parallels one in the book The Adventures of Baron Munchausen. A character had fallen part way down a manhole, and pulled himself out by grabbing his bootstraps and lifting. In the early days of computing, the term _bootstrap_ was applied to the mechanism used to load the operating system. It has since become shortened to "booting". On x86 hardware, the Basic Input/Output System (BIOS) is responsible for loading the operating system. The BIOS looks on the hard disk for the Master Boot Record (MBR), which must be located in a specific place on the disk. The BIOS has enough knowledge to load and run the MBR, and assumes that the MBR can then carry out the rest of the tasks involved in loading the operating system, possibly with the help of the BIOS. [NOTE] ==== FreeBSD provides for booting from both the older MBR standard, and the newer GUID Partition Table (GPT). GPT partitioning is often found on computers with the Unified Extensible Firmware Interface (UEFI). However, FreeBSD can boot from GPT partitions even on machines with only a legacy BIOS with man:gptboot[8]. Work is under way to provide direct UEFI booting. ==== The code within the MBR is typically referred to as a _boot manager_, especially when it interacts with the user. The boot manager usually has more code in the first track of the disk or within the file system. Examples of boot managers include the standard FreeBSD boot manager boot0, also called Boot Easy, and GNU GRUB, which is used by many Linux(R) distributions. [NOTE] ==== // There is extref:{faq}[a frequently asked question] about GRUB. Beyond the answer there, // Users of GRUB should refer to https://www.gnu.org/software/grub/grub-documentation.html[GNU-provided documentation]. ==== If only one operating system is installed, the MBR searches for the first bootable (active) slice on the disk, and then runs the code on that slice to load the remainder of the operating system. When multiple operating systems are present, a different boot manager can be installed to display a list of operating systems so the user can select one to boot. The remainder of the FreeBSD bootstrap system is divided into three stages. The first stage knows just enough to get the computer into a specific state and run the second stage. The second stage can do a little bit more, before running the third stage. The third stage finishes the task of loading the operating system. The work is split into three stages because the MBR puts limits on the size of the programs that can be run at stages one and two. Chaining the tasks together allows FreeBSD to provide a more flexible loader. The kernel is then started and begins to probe for devices and initialize them for use. Once the kernel boot process is finished, the kernel passes control to the user process man:init[8], which makes sure the disks are in a usable state, starts the user-level resource configuration which mounts file systems, sets up network cards to communicate on the network, and starts the processes which have been configured to run at startup. This section describes these stages in more detail and demonstrates how to interact with the FreeBSD boot process. [[boot-boot0]] === The Boot Manager The boot manager code in the MBR is sometimes referred to as _stage zero_ of the boot process. By default, FreeBSD uses the boot0 boot manager. The MBR installed by the FreeBSD installer is based on [.filename]#/boot/boot0#. The size and capability of boot0 is restricted to 446 bytes due to the slice table and `0x55AA` identifier at the end of the MBR. If boot0 and multiple operating systems are installed, a message similar to this example will be displayed at boot time: [[boot-boot0-example]] .[.filename]#boot0# Screenshot [example] ==== [source,shell] .... F1 Win F2 FreeBSD Default: F2 .... ==== Other operating systems will overwrite an existing MBR if they are installed after FreeBSD. If this happens, or to replace the existing MBR with the FreeBSD MBR, use the following command: [source,shell] .... # fdisk -B -b /boot/boot0 device .... where _device_ is the boot disk, such as [.filename]#ad0# for the first IDE disk, [.filename]#ad2# for the first IDE disk on a second IDE controller, or [.filename]#da0# for the first SCSI disk. To create a custom configuration of the MBR, refer to man:boot0cfg[8]. [[boot-boot1]] === Stage One and Stage Two Conceptually, the first and second stages are part of the same program on the same area of the disk. Due to space constraints, they have been split into two, but are always installed together. They are copied from the combined [.filename]#/boot/boot# by the FreeBSD installer or `bsdlabel`. These two stages are located outside file systems, in the first track of the boot slice, starting with the first sector. This is where boot0, or any other boot manager, expects to find a program to run which will continue the boot process. The first stage, [.filename]#boot1#, is very simple, since it can only be 512 bytes in size. It knows just enough about the FreeBSD _bsdlabel_, which stores information about the slice, to find and execute [.filename]#boot2#. Stage two, [.filename]#boot2#, is slightly more sophisticated, and understands the FreeBSD file system enough to find files. It can provide a simple interface to choose the kernel or loader to run. It runs loader, which is much more sophisticated and provides a boot configuration file. If the boot process is interrupted at stage two, the following interactive screen is displayed: [[boot-boot2-example]] .[.filename]#boot2# Screenshot [example] ==== [source,shell] .... >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: .... ==== To replace the installed [.filename]#boot1# and [.filename]#boot2#, use `bsdlabel`, where _diskslice_ is the disk and slice to boot from, such as [.filename]#ad0s1# for the first slice on the first IDE disk: [source,shell] .... # bsdlabel -B diskslice .... [WARNING] ==== If just the disk name is used, such as [.filename]#ad0#, `bsdlabel` will create the disk in "dangerously dedicated mode", without slices. This is probably not the desired action, so double check the _diskslice_ before pressing kbd:[Return]. ==== [[boot-loader]] === Stage Three The loader is the final stage of the three-stage bootstrap process. It is located on the file system, usually as [.filename]#/boot/loader#. The loader is intended as an interactive method for configuration, using a built-in command set, backed up by a more powerful interpreter which has a more complex command set. During initialization, loader will probe for a console and for disks, and figure out which disk it is booting from. It will set variables accordingly, and an interpreter is started where user commands can be passed from a script or interactively. The loader will then read [.filename]#/boot/loader.rc#, which by default reads in [.filename]#/boot/defaults/loader.conf# which sets reasonable defaults for variables and reads [.filename]#/boot/loader.conf# for local changes to those variables. [.filename]#loader.rc# then acts on these variables, loading whichever modules and kernel are selected. Finally, by default, loader issues a 10 second wait for key presses, and boots the kernel if it is not interrupted. If interrupted, the user is presented with a prompt which understands the command set, where the user may adjust variables, unload all modules, load modules, and then finally boot or reboot. crossref:boot[boot-loader-commands,Loader Built-In Commands] lists the most commonly used loader commands. For a complete discussion of all available commands, refer to man:loader[8]. [[boot-loader-commands]] .Loader Built-In Commands [cols="20%,80%", frame="none", options="header"] |=== | Variable | Description |autoboot _seconds_ |Proceeds to boot the kernel if not interrupted within the time span given, in seconds. It displays a countdown, and the default time span is 10 seconds. |boot [`-options`] [`kernelname`] |Immediately proceeds to boot the kernel, with any specified options or kernel name. Providing a kernel name on the command-line is only applicable after an `unload` has been issued. Otherwise, the previously-loaded kernel will be used. If _kernelname_ is not qualified, it will be searched under _/boot/kernel_ and _/boot/modules_. |boot-conf |Goes through the same automatic configuration of modules based on specified variables, most commonly `kernel`. This only makes sense if `unload` is used first, before changing some variables. |help [`_topic_`] |Shows help messages read from [.filename]#/boot/loader.help#. If the topic given is `index`, the list of available topics is displayed. |include `_filename_` ... |Reads the specified file and interprets it line by line. An error immediately stops the `include`. |load [-t ``_type_``] `_filename_` |Loads the kernel, kernel module, or file of the type given, with the specified filename. Any arguments after _filename_ are passed to the file. If _filename_ is not qualified, it will be searched under _/boot/kernel_ and _/boot/modules_. |ls [-l] [``_path_``] |Displays a listing of files in the given path, or the root directory, if the path is not specified. If `-l` is specified, file sizes will also be shown. |lsdev [`-v`] |Lists all of the devices from which it may be possible to load modules. If `-v` is specified, more details are printed. |lsmod [`-v`] |Displays loaded modules. If `-v` is specified, more details are shown. |more `_filename_` |Displays the files specified, with a pause at each `LINES` displayed. |reboot |Immediately reboots the system. |set `_variable_`, set `_variable=value_` |Sets the specified environment variables. |unload |Removes all loaded modules. |=== Here are some practical examples of loader usage. To boot the usual kernel in single-user mode: [source,shell] .... boot -s .... To unload the usual kernel and modules and then load the previous or another, specified kernel: [source,shell] .... unload load /path/to/kernelfile .... Use the qualified [.filename]#/boot/GENERIC/kernel# to refer to the default kernel that comes with an installation, or [.filename]#/boot/kernel.old/kernel#, to refer to the previously installed kernel before a system upgrade or before configuring a custom kernel. Use the following to load the usual modules with another kernel. Note that in this case it is not necessary the qualified name: [source,shell] .... unload set kernel="mykernel" boot-conf .... To load an automated kernel configuration script: [source,shell] .... load -t userconfig_script /boot/kernel.conf .... [[boot-init]] === Last Stage Once the kernel is loaded by either loader or by boot2, which bypasses loader, it examines any boot flags and adjusts its behavior as necessary. crossref:boot[boot-kernel,Kernel Interaction During Boot] lists the commonly used boot flags. Refer to man:boot[8] for more information on the other boot flags. [[boot-kernel]] .Kernel Interaction During Boot [cols="1,1", frame="none", options="header"] |=== | Option | Description |`-a` |During kernel initialization, ask for the device to mount as the root file system. |`-C` |Boot the root file system from a CDROM. |`-s` |Boot into single-user mode. |`-v` |Be more verbose during kernel startup. |=== Once the kernel has finished booting, it passes control to the user process man:init[8], which is located at [.filename]#/sbin/init#, or the program path specified in the `init_path` variable in `loader`. This is the last stage of the boot process. The boot sequence makes sure that the file systems available on the system are consistent. If a UFS file system is not, and `fsck` cannot fix the inconsistencies, init drops the system into single-user mode so that the system administrator can resolve the problem directly. Otherwise, the system boots into multi-user mode. [[boot-singleuser]] ==== Single-User Mode A user can specify this mode by booting with `-s` or by setting the `boot_single` variable in loader. It can also be reached by running `shutdown now` from multi-user mode. Single-user mode begins with this message: [.programlisting] .... Enter full pathname of shell or RETURN for /bin/sh: .... If the user presses kbd:[Enter], the system will enter the default Bourne shell. To specify a different shell, input the full path to the shell. Single-user mode is usually used to repair a system that will not boot due to an inconsistent file system or an error in a boot configuration file. It can also be used to reset the `root` password when it is unknown. These actions are possible as the single-user mode prompt gives full, local access to the system and its configuration files. There is no networking in this mode. While single-user mode is useful for repairing a system, it poses a security risk unless the system is in a physically secure location. By default, any user who can gain physical access to a system will have full control of that system after booting into single-user mode. If the system `console` is changed to `insecure` in [.filename]#/etc/ttys#, the system will first prompt for the `root` password before initiating single-user mode. This adds a measure of security while removing the ability to reset the `root` password when it is unknown. [[boot-insecure-console]] .Configuring an Insecure Console in [.filename]#/etc/ttys# [example] ==== [.programlisting] .... # name getty type status comments # # If console is marked "insecure", then init will ask for the root password # when going to single-user mode. console none unknown off insecure .... ==== An `insecure` console means that physical security to the console is considered to be insecure, so only someone who knows the `root` password may use single-user mode. [[boot-multiuser]] ==== Multi-User Mode If init finds the file systems to be in order, or once the user has finished their commands in single-user mode and has typed `exit` to leave single-user mode, the system enters multi-user mode, in which it starts the resource configuration of the system. The resource configuration system reads in configuration defaults from [.filename]#/etc/defaults/rc.conf# and system-specific details from [.filename]#/etc/rc.conf#. It then proceeds to mount the system file systems listed in [.filename]#/etc/fstab#. It starts up networking services, miscellaneous system daemons, then the startup scripts of locally installed packages. To learn more about the resource configuration system, refer to man:rc[8] and examine the scripts located in [.filename]#/etc/rc.d#. [[device-hints]] == Device Hints During initial system startup, the boot man:loader[8] reads man:device.hints[5]. This file stores kernel boot information known as variables, sometimes referred to as "device hints". These "device hints" are used by device drivers for device configuration. Device hints may also be specified at the Stage 3 boot loader prompt, as demonstrated in crossref:boot[boot-loader, Stage Three]. Variables can be added using `set`, removed with `unset`, and viewed `show`. Variables set in [.filename]#/boot/device.hints# can also be overridden. Device hints entered at the boot loader are not permanent and will not be applied on the next reboot. Once the system is booted, man:kenv[1] can be used to dump all of the variables. The syntax for [.filename]#/boot/device.hints# is one variable per line, using the hash "#" as comment markers. Lines are constructed as follows: [source,shell] .... hint.driver.unit.keyword="value" .... The syntax for the Stage 3 boot loader is: [source,shell] .... set hint.driver.unit.keyword=value .... where `driver` is the device driver name, `unit` is the device driver unit number, and `keyword` is the hint keyword. The keyword may consist of the following options: * `at`: specifies the bus which the device is attached to. * `port`: specifies the start address of the I/O to be used. * `irq`: specifies the interrupt request number to be used. * `drq`: specifies the DMA channel number. * `maddr`: specifies the physical memory address occupied by the device. * `flags`: sets various flag bits for the device. * `disabled`: if set to `1` the device is disabled. Since device drivers may accept or require more hints not listed here, viewing a driver's manual page is recommended. For more information, refer to man:device.hints[5], man:kenv[1], man:loader.conf[5], and man:loader[8]. [[boot-shutdown]] == Shutdown Sequence Upon controlled shutdown using man:shutdown[8], man:init[8] will attempt to run the script [.filename]#/etc/rc.shutdown#, and then proceed to send all processes the `TERM` signal, and subsequently the `KILL` signal to any that do not terminate in a timely manner. To power down a FreeBSD machine on architectures and systems that support power management, use `shutdown -p now` to turn the power off immediately. To reboot a FreeBSD system, use `shutdown -r now`. One must be `root` or a member of `operator` in order to run man:shutdown[8]. One can also use man:halt[8] and man:reboot[8]. Refer to their manual pages and to man:shutdown[8] for more information. Modify group membership by referring to crossref:basics[users-synopsis,“Users and Basic Account Management”]. [NOTE] ==== Power management requires man:acpi[4] to be loaded as a module or statically compiled into a custom kernel. ==== diff --git a/documentation/content/en/books/handbook/config/_index.adoc b/documentation/content/en/books/handbook/config/_index.adoc index 7675b13762..6089cf402d 100644 --- a/documentation/content/en/books/handbook/config/_index.adoc +++ b/documentation/content/en/books/handbook/config/_index.adoc @@ -1,1593 +1,1593 @@ --- title: Chapter 14. Configuration, Services, Logging and Power Management part: Part III. System Administration prev: books/handbook/partiii next: books/handbook/boot description: This chapter explains much of the FreeBSD configuration files, how to enable or disable a service, how to configure the logging system and the power management area. tags: ["configuration", "services", "cron", "periodic", "logging", "configuration files", "sysctl", "swap", "power management"] showBookMenu: true weight: 18 params: path: "/books/handbook/config/" --- [[config-tuning]] = Configuration, Services, Logging and Power Management :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 14 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/config/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[config-synopsis]] == Synopsis One of the important aspects of FreeBSD is proper system configuration. This chapter explains much of the FreeBSD configuration process, including some of the parameters which can be set to tune a FreeBSD system. -Before reading this chapter, you should: +Before reading this chapter: * Understand UNIX(R) and FreeBSD basics (crossref:basics[basics,FreeBSD Basics]). -After reading this chapter, you will know: +Read this chapter to learn: * How to use the various configuration files in [.filename]#/etc#. * The basics of [.filename]#rc.conf# configuration and [.filename]#/usr/local/etc/rc.d# startup scripts. * How to tune FreeBSD using man:sysctl[8] variables. * How to configure the power management in FreeBSD. [[configtuning-configfiles]] == Configuration Files FreeBSD maintains a clear separation between the base system and third party applications and therefore this affects where the configuration files of these applications are located. FreeBSD base system configuration is located at the [.filename]#/etc# directory, and the [.filename]#/usr/local/etc# directory contains all the configuration files of the applications installed on the system through the ports collection and packages. The kernel state configuration is located in [.filename]#/etc/sysctl.conf#. In the section crossref:config[configtuning-sysctl, The sysctl utility], the operation of man:sysctl[8] will be explained in more detail. For more information about the FreeBSD file system structure refer to man:hier[7]. As a general rule, configuration files do not use a standard on what syntax they must follow. Although it is true that the `#` character is normally used to comment a line and that each line has a configuration variable. [NOTE] ==== Some applications like man:pkg[8] are starting to use the link:https://github.com/vstakhov/libucl[Universal Configuration Language (UCL)]. ==== === The [.filename]#/etc# directory The [.filename]#/etc# directory contains all of the FreeBSD base system configuration files that are responsible for configuring FreeBSD. [CAUTION] ==== *Extreme* caution must be taken when modifying files in the [.filename]#/etc# directory; misconfiguration could make FreeBSD unbootable or malfunction. ==== [.informaltable] [cols="1,1", frame="none"] |=== |[.filename]#/etc# |System configuration files and scripts. |[.filename]#/etc/defaults# |Default system configuration files, see man:rc[8] for more information. |[.filename]#/etc/fstab# |man:fstab[5] contains descriptive information about the various file systems. |[.filename]#/etc/mail# |Extra man:sendmail[8] configuration and other MTA configuration files. |[.filename]#/etc/mtree# |mtree configuration files, see man: mtree[8] for more information. |[.filename]#/etc/pam.d# |Configuration files for the Pluggable Authentication Modules (PAM) library. |[.filename]#/etc/periodic# |Scripts that are run daily, weekly, and monthly, via man:cron[8], see man:periodic[8] for more information. |[.filename]#/etc/rc.d# |System and daemon startup/control scripts, see man:rc[8] for more information. |[.filename]#/etc/rc.conf# |Contains descriptive information about the local host name, configuration details for any potential network interfaces and which services should be started up at system initial boot time. More information in crossref:bsdinstall[configtuning-core-configuration, Managing System-Specific Configuration] |[.filename]#/etc/security# |OpenBSM audit configuration files, see man:audit[8] for more information. |[.filename]#/etc/ppp# |ppp configuration files, see man:ppp[8] for more information. |[.filename]#/etc/ssh# |OpenSSH configuration files, see man:ssh[1] for more information. |[.filename]#/etc/ssl# |OpenSSL configuration files. |[.filename]#/etc/sysctl.conf# |Contains settings for the kernel. More information in crossref:bsdinstall[configtuning-sysctl, The sysctl utility] |=== [[configtuning-sysctl]] === The sysctl utility The man:sysctl[8] utility is used to make changes to a running FreeBSD system. The man:sysctl[8] utility retrieves kernel state and allows processes with appropriate privilege to set kernel state. The state to be retrieved or set is described using a "Management Information Base" ("MIB") style name, described as a dotted set of components. .Management Information Base [.informaltable] [cols="1,1", frame="none"] |=== |sysctl |"Magic" numbers |kern |Kernel functions and features |vm |virtual memory |vfs |Filesystem |net |Network |debug |Debugging parameters |hw |Hardware |machdep |Machine dependent |user |Userland |p1003_1b |POSIX 1003.1B |=== At its core, man:sysctl[8] serves two functions: to read and to modify system settings. To view all readable variables: [source,shell] .... % sysctl -a .... The output should be similar to the following: [.programlisting] .... kern.ostype: FreeBSD ... vm.swap_enabled: 1 vm.overcommit: 0 vm.domain.0.pidctrl.kdd: 8 vm.domain.0.pidctrl.kid: 4 vm.domain.0.pidctrl.kpd: 3 ... vfs.zfs.sync_pass_rewrite: 2 vfs.zfs.sync_pass_dont_compress: 8 vfs.zfs.sync_pass_deferred_free: 2 .... To read a particular variable, specify its name: [source,shell] .... % sysctl kern.maxproc .... The output should be similar to the following: [.programlisting] .... kern.maxproc: 1044 .... The Management Information Base (MIB) is hierarchical and hence, specifying a prefix prints all the nodes hanging from it: [source,shell] .... % sysctl net .... The output should be similar to the following: [.programlisting] .... net.local.stream.recvspace: 8192 net.local.stream.sendspace: 8192 net.local.dgram.recvspace: 16384 net.local.dgram.maxdgram: 2048 net.local.seqpacket.recvspace: 8192 net.local.seqpacket.maxseqpacket: 8192 net.local.sockcount: 60 net.local.taskcount: 25 net.local.recycled: 0 net.local.deferred: 0 net.local.inflight: 0 net.inet.ip.portrange.randomtime: 1 net.inet.ip.portrange.randomcps: 9999 [...] .... To set a particular variable, use the _variable_=_value_ syntax: [source,shell] .... # sysctl kern.maxfiles=5000 .... The output should be similar to the following: [.programlisting] .... kern.maxfiles: 2088 -> 5000 .... [NOTE] ==== To keep the configuration after a reboot it is necessary to add these variables to the [.filename]#/etc/sysctl.conf# file as explained below. ==== [[configtuning-sysctlconf]] === The [.filename]#/etc/sysctl.conf# file The configuration file for man:sysctl[8], [.filename]#/etc/sysctl.conf#, looks much like [.filename]#/etc/rc.conf#. Values are set using a `variable=value` syntax. [NOTE] ==== The specified values are set after the system goes into multi-user mode. Not all variables are settable in this mode. ==== For example, to turn off logging of fatal signal exits and prevent users from seeing processes started by other users, the following tunables can be set in [.filename]#/etc/sysctl.conf#: [.programlisting] .... # Do not log fatal signal exits (e.g., sig 11) kern.logsigexit=0 # Prevent users from seeing information about processes that # are being run under another UID. security.bsd.see_other_uids=0 .... To obtain more information about what function a particular sysctl has, the following command can be executed: [source,shell] .... % sysctl -d kern.dfldsiz .... The output should be similar to the following: [.programlisting] .... kern.dfldsiz: Initial data size limit .... [[configtuning-core-configuration]] === Managing System-Specific Configuration The principal location for system configuration information is [.filename]#/etc/rc.conf#. This file contains a wide range of configuration information and it is read at system startup to configure the system. It provides the configuration information for the [.filename]#rc*# files. The entries in [.filename]#/etc/rc.conf# override the default settings in [.filename]#/etc/defaults/rc.conf#. [TIP] ==== The file [.filename]#/etc/defaults/rc.conf# containing the default settings should not be edited. Instead, all system-specific changes should be made to [.filename]#/etc/rc.conf#. ==== A number of strategies may be applied in clustered applications to separate site-wide configuration from system-specific configuration in order to reduce administration overhead. The recommended approach is to place system-specific configuration into [.filename]#/etc/rc.conf.local#. For example, these entries in [.filename]#/etc/rc.conf# apply to all systems: [.programlisting] .... sshd_enable="YES" keyrate="fast" defaultrouter="10.1.1.254" .... Whereas these entries in [.filename]#/etc/rc.conf.local# apply to this system only: [.programlisting] .... hostname="node1.example.org" ifconfig_fxp0="inet 10.1.1.1/8" .... Distribute [.filename]#/etc/rc.conf# to every system using an application such as rsync or puppet, while [.filename]#/etc/rc.conf.local# remains unique. Upgrading the system will not overwrite [.filename]#/etc/rc.conf#, so system configuration information will not be lost. [TIP] ==== Both [.filename]#/etc/rc.conf# and [.filename]#/etc/rc.conf.local# are parsed by man:sh[1]. This allows system operators to create complex configuration scenarios. Refer to man:rc.conf[5] for further information on this topic. ==== [[configtuning-rcd]] == Managing Services in FreeBSD FreeBSD uses the man:rc[8] system of startup scripts during system initialization and for managing services. The scripts listed in [.filename]#/etc/rc.d# provide basic services which can be controlled with the `start`, `stop`, and `restart` options to man:service[8]. A basic script may look similar to the following: [.programlisting] .... #!/bin/sh # # PROVIDE: utility # REQUIRE: DAEMON # KEYWORD: shutdown . /etc/rc.subr name=utility rcvar=utility_enable command="/usr/local/sbin/utility" load_rc_config $name # # DO NOT CHANGE THESE DEFAULT VALUES HERE # SET THEM IN THE /etc/rc.conf FILE # utility_enable=${utility_enable-"NO"} pidfile=${utility_pidfile-"/var/run/utility.pid"} run_rc_command "$1" .... Refer to extref:{rc-scripting}[this article] for instructions on how to create custom man:rc[8] scripts. [[configtuning-starting-services]] === Starting Services Many users install third party software on FreeBSD from the Ports Collection and require the installed services to be started upon system initialization. Services, such as package:security/openssh-portable[] or package:www/nginx[] are just two of the many software packages which may be started during system initialization. This section explains the procedures available for starting services. Since the man:rc[8] system is primarily intended to start and stop services at system startup and shutdown time, the `start`, `stop` and `restart` options will only perform their action if the appropriate [.filename]#/etc/rc.conf# variable is set. So the first step to start a service, like for example package:www/nginx[] is to add it to [.filename]#/etc/rc.conf# by executing the following command: [source,shell] .... # sysrc nginx_enable="YES" .... Then nginx can be started executing the following command: [source,shell] .... # service nginx start .... [TIP] ==== To `start`, `stop` or `restart` a service regardless of the settings in [.filename]#/etc/rc.conf#, these commands should be prefixed with "one". For instance, to start package:www/nginx[] regardless of the current [.filename]#/etc/rc.conf# setting, execute the following command: [source,shell] .... # service nginx onestart .... ==== It is also possible to put a service automatically into a jail, see the corresponding crossref:jails[service-jails,Service Jails] explanation. [[configtuning-status-services]] === Status of a Service To determine if a service is running, use the `status` subcommand. For example, to verify that package:www/nginx[] is running: [source,shell] .... # service nginx status .... The output should be similar to the following: [.programlisting] .... nginx is running as pid 27871. .... [[configtuning-reload-services]] === Reload a Service In some cases, it is also possible to `reload` a service. This attempts to send a signal to an individual service, forcing the service to reload its configuration files. In most cases, this means sending the service a `SIGHUP` signal. *Not all services support this feature.* The man:rc[8] system is used for network services and it also contributes to most of the system initialization. For instance, when the [.filename]#/etc/rc.d/bgfsck# script is executed, it prints out the following message: [source,shell] .... Starting background file system checks in 60 seconds. .... This script is used for background file system checks, which occur only during system initialization. Many system services depend on other services to function properly. For example, man:yp[8] and other RPC-based services may fail to start until after the man:rpcbind[8] service has started. Additional information can be found in man:rc[8] and man:rc.subr[8]. === Using Services to Start Services Other services can be started using man:inetd[8]. Working with man:inetd[8] and its configuration is described in depth in crossref:network-servers[network-inetd,“The inetd Super-Server”]. In some cases, it may make more sense to use man:cron[8] to start system services. This approach has a number of advantages as man:cron[8] runs these processes as the owner of the man:crontab[5]. This allows regular users to start and maintain their own applications. The `@reboot` feature of man:cron[8], may be used in place of the time specification. This causes the job to run when man:cron[8] is started, normally during system initialization. [[cron-periodic]] == Cron and Periodic Scheduling tasks to run at a certain day or time is a very common task on FreeBSD. The tool in charge of performing this task is man:cron[8]. In addition to tasks that can be scheduled by the user via man:cron[8], FreeBSD performs routine background tasks managed by man:periodic[8]. [[configtuning-cron]] === Cron The man:cron[8] utility runs in the background and regularly checks [.filename]#/etc/crontab# for tasks to execute and searches [.filename]#/var/cron/tabs# for custom crontab files. These files are used to schedule tasks which cron runs at the specified times. Each entry in a crontab defines a task to run and is known as a _cron job_. Two different types of configuration files are used: the system crontab, which should not be modified, and user crontabs, which can be created and edited as needed. The format used by these files is documented in man:crontab[5]. The format of the system crontab, [.filename]#/etc/crontab# includes a `who` column which does not exist in user crontabs. In the system crontab, cron runs the command as the user specified in this column. In a user crontab, all commands run as the user who created the crontab. User crontabs allow individual users to schedule their own tasks. The `root` user can also have a user [.filename]#crontab# which can be used to schedule tasks that do not exist in the system [.filename]#crontab#. Here is a sample entry from the system crontab, [.filename]#/etc/crontab#: [.programlisting] .... # /etc/crontab - root's crontab for FreeBSD # # <.> # SHELL=/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin <.> # #minute hour mday month wday who command <.> # # Save some entropy so that /dev/random can re-seed on boot. */11 * * * * operator /usr/libexec/save-entropy <.> # # Rotate log files every hour, if necessary. 0 * * * * root newsyslog # # Perform daily/weekly/monthly maintenance. 1 3 * * * root periodic daily 15 4 * * 6 root periodic weekly 30 5 1 * * root periodic monthly # # Adjust the time zone if the CMOS clock keeps local time, as opposed to # UTC time. See adjkerntz(8) for details. 1,31 0-5 * * * root adjkerntz -a .... <.> Lines that begin with the `+#+` character are comments. A comment can be placed in the file as a reminder of what and why a desired action is performed. Comments cannot be on the same line as a command or else they will be interpreted as part of the command; they must be on a new line. Blank lines are ignored. <.> The equals (`=`) character is used to define any environment settings. In this example, it is used to define the `SHELL` and `PATH`. If the `SHELL` is omitted, cron will use the default Bourne shell. If the `PATH` is omitted, the full path must be given to the command or script to run. <.> This line defines the seven fields used in a system crontab: `minute`, `hour`, `mday`, `month`, `wday`, `who`, and `command`. The `minute` field is the time in minutes when the specified command will be run, the `hour` is the hour when the specified command will be run, the `mday` is the day of the month, `month` is the month, and `wday` is the day of the week. These fields must be numeric values, representing the twenty-four hour clock, or a `*`, representing all values for that field. The `who` field only exists in the system crontab and specifies which user the command should be run as. The last field is the command to be executed. <.> This entry defines the values for this cron job. The `\*/11`, followed by several more `*` characters, specifies that `/usr/libexec/save-entropy` is invoked by `operator` every eleven minutes of every hour, of every day and day of the week, of every month. Commands can include any number of switches. However, commands which extend to multiple lines need to be broken with the backslash "\" continuation character. [[configtuning-installcrontab]] === Creating a User Crontab To create a user crontab, invoke `crontab` in editor mode: [source,shell] .... % crontab -e .... This will open the user's crontab using the default text editor. The first time a user runs this command, it will open an empty file. Once a user creates a crontab, this command will open that file for editing. It is useful to add these lines to the top of the crontab file in order to set the environment variables and to remember the meanings of the fields in the crontab: [.programlisting] .... SHELL=/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin # Order of crontab fields # minute hour mday month wday command .... Then add a line for each command or script to run, specifying the time to run the command. This example runs the specified custom Bourne shell script every day at two in the afternoon. Since the path to the script is not specified in `PATH`, the full path to the script is given: [.programlisting] .... 0 14 * * * /home/user/bin/mycustomscript.sh .... [TIP] ==== Before using a custom script, make sure it is executable and test it with the limited set of environment variables set by cron. To replicate the environment that would be used to run the above cron entry, use: [.programlisting] .... env -i SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin HOME=/home/user LOGNAME=user /home/user/bin/mycustomscript.sh .... The environment set by cron is discussed in man:crontab[5]. Checking that scripts operate correctly in a cron environment is especially important if they include any commands that delete files using wildcards. ==== When finished editing the crontab, save the file. It will automatically be installed, and cron will read the crontab and run its cron jobs at their specified times. To list the cron jobs in a crontab, use this command: [source,shell] .... % crontab -l .... The output should be similar to the following: [.programlisting] .... 0 14 * * * /home/user/bin/mycustomscript.sh .... To remove all of the cron jobs in a user crontab: [source,shell] .... % crontab -r .... The output should be similar to the following: [.programlisting] .... remove crontab for user? y .... [[configtuning-periodic]] === Periodic FreeBSD provides a set of system management scripts to check status of various subsystems, perform security-related checks, rotate log files, etc. These scripts are run on a periodic basis: daily. weekly, or monthly. The management of these tasks is performed by man:periodic[8] and its configuration resides in man:periodic.conf[5]. The periodic tasks are initiated by entries in the system crontab, shown above. Scripts executed by man:periodic[8] are located in [.filename]#/etc/periodic/# for base utilities and in [.filename]#/usr/local/etc/periodic/# for third-party software. They are organized in 4 subdirectories, daily, weekly, monthly and security. [[enable-disable-periodic]] === Enable or Disable Periodic Tasks FreeBSD has some scripts enabled by default to run periodically. To enable or disable a task, the first step is to edit [.filename]#/etc/periodic.conf# executing the following command: [source,shell] .... # ee /etc/periodic.conf .... And then to enable, for example, `daily_status_zfs_enable` put the following content in the file: [.programlisting] .... daily_status_zfs_enable="YES" .... To disable a task that is active by default, all that needs to be done is to change `YES` to `NO`. [[configuring-output-periodic-tasks]] === Configuring the Output of Periodic Tasks In [.filename]#/etc/periodic.conf# the variables `daily_output`, `weekly_output` and `monthly_output` specifies where to send the results of the script execution. By default the output of the periodic scripts are emailed to root, and therefore it is best to read root's mail or alias root to a mailbox that is monitored. To send the results to another email or to other emails, add the email addresses separated by spaces to [.filename]#/etc/periodic.conf#: [.programlisting] .... daily_output="email1@example.com email2@example.com" weekly_output="email1@example.com email2@example.com" monthly_output="email1@example.com email2@example.com" .... To log periodic output instead of receiving it as email, add the following lines to [.filename]#/etc/periodic.conf#. man:newsyslog[8] will rotate these files at the appropriate times: [.programlisting] .... daily_output=/var/log/daily.log weekly_output=/var/log/weekly.log monthly_output=/var/log/monthly.log .... [[configtuning-syslog]] == Configuring System Logging Generating and reading system logs is an important aspect of system administration. The information in system logs can be used to detect hardware and software issues as well as application and system configuration errors. This information also plays an important role in security auditing and incident response. Most system daemons and applications will generate log entries. FreeBSD provides a system logger, man:syslogd[8], to manage logging. By default, syslogd is enabled and started when the system boots. This section describes how to configure the FreeBSD system logger for both local and remote logging and how to perform log rotation and log management. === Configuring Local Logging The configuration file, [.filename]#/etc/syslog.conf#, controls what syslogd does with log entries as they are received. There are several parameters to control the handling of incoming events. The _facility_ describes which subsystem generated the message, such as the kernel or a daemon, and the _level_ describes the severity of the event that occurred. This makes it possible to configure if and where a log message is logged, depending on the facility and level. It is also possible to take action depending on the application that sent the message, and in the case of remote logging, the hostname of the machine generating the logging event. This configuration file contains one line per action, where the syntax for each line is a selector field followed by an action field. The syntax of the selector field is _facility.level_ which will match log messages from _facility_ at level _level_ or higher. It is also possible to add an optional comparison flag before the level to specify more precisely what is logged. Multiple selector fields can be used for the same action, and are separated with a semicolon (`;`). Using `*` will match everything. The action field denotes where to send the log message, such as to a file or remote log host. As an example, here is the default [.filename]#/etc/syslog.conf# from FreeBSD: [.programlisting] .... # Spaces ARE valid field separators in this file. However, # other *nix-like systems still insist on using tabs as field # separators. If you are sharing this file between systems, you # may want to use only tabs as field separators here. # Consult the syslog.conf(5) manpage. *.err;kern.warning;auth.notice;mail.crit /dev/console <.> *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/security auth.info;authpriv.info /var/log/auth.log mail.info /var/log/maillog <.> cron.* /var/log/cron !-devd *.=debug /var/log/debug.log <.> *.emerg * daemon.info /var/log/daemon.log # uncomment this to log all writes to /dev/console to /var/log/console.log # touch /var/log/console.log and chmod it to mode 600 before it will work #console.info /var/log/console.log # uncomment this to enable logging of all log messages to /var/log/all.log # touch /var/log/all.log and chmod it to mode 600 before it will work #*.* /var/log/all.log # uncomment this to enable logging to a remote loghost named loghost #*.* @loghost # uncomment these if you're running inn # news.crit /var/log/news/news.crit # news.err /var/log/news/news.err # news.notice /var/log/news/news.notice # Uncomment this if you wish to see messages produced by devd # !devd # *.>=notice /var/log/devd.log <.> !* include /etc/syslog.d include /usr/local/etc/syslog.d .... <.> Matches all messages with a level of `err` or higher, as well as `kern.warning`, `auth.notice` and `mail.crit`, and sends these log messages to the console ([.filename]#/dev/console#). <.> Matches all messages from the `mail` facility at level `info` or above and logs the messages to [.filename]#/var/log/maillog#. <.> Uses a comparison flag (`=`) to only match messages at level `debug` and logs them to [.filename]#/var/log/debug.log#. <.> Is an example usage of a program specification. This makes the rules following it only valid for the specified program. In this case, only the messages generated by man:devd[8] are logged to [.filename]#/var/log/devd.log#. For more information about [.filename]#/etc/syslog.conf#, its syntax, and more advanced usage examples, see man:syslog.conf[5]. [[logging-facilities]] === Logging Facilities A facility describes the part of the system generating the message. Facilities are a way of separating the different messages so that it is easier for the user to consult the logs. .syslog facilities [options="header", cols="1,1"] |=== | Name | Description | auth | The authorization system: man:login[1], man:su[1], man:getty[8], etc. | authpriv | The same as auth, but logged to a file readable only by root. | console | Messages written to [.filename]#/dev/console# by the kernel console output driver. | cron | Messages written by the man:cron[8] daemon. | daemon | System daemons, such as man:routed[8], that are not provided for explicitly by other facilities. | ftp | The file transfer protocol daemons: man:ftpd[8], man:tftpd[8]. | kern | Messages generated by the kernel. These cannot be generated by any user processes. | lpr | The line printer spooling system: man:lpr[1], man:lpc[8], man:lpd[8], etc. | mail | The mail system. | mark | This facility adds a record every 20 minutes. | news | The network news system. | ntp | The network time protocol system. | security | Security subsystems, such as man:ipfw[4]. | syslog | Messages generated internally by syslogd(8). | user | Messages generated by random user processes. *This is the default facility identifier if none is specified*. | uucp | The Unix-to-Unix Copy system. An ancient protocol. Really weird to see messages from this facility. | local0 through local7 | Reserved for local use. |=== [[logging-levels]] === Logging Levels The level describes the severity of the message, and is a keyword from the following ordered list (higher to lower): .syslog levels [options="header", cols="1,1"] |=== | Name | Description | emerg | A panic condition. This is normally broadcast to all users. | alert | A condition that should be corrected immediately, such as a corrupted system database. | crit | Critical conditions, e.g., hard device errors. | err | Errors. | warning | Warning messages. | notice | Conditions that are not error conditions, but should possibly be handled specially. | info | Informational messages. | debug | Messages that contain information normally of use only when debugging a program. | none | This special level disables a particular facility. |=== [[read-log-messages]] === Read Log Messages By default FreeBSD log files use the format link:https://datatracker.ietf.org/doc/html/rfc3164[rfc3164], also known as The BSD syslog Protocol. Learn more about other formats and how to use them at man:syslog[8]. Typically the logs have the following syntax: [.programlisting] .... date time hostname program[pid]: the message .... The output of the [.filename]#/var/log/cron# file will be used as an example: [.programlisting] .... [...] Jul 16 12:40:00 FreeBSD /usr/sbin/cron[81519]: (root) CMD (/usr/libexec/atrun) Jul 16 12:44:00 FreeBSD /usr/sbin/cron[83072]: (operator) CMD (/usr/libexec/save-entropy) [...] .... Verbose logging, so the facility and the level on each message will be added, can be enabled in man:syslog[8] by running the following command: [source,shell] .... # sysrc syslogd_flags="-vv" .... Once the function is activated, the facility and the level will be displayed in the log as shown in the following example: [.programlisting] .... [...] Jul 16 17:40:00 FreeBSD /usr/sbin/cron[1016]: (root) CMD (/usr/libexec/atrun) Jul 16 17:44:00 FreeBSD /usr/sbin/cron[1030]: (operator) CMD (/usr/libexec/save-entropy) [...] .... === Log Management and Rotation Log files can grow quickly, taking up disk space and making it more difficult to locate useful information. In FreeBSD, man:newsyslog[8] is used to manage log files and attempt to mitigate this. This built-in program periodically rotates and compresses log files, and optionally creates missing log files and signals programs when log files are moved. [NOTE] ==== Since newsyslog is run from man:cron[8], it cannot rotate files more often than it is scheduled to run from man:cron[8]. In the default configuration, it runs every hour. ==== Here is the default configuration in FreeBSD, more information in man:newsyslog.conf[5]: [.programlisting] .... # configuration file for newsyslog # # Entries which do not specify the '/pid_file' field will cause the # syslogd process to be signalled when that log file is rotated. This # action is only appropriate for log files which are written to by the # syslogd process (ie, files listed in /etc/syslog.conf). If there # is no process which needs to be signalled when a given log file is # rotated, then the entry for that file should include the 'N' flag. # # Note: some sites will want to select more restrictive protections than the # defaults. In particular, it may be desirable to switch many of the 644 # entries to 640 or 600. For example, some sites will consider the # contents of maillog, messages, and lpd-errs to be confidential. In the # future, these defaults may change to more conservative ones. # # logfilename [owner:group] mode count size when flags [/pid_file] [sig_num] /var/log/all.log 600 7 * @T00 J /var/log/auth.log 600 7 1000 @0101T JC /var/log/console.log 600 5 1000 * J /var/log/cron 600 3 1000 * JC /var/log/daily.log 640 7 * @T00 JN /var/log/debug.log 600 7 1000 * JC /var/log/init.log 644 3 1000 * J /var/log/kerberos.log 600 7 1000 * J /var/log/maillog 640 7 * @T00 JC /var/log/messages 644 5 1000 @0101T JC /var/log/monthly.log 640 12 * $M1D0 JN /var/log/devd.log 644 3 1000 * JC /var/log/security 600 10 1000 * JC /var/log/utx.log 644 3 * @01T05 B /var/log/weekly.log 640 5 * $W6D0 JN /var/log/daemon.log 644 5 1000 @0101T JC /etc/newsyslog.conf.d/[!.]*.conf /usr/local/etc/newsyslog.conf.d/[!.]*.conf .... . `logfilename` - Name of the system log file to be archived. . `[owner:group]` - This optional field specifies the owner and group for the archive file. . `mode` - Specify the file mode of the log file and archives. Valid mode bits are 0666. (That is, read and write permissions for the rotated log may be specified for the owner, group, and others.) . `count` - Specify the maximum number of archive files which may exist. . `size` - When the size of the log file reaches size in kilobytes, the log file will be trimmed as described above. If this field contains an asterisk ('*'), the log file will not be trimmed based on size. . `when` - Consist of an interval, a specific time, or both. Supported options in man:newsyslog.conf[5]. . `flags` - Indicates the flags that newsyslog accepts, supported options in man:newsyslog.conf[5]. . `[/pid_file]` - This optional field specifies the file name containing a daemon's process ID or to find a group process ID. . `[sig_num]` - This optional field specifies the signal that will be sent to the daemon process. [NOTE] ==== The last two fields are optional and specify the name of the Process ID (PID) file of a process and a signal number to send to that process when the file is rotated. ==== [[network-syslogd]] === Configuring Remote Logging Monitoring the log files of multiple hosts can become unwieldy as the number of systems increases. Configuring centralized logging can reduce some of the administrative burden of log file administration. In FreeBSD, centralized log file aggregation, merging, and rotation can be configured using syslogd and newsyslog. This section demonstrates an example configuration, where host `A`, named `logserv.example.com`, will collect logging information for the local network. Host `B`, named `logclient.example.com`, will be configured to pass logging information to the logging server. ==== Log Server Configuration A log server is a system that has been configured to accept logging information from other hosts. Before configuring a log server, check the following: * If there is a firewall between the logging server and any logging clients, ensure that the firewall ruleset allows UDP port 514 for both the clients and the server. * The logging server and all client machines must have forward and reverse entries in the local DNS. If the network does not have a DNS server, create entries in each system's [.filename]#/etc/hosts#. Proper name resolution is required so that log entries are not rejected by the logging server. On the log server, edit [.filename]#/etc/syslog.conf# to specify the name of the client to receive log entries from, the logging facility to be used, and the name of the log to store the host's log entries. This example adds the hostname of `B`, logs all facilities, and stores the log entries in [.filename]#/var/log/logclient.log#. .Sample Log Server Configuration [example] ==== [.programlisting] .... +logclient.example.com *.* /var/log/logclient.log .... ==== When adding multiple log clients, add a similar two-line entry for each client. More information about the available facilities may be found in man:syslog.conf[5]. Next, execute the following commands: [source,shell] .... # sysrc syslogd_enable="YES" # sysrc syslogd_flags="-a logclient.example.com -v -v" .... The first entry starts syslogd at system boot. The second entry allows log entries from the specified client. The `-v -v` increases the verbosity of logged messages. This is useful for tweaking facilities as administrators are able to see what type of messages are being logged under each facility. Multiple `-a` options may be specified to allow logging from multiple clients. IP addresses and whole netblocks may also be specified. Refer to man:syslogd[8] for a full list of possible options. Finally, create the log file: [source,shell] .... # touch /var/log/logclient.log .... At this point, syslogd should be restarted and verified: [source,shell] .... # service syslogd restart # pgrep syslog .... If a PID is returned, the server restarted successfully, and client configuration can begin. If the server did not restart, consult [.filename]#/var/log/messages# for the error. ==== Log Client Configuration A logging client sends log entries to a logging server on the network. The client also keeps a local copy of its own logs. Once a logging server has been configured, execute the following commands on the logging client: [source,shell] .... # sysrc syslogd_enable="YES" # sysrc syslogd_flags="-s -v -v" .... The first entry enables syslogd on boot up. The second entry prevents logs from being accepted by this client from other hosts (`-s`) and increases the verbosity of logged messages. Next, define the logging server in the client's [.filename]#/etc/syslog.conf#. In this example, all logged facilities are sent to a remote system, denoted by the `@` symbol, with the specified hostname: [.programlisting] .... *.* @logserv.example.com .... After saving the edit, restart syslogd for the changes to take effect: [source,shell] .... # service syslogd restart .... To test that log messages are being sent across the network, use man:logger[1] on the client to send a message to syslogd: [source,shell] .... # logger "Test message from logclient" .... This message should now exist both in [.filename]#/var/log/messages# on the client and [.filename]#/var/log/logclient.log# on the log server. ==== Debugging Log Servers If no messages are being received on the log server, the cause is most likely a network connectivity issue, a hostname resolution issue, or a typo in a configuration file. To isolate the cause, ensure that both the logging server and the logging client are able to `ping` each other using the hostname specified in their [.filename]#/etc/rc.conf#. If this fails, check the network cabling, the firewall ruleset, and the hostname entries in the DNS server or [.filename]#/etc/hosts# on both the logging server and clients. Repeat until the `ping` is successful from both hosts. If the `ping` succeeds on both hosts but log messages are still not being received, temporarily increase logging verbosity to narrow down the configuration issue. In the following example, [.filename]#/var/log/logclient.log# on the logging server is empty and [.filename]#/var/log/messages# on the logging client does not indicate a reason for the failure. To increase debugging output, edit the `syslogd_flags` entry on the logging server and issue a restart: [source,shell] .... sysrc syslogd_flags="-d -a logclient.example.com -v -v" .... [source,shell] .... # service syslogd restart .... Debugging data similar to the following will flash on the console immediately after the restart: [.programlisting] .... logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel Logging to FILE /var/log/messages syslogd: kernel boot file is /boot/kernel/kernel cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; rejected in rule 0 due to name mismatch. .... In this example, the log messages are being rejected due to a typo which results in a hostname mismatch. The client's hostname should be `logclient`, not `logclien`. Fix the typo, issue a restart, and verify the results: [source,shell] .... # service syslogd restart .... The output should be similar to the following: [.programlisting] .... logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel syslogd: kernel boot file is /boot/kernel/kernel logmsg: pri 166, flags 17, from logserv.example.com, msg Dec 10 20:55:02 logserv.example.com syslogd: exiting on signal 2 cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; accepted in rule 0. logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2 Logging to FILE /var/log/logclient.log Logging to FILE /var/log/messages .... At this point, the messages are being properly received and placed in the correct file. ==== Security Considerations As with any network service, security requirements should be considered before implementing a logging server. Log files may contain sensitive data about services enabled on the local host, user accounts, and configuration data. Network data sent from the client to the server will not be encrypted or password protected. If a need for encryption exists, consider using package:security/stunnel[], which will transmit the logging data over an encrypted tunnel. Local security is also an issue. Log files are not encrypted during use or after log rotation. Local users may access log files to gain additional insight into system configuration. Setting proper permissions on log files is critical. The built-in log rotator, newsyslog, supports setting permissions on newly created and rotated log files. Setting log files to mode `600` should prevent unwanted access by local users. Refer to man:newsyslog.conf[5] for additional information. [[acpi-overview]] == Power and Resource Management It is important to utilize hardware resources in an efficient manner. Power and resource management allows the operating system to monitor system limits and to possibly run some actions triggered by events related to those limits. [[acpi-config]] === ACPI configuration On FreeBSD the management of these resources is managed by the man:acpi[4] kernel device. [NOTE] ==== In FreeBSD the man:acpi[4] driver is loaded by default at system boot. This driver *cannot be unloaded after boot* because the system bus uses it for various hardware interactions. ==== In addition to man:acpi[4], FreeBSD has several dedicated kernel modules for various ACPI vendor subsystems. These modules will add some extra functionality like fan speed, keyboard backlit or screen brightness. The list can be obtained by running the following command: [source,shell] .... % ls /boot/kernel | grep acpi .... The output should be similar to the following: [.programlisting] .... acpi_asus.ko acpi_asus_wmi.ko acpi_dock.ko acpi_fujitsu.ko acpi_hp.ko acpi_ibm.ko acpi_panasonic.ko acpi_sony.ko acpi_toshiba.ko acpi_video.ko acpi_wmi.ko sdhci_acpi.ko uacpi.ko .... In the event that, for example, an IBM/Lenovo laptop is used, it will be necessary to load the module man:acpi_ibm[4] by executing the following command: [source,shell] .... # kldload acpi_ibm .... And add this line to [.filename]#/boot/loader.conf# to load it at boot: [.programlisting] .... acpi_ibm_load="YES" .... An alternative to the man:acpi_video[4] module is the man:backlight[9] driver. It provides a generic way for handling a panel backlight. The default GENERIC kernel includes this driver. The man:backlight[8] utility can be used to query and adjust the brightness of the panel backlight. In this example the brightness is decreased by 10%: [source,shell] .... % backlight decr 10 .... [[cpu-power-management]] === CPU Power Management CPU is the most consuming part of the system. Knowing how to improve CPU efficiency is a fundamental part of our system in order to save energy. In order to make proper use of the machine's resources in a correct way, FreeBSD supports technologies such as Intel Turbo Boost, AMD Turbo Core, Intel Speed Shift among others through the use of man:powerd[8] and man:cpufreq[4]. The first step will be to obtain the CPU information by executing the following command: [source,shell] .... % sysctl dev.cpu.0 <.> .... <.> In this case the `0` digit represents the first core of the CPU. The output should be similar to the following: [.programlisting] .... dev.cpu.0.cx_method: C1/mwait/hwc C2/mwait/hwc C3/mwait/hwc/bma dev.cpu.0.cx_usage_counters: 3507294 0 0 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 3804us dev.cpu.0.cx_lowest: C3 <1> dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57 <2> dev.cpu.0.freq_levels: 2267/35000 2266/35000 1600/15000 800/12000 <3> dev.cpu.0.freq: 1600 <4> dev.cpu.0.temperature: 40.0C <5> dev.cpu.0.coretemp.throttle_log: 0 dev.cpu.0.coretemp.tjmax: 105.0C dev.cpu.0.coretemp.resolution: 1 dev.cpu.0.coretemp.delta: 65 dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 _CID=none dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU .... <1> Lowest Cx state to use for idling the CPU. <2> CPU supported Cx states. <3> Currently available levels for the CPU (frequency/power usage). <4> Current active CPU frequency in MHz. <5> Current temperature of the CPU. [NOTE] ==== If the temperature information is not displayed, load the man:coretemp[4] module. In case of using an AMD CPU, load the man:amdtemp[4] module. ==== Once the CPU information is available the easiest way to configure power saving is to let man:powerd[8] take over. Enable man:powerd[8] service in [.filename]#/etc/rc.conf# to start at system boot: [source,shell] .... # sysrc powerd_enable=YES .... It will also be necessary to indicate certain parameters to man:powerd[8] to tell it how to manage the state of the CPU executing the following command: [source,shell] .... # sysrc powerd_flags="-a hiadaptive -i 25 -r 85 -N" .... . `-a`: Selects the mode to use while on AC power. . `hiadaptive`: Operation mode. More info at man:powerd[8]. . `-i`: Specifies the CPU load percent level when adaptive mode should begin to degrade performance to save power. . `-r`: Specifies the CPU load percent level where adaptive mode should consider the CPU running and increase performance. . `-N`: Treat "nice" time as idle for the purpose of load calculation; i.e., do not increase the CPU frequency if the CPU is only busy with "nice" processes. And then enable the service executing the following command: [source,shell] .... # service powerd start .... [[cpufreq]] === CPU Frequency Control FreeBSD includes a generic man:cpufreq[4] driver to allow the administrator, or software such as man:powerd[8] and package:sysutils/powerdxx[], to manage the frequency of the CPU to achieve the desired balance between performance and economy. A lower setting will save power while reducing the heat generated by the CPU. A higher setting will increase performance at the cost of using additional power and generating more heat. [[est]] === Intel(R) Enhanced Speed Step(TM) The Intel(R) Enhanced Speed Step(TM) driver, man:est[4], replaces the generic man:cpufreq[4] driver for CPUs that provide this feature. The CPU frequency can be statically adjusted using man:sysctl[8], or with the `/etc/rc.d/power_profile` startup script. Additional software, such as man:powerd[8] or package:sysutils/powerdxx[], can be used to automatically adjust the CPU frequency based on processor utilization. Each supported frequency, along with its expected power consumption, can be listed by examining the man:sysctl[3] tree: [source,shell] .... # sysctl dev.cpufreq.0.freq_driver dev.cpu.0.freq_levels dev.cpu.0.freq .... The output should be similar to the following: [.programlisting] .... dev.cpufreq.0.freq_driver: est0 dev.cpu.0.freq_levels: 3001/53000 3000/53000 2900/50301 2700/46082 2600/43525 2400/39557 2300/37137 2100/33398 2000/31112 1800/27610 1700/25455 1500/22171 1400/20144 1200/17084 1100/15181 900/12329 800/10550 dev.cpu.0.freq: 800 .... A frequency 1 MHz higher than the maximum frequency of the CPU indicates the Intel(R) Turbo Boost(TM) feature. [[hwpstate_intel]] === Intel Speed Shift(TM) Users running newer Intel(R) CPUs may find some differences in dynamic frequency control when upgrading to FreeBSD 13. A new driver for the Intel(R) Speed Shift(TM) feature set, available on certain SKUs, exposes the ability for the hardware to dynamically vary the core frequencies, including on a per core basis. FreeBSD 13 comes with the man:hwpstate_intel[4] driver to automatically enable Speed Shift(TM) control on equipped CPUs, replacing the older Enhanced Speed Step(TM) man:est[4] driver. The man:sysctl[8] `dev.cpufreq.%d.freq_driver` will indicate if the system is using Speed Shift. To determine which frequency control driver is being used, examining the `dev.cpufreq.0.freq_driver` oid. [source,shell] .... # sysctl dev.cpufreq.0.freq_driver .... The output should be similar to the following: [.programlisting] .... dev.cpufreq.0.freq_driver: hwpstate_intel0 .... This indicates that the new man:hwpstate_intel[4] driver is in use. On such systems, the oid `dev.cpu.%d.freq_levels` will show only the maximum CPU frequency, and will indicate a power consumption level of `-1`. The current CPU frequency can be determined by examining the `dev.cpu.%d.freq` oid. [source,shell] .... # sysctl dev.cpu.0.freq_levels dev.cpu.0.freq .... The output should be similar to the following: [.programlisting] .... dev.cpu.0.freq_levels: 3696/-1 dev.cpu.0.freq: 898 .... For more information, including on how to balance performance and energy use, and on how to disable this driver, refer to the man page man:hwpstate_intel[4]. [NOTE] ==== Users accustomed to using man:powerd[8] or package:sysutils/powerdxx[] will find these utilities have been superseded by the man:hwpstate_intel[4] driver and no longer work as expected. ==== [[graphics-card-power-management]] === Graphics Card Power Management Graphics cards have become a fundamental part of computing in recent years. Some graphics cards may have excessive power consumption. FreeBSD allows certain configurations to improve power consumption. In case of using a Intel(R) graphics card with the package:graphics/drm-kmod[] driver these options can be added to [.filename]#/boot/loader.conf#: [.programlisting] .... compat.linuxkpi.fastboot=1 <.> compat.linuxkpi.enable_dc=2 <.> compat.linuxkpi.enable_fbc=1 <.> .... <.> Try to skip unnecessary mode sets at boot time. <.> Enable power-saving display C-states. <.> Enable frame buffer compression for power savings === Suspend/Resume The suspend/resume function allows the machine to be kept in a state in which there is no a big energy consumption and allows the system to be resumed without having to lose the state of the running programs. [NOTE] ==== In order for the suspend/resume functionality to work correctly the graphics drivers must be loaded on the system. In non-KMS-supported graphics cards man:sc[4] must be used not to break the suspend/resume functionality. More information about which driver to use and how to configure it can be found at the crossref:x11[x11, The X Window System chapter]. ==== man:acpi[4] supports the next list of sleep states: .Supported Sleep States [options="header", cols="1,1"] |=== |S1 |Quick suspend to RAM. The CPU enters a lower power state, but most peripherals are left running. |S2 |Lower power state than S1, but with the same basic characteristics. Not supported by many systems. |S3 (Sleep mode) |Suspend to RAM. Most devices are powered off, and the system stops running except for memory refresh. |S4 (Hibernation) |Suspend to disk. All devices are powered off, and the system stops running. When resuming, the system starts as if from a cold power on. *Not yet supported by FreeBSD*. |S5 |System shuts down cleanly and powers off. |=== [[configure-suspend-resume]] ==== Configuring Suspend/Resume The first step will be to know which type of sleep states supports the hardware we are using executing the following command: [source,shell] .... % sysctl hw.acpi.supported_sleep_state .... The output should be similar to the following: [.programlisting] .... hw.acpi.supported_sleep_state: S3 S4 S5 .... [WARNING] ==== As stated above FreeBSD does *not* yet support the `S4` state. ==== man:acpiconf[8] can be used to check if the `S3` state works correctly by running the following command, if it succeeds, the screen should go black and the machine will turn off: [source,shell] .... # acpiconf -s 3 .... In the vast majority of cases the Suspend/Resume functionality wants to be used on a laptop. FreeBSD can be configured to enter the `S3` state when closing the lid by adding the following line to the [.filename]#/etc/sysctl.conf# file. [.programlisting] .... hw.acpi.lid_switch_state=S3 .... [[troubleshooting-suspend-resume]] ==== Troubleshooting in Suspend/Resume A lot of effort has been made to make the Suspend and Resume functions work properly and in the best way on FreeBSD. But currently the Suspend and Resume functions only work properly on some specific laptops. Some checks can be done in case it doesn't work properly. In some cases it is enough to turn off the bluetooth. In others it is enough loading the correct driver for the graphics card, etc. In case it doesn't work correctly, some tips can be found on the FreeBSD Wiki in the section link:https://wiki.freebsd.org/SuspendResume[Suspend/Resume]. [[adding-swap-space]] == Adding Swap Space Sometimes a FreeBSD system requires more swap space. This section describes two methods to increase swap space: adding swap to an existing partition or new hard drive, and creating a swap file on an existing file system. For information on how to encrypt swap space, which options exist, and why it should be done, refer to crossref:disks[swap-encrypting,“Encrypting Swap”]. [[new-drive-swap]] === Swap on a New Hard Drive or Existing Partition Adding a new drive for swap gives better performance than using a partition on an existing drive. Setting up partitions and drives is explained in crossref:disks[disks-adding,"Adding Disks"] while crossref:bsdinstall[configtuning-initial,"Designing the Partition Layout"] discusses partition layouts and swap partition size considerations. [WARNING] ==== It is possible to use any partition not currently mounted, even if it already contains data. Using `swapon` on a partition that contains data will overwrite and destroy that data. Make sure that the partition to be added as swap is really the intended partition before running `swapon`. ==== man:swapon[8] can be used to add a swap partition to the system executing the following command: [source,shell] .... # swapon /dev/ada1p2 .... To automatically add this swap partition on boot, add an entry to [.filename]#/etc/fstab#: [.programlisting] .... /dev/ada1p2 none swap sw 0 0 .... See man:fstab[5] for an explanation of the entries in [.filename]#/etc/fstab#. [[create-swapfile]] === Creating a Swap File [[swapfile-10-and-later]] These examples create a 512M swap file called [.filename]#/usr/swap0#. [WARNING] ==== Swap files on ZFS file systems are strongly discouraged, as swapping can lead to system hangs. ==== The first step is to create the swap file: [source,shell] .... # dd if=/dev/zero of=/usr/swap0 bs=1m count=512 .... The second step is to put the proper permissions on the new file: [source,shell] .... # chmod 0600 /usr/swap0 .... The third step is to inform the system about the swap file by adding a line to [.filename]#/etc/fstab#: [.programlisting] .... md none swap sw,file=/usr/swap0,late 0 0 .... Swap space will be added on system startup. To add swap space immediately, use man:swapon[8]: [source,shell] .... # swapon -aL .... diff --git a/documentation/content/en/books/handbook/desktop/_index.adoc b/documentation/content/en/books/handbook/desktop/_index.adoc index 829a63d77c..fd6e26e695 100644 --- a/documentation/content/en/books/handbook/desktop/_index.adoc +++ b/documentation/content/en/books/handbook/desktop/_index.adoc @@ -1,1148 +1,1148 @@ --- title: Chapter 8. Desktop Environments part: Part II. Common Tasks prev: books/handbook/partii next: books/handbook/multimedia description: This chapter demonstrates how to install numerous desktop environments, including web browsers, productivity software, document viewers, and financial software tags: ["desktop", "KDE Plasma", "GNOME", "XFCE", "MATE", "Cinnamon", "LXQT", "browsers", "Firefox", "Chromium", "Iridium", "Falkon", "Konqueror", "Epiphany", "qutebrowser", "Dillo", "Links", "w3m", "Development tools", "Visual Studio Code", "Qt Creator", "Kdevelop", "Eclipse IDE", "Vim", "Neovim", "GNU Emacs", "Productivity", "LibreOffice", "Calligra", "AbiWord", "Viewers", "Okular", "Evince", "ePDFView", "Xpdf", "Finance", "KMyMoney", "GnuCash"] showBookMenu: true weight: 11 params: path: "/books/handbook/desktop/" --- [[desktop]] = Desktop Environments :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 8 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/desktop/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[desktop-synopsis]] == Synopsis While FreeBSD is popular as a server for its performance and stability, it is also well suited for day-to-day use as a desktop. With over {numports} applications available in the FreeBSD ports tree, it is straightforward to build a customized desktop that can run a wide variety of desktop applications. This chapter demonstrates how to install popular desktop environments as well as desktop applications such as web browsers, productivity software, document viewers, and financial software. Prerequisites: * Readers of this chapter should already understand how to install either the crossref:x11[x11,X Window System] or crossref:wayland[wayland,Wayland] on FreeBSD. * Readers are instructed throughout this chapter to install official packages. Refer to the section on crossref:ports[ports-using,using the ports collection] to build customized packages from ports. [[desktop-environments]] == Desktop Environments This section describes how to install and configure some popular desktop environments on a FreeBSD system. A desktop environment can range from a simple window manager to a complete suite of desktop applications. .Supported desktop environments [options="header", cols="1,1,1"] |=== | Name | License | Package | KDE Plasma | GPL 2.0 or later | x11/kde | GNOME | GPL 2.0 or later | x11/gnome | XFCE | GPL, LGPL, BSD | x11-wm/xfce4 | MATE | GPL 2.0, LGPL 2.0 | x11/mate | Cinnamon | GPL 2.0 or later | x11/cinnamon | LXQT | GPL, LGPL | x11-wm/lxqt |=== [[kde-environment]] === KDE Plasma KDE Plasma is an easy-to-use desktop environment. This desktop provides a suite of applications with a consistent look and feel, a standardized menu and toolbars, keybindings, color-schemes, internationalization, and a centralized, dialog-driven desktop configuration. More information on KDE can be found at the link:https://kde.org/[KDE homepage]. For FreeBSD-specific information, consult the link:https://freebsd.kde.org/[FreeBSD homepage at KDE]. [[kde-meta-install]] ==== Install KDE Plasma meta package To install the KDE Plasma meta package with KDE Frameworks, Plasma Desktop and Applications execute: [source,shell] .... # pkg install kde .... [[kde-minimal-install]] ==== Minimal KDE Plasma installation To install a minimal KDE Plasma execute: [source,shell] .... # pkg install plasma6-plasma .... [TIP] ==== This installation is *really* minimal. Konsole must be installed separately executing: [source,shell] .... # pkg install konsole .... ==== [[kde-configuration]] ==== Configure KDE Plasma KDE Plasma uses man:dbus-daemon[1] for a message bus and hardware abstraction. This application is automatically installed as a dependency of KDE Plasma. Enable D-BUS service in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc dbus_enable="YES" .... KDE Plasma requires larger message sizes for optimal performance. Add the following lines to man:sysctl.conf[5]: [.programlisting] .... sysctl net.local.stream.recvspace=65536 sysctl net.local.stream.sendspace=65536 .... To apply the change, either run the following command as root or simply reboot the system: [source,shell] .... # sysctl -f /etc/sysctl.conf .... [[kde-start]] ==== Start KDE Plasma The preferred KDE Plasma display manager is package:x11/sddm[]. To install package:x11/sddm[], execute: [source,shell] .... # pkg install sddm .... Enable SDDM service in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc sddm_enable="YES" .... The keyboard language can be set in SDDM by running the following command (for Spanish, for example): [source,shell] .... # sysrc sddm_lang="es_ES" .... A second method to start KDE Plasma is by manually invoking man:startx[1]. For this to work, the following line is needed in ~/.xinitrc: [source,shell] .... % echo "exec dbus-launch --exit-with-x11 ck-launch-session startplasma-x11" > ~/.xinitrc .... [[gnome-environment]] === GNOME GNOME is a user-friendly desktop environment. It includes a panel for starting applications and displaying status, a desktop, a set of tools and applications, and a set of conventions that make it easy for applications to cooperate and be consistent with each other. [[gnome-meta-install]] ==== Install GNOME meta package To install the GNOME meta package with GNOME Desktop and Applications, execute: [source,shell] .... # pkg install gnome .... [[gnome-minimal-install]] ==== Minimal GNOME installation To install the GNOME-lite meta package with a GNOME desktop slimmed down for only the basics, execute: [source,shell] .... # pkg install gnome-lite .... [[gnome-configuration]] ==== Configure GNOME GNOME requires `/proc` to be mounted. Add this line to `/etc/fstab` to mount this file system automatically during system startup: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# proc /proc procfs rw 0 0 .... GNOME uses man:dbus-daemon[1] for a message bus and hardware abstraction. This application is automatically installed as a dependency of GNOME. Enable D-BUS service in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc dbus_enable="YES" .... [[gnome-start]] ==== Start GNOME GNOME Display Manager is the preferred display manager for GNOME. GDM is installed as part of the GNOME package. Enable GDM in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc gdm_enable="YES" .... A second method to start GNOME is by manually invoking man:startx[1]. For this to work, the following line is needed in `~/.xinitrc`: [source,shell] .... % echo "exec gnome-session" > ~/.xinitrc .... [[xfce-environment]] === XFCE XFCE is a desktop environment based on the GTK+, lightweight and provides a simple, efficient, easy-to-use desktop. It is fully configurable, has a main panel with menus, applets, and application launchers, provides a file manager and sound manager, and is themeable. Since it is fast, light, and efficient, it is ideal for older or slower machines with memory limitations. [[xfce-install]] ==== Install XFCE To install the XFCE meta package, execute: [source,shell] .... # pkg install xfce .... [[xfce-configuration]] ==== Configure XFCE XFCE uses man:dbus-daemon[1] for a message bus and hardware abstraction. This application is automatically installed as a dependency of XFCE. Enable D-BUS in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc dbus_enable="YES" .... [[xfce-start]] ==== Start XFCE package:x11/lightdm[] is a display manager that supports different display technologies and is a good choice as it is very lightweight, requires little memory usage, and has fast performance. To install it, execute: [source,shell] .... # pkg install lightdm lightdm-gtk-greeter .... Enable lightdm in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc lightdm_enable="YES" .... A second method to start XFCE is by manually invoking man:startx[1]. For this to work, the following line is needed in `~/.xinitrc`: [source,shell] .... % echo '. /usr/local/etc/xdg/xfce4/xinitrc' > ~/.xinitrc .... [[mate-environment]] === MATE The MATE Desktop Environment is the continuation of GNOME 2. It provides an intuitive and attractive desktop environment using traditional metaphors. [[mate-meta-install]] ==== Install MATE meta package To install the MATE meta package that includes the MATE Desktop with some extra applications such as text editor, archiver manager, etc., execute: [source,shell] .... # pkg install mate .... [[mate-minimal-install]] ==== Minimal MATE installation To install the MATE lite meta package with MATE desktop slimmed down for only the basics, execute: [source,shell] .... # pkg install mate-base .... [[mate-configuration]] ==== Configure MATE MATE requires `/proc` to be mounted. Add this line to `/etc/fstab` to mount this file system automatically during system startup: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# proc /proc procfs rw 0 0 .... MATE uses man:dbus-daemon[1] for a message bus and hardware abstraction. This application is automatically installed as a dependency of MATE. Enable D-BUS in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc dbus_enable="YES" .... [[mate-start]] ==== Start MATE package:x11/lightdm[] is a display manager that supports different display technologies and is a good choice as it is very lightweight, requires little memory usage, and has fast performance. To install it, execute: [source,shell] .... # pkg install lightdm lightdm-gtk-greeter .... Enable lightdm in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc lightdm_enable="YES" .... A second method to start MATE is by manually invoking man:startx[1]. For this to work, the following line is needed in `~/.xinitrc`: [source,shell] .... % echo "exec dbus-launch --exit-with-x11 ck-launch-session mate-session" > ~/.xinitrc .... [[cinnamon-environment]] === Cinnamon Cinnamon is a UNIX(R) desktop which provides advanced innovative features and a traditional user experience. The desktop layout is similar to Gnome 2. The underlying technology is forked from Gnome Shell. The emphasis is put on making users feel at home and providing them with an easy to use and comfortable desktop experience. [[cinnamon-install]] ==== Install Cinnamon To install the Cinnamon package, execute: [source,shell] .... # pkg install cinnamon .... [[cinnamon-configuration]] ==== Configure Cinnamon Cinnamon requires `/proc` to be mounted. Add this line to `/etc/fstab` to mount this file system automatically during system startup: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# proc /proc procfs rw 0 0 .... Cinnamon uses man:dbus-daemon[1] for a message bus and hardware abstraction. This application is automatically installed as a dependency of Cinnamon. Enable D-BUS in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc dbus_enable="YES" .... [[cinnamon-start]] ==== Start Cinnamon package:x11/lightdm[] is a display manager that supports different display technologies and is a good choice as it is very lightweight, requires little memory usage, and has fast performance. To install it execute: [source,shell] .... # pkg install lightdm lightdm-gtk-greeter .... Enable lightdm in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc lightdm_enable="YES" .... A second method to start Cinnamon is by manually invoking man:startx[1]. For this to work, the following line is needed in `~/.xinitrc`: [source,shell] .... % echo "exec dbus-launch --exit-with-x11 ck-launch-session cinnamon-session" > ~/.xinitrc .... [[lxqt-environment]] === LXQT LXQt is an advanced, easy-to-use, and fast desktop environment based on Qt technologies. It has been tailored for users who value simplicity, speed, and an intuitive interface. Unlike most desktop environments, LXQt also works fine with less powerful machines. [[lxqt-install]] ==== Install LXQT To install the LXQT meta package, execute: [source,shell] .... # pkg install lxqt .... [[lxqt-configuration]] ==== Configure LXQT LXQT requires `/proc` to be mounted. Add this line to `/etc/fstab` to mount this file system automatically during system startup: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# proc /proc procfs rw 0 0 .... LXQT uses man:dbus-daemon[1] for a message bus and hardware abstraction. This application is automatically installed as a dependency of LXQT. Enable D-BUS in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc dbus_enable="YES" .... [[lxqt-start]] ==== Start LXQT The preferred LXQT display manager is package:x11/sddm[]. To install package:x11/sddm[], execute: [source,shell] .... # pkg install sddm .... Enable SDDM service in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc sddm_enable="YES" .... The keyboard language can be set in SDDM by running the following command (for example, for Spanish): [source,shell] .... # sysrc sddm_lang="es_ES" .... A second method to start LXQT is by manually invoking man:startx[1]. For this to work, the following line is needed in `~/.xinitrc`: [source,shell] .... % echo "exec dbus-launch --exit-with-x11 ck-launch-session startlxqt" > ~/.xinitrc .... [[desktop-browsers]] == Browsers This section describes how to install and configure some popular web browsers on a FreeBSD system, from full web browsers with high resource consumption to command line web browsers with reduced resource usage. .Supported browsers [options="header", cols="1,1,1,1"] |=== | Name | License | Package | Resources Needed | Firefox | MPL 2.0 | package:www/firefox[] | Heavy | Chromium | BSD-3 and others | package:www/chromium[] | Heavy | Iridium browser | BSD-3 and others | package:www/iridium-browser[] | Heavy | Falkon | MPL 2.0 | package:www/falkon-qtonly[] | Heavy | Konqueror | GPL 2.0 or later | package:x11-fm/konqueror[] | Medium | Gnome Web (Epiphany) | GPL 3.0 or later | package:www/epiphany[] | Medium | qutebrowser | GPL 3.0 or later | package:www/qutebrowser[] | Medium | Dillo | GPL 3.0 or later | package:www/dillo2[] | Light | Links | GPL 2.0 or later | package:www/links[] | Light | w3m | MIT | package:www/w3m[] | Light |=== [[firefox]] === Firefox Firefox is an open source browser that features a standards-compliant HTML display engine, tabbed browsing, popup blocking, extensions, improved security, and more. Firefox is based on the Mozilla codebase. To install the package of the latest release version of Firefox, execute: [source,shell] .... # pkg install firefox .... To instead install Firefox Extended Support Release (ESR) version, execute: [source,shell] .... # pkg install firefox-esr .... [[chromium]] === Chromium Chromium is an open source browser project that aims to build a safer, faster, and more stable web browsing experience. Chromium features tabbed browsing, popup blocking, extensions, and much more. Chromium is the open source project upon which the Google Chrome web browser is based. To install Chromium, execute: [source,shell] .... # pkg install chromium .... [NOTE] ==== The executable for Chromium is [.filename]#/usr/local/bin/chrome#, not [.filename]#/usr/local/bin/chromium#. ==== [[iridium]] === Iridium browser Iridium is a free, open, and libre browser modification of the Chromium code base, with privacy being enhanced in several key areas. Automatic transmission of partial queries, keywords, metrics to central services is inhibited and only occurs with consent. To install Iridium, execute: [source,shell] .... # pkg install iridium-browser .... [[falkon]] === Falkon Falkon is a new-ish and very fast QtWebEngine browser. It aims to be a lightweight web browser available on all major platforms. Falkon has all standard functions someone can expect from a web browser. It includes bookmarks, history (both also in sidebar) and tabs. Beyond that, AdBlock plugin can block ads, Click2Flash can block Flash content and SSL Manager can edit the local CA Certificates database. To install Falkon, execute: [source,shell] .... # pkg install falkon .... [[konqueror]] === Konqueror Konqueror is more than a web browser as it is also a file manager and a multimedia viewer. It supports WebKit, a rendering engine used by many modern browsers including Chromium, as well as its own KHTML engine. To install Konqueror, execute: [source,shell] .... # pkg install konqueror .... [[gnome-web-epiphany]] === Gnome Web (Epiphany) Gnome Web (Epiphany) is a web browser designed to be as lightweight and fast as possible, at the expense of many of the features found in other browsers. To install Gnome Web (Epiphany), execute: [source,shell] .... # pkg install epiphany .... [[qutebrowser]] === qutebrowser Qutebrowser is a keyboard-focused browser with a minimal GUI. It is based on Python and PyQt5 and free software, licensed under the GPL. To install qutebrowser, execute: [source,shell] .... # pkg install qutebrowser .... [[dillo]] === Dillo Dillo aims to be a multiplatform alternative browser that is small, stable, developer-friendly, usable, fast, and extensible. This new, experimental version of Dillo is based upon FLTK toolkit, rather than GTK1, and has been substantially rewritten. To install Dillo, execute: [source,shell] .... # pkg install dillo2 .... [[links]] === Links A lynx-like web browser with text and graphics modes with many features like displaying tables, menus, etc. To install Links, execute: [source,shell] .... # pkg install links .... [[w3m]] === w3m w3m is a pager/text-based web browser. It is a similar application to Lynx, but it has several features Lynx does not have like rendering tables and rendering frames. To install w3m, execute: [source,shell] .... # pkg install w3m .... [[desktop-development]] == Development tools This section describes how to install and configure some popular development tools on a FreeBSD system. .Supported development tools [options="header", cols="1,1,1,1"] |=== | Name | License | Package | Resources Needed | Visual Studio Code | MIT | package:editors/vscode[] | Heavy | Qt Creator | QtGPL | package:devel/qtcreator[] | Heavy | Kdevelop | GPL 2.0 or later and LGPL 2.0 or later | package:devel/kdevelop[] | Heavy | Eclipse IDE | EPL | package:java/eclipse[] | Heavy | Vim | VIM | package:editors/vim[] | Light | Neovim | Apache 2.0 | package:editors/neovim[] | Light | GNU Emacs | GPL 3.0 or later | package:editors/emacs[] | Light |=== [[vs-code]] === Visual Studio Code Visual Studio Code is a type of tool that combines the simplicity of a code editor with what developers need for their core edit-build-debug cycle. It provides comprehensive editing and debugging support, an extensibility model, and lightweight integration with existing tools. To install Visual Studio Code, execute: [source,shell] .... # pkg install vscode .... [[qt-creator]] === Qt Creator Qt Creator is a cross-platform IDE (integrated development environment) tailored to the needs of Qt developers. Functionalities included with Qt Creator are: * code editor with C++, QML and ECMAscript support; * rapid code navigation tools; -* static code checking and style hints as you type; +* static code checking and style hints when typing; * context sensitive help; * visual debugger; * integrated GUI layout and forms designer. To install Qt Creator, execute: [source,shell] .... # pkg install qtcreator .... [[kdevelop]] === kdevelop Open source, feature-full, plugin extensible IDE for C/C++ and other programming languages. It is based on KDevPlatform and the KDE and Qt libraries, and it has been under development since 1998. To install kdevelop, execute: [source,shell] .... # pkg install kdevelop .... [[eclipse]] === Eclipse IDE The Eclipse Platform is an open extensible IDE for anything and yet nothing in particular. The Eclipse Platform provides building blocks and a foundation for constructing and running integrated software-development tools. The Eclipse Platform allows tool builders to independently develop tools that integrate with other people's tools. To install Eclipse IDE, execute: [source,shell] .... # pkg install eclipse .... [[vim]] === Vim Vim is a highly configurable text editor built to enable efficient text editing. It is an improved version of the vi editor distributed with most UNIX systems. Vim is often called a "programmer's editor," and so useful for programming that many consider it an entire IDE. It is not just for programmers, though. Vim is perfect for all kinds of text editing, from composing email to editing configuration files. To install Vim, execute: [source,shell] .... # pkg install vim .... [[neovim]] === Neovim Neovim is an aggressive refactor of package:editors/vim[]. It represents a complete overhaul of the codebase with many sanity improvements, including sensible defaults, a built-in terminal emulator, asynchronous plugin architecture, and powerful APIs designed for speed and extensibility. It retains full compatibility with almost all Vim plugins and scripts. To install Neovim, execute: [source,shell] .... # pkg install neovim .... [[gnu-emacs]] === GNU Emacs GNU Emacs is an extensible, customizable, free/libre text editor. At its core is an interpreter for Emacs Lisp, a dialect of the Lisp programming language with extensions to support text editing. To install GNU Emacs, execute: [source,shell] .... # pkg install emacs .... [[desktop-productivity]] == Desktop office productivity When it comes to productivity, users often look for an office suite or an easy-to-use word processor. While some desktop environments like crossref:desktop[kde-environment, KDE Plasma] provide an office suite, there is no default productivity package. Several office suites and graphical word processors are available for FreeBSD, regardless of the installed desktop environments. This section demonstrates how to install the following popular productivity software and indicates if the application is resource-heavy, takes time to compile from ports, or has any major dependencies. .Supported Desktop office productivity suites [options="header", cols="1,1,1,1"] |=== | Name | License | Package | Resources Needed | LibreOffice | MPL 2.0 | package:editors/libreoffice[] | Heavy | Calligra Suite | LGPL and GPL | package:editors/calligra[] | Medium | AbiWord | GPL 2.0 or later | package:editors/abiword[] | Medium |=== [[libreoffice]] === LibreOffice LibreOffice is a free software office suite developed by http://www.documentfoundation.org/[The Document Foundation]. It is compatible with other major office suites and available on a variety of platforms. It is a rebranded fork of Apache OpenOffice and includes applications found in a complete office productivity suite: a word processor, spreadsheet, presentation manager, drawing program, database management program, and a tool for creating and editing mathematical formulæ. It is available in a number of different languages and internationalization has been extended to interfaces, spell checkers, and dictionaries. More information about LibreOffice can be found at http://www.libreoffice.org/[libreoffice.org]. To install LibreOffice, execute: [source,shell] .... # pkg install libreoffice .... The LibreOffice package comes by default only in English. To have a localized version of LibreOffice it is necessary to install a language pack. For example, for the version localized in Spanish, it is necessary to install the package package:editors/libreoffice-es[] with the command: [source,shell] .... # pkg install libreoffice-es .... [[calligra]] === Calligra The KDE Plasma desktop environment includes an office suite which can be installed separately from KDE Plasma. Calligra includes standard components that can be found in other office suites. Words is the word processor, Sheets is the spreadsheet program, Stage manages slide presentations, and Karbon is used to draw graphical documents. To install Calligra, execute: [source,shell] .... # pkg install calligra .... [[abiword]] === AbiWord AbiWord is a free word processing program similar in look and feel to Microsoft(R) Word. It is fast, contains many features, and is user-friendly. AbiWord can import or export many file formats, including some proprietary ones like Microsoft(R) [.filename]#.rtf#. To install AbiWord, execute: [source,shell] .... # pkg install abiword .... [[desktop-viewers]] == Document Viewers Some new document formats have gained popularity since the advent of UNIX(R) and the viewers they require may not be available in the base system. This section demonstrates how to install the following document viewers: .Supported Document Viewers [options="header", cols="1,1,1,1"] |=== | Name | License | Package | Resources Needed | Okular | GPL 2.0 | package:graphics/okular[] | Heavy | Evince | GPL 2.0 | package:graphics/evince[] | Medium | ePDFView | GPL 2.0 | package:graphics/epdfview[] | Medium | Xpdf | GPL 2.0 | package:graphics/xpdf[] | light | Zathura | Zlib | package:graphics/zathura[] | light |=== [[okular]] === Okular Okular is a universal document viewer, part of the KDE Plasma project. Okular combines excellent functionality with the versatility of supporting different kind of documents, like PDF, Postscript, DjVu, CHM, XPS, ePub and others. To install Okular, execute: [source,shell] .... # pkg install okular .... [[evince]] === Evince Evince is a document viewer for multiple document formats including PDF and Postscript. Part of the GNOME project. The goal of evince is to replace document viewers such as ggv and gpdf with a single, simple application. To install Evince, execute: [source,shell] .... # pkg install evince .... [[epdfview]] === ePDFView ePDFView is a lightweight PDF document viewer that only uses the Gtk+ and Poppler libraries. The aim of ePDFView is to make a simple PDF document viewer, similar to Evince but without using the GNOME libraries. To install ePDFView, execute: [source,shell] .... # pkg install epdfview .... [[xpdf]] === Xpdf For users that prefer a small FreeBSD PDF viewer, Xpdf provides a light-weight and efficient viewer which requires few resources. It uses the standard X fonts and does not require any additional toolkit. To install Xpdf, execute: [source,shell] .... # pkg install xpdf .... [[zathura]] === Zathura Zathura is a highly customizable and functional document viewer. It provides a minimalistic and space saving interface as well as an easy usage that mainly focuses on keyboard interaction. To install zathura, with PDF support, execute: [source,shell] .... # pkg install zathura zathura-pdf-mupdf .... Additionally, one can install package:graphics/zathura-pdf-poppler[] for alternative PDF support, package:graphics/zathura-ps[] for PostScript support, package:graphics/zathura-djvu[] for DjVu support, and package:graphics/zathura-cb[] for comic book support. [[desktop-finance]] == Finance For managing personal finances on a FreeBSD desktop, some powerful and easy-to-use applications can be installed. Some are compatible with widespread file formats, such as the formats used by Quicken and Excel. This section covers these programs: .Supported Finance programs [options="header", cols="1,1,1,1"] |=== | Name | License | Package | Resources Needed | KMyMoney | GPL 2.0 | package:finance/kmymoney[] | Heavy | GnuCash | GPL 2.0 and GPL 3.0 | package:finance/gnucash[] | Heavy |=== [[kmymoney]] === KMyMoney KMyMoney is a personal finance application created by the KDE community. KMyMoney aims to provide the important features found in commercial personal finance manager applications. It also highlights ease-of-use and proper double-entry accounting among its features. KMyMoney imports from standard Quicken QIF files, tracks investments, handles multiple currencies, and provides a wealth of reports. To install KMyMoney, execute: [source,shell] .... # pkg install kmymoney .... [[gnucash]] === GnuCash GnuCash is part of the GNOME effort to provide user-friendly, yet powerful, applications to end-users. GnuCash can be used to keep track of income and expenses, bank accounts, and stocks. It features an intuitive interface while remaining professional. GnuCash provides a smart register, a hierarchical system of accounts, and many keyboard accelerators and auto-completion methods. It can split a single transaction into several more detailed pieces. GnuCash can import and merge Quicken QIF files. It also handles most international date and currency formats. To install GnuCash, execute: [source,shell] .... # pkg install gnucash .... diff --git a/documentation/content/en/books/handbook/dtrace/_index.adoc b/documentation/content/en/books/handbook/dtrace/_index.adoc index 755a21404e..b2a8fb93b1 100644 --- a/documentation/content/en/books/handbook/dtrace/_index.adoc +++ b/documentation/content/en/books/handbook/dtrace/_index.adoc @@ -1,287 +1,287 @@ --- title: Chapter 27. DTrace part: Part III. System Administration prev: books/handbook/cutting-edge next: books/handbook/usb-device-mode description: This chapter explains how to use DTrace in FreeBSD tags: ["DTrace", "features", "guide", "tutorial", "kldload"] showBookMenu: true weight: 31 params: path: "/books/handbook/dtrace/" --- [[dtrace]] = DTrace :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 27 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/dtrace/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[dtrace-synopsis]] == Synopsis DTrace, also known as Dynamic Tracing, was developed by Sun(TM) as a tool for locating performance bottlenecks in production and pre-production systems. In addition to diagnosing performance problems, DTrace can be used to help investigate and debug unexpected behavior in both the FreeBSD kernel and in userland programs. DTrace is a remarkable profiling tool, with an impressive array of features for diagnosing system issues. It may also be used to run pre-written scripts to take advantage of its capabilities. Users can author their own utilities using the DTrace D Language, allowing them to customize their profiling based on specific needs. The FreeBSD implementation provides full support for kernel DTrace and experimental support for userland DTrace. Userland DTrace allows users to perform function boundary tracing for userland programs using the `pid` provider, and to insert static probes into userland programs for later tracing. Some ports, such as package:databases/postgresql12-server[] and package:lang/php74[] have a DTrace option to enable static probes. The official guide to DTrace is maintained by the illumos project at https://illumos.org/books/dtrace/bookinfo.html[illumos Dynamic Tracing Guide]. -After reading this chapter, you will know: +Read this chapter to learn: * What DTrace is and what features it provides. * Differences between the Solaris(TM) DTrace implementation and the one provided by FreeBSD. * How to enable and use DTrace on FreeBSD. -Before reading this chapter, you should: +Before reading this chapter: * Understand UNIX(R) and FreeBSD basics (crossref:basics[basics,FreeBSD Basics]). * Have some familiarity with security and how it pertains to FreeBSD (crossref:security[security,Security]). [[dtrace-implementation]] == Implementation Differences While the DTrace in FreeBSD is similar to that found in Solaris(TM), differences do exist. The primary difference is that in FreeBSD, DTrace is implemented as a set of kernel modules and DTrace can not be used until the modules are loaded. To load all of the necessary modules: [source,shell] .... # kldload dtraceall .... Beginning with FreeBSD 10.0-RELEASE, the modules are automatically loaded when man:dtrace[1] is run. FreeBSD uses the `DDB_CTF` kernel option to enable support for loading man:ctf[5] data from kernel modules and the kernel itself. `CTF` is the Solaris(TM) Compact C Type Format which encapsulates a reduced form of debugging information similar to `DWARF` and the venerable stabs. `CTF` data is added to binaries by the man:ctfconvert[1] and man:ctfmerge[1] build tools. The `ctfconvert` utility parses `DWARF` `ELF` debug sections created by the compiler and `ctfmerge` merges `CTF` `ELF` sections from objects into either executables or shared libraries. Some different providers exist for FreeBSD than for Solaris(TM). Most notable is the `dtmalloc` provider, which allows tracing man:malloc[9] by type in the FreeBSD kernel. Some of the providers found in Solaris(TM), such as `cpc`, are not present in FreeBSD. These may appear in future versions of FreeBSD. Moreover, some of the providers available in both operating systems are not compatible, in the sense that their probes have different argument types. Thus, `D` scripts written on Solaris(TM) may or may not work unmodified on FreeBSD, and vice versa. Due to security differences, only `root` may use DTrace on FreeBSD. Solaris(TM) has a few low level security checks which do not yet exist in FreeBSD. As such, the [.filename]#/dev/dtrace/dtrace# is strictly limited to `root`. DTrace falls under the Common Development and Distribution License (`CDDL`) license. To view this license on FreeBSD, see [.filename]#/usr/src/cddl/contrib/opensolaris/OPENSOLARIS.LICENSE# or view it online at http://opensource.org/licenses/CDDL-1.0[http://opensource.org/licenses/CDDL-1.0]. While a FreeBSD kernel with DTrace support is `BSD` licensed, the `CDDL` is used when the modules are distributed in binary form or the binaries are loaded. [[dtrace-enable]] == Enabling DTrace Support In FreeBSD 9.2 and 10.0, DTrace support is built into the [.filename]#GENERIC# kernel. Users of earlier versions of FreeBSD or who prefer to statically compile in DTrace support should add the following lines to a custom kernel configuration file and recompile the kernel using the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]: [.programlisting] .... options KDTRACE_HOOKS options DDB_CTF makeoptions DEBUG=-g makeoptions WITH_CTF=1 .... Users of the AMD64 architecture should also add this line: [.programlisting] .... options KDTRACE_FRAME .... This option provides support for man:dtrace_fbt[4]. While DTrace will work without this option, there will be limited support for function boundary tracing. Once the FreeBSD system has rebooted into the new kernel, or the DTrace kernel modules have been loaded using `kldload dtraceall`, install the current DTrace Toolkit (package:sysutils/dtrace-toolkit[]), a collection of ready-made scripts for collecting system information. There are scripts to check open files, memory, CPU usage, and a lot more. FreeBSD includes some scripts in the base system as well; see [.filename]#/usr/share/dtrace#. [NOTE] ==== The scripts found in [.filename]#/usr/share/dtrace# have been specifically ported to FreeBSD. Not all of the scripts found in the DTrace Toolkit will work as-is on FreeBSD and some scripts may require some effort in order for them to work on FreeBSD. ==== The DTrace Toolkit includes many scripts in the special language of DTrace. This language is called the D language and it is very similar to C++. An in depth discussion of the language is beyond the scope of this document. Refer to the FreeBSD man:d[7] manual page for an overview of the D language on FreeBSD. The D language is also covered extensively in the https://www.illumos.org/books/dtrace/bookinfo.html[illumos Dynamic Tracing Guide]. [[dtrace-out-of-kernel]] == Enabling DTrace in Out-of-Kernel Modules To add DTrace support to an out-of-kernel module, which is useful for development and debugging, include the following line in the module's Makefile: [.programlisting] .... CFLAGS+= -DKDTRACE_HOOKS .... This flag enables DTrace hooks during compilation, allowing for advanced debugging and monitoring of the module. Ensure to recompile the module after this modification to activate DTrace functionality. [[dtrace-using]] == Using DTrace DTrace scripts consist of a list of one or more _probes_, or instrumentation points, where each probe is associated with an action. Whenever the condition for a probe is met, the associated action is executed. For example, an action may occur when a file is opened, a process is started, or a line of code is executed. The action might be to log some information or to modify context variables. The reading and writing of context variables allows probes to share information and to cooperatively analyze the correlation of different events. To view all probes, the administrator can execute the following command: [source,shell] .... # dtrace -l | more .... Each probe has an `ID`, a `PROVIDER` (e.g., `dtrace` or `fbt`), a `MODULE`, and a `FUNCTION NAME`. Refer to man:dtrace[1] for more information about this command. The examples in this section provide an overview of how to use two of the fully supported scripts from the DTrace Toolkit: the [.filename]#hotkernel# and [.filename]#procsystime# scripts. The [.filename]#hotkernel# script is designed to identify which function is using the most kernel time. It will produce output similar to the following: [source,shell] .... # cd /usr/local/share/dtrace-toolkit # ./hotkernel Sampling... Hit Ctrl-C to end. .... As instructed, use the kbd:[Ctrl+C] key combination to stop the process. Upon termination, the script will display a list of kernel functions and timing information, sorting the output in increasing order of time: [source,shell] .... kernel`_thread_lock_flags 2 0.0% 0xc1097063 2 0.0% kernel`sched_userret 2 0.0% kernel`kern_select 2 0.0% kernel`generic_copyin 3 0.0% kernel`_mtx_assert 3 0.0% kernel`vm_fault 3 0.0% kernel`sopoll_generic 3 0.0% kernel`fixup_filename 4 0.0% kernel`_isitmyx 4 0.0% kernel`find_instance 4 0.0% kernel`_mtx_unlock_flags 5 0.0% kernel`syscall 5 0.0% kernel`DELAY 5 0.0% 0xc108a253 6 0.0% kernel`witness_lock 7 0.0% kernel`read_aux_data_no_wait 7 0.0% kernel`Xint0x80_syscall 7 0.0% kernel`witness_checkorder 7 0.0% kernel`sse2_pagezero 8 0.0% kernel`strncmp 9 0.0% kernel`spinlock_exit 10 0.0% kernel`_mtx_lock_flags 11 0.0% kernel`witness_unlock 15 0.0% kernel`sched_idletd 137 0.3% 0xc10981a5 42139 99.3% .... This script will also work with kernel modules. To use this feature, run the script with `-m`: [source,shell] .... # ./hotkernel -m Sampling... Hit Ctrl-C to end. ^C MODULE COUNT PCNT 0xc107882e 1 0.0% 0xc10e6aa4 1 0.0% 0xc1076983 1 0.0% 0xc109708a 1 0.0% 0xc1075a5d 1 0.0% 0xc1077325 1 0.0% 0xc108a245 1 0.0% 0xc107730d 1 0.0% 0xc1097063 2 0.0% 0xc108a253 73 0.0% kernel 874 0.4% 0xc10981a5 213781 99.6% .... The [.filename]#procsystime# script captures and prints the system call time usage for a given process `ID` (`PID`) or process name. In the following example, a new instance of [.filename]#/bin/csh# was spawned. Then, [.filename]#procsystime# was executed and remained waiting while a few commands were typed on the other incarnation of `csh`. These are the results of this test: [source,shell] .... # ./procsystime -n csh Tracing... Hit Ctrl-C to end... ^C Elapsed Times for processes csh, SYSCALL TIME (ns) getpid 6131 sigreturn 8121 close 19127 fcntl 19959 dup 26955 setpgid 28070 stat 31899 setitimer 40938 wait4 62717 sigaction 67372 sigprocmask 119091 gettimeofday 183710 write 263242 execve 492547 ioctl 770073 vfork 3258923 sigsuspend 6985124 read 3988049784 .... As shown, the man:read[2] system call used the most time in nanoseconds while the man:getpid[2] system call used the least amount of time. diff --git a/documentation/content/en/books/handbook/eresources/_index.adoc b/documentation/content/en/books/handbook/eresources/_index.adoc index d237a62b71..b63222c1af 100644 --- a/documentation/content/en/books/handbook/eresources/_index.adoc +++ b/documentation/content/en/books/handbook/eresources/_index.adoc @@ -1,200 +1,200 @@ --- title: Appendix C. Resources on the Internet part: Part V. Appendices prev: books/handbook/bibliography next: books/handbook/pgpkeys description: FreeBSD additional resources on internet like websites, mailing lists, mirrors, etc tags: ["eresources", "Websites", "Mailing Lists", "Usenet", "Newsgroups"] showBookMenu: true weight: 43 params: path: "/books/handbook/eresources/" --- [appendix] [[eresources]] = Resources on the Internet :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: C :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/eresources/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] Development of FreeBSD is too rapid for print media to be practical for keeping people informed. For awareness of developments: electronic alternatives to print are best. The FreeBSD user community provides much technical support -- with forums, chat and email amongst the most popular and effective means of communication. The most important points of contact are outlined below. The link:https://wiki.freebsd.org/Community[Community wiki area] may be more up-to-date. Please make the {freebsd-doc} aware of any resource that is either redundant, or not yet listed below. [[eresources-www]] == Websites * The link:https://forums.FreeBSD.org/[FreeBSD Forums] provide a web based discussion forum for FreeBSD questions and technical discussion. * The link:https://wiki.FreeBSD.org/[FreeBSD Wiki] provides various bits of information that hadn't yet made it into the Handbook. * The link:https://docs.FreeBSD.org/[Documentation Portal] offers much more than the FreeBSD Handbook alone; there are more than forty books and articles. * The link:https://freebsdfoundation.org/our-work/journal/browser-based-edition/[FreeBSD Journal] is a free, professionally-edited, bi-monthly technical magazine released by link:https://freebsdfoundation.org[The FreeBSD Foundation]. * The link:http://www.youtube.com/bsdconferences[BSDConferences YouTube Channel] provides a collection of high quality videos from BSD conferences around the world. This is a great way to watch key developers give presentations about new work in FreeBSD. * link:https://www.freebsd.org/status/[FreeBSD Status Reports] are released every three months and track progress of FreeBSD development. * There's a link:https://www.reddit.com/r/freebsd/[FreeBSD-focused Reddit group] at r/freebsd. * link:https://superuser.com/questions/tagged/freebsd[Super User] and link:https://serverfault.com/questions/tagged/freebsd[Server Fault], the Stack Exchange services for system administrators. * link:https://wiki.freebsd.org/Discord[FreeBSD Discord server], a communications and community-building service, where FreeBSD community members can socialise, obtain support or support others, learn, contribute, collaborate, and stay up to date with all things FreeBSD-related. * link:https://wiki.freebsd.org/IRC/Channels[IRC channels], a widely implemented, technically mature, open standard text chat. [[eresources-mail]] == Mailing Lists The mailing lists are the most direct way of addressing questions or opening a technical discussion to a concentrated FreeBSD audience. There are a wide variety of lists on a number of different FreeBSD topics. Sending questions to the most appropriate mailing list will invariably assure a faster and more accurate response. Technical list threads should remain technical. All users and developers of FreeBSD should subscribe to the {freebsd-announce}. [NOTE] ==== To test FreeBSD mailing list capabilities, aim for the {freebsd-test}. Please do not send test messages to any other list. ==== When in doubt about what list to post a question to, see extref:{freebsd-questions-article}[How to get best results from the FreeBSD-questions mailing list]. Before posting to any list, please: * learn about how to best use the mailing lists, such as how to help avoid frequently-repeated discussions, by reading the extref:{mailing-list-faq}[Mailing List Frequently Asked Questions] (FAQ) document -* search the archives, to tell whether someone else has already posted what you intend to post. +* search the archives, to tell whether someone else has already posted the same. + +Archive search interfaces include: -Archive search interfaces include: - - https://lists.freebsd.org/search[] (FreeBSD, experimental) - https://www.freebsd.org/search/[] (DuckDuckGo) Note that this also means that messages sent to FreeBSD mailing lists are archived in perpetuity. When protecting privacy is a concern, consider using a disposable secondary email address and posting only public information. FreeBSD-provided archives: * do not present links as links * do not present inline images * do not present HTML content of HTML messages. [[eresources-summary]] The FreeBSD public mailing lists can be consulted link:{mailing-lists-url}[here]. [[eresources-subscribe]] === How to Subscribe or Unsubscribe At {mailing-lists-url}, click the name of a list to reveal its options. To post, after subscribing, send mail to `listname@FreeBSD.org`. The message will be redistributed to list members. [[eresources-charters]] === Lists Basic Rules _All_ FreeBSD mailing lists have certain basic rules which must be adhered to by anyone using them. Failure to comply with these guidelines will result in two (2) written warnings from the FreeBSD Postmaster mailto:postmaster@FreeBSD.org[postmaster@FreeBSD.org], after which, on a third offense, the poster will removed from all FreeBSD mailing lists and filtered from further posting to them. We regret that such rules and measures are necessary at all, but today's Internet is a pretty harsh environment, it would seem, and many fail to appreciate just how fragile some of its mechanisms are. Rules of the road: * The topic of any posting should adhere to the basic description of the list it is posted to. If the list is about technical issues, the posting should contain technical discussion. Ongoing irrelevant chatter or flaming only detracts from the value of the mailing list for everyone on it and will not be tolerated. For free-form discussion on no particular topic, the {freebsd-chat} is freely available and should be used instead. * No posting should be made to more than 2 mailing lists, and only to 2 when a clear and obvious need to post to both lists exists. For most lists, there is already a great deal of subscriber overlap and except for the most esoteric mixes (say "-stable & -scsi"), there really is no reason to post to more than one list at a time. If a message is received with multiple mailing lists on the `Cc` line, trim the `Cc` line before replying. _The person who replies is still responsible for cross-posting, no matter who the originator might have been._ * Personal attacks and profanity (in the context of an argument) are not allowed, and that includes users and developers alike. Gross breaches of netiquette, like excerpting or reposting private mail when permission to do so was not and would not be forthcoming, are frowned upon but not specifically enforced. * Advertising of non-FreeBSD related products or services is strictly prohibited and will result in an immediate ban if it is clear that the offender is advertising by spam. [[eresources-mailfiltering]] === Filtering on the Mailing Lists The FreeBSD mailing lists are filtered in multiple ways to avoid the distribution of spam, viruses, and other unwanted emails. The filtering actions described in this section do not include all those used to protect the mailing lists. Only certain types of attachments are allowed on the mailing lists. All attachments with a MIME content type not found in the list below will be stripped before an email is distributed on the mailing lists. * application/octet-stream * application/pdf * application/pgp-signature * application/x-pkcs7-signature * message/rfc822 * multipart/alternative * multipart/related * multipart/signed * text/html * text/plain * text/x-diff * text/x-patch [NOTE] ==== Some of the mailing lists might allow attachments of other MIME content types, but the above list should be applicable for most of the mailing lists. ==== If a multi-part message includes text/plain and text/html parts: - addressees will receive both parts - lists.freebsd.org will present text/plain with an option to view original text (source, with raw HTML amongst the parts). If text/plain does not accompany text/html: - there will be conversion from HTML to plain text. [[eresources-news]] == Usenet Newsgroups In addition to two FreeBSD specific newsgroups, there are many others in which FreeBSD is discussed or are otherwise relevant to FreeBSD users. === BSD Specific Newsgroups * link:news:comp.unix.bsd.freebsd.announce[comp.unix.bsd.freebsd.announce] * link:news:comp.unix.bsd.freebsd.misc[comp.unix.bsd.freebsd.misc] * link:news:de.comp.os.unix.bsd[de.comp.os.unix.bsd] (German) * link:news:fr.comp.os.bsd[fr.comp.os.bsd] (French) === Other UNIX(R) Newsgroups of Interest * link:news:comp.unix[comp.unix] * link:news:comp.unix.questions[comp.unix.questions] * link:news:comp.unix.admin[comp.unix.admin] * link:news:comp.unix.programmer[comp.unix.programmer] * link:news:comp.unix.shell[comp.unix.shell] * link:news:comp.unix.misc[comp.unix.misc] * link:news:comp.unix.bsd[comp.unix.bsd] === X Window System * link:news:comp.windows.x[comp.windows.x] diff --git a/documentation/content/en/books/handbook/filesystems/_index.adoc b/documentation/content/en/books/handbook/filesystems/_index.adoc index 5e15895838..85652391bc 100644 --- a/documentation/content/en/books/handbook/filesystems/_index.adoc +++ b/documentation/content/en/books/handbook/filesystems/_index.adoc @@ -1,236 +1,236 @@ --- title: Chapter 23. Other File Systems part: Part III. System Administration prev: books/handbook/zfs next: books/handbook/virtualization description: This chapter shows the other filesystems supported by FreeBSD tags: ["filesystem", "ext2", "ext3", "ext4", "ext2fs", "FAT", "exFAT", "NTFS", "HFS", "HFS+", "Apple", "Microsoft", "Linux"] showBookMenu: true weight: 27 params: path: "/books/handbook/filesystems/" --- [[filesystems]] = Other File Systems :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 23 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/filesystems/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[filesystems-synopsis]] == Synopsis File systems are a fundamental component of any operating system. They enable users to store, manage, and access data, making storage devices like hard drives, flash drives, and USB storage devices practical for everyday use. Different operating systems use different file systems natively. FreeBSD has traditionally used the Unix File System (UFS), with the modernized UFS2 as its primary native file system. FreeBSD also uses the Z File System (ZFS), known for its advanced features, robustness, and reliability. See crossref:zfs[zfs,The Z File System (ZFS)] for more details. In addition to its native file systems, FreeBSD supports a broad range of file systems from other operating systems. Support for these file systems varies, some require loading kernel modules, while others need additional userland tools. -Before reading this chapter, you should: +Before reading this chapter: * Be familiar with UNIX(R) concepts and crossref:basics[basics,FreeBSD basics]. * Feel comfortable crossref:ports[ports,installing software] in FreeBSD. * Have some understanding of crossref:disks[disks,disks], storage devices, and FreeBSD's naming conventions for devices. -After reading this chapter, you will: +Read this chapter to: * Understand the differences between native and supported file systems. * Know which file systems are supported by FreeBSD and the level of support available. * Learn how to enable, configure, access, and work with non-native file systems. [[filesystems-linux]] == Linux(R) File Systems FreeBSD provides built-in support for several Linux(R) file systems. This section demonstrates how to load support for and how to mount the supported Linux(R) file systems. [[ext]] === Extended File System (EXT) Kernel support for Extended File System (EXT) file systems has been available since FreeBSD 2.2. The man:ext2fs[5] driver allows the FreeBSD kernel to both read and write to ext2, ext3, and ext4 file systems. [WARNING] ==== Journalling and encryption are not supported yet. ==== To access an ext file system, mount the ext volume by specifying its FreeBSD partition name and an existing mount point. This example mounts [.filename]#/dev/ada1s1# on [.filename]#/mnt#: [source,shell] .... # mount -t ext2fs /dev/ada1s1 /mnt .... [[filesystems-windows]] == Windows(R) File Systems FreeBSD supports FAT, exFAT, and NTFS file systems, enabling access to Windows-formatted storage. [[fat]] === FAT File System The FAT file system is a simple and robust file system. Although it lacks the performance, reliability, and scalability of modern alternatives, its availability on many different operating systems makes it a common choice for data exchange between devices. To access a FAT file system, mount the FAT volume by specifying its FreeBSD partition name and an existing mount point. This example mounts [.filename]#/dev/ada0s1# on [.filename]#/mnt#: [source,shell] .... # mount -t msdosfs /dev/ada0s1 /mnt .... [[ex-fat]] === exFAT File System exFAT (Extended File Allocation Table) is a lightweight file system optimized for flash storage devices, such as USB drives and SD cards. It supports large file sizes and is widely used across various platforms, making it ideal for external storage. To use exFAT on FreeBSD, install the package:filesystems/exfat[] package, load the FUSE kernel module, and mount the file system as shown below: Install the exFAT package: [source,shell] .... # pkg install exfat .... Before using a FUSE file system, load the man:fusefs[5] kernel module: [source,shell] .... # kldload fusefs .... Use man:sysrc[8] to load the module at startup: [source,shell] .... # sysrc kld_list+=fusefs .... Mount the exFAT volumne by specifying its FreeBSD partition name and an existing mount point. This example mounts [.filename]#/dev/ada0s1# on [.filename]#/mnt#: [source,shell] .... # mount.exfat /dev/ada0s1 /mnt .... [[using-ntfs]] === NTFS File System NTFS is a robust file system developed by Microsoft(R) and commonly used in Windows operating systems. FreeBSD provides full read and write support for NTFS through the package:filesystems/ntfs[] package, making it easy to access and modify NTFS-formatted storage devices. To use NTFS on FreeBSD, install the package:filesystems/ntfs[] package, load the FUSE kernel module, and mount the file system as shown below: Install the NTFS package: [source,shell] .... # pkg install ntfs .... Before using a FUSE file system, load the man:fusefs[5] kernel module: [source,shell] .... # kldload fusefs .... Use man:sysrc[8] to load the module at startup: [source,shell] .... # sysrc kld_list+=fusefs .... Mount the NTFS volumne by specifying its FreeBSD partition name and an existing mount point. This example mounts [.filename]#/dev/ada0s1# on [.filename]#/mnt#: [source,shell] .... # ntfs-3g /dev/ada0s1 /mnt .... [[filesystems-macos]] == MacOS(R) File Systems FreeBSD provides support for MacOS(R) file systems, including HFS/HFS+, allowing access to storage devices formatted for Apple(R) systems. [[hfs]] === HFS/HFS+ File System HFS/HFS+ was the primary file system for MacOS prior to APFS, commonly used on older Mac devices and external drives. FreeBSD provides read-only support for HFS/HFS+ through the package:filesystems/hfsfuse[] package. To use HFS/HFS+ on FreeBSD, install the package:filesystems/hfsfuse[] package, load the FUSE kernel module, and mount the file system as shown below: Install the HFS/HFS+ package: [source,shell] .... # pkg install fusefs-hfsfuse .... Before using a FUSE file system, load the man:fusefs[5] kernel module: [source,shell] .... # kldload fusefs .... Use man:sysrc[8] to load the module at startup: [source,shell] .... # sysrc kld_list+=fusefs .... Mount the HFS/HFS+ volumne by specifying its FreeBSD partition name and an existing mount point. This example mounts [.filename]#/dev/ada0s1# on [.filename]#/mnt#: [source,shell] .... # hfsfuse /dev/ada0s1 /mnt .... diff --git a/documentation/content/en/books/handbook/firewalls/_index.adoc b/documentation/content/en/books/handbook/firewalls/_index.adoc index 00e7f7688d..399eb35317 100644 --- a/documentation/content/en/books/handbook/firewalls/_index.adoc +++ b/documentation/content/en/books/handbook/firewalls/_index.adoc @@ -1,2692 +1,2692 @@ --- title: Chapter 33. Firewalls part: IV. Network Communication prev: books/handbook/network-servers next: books/handbook/advanced-networking description: "FreeBSD has three firewalls built into the base system: PF, IPFW, and IPFILTER. This chapter covers how to define packet filtering rules, the differences between the firewalls built into FreeBSD and how to use them" tags: ["firewall", "pf", "ipfw", "ipfilter", "blacklistd", "filtering"] showBookMenu: true weight: 38 params: path: "/books/handbook/firewalls/" --- [[firewalls]] = Firewalls :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 33 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/firewalls/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[firewalls-intro]] == Synopsis Firewalls make it possible to filter the incoming and outgoing traffic that flows through a system. A firewall can use one or more sets of "rules" to inspect network packets as they come in or go out of network connections and either allows the traffic through or blocks it. The rules of a firewall can inspect one or more characteristics of the packets such as the protocol type, source or destination host address, and source or destination port. Firewalls can enhance the security of a host or a network. They can be used to do one or more of the following: * Protect and insulate the applications, services, and machines of an internal network from unwanted traffic from the public Internet. * Limit or disable access from hosts of the internal network to services of the public Internet. * Support network address translation (NAT), which allows an internal network to use private IP addresses and share a single connection to the public Internet using either a single IP address or a shared pool of automatically assigned public addresses. FreeBSD has three firewalls built into the base system: PF, IPFW, and IPFILTER, also known as IPF. FreeBSD also provides two traffic shapers for controlling bandwidth usage: man:altq[4] and man:dummynet[4]. ALTQ has traditionally been closely tied with PF and dummynet with IPFW. Each firewall uses rules to control the access of packets to and from a FreeBSD system, although they go about it in different ways and each has a different rule syntax. FreeBSD provides multiple firewalls in order to meet the different requirements and preferences for a wide variety of users. Each user should evaluate which firewall best meets their needs. -After reading this chapter, you will know: +Read this chapter to learn: * How to define packet filtering rules. * The differences between the firewalls built into FreeBSD. * How to use and configure the PF firewall. * How to use and configure the IPFW firewall. * How to use and configure the IPFILTER firewall. -Before reading this chapter, you should: +Before reading this chapter: * Understand basic FreeBSD and Internet concepts. [NOTE] ==== Since all firewalls are based on inspecting the values of selected packet control fields, the creator of the firewall ruleset must have an understanding of how TCP/IP works, what the different values in the packet control fields are, and how these values are used in a normal session conversation. For a good introduction, refer to http://www.ipprimer.com[Daryl's TCP/IP Primer]. ==== [[firewalls-concepts]] == Firewall Concepts A ruleset contains a group of rules which pass or block packets based on the values contained in the packet. The bi-directional exchange of packets between hosts comprises a session conversation. The firewall ruleset processes both the packets arriving from the public Internet, as well as the packets produced by the system as a response to them. Each TCP/IP service is predefined by its protocol and listening port. Packets destined for a specific service originate from the source address using an unprivileged port and target the specific service port on the destination address. All the above parameters can be used as selection criteria to create rules which will pass or block services. To lookup unknown port numbers, refer to [.filename]#/etc/services#. Alternatively, visit https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers[https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers] and do a port number lookup to find the purpose of a particular port number. Check out this link for http://web.archive.org/web/20150803024617/http://www.sans.org/security-resources/idfaq/oddports.php[port numbers used by Trojans]. FTP has two modes: active mode and passive mode. The difference is in how the data channel is acquired. Passive mode is more secure as the data channel is acquired by the ordinal ftp session requester. For a good explanation of FTP and the different modes, see http://www.slacksite.com/other/ftp.html[http://www.slacksite.com/other/ftp.html]. A firewall ruleset can be either "exclusive" or "inclusive". An exclusive firewall allows all traffic through except for the traffic matching the ruleset. An inclusive firewall does the reverse as it only allows traffic matching the rules through and blocks everything else. An inclusive firewall offers better control of the outgoing traffic, making it a better choice for systems that offer services to the public Internet. It also controls the type of traffic originating from the public Internet that can gain access to a private network. All traffic that does not match the rules is blocked and logged. Inclusive firewalls are generally safer than exclusive firewalls because they significantly reduce the risk of allowing unwanted traffic. [NOTE] ==== Unless noted otherwise, all configuration and example rulesets in this chapter create inclusive firewall rulesets. ==== Security can be tightened further using a "stateful firewall". This type of firewall keeps track of open connections and only allows traffic which either matches an existing connection or opens a new, allowed connection. Stateful filtering treats traffic as a bi-directional exchange of packets comprising a session. When state is specified on a matching rule the firewall dynamically generates internal rules for each anticipated packet being exchanged during the session. It has sufficient matching capabilities to determine if a packet is valid for a session. Any packets that do not properly fit the session template are automatically rejected. When the session completes, it is removed from the dynamic state table. Stateful filtering allows one to focus on blocking/passing new sessions. If the new session is passed, all its subsequent packets are allowed automatically and any impostor packets are automatically rejected. If a new session is blocked, none of its subsequent packets are allowed. Stateful filtering provides advanced matching abilities capable of defending against the flood of different attack methods employed by attackers. NAT stands for _Network Address Translation_. NAT function enables the private LAN behind the firewall to share a single ISP-assigned IP address, even if that address is dynamically assigned. NAT allows each computer in the LAN to have Internet access, without having to pay the ISP for multiple Internet accounts or IP addresses. NAT will automatically translate the private LAN IP address for each system on the LAN to the single public IP address as packets exit the firewall bound for the public Internet. It also performs the reverse translation for returning packets. According to RFC 1918, the following IP address ranges are reserved for private networks which will never be routed directly to the public Internet, and therefore are available for use with NAT: * `10.0.0.0/8`. * `172.16.0.0/12`. * `192.168.0.0/16`. [WARNING] ==== When working with the firewall rules, be _very careful_. Some configurations _can lock the administrator out_ of the server. To be on the safe side, consider performing the initial firewall configuration from the local console rather than doing it remotely over ssh. ==== [[firewalls-pf]] == PF Since FreeBSD 5.3, a ported version of OpenBSD's PF firewall has been included as an integrated part of the base system. PF is a complete, full-featured firewall that has optional support for ALTQ (Alternate Queuing), which provides Quality of Service (QoS). The OpenBSD Project maintains the definitive reference for PF in the http://www.openbsd.org/faq/pf/[PF FAQ]. Peter Hansteen maintains a thorough PF tutorial at http://home.nuug.no/\~peter/pf/[http://home.nuug.no/~peter/pf/]. [WARNING] ==== When reading the http://www.openbsd.org/faq/pf/[PF FAQ], keep in mind that FreeBSD's version of PF has diverged substantially from the upstream OpenBSD version over the years. Not all features work the same way on FreeBSD as they do in OpenBSD and vice versa. ==== The {freebsd-pf} is a good place to ask questions about configuring and running the PF firewall. Check the mailing list archives before asking a question as it may have already been answered. This section of the Handbook focuses on PF as it pertains to FreeBSD. It demonstrates how to enable PF and ALTQ. It also provides several examples for creating rulesets on a FreeBSD system. === Enabling PF To use PF, its kernel module must be first loaded. This section describes the entries that can be added to [.filename]#/etc/rc.conf# to enable PF. Start by adding `pf_enable=yes` to [.filename]#/etc/rc.conf#: [source,shell] .... # sysrc pf_enable=yes .... Additional options, described in man:pfctl[8], can be passed to PF when it is started. Add or change this entry in [.filename]#/etc/rc.conf# and specify any required flags between the two quotes (`""`): [.programlisting] .... pf_flags="" # additional flags for pfctl startup .... PF will not start if it cannot find its ruleset configuration file. By default, FreeBSD does not ship with a ruleset and there is no [.filename]#/etc/pf.conf#. Example rulesets can be found in [.filename]#/usr/share/examples/pf/#. If a custom ruleset has been saved somewhere else, add a line to [.filename]#/etc/rc.conf# which specifies the full path to the file: [.programlisting] .... pf_rules="/path/to/pf.conf" .... Logging support for PF is provided by man:pflog[4]. To enable logging support, add `pflog_enable=yes` to [.filename]#/etc/rc.conf#: [source,shell] .... # sysrc pflog_enable=yes .... The following lines can also be added to change the default location of the log file or to specify any additional flags to pass to man:pflog[4] when it is started: [.programlisting] .... pflog_logfile="/var/log/pflog" # where pflogd should store the logfile pflog_flags="" # additional flags for pflogd startup .... Finally, if there is a LAN behind the firewall and packets need to be forwarded for the computers on the LAN, or NAT is required, enable the following option: [.programlisting] .... gateway_enable="YES" # Enable as LAN gateway .... After saving the needed edits, PF can be started with logging support by typing: [source,shell] .... # service pf start # service pflog start .... By default, PF reads its configuration rules from [.filename]#/etc/pf.conf# and modifies, drops, or passes packets according to the rules or definitions specified in this file. The FreeBSD installation includes several sample files located in [.filename]#/usr/share/examples/pf/#. Refer to the http://www.openbsd.org/faq/pf/[PF FAQ] for complete coverage of PF rulesets. To control PF, use `pfctl`. crossref:firewalls[pfctl,Useful `pfctl` Options] summarizes some useful options to this command. Refer to man:pfctl[8] for a description of all available options: [[pfctl]] .Useful `pfctl` Options [cols="1,1", frame="none", options="header"] |=== | Command | Purpose |`pfctl -e` |Enable PF. |`pfctl -d` |Disable PF. |`pfctl -F all -f /etc/pf.conf` |Flush all NAT, filter, state, and table rules and reload [.filename]#/etc/pf.conf#. |`pfctl -s [ rules \| nat \| states ]` |Report on the filter rules, NAT rules, or state table. |`pfctl -vnf /etc/pf.conf` |Check [.filename]#/etc/pf.conf# for errors, but do not load ruleset. |=== [TIP] ==== package:security/sudo[] is useful for running commands like `pfctl` that require elevated privileges. It can be installed from the Ports Collection. ==== To keep an eye on the traffic that passes through the PF firewall, consider installing the package:sysutils/pftop[] package or port. Once installed, pftop can be run to view a running snapshot of traffic in a format which is similar to man:top[1]. [[pf-tutorial]] === PF Rulesets This section demonstrates how to create a customized ruleset. It starts with the simplest of rulesets and builds upon its concepts using several examples to demonstrate real-world usage of PF's many features. The simplest possible ruleset is for a single machine that does not run any services and which needs access to one network, which may be the Internet. To create this minimal ruleset, edit [.filename]#/etc/pf.conf# so it looks like this: [.programlisting] .... block in all pass out all keep state .... The first rule denies all incoming traffic by default. The second rule allows connections created by this system to pass out, while retaining state information on those connections. This state information allows return traffic for those connections to pass back and should only be used on machines that can be trusted. The ruleset can be loaded with: [source,shell] .... # pfctl -e ; pfctl -f /etc/pf.conf .... In addition to keeping state, PF provides _lists_ and _macros_ which can be defined for use when creating rules. Macros can include lists and need to be defined before use. As an example, insert these lines at the very top of the ruleset: [.programlisting] .... tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }" udp_services = "{ domain }" .... PF understands port names as well as port numbers, as long as the names are listed in [.filename]#/etc/services#. This example creates two macros. The first is a list of seven TCP port names and the second is one UDP port name. Once defined, macros can be used in rules. In this example, all traffic is blocked except for the connections initiated by this system for the seven specified TCP services and the one specified UDP service: [.programlisting] .... tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }" udp_services = "{ domain }" block all pass out proto tcp to any port $tcp_services keep state pass proto udp to any port $udp_services keep state .... Even though UDP is considered to be a stateless protocol, PF is able to track some state information. For example, when a UDP request is passed which asks a name server about a domain name, PF will watch for the response to pass it back. Whenever an edit is made to a ruleset, the new rules must be loaded so they can be used: [source,shell] .... # pfctl -f /etc/pf.conf .... If there are no syntax errors, `pfctl` will not output any messages during the rule load. Rules can also be tested before attempting to load them: [source,shell] .... # pfctl -nf /etc/pf.conf .... Including `-n` causes the rules to be interpreted only, but not loaded. This provides an opportunity to correct any errors. At all times, the last valid ruleset loaded will be enforced until either PF is disabled or a new ruleset is loaded. [TIP] ==== Adding `-v` to a `pfctl` ruleset verify or load will display the fully parsed rules exactly the way they will be loaded. This is extremely useful when debugging rules. ==== [[pftut-gateway]] ==== A Simple Gateway with NAT This section demonstrates how to configure a FreeBSD system running PF to act as a gateway for at least one other machine. The gateway needs at least two network interfaces, each connected to a separate network. In this example, [.filename]#xl0# is connected to the Internet and [.filename]#xl1# is connected to the internal network. First, enable the gateway to let the machine forward the network traffic it receives on one interface to another interface. This sysctl setting will forward IPv4 packets: [source,shell] .... # sysctl net.inet.ip.forwarding=1 .... To forward IPv6 traffic, use: [source,shell] .... # sysctl net.inet6.ip6.forwarding=1 .... To enable these settings at system boot, use man:sysrc[8] to add them to [.filename]#/etc/rc.conf#: [source,shell] .... # sysrc gateway_enable=yes # sysrc ipv6_gateway_enable=yes .... Verify with `ifconfig` that both of the interfaces are up and running. Next, create the PF rules to allow the gateway to pass traffic. While the following rule allows stateful traffic from hosts of the internal network to pass to the gateway, the `to` keyword does not guarantee passage all the way from source to destination: [.programlisting] .... pass in on xl1 from xl1:network to xl0:network port $ports keep state .... That rule only lets the traffic pass in to the gateway on the internal interface. To let the packets go further, a matching rule is needed: [.programlisting] .... pass out on xl0 from xl1:network to xl0:network port $ports keep state .... While these two rules will work, rules this specific are rarely needed. For a busy network admin, a readable ruleset is a safer ruleset. The remainder of this section demonstrates how to keep the rules as simple as possible for readability. For example, those two rules could be replaced with one rule: [.programlisting] .... pass from xl1:network to any port $ports keep state .... The `interface:network` notation can be replaced with a macro to make the ruleset even more readable. For example, a `$localnet` macro could be defined as the network directly attached to the internal interface (`$xl1:network`). Alternatively, the definition of `$localnet` could be changed to an _IP address/netmask_ notation to denote a network, such as `192.168.100.1/24` for a subnet of private addresses. If required, `$localnet` could even be defined as a list of networks. Whatever the specific needs, a sensible `$localnet` definition could be used in a typical pass rule as follows: [.programlisting] .... pass from $localnet to any port $ports keep state .... The following sample ruleset allows all traffic initiated by machines on the internal network. It first defines two macros to represent the external and internal 3COM interfaces of the gateway. [NOTE] ==== For dialup users, the external interface will use [.filename]#tun0#. For an ADSL connection, specifically those using PPP over Ethernet (PPPoE), the correct external interface is [.filename]#tun0#, not the physical Ethernet interface. ==== [.programlisting] .... ext_if = "xl0" # macro for external interface - use tun0 for PPPoE int_if = "xl1" # macro for internal interface localnet = $int_if:network # ext_if IP address could be dynamic, hence ($ext_if) nat on $ext_if from $localnet to any -> ($ext_if) block all pass from { lo0, $localnet } to any keep state .... This ruleset introduces the `nat` rule which is used to handle the network address translation from the non-routable addresses inside the internal network to the IP address assigned to the external interface. The parentheses surrounding the last part of the nat rule `($ext_if)` is included when the IP address of the external interface is dynamically assigned. It ensures that network traffic runs without serious interruptions even if the external IP address changes. Note that this ruleset probably allows more traffic to pass out of the network than is needed. One reasonable setup could create this macro: [.programlisting] .... client_out = "{ ftp-data, ftp, ssh, domain, pop3, auth, nntp, http, \ https, cvspserver, 2628, 5999, 8000, 8080 }" .... to use in the main pass rule: [.programlisting] .... pass inet proto tcp from $localnet to any port $client_out \ flags S/SA keep state .... A few other pass rules may be needed. This one enables SSH on the external interface: [.programlisting] .... pass in inet proto tcp to $ext_if port ssh .... This macro definition and rule allows DNS and NTP for internal clients: [.programlisting] .... udp_services = "{ domain, ntp }" pass quick inet proto { tcp, udp } to any port $udp_services keep state .... Note the `quick` keyword in this rule. Since the ruleset consists of several rules, it is important to understand the relationships between the rules in a ruleset. Rules are evaluated from top to bottom, in the sequence they are written. For each packet or connection evaluated by PF, _the last matching rule_ in the ruleset is the one which is applied. However, when a packet matches a rule which contains the `quick` keyword, the rule processing stops and the packet is treated according to that rule. This is very useful when an exception to the general rules is needed. [[pftut-ftp]] ==== Creating an FTP Proxy Configuring working FTP rules can be problematic due to the nature of the FTP protocol. FTP pre-dates firewalls by several decades and is insecure in its design. The most common points against using FTP include: * Passwords are transferred in the clear. * The protocol demands the use of at least two TCP connections (control and data) on separate ports. * When a session is established, data is communicated using randomly selected ports. All of these points present security challenges, even before considering any potential security weaknesses in client or server software. More secure alternatives for file transfer exist, such as man:sftp[1] or man:scp[1], which both feature authentication and data transfer over encrypted connections. For those situations when FTP is required, PF provides redirection of FTP traffic to a small proxy program called man:ftp-proxy[8], which is included in the base system of FreeBSD. The role of the proxy is to dynamically insert and delete rules in the ruleset, using a set of anchors, to correctly handle FTP traffic. To enable the FTP proxy, add this line to [.filename]#/etc/rc.conf#: [.programlisting] .... ftpproxy_enable="YES" .... Then start the proxy by running: [source,bash] .... # service ftp-proxy start .... For a basic configuration, three elements need to be added to [.filename]#/etc/pf.conf#. First, the anchors which the proxy will use to insert the rules it generates for the FTP sessions: [.programlisting] .... nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*" .... Second, a pass rule is needed to allow FTP traffic in to the proxy. Third, redirection and NAT rules need to be defined before the filtering rules. Insert this `rdr` rule immediately after the `nat` rule: [.programlisting] .... rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021 .... Finally, allow the redirected traffic to pass: [.programlisting] .... pass out proto tcp from $proxy to any port ftp .... where `$proxy` expands to the address the proxy daemon is bound to. Save [.filename]#/etc/pf.conf#, load the new rules, and verify from a client that FTP connections are working: [source,shell] .... # pfctl -f /etc/pf.conf .... This example covers a basic setup where the clients in the local network need to contact FTP servers elsewhere. This basic configuration should work well with most combinations of FTP clients and servers. As shown in man:ftp-proxy[8], the proxy's behavior can be changed in various ways by adding options to the `ftpproxy_flags=` line. Some clients or servers may have specific quirks that must be compensated for in the configuration, or there may be a need to integrate the proxy in specific ways such as assigning FTP traffic to a specific queue. For ways to run an FTP server protected by PF and man:ftp-proxy[8], configure a separate `ftp-proxy` in reverse mode, using `-R`, on a separate port with its own redirecting pass rule. [[pftut-icmp]] ==== Managing ICMP Many of the tools used for debugging or troubleshooting a TCP/IP network rely on the Internet Control Message Protocol (ICMP), which was designed specifically with debugging in mind. The ICMP protocol sends and receives _control messages_ between hosts and gateways, mainly to provide feedback to a sender about any unusual or difficult conditions enroute to the target host. Routers use ICMP to negotiate packet sizes and other transmission parameters in a process often referred to as _path MTU discovery_. From a firewall perspective, some ICMP control messages are vulnerable to known attack vectors. Also, letting all diagnostic traffic pass unconditionally makes debugging easier, but it also makes it easier for others to extract information about the network. For these reasons, the following rule may not be optimal: [.programlisting] .... pass inet proto icmp from any to any .... One solution is to let all ICMP traffic from the local network through while stopping all probes from outside the network: [.programlisting] .... pass inet proto icmp from $localnet to any keep state pass inet proto icmp from any to $ext_if keep state .... Additional options are available which demonstrate some of PF's flexibility. For example, rather than allowing all ICMP messages, one can specify the messages used by man:ping[8] and man:traceroute[8]. Start by defining a macro for that type of message: [.programlisting] .... icmp_types = "echoreq" .... and a rule which uses the macro: [.programlisting] .... pass inet proto icmp all icmp-type $icmp_types keep state .... If other types of ICMP packets are needed, expand `icmp_types` to a list of those packet types. Type `more /usr/src/sbin/pfctl/pfctl_parser.c` to see the list of ICMP message types supported by PF. Refer to http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml[http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml] for an explanation of each message type. Since Unix `traceroute` uses UDP by default, another rule is needed to allow Unix `traceroute`: [.programlisting] .... # allow out the default range for traceroute(8): pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state .... Since `TRACERT.EXE` on Microsoft Windows systems uses ICMP echo request messages, only the first rule is needed to allow network traces from those systems. Unix `traceroute` can be instructed to use other protocols as well, and will use ICMP echo request messages if `-I` is used. Check the man:traceroute[8] man page for details. [[pftut-pathmtudisc]] ===== Path MTU Discovery Internet protocols are designed to be device independent, and one consequence of device independence is that the optimal packet size for a given connection cannot always be predicted reliably. The main constraint on packet size is the _Maximum Transmission Unit_ (MTU) which sets the upper limit on the packet size for an interface. Type `ifconfig` to view the MTUs for a system's network interfaces. TCP/IP uses a process known as path MTU discovery to determine the right packet size for a connection. This process sends packets of varying sizes with the "Do not fragment" flag set, expecting an ICMP return packet of "type 3, code 4" when the upper limit has been reached. Type 3 means "destination unreachable", and code 4 is short for "fragmentation needed, but the do-not-fragment flag is set". To allow path MTU discovery in order to support connections to other MTUs, add the `destination unreachable` type to the `icmp_types` macro: [.programlisting] .... icmp_types = "{ echoreq, unreach }" .... Since the pass rule already uses that macro, it does not need to be modified to support the new ICMP type: [.programlisting] .... pass inet proto icmp all icmp-type $icmp_types keep state .... PF allows filtering on all variations of ICMP types and codes. The list of possible types and codes are documented in man:icmp[4] and man:icmp6[4]. [[pftut-tables]] ==== Using Tables Some types of data are relevant to filtering and redirection at a given time, but their definition is too long to be included in the ruleset file. PF supports the use of tables, which are defined lists that can be manipulated without needing to reload the entire ruleset, and which can provide fast lookups. Table names are always enclosed within `< >`, like this: [.programlisting] .... table { 192.168.2.0/24, !192.168.2.5 } .... In this example, the `192.168.2.0/24` network is part of the table, except for the address `192.168.2.5`, which is excluded using the `!` operator. It is also possible to load tables from files where each item is on a separate line, as seen in this example [.filename]#/etc/clients#: [.programlisting] .... 192.168.2.0/24 !192.168.2.5 .... To refer to the file, define the table like this: [.programlisting] .... table persist file "/etc/clients" .... Once the table is defined, it can be referenced by a rule: [.programlisting] .... pass inet proto tcp from to any port $client_out flags S/SA keep state .... A table's contents can be manipulated live, using `pfctl`. This example adds another network to the table: [source,shell] .... # pfctl -t clients -T add 192.168.1.0/16 .... Note that any changes made this way will take affect now, making them ideal for testing, but will not survive a power failure or reboot. To make the changes permanent, modify the definition of the table in the ruleset or edit the file that the table refers to. One can maintain the on-disk copy of the table using a man:cron[8] job which dumps the table's contents to disk at regular intervals, using a command such as `pfctl -t clients -T show >/etc/clients`. Alternatively, [.filename]#/etc/clients# can be updated with the in-memory table contents: [source,shell] .... # pfctl -t clients -T replace -f /etc/clients .... [[pftut-overload]] ==== Using Overload Tables to Protect SSH Those who run SSH on an external interface have probably seen something like this in the authentication logs: [.programlisting] .... Sep 26 03:12:34 skapet sshd[25771]: Failed password for root from 200.72.41.31 port 40992 ssh2 Sep 26 03:12:34 skapet sshd[5279]: Failed password for root from 200.72.41.31 port 40992 ssh2 Sep 26 03:12:35 skapet sshd[5279]: Received disconnect from 200.72.41.31: 11: Bye Bye Sep 26 03:12:44 skapet sshd[29635]: Invalid user admin from 200.72.41.31 Sep 26 03:12:44 skapet sshd[24703]: input_userauth_request: invalid user admin Sep 26 03:12:44 skapet sshd[24703]: Failed password for invalid user admin from 200.72.41.31 port 41484 ssh2 .... This is indicative of a brute force attack where somebody or some program is trying to discover the user name and password which will let them into the system. If external SSH access is needed for legitimate users, changing the default port used by SSH can offer some protection. However, PF provides a more elegant solution. Pass rules can contain limits on what connecting hosts can do and violators can be banished to a table of addresses which are denied some or all access. It is even possible to drop all existing connections from machines which overreach the limits. To configure this, create this table in the tables section of the ruleset: [.programlisting] .... table persist .... Then, somewhere early in the ruleset, add rules to block brute access while allowing legitimate access: [.programlisting] .... block quick from pass inet proto tcp from any to $localnet port $tcp_services \ flags S/SA keep state \ (max-src-conn 100, max-src-conn-rate 15/5, \ overload flush global) .... The part in parentheses defines the limits and the numbers should be changed to meet local requirements. It can be read as follows: `max-src-conn` is the number of simultaneous connections allowed from one host. `max-src-conn-rate` is the rate of new connections allowed from any single host (_15_) per number of seconds (_5_). `overload ` means that any host which exceeds these limits gets its address added to the `bruteforce` table. The ruleset blocks all traffic from addresses in the `bruteforce` table. Finally, `flush global` says that when a host reaches the limit, that all (`global`) of that host's connections will be terminated (`flush`). [NOTE] ==== These rules will _not_ block slow bruteforcers, as described in http://home.nuug.no/\~peter/hailmary2013/[http://home.nuug.no/~peter/hailmary2013/]. ==== This example ruleset is intended mainly as an illustration. For example, if a generous number of connections in general are wanted, but the desire is to be more restrictive when it comes to ssh, supplement the rule above with something like the one below, early on in the rule set: [.programlisting] .... pass quick proto { tcp, udp } from any to any port ssh \ flags S/SA keep state \ (max-src-conn 15, max-src-conn-rate 5/3, \ overload flush global) .... [NOTE] ==== *It May Not be Necessary to Block All Overloaders:* + It is worth noting that the overload mechanism is a general technique which does not apply exclusively to SSH, and it is not always optimal to entirely block all traffic from offenders. For example, an overload rule could be used to protect a mail service or a web service, and the overload table could be used in a rule to assign offenders to a queue with a minimal bandwidth allocation or to redirect to a specific web page. ==== Over time, tables will be filled by overload rules and their size will grow incrementally, taking up more memory. Sometimes an IP address that is blocked is a dynamically assigned one, which has since been assigned to a host who has a legitimate reason to communicate with hosts in the local network. For situations like these, pfctl provides the ability to expire table entries. For example, this command will remove `` table entries which have not been referenced for `86400` seconds: [source,shell] .... # pfctl -t bruteforce -T expire 86400 .... Similar functionality is provided by package:security/expiretable[], which removes table entries which have not been accessed for a specified period of time. Once installed, expiretable can be run to remove `` table entries older than a specified age. This example removes all entries older than 24 hours: [.programlisting] .... /usr/local/sbin/expiretable -v -d -t 24h bruteforce .... [[pftut-spamd]] ==== Protecting Against SPAM Not to be confused with the spamd daemon which comes bundled with spamassassin, package:mail/spamd[] can be configured with PF to provide an outer defense against SPAM. This spamd hooks into the PF configuration using a set of redirections. Spammers tend to send a large number of messages, and SPAM is mainly sent from a few spammer friendly networks and a large number of hijacked machines, both of which are reported to _blocklists_ fairly quickly. When an SMTP connection from an address in a blocklist is received, spamd presents its banner and immediately switches to a mode where it answers SMTP traffic one byte at a time. This technique, which is intended to waste as much time as possible on the spammer's end, is called _tarpitting_. The specific implementation which uses one byte SMTP replies is often referred to as _stuttering_. This example demonstrates the basic procedure for setting up spamd with automatically updated blocklists. Refer to the man pages which are installed with package:mail/spamd[] for more information. [.procedure] **** .Procedure: Configuring spamd . Install the package:mail/spamd[] package or port. To use spamd's greylisting features, man:fdescfs[5] must be mounted at [.filename]#/dev/fd#. Add the following line to [.filename]#/etc/fstab#: + [.programlisting] .... fdescfs /dev/fd fdescfs rw 0 0 .... + Then, mount the filesystem: + [.programlisting] .... # mount fdescfs .... . Next, edit the PF ruleset to include: + [.programlisting] .... table persist table persist rdr pass on $ext_if inet proto tcp from to \ { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 rdr pass on $ext_if inet proto tcp from ! to \ { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 .... + The two tables `` and `` are essential. SMTP traffic from an address listed in `` but not in `` is redirected to the spamd daemon listening at port 8025. . The next step is to configure spamd in [.filename]#/usr/local/etc/spamd.conf# and to add some [.filename]#rc.conf# parameters. + The installation of package:mail/spamd[] includes a sample configuration file ([.filename]#/usr/local/etc/spamd.conf.sample#) and a man page for [.filename]#spamd.conf#. Refer to these for additional configuration options beyond those shown in this example. + One of the first lines in the configuration file that does not begin with a `+#+` comment sign contains the block which defines the `all` list, which specifies the lists to use: + [.programlisting] .... all:\ :traplist:allowlist: .... + This entry adds the desired blocklists, separated by colons (`:`). To use an allowlist to subtract addresses from a blocklist, add the name of the allowlist _immediately_ after the name of that blocklist. For example: `:blocklist:allowlist:`. + This is followed by the specified blocklist's definition: + [.programlisting] .... traplist:\ :black:\ :msg="SPAM. Your address %A has sent spam within the last 24 hours":\ :method=http:\ :file=www.openbsd.org/spamd/traplist.gz .... + where the first line is the name of the blocklist and the second line specifies the list type. The `msg` field contains the message to display to blocklisted senders during the SMTP dialogue. The `method` field specifies how spamd-setup fetches the list data; supported methods are `http`, `ftp`, from a `file` in a mounted file system, and via `exec` of an external program. Finally, the `file` field specifies the name of the file spamd expects to receive. + The definition of the specified allowlist is similar, but omits the `msg` field since a message is not needed: + [.programlisting] .... allowlist:\ :white:\ :method=file:\ :file=/var/mail/allowlist.txt .... + [TIP] ==== *Choose Data Sources with Care:* + Using all the blocklists in the sample [.filename]#spamd.conf# will block large blocks of the Internet. Administrators need to edit the file to create an optimal configuration which uses applicable data sources and, when necessary, uses custom lists. ==== + Next, add this entry to [.filename]#/etc/rc.conf#. Additional flags are described in the man page specified by the comment: + [.programlisting] .... spamd_flags="-v" # use "" and see spamd-setup(8) for flags .... + When finished, reload the ruleset, start spamd by typing `service obspamd start`, and complete the configuration using `spamd-setup`. Finally, create a man:cron[8] job which calls `spamd-setup` to update the tables at reasonable intervals. **** On a typical gateway in front of a mail server, hosts will soon start getting trapped within a few seconds to several minutes. PF also supports _greylisting_, which temporarily rejects messages from unknown hosts with _45n_ codes. Messages from greylisted hosts which try again within a reasonable time are let through. Traffic from senders which are set up to behave within the limits set by RFC 1123 and RFC 2821 are immediately let through. More information about greylisting as a technique can be found at the http://www.greylisting.org/[greylisting.org] web site. The most amazing thing about greylisting, apart from its simplicity, is that it still works. Spammers and malware writers have been very slow to adapt to bypass this technique. The basic procedure for configuring greylisting is as follows: [.procedure] .Procedure: Configuring Greylisting . Make sure that man:fdescfs[5] is mounted as described in Step 1 of the previous Procedure. . To run spamd in greylisting mode, add this line to [.filename]#/etc/rc.conf#: + [.programlisting] .... spamd_grey="YES" # use spamd greylisting if YES .... + Refer to the spamd man page for descriptions of additional related parameters. . To complete the greylisting setup: + [.programlisting] .... # service obspamd restart # service obspamlogd start .... Behind the scenes, the spamdb database tool and the spamlogd whitelist updater perform essential functions for the greylisting feature. spamdb is the administrator's main interface to managing the block, grey, and allow lists via the contents of the [.filename]#/var/db/spamdb# database. [[pftut-hygiene]] ==== Network Hygiene This section describes how `block-policy`, `scrub`, and `antispoof` can be used to make the ruleset behave sanely. The `block-policy` is an option which can be set in the `options` part of the ruleset, which precedes the redirection and filtering rules. This option determines which feedback, if any, PF sends to hosts that are blocked by a rule. The option has two possible values: `drop` drops blocked packets with no feedback, and `return` returns a status code such as `Connection refused`. If not set, the default policy is `drop`. To change the `block-policy`, specify the desired value: [.programlisting] .... set block-policy return .... In PF, `scrub` is a keyword which enables network packet normalization. This process reassembles fragmented packets and drops TCP packets that have invalid flag combinations. Enabling `scrub` provides a measure of protection against certain kinds of attacks based on incorrect handling of packet fragments. A number of options are available, but the simplest form is suitable for most configurations: [.programlisting] .... scrub in all .... Some services, such as NFS, require specific fragment handling options. Refer to https://home.nuug.no/\~peter/pf/en/scrub.html[https://home.nuug.no/~peter/pf/en/scrub.html] for more information. This example reassembles fragments, clears the "do not fragment" bit, and sets the maximum segment size to 1440 bytes: [.programlisting] .... scrub in all fragment reassemble no-df max-mss 1440 .... The `antispoof` mechanism protects against activity from spoofed or forged IP addresses, mainly by blocking packets appearing on interfaces and in directions which are logically not possible. These rules weed out spoofed traffic coming in from the rest of the world as well as any spoofed packets which originate in the local network: [.programlisting] .... antispoof for $ext_if antispoof for $int_if .... [[pftut-unrouteables]] ==== Handling Non-Routable Addresses Even with a properly configured gateway to handle network address translation, one may have to compensate for other people's misconfigurations. A common misconfiguration is to let traffic with non-routable addresses out to the Internet. Since traffic from non-routeable addresses can play a part in several DoS attack techniques, consider explicitly blocking traffic from non-routeable addresses from entering the network through the external interface. In this example, a macro containing non-routable addresses is defined, then used in blocking rules. Traffic to and from these addresses is quietly dropped on the gateway's external interface. [.programlisting] .... martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \ 10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, \ 0.0.0.0/8, 240.0.0.0/4 }" block drop in quick on $ext_if from $martians to any block drop out quick on $ext_if from any to $martians .... === Enabling ALTQ On FreeBSD, ALTQ can be used with PF to provide Quality of Service (QOS). Once ALTQ is enabled, queues can be defined in the ruleset which determine the processing priority of outbound packets. Before enabling ALTQ, refer to man:altq[4] to determine if the drivers for the network cards installed on the system support it. ALTQ is not available as a loadable kernel module. If the system's interfaces support ALTQ, create a custom kernel using the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]. The following kernel options are available. The first is needed to enable ALTQ. At least one of the other options is necessary to specify the queueing scheduler algorithm: [.programlisting] .... options ALTQ options ALTQ_CBQ # Class Based Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) .... The following scheduler algorithms are available: CBQ:: Class Based Queuing (CBQ) is used to divide a connection's bandwidth into different classes or queues to prioritize traffic based on filter rules. RED:: Random Early Detection (RED) is used to avoid network congestion by measuring the length of the queue and comparing it to the minimum and maximum thresholds for the queue. When the queue is over the maximum, all new packets are randomly dropped. RIO:: In Random Early Detection In and Out (RIO) mode, RED maintains multiple average queue lengths and multiple threshold values, one for each QOS level. HFSC:: Hierarchical Fair Service Curve Packet Scheduler (HFSC) is described in http://www-2.cs.cmu.edu/\~hzhang/HFSC/main.html[http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html]. PRIQ:: Priority Queuing (PRIQ) always passes traffic that is in a higher queue first. More information about the scheduling algorithms and example rulesets are available at the https://web.archive.org/web/20151109213426/http://www.openbsd.org/faq/pf/queueing.html[OpenBSD's web archive]. [[firewalls-ipfw]] == IPFW IPFW is a stateful firewall written for FreeBSD which supports both IPv4 and IPv6. It is comprised of several components: the kernel firewall filter rule processor and its integrated packet accounting facility, the logging facility, NAT, the man:dummynet[4] traffic shaper, a forward facility, a bridge facility, and an ipstealth facility. FreeBSD provides a sample ruleset in [.filename]#/etc/rc.firewall# which defines several firewall types for common scenarios to assist novice users in generating an appropriate ruleset. IPFW provides a powerful syntax which advanced users can use to craft customized rulesets that meet the security requirements of a given environment. This section describes how to enable IPFW, provides an overview of its rule syntax, and demonstrates several rulesets for common configuration scenarios. [[firewalls-ipfw-enable]] === Enabling IPFW IPFW is included in the basic FreeBSD install as a kernel loadable module, meaning that a custom kernel is not needed in order to enable IPFW. For those users who wish to statically compile IPFW support into a custom kernel, see crossref:firewalls[firewalls-ipfw-kernelconfig, IPFW Kernel Options]. To configure the system to enable IPFW at boot time, add `firewall_enable="YES"` to [.filename]#/etc/rc.conf#: [source,shell] .... # sysrc firewall_enable="YES" .... To use one of the default firewall types provided by FreeBSD, add another line which specifies the type: [source,shell] .... # sysrc firewall_type="open" .... The available types are: * `open`: passes all traffic. * `client`: protects only this machine. * `simple`: protects the whole network. * `closed`: entirely disables IP traffic except for the loopback interface. * `workstation`: protects only this machine using stateful rules. * `UNKNOWN`: disables the loading of firewall rules. * [.filename]#filename#: full path of the file containing the firewall ruleset. If `firewall_type` is set to either `client` or `simple`, modify the default rules found in [.filename]#/etc/rc.firewall# to fit the configuration of the system. Note that the `filename` type is used to load a custom ruleset. An alternate way to load a custom ruleset is to set the `firewall_script` variable to the absolute path of an _executable script_ that includes IPFW commands. The examples used in this section assume that the `firewall_script` is set to [.filename]#/etc/ipfw.rules#: [source,shell] .... # sysrc firewall_script="/etc/ipfw.rules" .... To enable logging through man:syslogd[8], include this line: [source,shell] .... # sysrc firewall_logging="YES" .... [WARNING] ==== Only firewall rules with the `log` option will be logged. The default rules do not include this option and it must be manually added. Therefore it is advisable that the default ruleset is edited for logging. In addition, log rotation may be desired if the logs are stored in a separate file. ==== There is no [.filename]#/etc/rc.conf# variable to set logging limits. To limit the number of times a rule is logged per connection attempt, specify the number using this line in [.filename]#/etc/sysctl.conf#: [source,shell] .... # echo "net.inet.ip.fw.verbose_limit=5" >> /etc/sysctl.conf .... To enable logging through a dedicated interface named `ipfw0`, add this line to [.filename]#/etc/rc.conf# instead: [source,shell] .... # sysrc firewall_logif="YES" .... Then use tcpdump to see what is being logged: [source,shell] .... # tcpdump -t -n -i ipfw0 .... [TIP] ==== There is no overhead due to logging unless tcpdump is attached. ==== After saving the needed edits, start the firewall. To enable logging limits now, also set the `sysctl` value specified above: [source,shell] .... # service ipfw start # sysctl net.inet.ip.fw.verbose_limit=5 .... [[firewalls-ipfw-rules]] === IPFW Rule Syntax When a packet enters the IPFW firewall, it is compared against the first rule in the ruleset and progresses one rule at a time, moving from top to bottom in sequence. When the packet matches the selection parameters of a rule, the rule's action is executed and the search of the ruleset terminates for that packet. This is referred to as "first match wins". If the packet does not match any of the rules, it gets caught by the mandatory IPFW default rule number 65535, which denies all packets and silently discards them. However, if the packet matches a rule that contains the `count`, `skipto`, or `tee` keywords, the search continues. Refer to man:ipfw[8] for details on how these keywords affect rule processing. When creating an IPFW rule, keywords must be written in the following order. Some keywords are mandatory while other keywords are optional. The words shown in uppercase represent a variable and the words shown in lowercase must precede the variable that follows it. The `+#+` symbol is used to mark the start of a comment and may appear at the end of a rule or on its own line. Blank lines are ignored. `_CMD RULE_NUMBER set SET_NUMBER ACTION log LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT OPTIONS_` This section provides an overview of these keywords and their options. It is not an exhaustive list of every possible option. Refer to man:ipfw[8] for a complete description of the rule syntax that can be used when creating IPFW rules. CMD:: Every rule must start with `ipfw add`. RULE_NUMBER:: Each rule is associated with a number from `1` to `65534`. The number is used to indicate the order of rule processing. Multiple rules can have the same number, in which case they are applied according to the order in which they have been added. SET_NUMBER:: Each rule is associated with a set number from `0` to `31`. Sets can be individually disabled or enabled, making it possible to quickly add or delete a set of rules. If a SET_NUMBER is not specified, the rule will be added to set `0`. ACTION:: A rule can be associated with one of the following actions. The specified action will be executed when the packet matches the selection criterion of the rule. + `allow | accept | pass | permit`: these keywords are equivalent and allow packets that match the rule. + `check-state`: checks the packet against the dynamic state table. If a match is found, execute the action associated with the rule which generated this dynamic rule, otherwise move to the next rule. A `check-state` rule does not have selection criterion. If no `check-state` rule is present in the ruleset, the dynamic rules table is checked at the first `keep-state` or `limit` rule. + `count`: updates counters for all packets that match the rule. The search continues with the next rule. + `deny | drop`: either word silently discards packets that match this rule. + Additional actions are available. Refer to man:ipfw[8] for details. LOG_AMOUNT:: When a packet matches a rule with the `log` keyword, a message will be logged to man:syslogd[8] with a facility name of `SECURITY`. Logging only occurs if the number of packets logged for that particular rule does not exceed a specified LOG_AMOUNT. If no LOG_AMOUNT is specified, the limit is taken from the value of `net.inet.ip.fw.verbose_limit`. A value of zero removes the logging limit. Once the limit is reached, logging can be re-enabled by clearing the logging counter or the packet counter for that rule, using `ipfw resetlog`. + [NOTE] ==== Logging is done after all other packet matching conditions have been met, and before performing the final action on the packet. The administrator decides which rules to enable logging on. ==== PROTO:: This optional value can be used to specify any protocol name or number found in [.filename]#/etc/protocols#. SRC:: The `from` keyword must be followed by the source address or a keyword that represents the source address. An address can be represented by `any`, `me` (any address configured on an interface on this system), `me6`, (any IPv6 address configured on an interface on this system), or `table` followed by the number of a lookup table which contains a list of addresses. When specifying an IP address, it can be optionally followed by its CIDR mask or subnet mask. For example, `1.2.3.4/25` or `1.2.3.4:255.255.255.128`. SRC_PORT:: An optional source port can be specified using the port number or name from [.filename]#/etc/services#. DST:: The `to` keyword must be followed by the destination address or a keyword that represents the destination address. The same keywords and addresses described in the SRC section can be used to describe the destination. DST_PORT:: An optional destination port can be specified using the port number or name from [.filename]#/etc/services#. OPTIONS:: Several keywords can follow the source and destination. As the name suggests, OPTIONS are optional. Commonly used options include `in` or `out`, which specify the direction of packet flow, `icmptypes` followed by the type of ICMP message, and `keep-state`. + When a `keep-state` rule is matched, the firewall will create a dynamic rule which matches bidirectional traffic between the source and destination addresses and ports using the same protocol. + The dynamic rules facility is vulnerable to resource depletion from a SYN-flood attack which would open a huge number of dynamic rules. To counter this type of attack with IPFW, use `limit`. This option limits the number of simultaneous sessions by checking the open dynamic rules, counting the number of times this rule and IP address combination occurred. If this count is greater than the value specified by `limit`, the packet is discarded. + Dozens of OPTIONS are available. Refer to man:ipfw[8] for a description of each available option. === Example Ruleset This section demonstrates how to create an example stateful firewall ruleset script named [.filename]#/etc/ipfw.rules#. In this example, all connection rules use `in` or `out` to clarify the direction. They also use `via` _interface-name_ to specify the interface the packet is traveling over. [NOTE] ==== When first creating or testing a firewall ruleset, consider temporarily setting this tunable: [.programlisting] .... net.inet.ip.fw.default_to_accept="1" .... This sets the default policy of man:ipfw[8] to be more permissive than the default `deny ip from any to any`, making it slightly more difficult to get locked out of the system right after a reboot. ==== The firewall script begins by indicating that it is a Bourne shell script and flushes any existing rules. It then creates the `cmd` variable so that `ipfw add` does not have to be typed at the beginning of every rule. It also defines the `pif` variable which represents the name of the interface that is attached to the Internet. [.programlisting] .... #!/bin/sh # Flush out the list before we begin. ipfw -q -f flush # Set rules command prefix cmd="ipfw -q add" pif="dc0" # interface name of NIC attached to Internet .... The first two rules allow all traffic on the trusted internal interface and on the loopback interface: [.programlisting] .... # Change xl0 to LAN NIC interface name $cmd 00005 allow all from any to any via xl0 # No restrictions on Loopback Interface $cmd 00010 allow all from any to any via lo0 .... The next rule allows the packet through if it matches an existing entry in the dynamic rules table: [.programlisting] .... $cmd 00101 check-state .... The next set of rules defines which stateful connections internal systems can create to hosts on the Internet: [.programlisting] .... # Allow access to public DNS # Replace x.x.x.x with the IP address of a public DNS server # and repeat for each DNS server in /etc/resolv.conf $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state $cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state # Allow access to ISP's DHCP server for cable/DSL configurations. # Use the first rule and check log for IP address. # Then, uncomment the second rule, input the IP address, and delete the first rule $cmd 00120 allow log udp from any to any 67 out via $pif keep-state #$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state # Allow outbound HTTP and HTTPS connections $cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state $cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state # Allow outbound email connections $cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state $cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state # Allow outbound ping $cmd 00250 allow icmp from any to any out via $pif keep-state # Allow outbound NTP $cmd 00260 allow udp from any to any 123 out via $pif keep-state # Allow outbound SSH $cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state # deny and log all other outbound connections $cmd 00299 deny log all from any to any out via $pif .... The next set of rules controls connections from Internet hosts to the internal network. It starts by denying packets typically associated with attacks and then explicitly allows specific types of connections. All the authorized services that originate from the Internet use `limit` to prevent flooding. [.programlisting] .... # Deny all inbound traffic from non-routable reserved address spaces $cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP $cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP $cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP $cmd 00303 deny all from 127.0.0.0/8 to any in via $pif #loopback $cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #loopback $cmd 00305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config $cmd 00306 deny all from 192.0.2.0/24 to any in via $pif #reserved for docs $cmd 00307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster interconnect $cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast # Deny public pings $cmd 00310 deny icmp from any to any in via $pif # Deny ident $cmd 00315 deny tcp from any to any 113 in via $pif # Deny all Netbios services. $cmd 00320 deny tcp from any to any 137 in via $pif $cmd 00321 deny tcp from any to any 138 in via $pif $cmd 00322 deny tcp from any to any 139 in via $pif $cmd 00323 deny tcp from any to any 81 in via $pif # Deny fragments $cmd 00330 deny all from any to any frag in via $pif # Deny ACK packets that did not match the dynamic rule table $cmd 00332 deny tcp from any to any established in via $pif # Allow traffic from ISP's DHCP server. # Replace x.x.x.x with the same IP address used in rule 00120. #$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state # Allow HTTP connections to internal web server $cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Allow inbound SSH connections $cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Reject and log all other incoming connections $cmd 00499 deny log all from any to any in via $pif .... The last rule logs all packets that do not match any of the rules in the ruleset: [.programlisting] .... # Everything else is denied and logged $cmd 00999 deny log all from any to any .... [[in-kernel-nat]] === In-kernel NAT FreeBSD's IPFW firewall has two implementations of NAT: the userland implementation man:natd[8], and the more recent in-kernel NAT implementation. Both work in conjunction with IPFW to provide network address translation. This can be used to provide an Internet Connection Sharing solution so that several internal computers can connect to the Internet using a single public IP address. To do this, the FreeBSD machine connected to the Internet must act as a gateway. This system must have two NICs, where one is connected to the Internet and the other is connected to the internal LAN. Each machine connected to the LAN should be assigned an IP address in the private network space, as defined by https://www.ietf.org/rfc/rfc1918.txt[RFC 1918]. Some additional configuration is needed in order to enable the in-kernel NAT facility of IPFW. To enable in-kernel NAT support at boot time, the following must be set in [.filename]#/etc/rc.conf#: [.programlisting] .... gateway_enable="YES" firewall_enable="YES" firewall_nat_enable="YES" .... [NOTE] ==== When `firewall_nat_enable` is set but `firewall_enable` is not, it will have no effect and do nothing. This is because the in-kernel NAT implementation is only compatible with IPFW. ==== When the ruleset contains stateful rules, the positioning of the NAT rule is critical and the `skipto` action is used. The `skipto` action requires a rule number so that it knows which rule to jump to. The example below builds upon the firewall ruleset shown in the previous section. It adds some additional entries and modifies some existing rules in order to configure the firewall for in-kernel NAT. It starts by adding some additional variables which represent the rule number to skip to, the `keep-state` option, and a list of TCP ports which will be used to reduce the number of rules. [.programlisting] .... #!/bin/sh ipfw -q -f flush cmd="ipfw -q add" skip="skipto 1000" pif=dc0 ks="keep-state" good_tcpo="22,25,37,53,80,443,110" .... With in-kernel NAT it is necessary to disable TCP segmentation offloading (TSO) due to the architecture of man:libalias[3], a library implemented as a kernel module to provide the in-kernel NAT facility of IPFW. TSO can be disabled on a per network interface basis using man:ifconfig[8] or on a system wide basis using man:sysctl[8]. To disable TSO system wide, the following must be set it [.filename]#/etc/sysctl.conf#: [.programlisting] .... net.inet.tcp.tso="0" .... A NAT instance will also be configured. It is possible to have multiple NAT instances each with their own configuration. For this example only one NAT instance is needed, NAT instance number 1. The configuration can take a few options such as: `if` which indicates the public interface, `same_ports` which takes care that aliased ports and local port numbers are mapped the same, `unreg_only` will result in only unregistered (private) address spaces to be processed by the NAT instance, and `reset` which will help to keep a functioning NAT instance even when the public IP address of the IPFW machine changes. For all possible options that can be passed to a single NAT instance configuration consult man:ipfw[8]. When configuring a stateful NATing firewall, it is necessary to allow translated packets to be reinjected in the firewall for further processing. This can be achieved by disabling `one_pass` behavior at the start of the firewall script. [.programlisting] .... ipfw disable one_pass ipfw -q nat 1 config if $pif same_ports unreg_only reset .... The inbound NAT rule is inserted _after_ the two rules which allow all traffic on the trusted and loopback interfaces and after the reassemble rule but _before_ the `check-state` rule. It is important that the rule number selected for this NAT rule, in this example `100`, is higher than the first three rules and lower than the `check-state` rule. Furthermore, because of the behavior of in-kernel NAT it is advised to place a reassemble rule just before the first NAT rule and after the rules that allow traffic on trusted interface. Normally, IP fragmentation should not happen, but when dealing with IPSEC/ESP/GRE tunneling traffic it might and the reassembling of fragments is necessary before handing the complete packet over to the in-kernel NAT facility. [NOTE] ==== The reassemble rule was not needed with userland man:natd[8] because the internal workings of the IPFW `divert` action already takes care of reassembling packets before delivery to the socket as also stated in man:ipfw[8]. The NAT instance and rule number used in this example does not match with the default NAT instance and rule number created by [.filename]#rc.firewall#. [.filename]#rc.firewall# is a script that sets up the default firewall rules present in FreeBSD. ==== [.programlisting] .... $cmd 005 allow all from any to any via xl0 # exclude LAN traffic $cmd 010 allow all from any to any via lo0 # exclude loopback traffic $cmd 099 reass all from any to any in # reassemble inbound packets $cmd 100 nat 1 ip from any to any in via $pif # NAT any inbound packets # Allow the packet through if it has an existing entry in the dynamic rules table $cmd 101 check-state .... The outbound rules are modified to replace the `allow` action with the `$skip` variable, indicating that rule processing will continue at rule `1000`. The seven `tcp` rules have been replaced by rule `125` as the `$good_tcpo` variable contains the seven allowed outbound ports. [NOTE] ==== Remember that IPFW's performance is largely determined by the number of rules present in the ruleset. ==== [.programlisting] .... # Authorized outbound packets $cmd 120 $skip udp from any to x.x.x.x 53 out via $pif $ks $cmd 121 $skip udp from any to x.x.x.x 67 out via $pif $ks $cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks $cmd 130 $skip icmp from any to any out via $pif $ks .... The inbound rules remain the same, except for the very last rule which removes the `via $pif` in order to catch both inbound and outbound rules. The NAT rule must follow this last outbound rule, must have a higher number than that last rule, and the rule number must be referenced by the `skipto` action. In this ruleset, rule number `1000` handles passing all packets to our configured instance for NAT processing. The next rule allows any packet which has undergone NAT processing to pass. [.programlisting] .... $cmd 999 deny log all from any to any $cmd 1000 nat 1 ip from any to any out via $pif # skipto location for outbound stateful rules $cmd 1001 allow ip from any to any .... In this example, rules `100`, `101`, `125`, `1000`, and `1001` control the address translation of the outbound and inbound packets so that the entries in the dynamic state table always register the private LANIP address. Consider an internal web browser which initializes a new outbound HTTP session over port 80. When the first outbound packet enters the firewall, it does not match rule `100` because it is headed out rather than in. It passes rule `101` because this is the first packet and it has not been posted to the dynamic state table yet. The packet finally matches rule `125` as it is outbound on an allowed port and has a source IP address from the internal LAN. On matching this rule, two actions take place. First, the `keep-state` action adds an entry to the dynamic state table and the specified action, `skipto rule 1000`, is executed. Next, the packet undergoes NAT and is sent out to the Internet. This packet makes its way to the destination web server, where a response packet is generated and sent back. This new packet enters the top of the ruleset. It matches rule `100` and has its destination IP address mapped back to the original internal address. It then is processed by the `check-state` rule, is found in the table as an existing session, and is released to the LAN. On the inbound side, the ruleset has to deny bad packets and allow only authorized services. A packet which matches an inbound rule is posted to the dynamic state table and the packet is released to the LAN. The packet generated as a response is recognized by the `check-state` rule as belonging to an existing session. It is then sent to rule `1000` to undergo NAT before being released to the outbound interface. [NOTE] ==== Transitioning from userland man:natd[8] to in-kernel NAT might appear seamless at first but there is small catch. When using the GENERIC kernel, IPFW will load the [.filename]#libalias.ko# kernel module, when `firewall_nat_enable` is enabled in [.filename]#/etc/rc.conf#. The [.filename]#libalias.ko# kernel module only provides basic NAT functionality, whereas the userland implementation man:natd[8] has all NAT functionality available in its userland library without any extra configuration. All functionality refers to the following kernel modules that can additionally be loaded when needed besides the standard [.filename]#libalias.ko# kernel module: [.filename]#alias_ftp.ko#, [.filename]#alias_bbt.ko#, [.filename]#skinny.ko#, [.filename]#irc.ko#, [.filename]#alias_pptp.ko# and [.filename]#alias_smedia.ko# using the `kld_list` directive in [.filename]#/etc/rc.conf#. If a custom kernel is used, the full functionality of the userland library can be compiled in, in the kernel, using the `options LIBALIAS`. ==== ==== Port Redirection The drawback with NAT in general is that the LAN clients are not accessible from the Internet. Clients on the LAN can make outgoing connections to the world but cannot receive incoming ones. This presents a problem if trying to run Internet services on one of the LAN client machines. A simple way around this is to redirect selected Internet ports on the NAT providing machine to a LAN client. For example, an IRC server runs on client `A` and a web server runs on client `B`. For this to work properly, connections received on ports 6667 (IRC) and 80 (HTTP) must be redirected to the respective machines. With in-kernel NAT all configuration is done in the NAT instance configuration. For a full list of options that an in-kernel NAT instance can use, consult man:ipfw[8]. The IPFW syntax follows the syntax of natd. The syntax for `redirect_port` is as follows: [.programlisting] .... redirect_port proto targetIP:targetPORT[-targetPORT] [aliasIP:]aliasPORT[-aliasPORT] [remoteIP[:remotePORT[-remotePORT]]] .... To configure the above example setup, the arguments should be: [.programlisting] .... redirect_port tcp 192.168.0.2:6667 6667 redirect_port tcp 192.168.0.3:80 80 .... After adding these arguments to the configuration of NAT instance 1 in the above ruleset, the TCP ports will be port forwarded to the LAN client machines running the IRC and HTTP services. [.programlisting] .... ipfw -q nat 1 config if $pif same_ports unreg_only reset \ redirect_port tcp 192.168.0.2:6667 6667 \ redirect_port tcp 192.168.0.3:80 80 .... Port ranges over individual ports can be indicated with `redirect_port`. For example, _tcp 192.168.0.2:2000-3000 2000-3000_ would redirect all connections received on ports 2000 to 3000 to ports 2000 to 3000 on client `A`. ==== Address Redirection Address redirection is useful if more than one IP address is available. Each LAN client can be assigned its own external IP address by man:ipfw[8], which will then rewrite outgoing packets from the LAN clients with the proper external IP address and redirects all traffic incoming on that particular IP address back to the specific LAN client. This is also known as static NAT. For example, if IP addresses `128.1.1.1`, `128.1.1.2`, and `128.1.1.3` are available, `128.1.1.1` can be used as the man:ipfw[8] machine's external IP address, while `128.1.1.2` and `128.1.1.3` are forwarded back to LAN clients `A` and `B`. The `redirect_addr` syntax is as below, where `localIP` is the internal IP address of the LAN client, and `publicIP` the external IP address corresponding to the LAN client. [.programlisting] .... redirect_addr localIP publicIP .... In the example, the arguments would read: [.programlisting] .... redirect_addr 192.168.0.2 128.1.1.2 redirect_addr 192.168.0.3 128.1.1.3 .... Like `redirect_port`, these arguments are placed in a NAT instance configuration. With address redirection, there is no need for port redirection, as all data received on a particular IP address is redirected. The external IP addresses on the man:ipfw[8] machine must be active and aliased to the external interface. Refer to man:rc.conf[5] for details. ==== Userspace NAT Let us start with a statement: the userspace NAT implementation: man:natd[8], has more overhead than in-kernel NAT. For man:natd[8] to translate packets, the packets have to be copied from the kernel to userspace and back which brings in extra overhead that is not present with in-kernel NAT. To enable the userspace NAT daemon man:natd[8] at boot time, the following is a minimum configuration in [.filename]#/etc/rc.conf#. Where `natd_interface` is set to the name of the NIC attached to the Internet. The man:rc[8] script of man:natd[8] will automatically check if a dynamic IP address is used and configure itself to handle that. [.programlisting] .... gateway_enable="YES" natd_enable="YES" natd_interface="rl0" .... In general, the above ruleset as explained for in-kernel NAT can also be used together with man:natd[8]. The exceptions are the configuration of the in-kernel NAT instance `(ipfw -q nat 1 config ...)` which is not needed together with reassemble rule 99 because its functionality is included in the `divert` action. Rule number 100 and 1000 will have to change slightly as shown below. [.programlisting] .... $cmd 100 divert natd ip from any to any in via $pif $cmd 1000 divert natd ip from any to any out via $pif .... To configure port or address redirection, a similar syntax as with in-kernel NAT is used. Although, now, instead of specifying the configuration in our ruleset script like with in-kernel NAT, configuration of man:natd[8] is best done in a configuration file. To do this, an extra flag must be passed via [.filename]#/etc/rc.conf# which specifies the path of the configuration file. [.programlisting] .... natd_flags="-f /etc/natd.conf" .... [NOTE] ==== The specified file must contain a list of configuration options, one per line. For more information about the configuration file and possible variables, consult man:natd[8]. Below are two example entries, one per line: [.programlisting] .... redirect_port tcp 192.168.0.2:6667 6667 redirect_addr 192.168.0.3 128.1.1.3 .... ==== [[firewalls-ipfw-cmd]] === The IPFW Command `ipfw` can be used to make manual, single rule additions or deletions to the active firewall while it is running. The problem with using this method is that all the changes are lost when the system reboots. It is recommended to instead write all the rules in a file and to use that file to load the rules at boot time and to replace the currently running firewall rules whenever that file changes. `ipfw` is a useful way to display the running firewall rules to the console screen. The IPFW accounting facility dynamically creates a counter for each rule that counts each packet that matches the rule. During the process of testing a rule, listing the rule with its counter is one way to determine if the rule is functioning as expected. To list all the running rules in sequence: [source,shell] .... # ipfw list .... To list all the running rules with a time stamp of when the last time the rule was matched: [source,shell] .... # ipfw -t list .... The next example lists accounting information and the packet count for matched rules along with the rules themselves. The first column is the rule number, followed by the number of matched packets and bytes, followed by the rule itself. [source,shell] .... # ipfw -a list .... To list dynamic rules in addition to static rules: [source,shell] .... # ipfw -d list .... To also show the expired dynamic rules: [source,shell] .... # ipfw -d -e list .... To zero the counters: [source,shell] .... # ipfw zero .... To zero the counters for just the rule with number _NUM_: [source,shell] .... # ipfw zero NUM .... ==== Logging Firewall Messages Even with the logging facility enabled, IPFW will not generate any rule logging on its own. The firewall administrator decides which rules in the ruleset will be logged, and adds the `log` keyword to those rules. Normally only deny rules are logged. It is customary to duplicate the "ipfw default deny everything" rule with the `log` keyword included as the last rule in the ruleset. This way, it is possible to see all the packets that did not match any of the rules in the ruleset. Logging is a two edged sword. If one is not careful, an over abundance of log data or a DoS attack can fill the disk with log files. Log messages are not only written to syslogd, but also are displayed on the root console screen and soon become annoying. The `IPFIREWALL_VERBOSE_LIMIT=5` kernel option limits the number of consecutive messages sent to man:syslogd[8], concerning the packet matching of a given rule. When this option is enabled in the kernel, the number of consecutive messages concerning a particular rule is capped at the number specified. There is nothing to be gained from 200 identical log messages. With this option set to five, five consecutive messages concerning a particular rule would be logged to syslogd and the remainder identical consecutive messages would be counted and posted to syslogd with a phrase like the following: [.programlisting] .... last message repeated 45 times .... All logged packets messages are written by default to [.filename]#/var/log/security#, which is defined in [.filename]#/etc/syslog.conf#. [[firewalls-ipfw-rules-script]] ==== Building a Rule Script Most experienced IPFW users create a file containing the rules and code them in a manner compatible with running them as a script. The major benefit of doing this is the firewall rules can be refreshed in mass without the need of rebooting the system to activate them. This method is convenient in testing new rules as the procedure can be executed as many times as needed. Being a script, symbolic substitution can be used for frequently used values to be substituted into multiple rules. This example script is compatible with the syntax used by the man:sh[1], man:csh[1], and man:tcsh[1] shells. Symbolic substitution fields are prefixed with a dollar sign ($). Symbolic fields do not have the $ prefix. The value to populate the symbolic field must be enclosed in double quotes (""). Start the rules file like this: [.programlisting] .... ############### start of example ipfw rules script ############# # ipfw -q -f flush # Delete all rules # Set defaults oif="tun0" # out interface odns="192.0.2.11" # ISP's DNS server IP address cmd="ipfw -q add " # build rule prefix ks="keep-state" # just too lazy to key this each time $cmd 00500 check-state $cmd 00502 deny all from any to any frag $cmd 00501 deny tcp from any to any established $cmd 00600 allow tcp from any to any 80 out via $oif setup $ks $cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks $cmd 00611 allow udp from any to $odns 53 out via $oif $ks ################### End of example ipfw rules script ############ .... The rules are not important as the focus of this example is how the symbolic substitution fields are populated. If the above example was in [.filename]#/etc/ipfw.rules#, the rules could be reloaded by the following command: [source,shell] .... # sh /etc/ipfw.rules .... [.filename]#/etc/ipfw.rules# can be located anywhere and the file can have any name. The same thing could be accomplished by running these commands by hand: [source,shell] .... # ipfw -q -f flush # ipfw -q add check-state # ipfw -q add deny all from any to any frag # ipfw -q add deny tcp from any to any established # ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state # ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state # ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state .... [[firewalls-ipfw-kernelconfig]] === IPFW Kernel Options In order to statically compile IPFW support into a custom kernel, refer to the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]. The following options are available for the custom kernel configuration file: [.programlisting] .... options IPFIREWALL # enables IPFW options IPFIREWALL_VERBOSE # enables logging for rules with log keyword to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=5 # limits number of logged packets per-entry options IPFIREWALL_DEFAULT_TO_ACCEPT # sets default policy to pass what is not explicitly denied options IPFIREWALL_NAT # enables basic in-kernel NAT support options LIBALIAS # enables full in-kernel NAT support options IPFIREWALL_NAT64 # enables in-kernel NAT64 support options IPFIREWALL_NPTV6 # enables in-kernel IPv6 NPT support options IPFIREWALL_PMOD # enables protocols modification module support options IPDIVERT # enables NAT through natd(8) .... [NOTE] ==== IPFW can be loaded as a kernel module: options above are built by default as modules or can be set at runtime using tunables. ==== [[firewalls-ipf]] == IPFILTER (IPF) IPFILTER, also known as IPF, is a cross-platform, open source firewall which has been ported to several operating systems, including FreeBSD, NetBSD, OpenBSD, and Solaris(TM). IPFILTER is a kernel-side firewall and NAT mechanism that can be controlled and monitored by userland programs. Firewall rules can be set or deleted using ipf, NAT rules can be set or deleted using ipnat, run-time statistics for the kernel parts of IPFILTER can be printed using ipfstat, and ipmon can be used to log IPFILTER actions to the system log files. IPF was originally written using a rule processing logic of "the last matching rule wins" and only used stateless rules. Since then, IPF has been enhanced to include the `quick` and `keep state` options. The IPF FAQ is at http://www.phildev.net/ipf/index.html[http://www.phildev.net/ipf/index.html]. A searchable archive of the IPFilter mailing list is available at http://marc.info/?l=ipfilter[http://marc.info/?l=ipfilter]. This section of the Handbook focuses on IPF as it pertains to FreeBSD. It provides examples of rules that contain the `quick` and `keep state` options. === Enabling IPF IPF is included in the basic FreeBSD install as a kernel loadable module, meaning that a custom kernel is not needed in order to enable IPF. For users who prefer to statically compile IPF support into a custom kernel, refer to the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]. The following kernel options are available: [.programlisting] .... options IPFILTER options IPFILTER_LOG options IPFILTER_LOOKUP options IPFILTER_DEFAULT_BLOCK .... where `options IPFILTER` enables support for IPFILTER, `options IPFILTER_LOG` enables IPF logging using the [.filename]#ipl# packet logging pseudo-device for every rule that has the `log` keyword, `IPFILTER_LOOKUP` enables IP pools in order to speed up IP lookups, and `options IPFILTER_DEFAULT_BLOCK` changes the default behavior so that any packet not matching a firewall `pass` rule gets blocked. To configure the system to enable IPF at boot time, add the following entries to [.filename]#/etc/rc.conf#. These entries will also enable logging and `default pass all`. To change the default policy to `block all` without compiling a custom kernel, remember to add a `block all` rule at the end of the ruleset. [.programlisting] .... ipfilter_enable="YES" # Start ipf firewall ipfilter_rules="/etc/ipf.rules" # loads rules definition text file ipv6_ipfilter_rules="/etc/ipf6.rules" # loads rules definition text file for IPv6 ipmon_enable="YES" # Start IP monitor log ipmon_flags="-Ds" # D = start as daemon # s = log to syslog # v = log tcp window, ack, seq # n = map IP & port to names .... If NAT functionality is needed, also add these lines: [.programlisting] .... gateway_enable="YES" # Enable as LAN gateway ipnat_enable="YES" # Start ipnat function ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat .... Then, to start IPF now: [.programlisting] .... # service ipfilter start .... To load the firewall rules, specify the name of the ruleset file using `ipf`. The following command can be used to replace the currently running firewall rules: [source,shell] .... # ipf -Fa -f /etc/ipf.rules .... where `-Fa` flushes all the internal rules tables and `-f` specifies the file containing the rules to load. This provides the ability to make changes to a custom ruleset and update the running firewall with a fresh copy of the rules without having to reboot the system. This method is convenient for testing new rules as the procedure can be executed as many times as needed. Refer to man:ipf[8] for details on the other flags available with this command. === IPF Rule Syntax This section describes the IPF rule syntax used to create stateful rules. When creating rules, keep in mind that unless the `quick` keyword appears in a rule, every rule is read in order, with the _last matching rule_ being the one that is applied. This means that even if the first rule to match a packet is a `pass`, if there is a later matching rule that is a `block`, the packet will be dropped. Sample rulesets can be found in [.filename]#/usr/share/examples/ipfilter#. When creating rules, a `+#+` character is used to mark the start of a comment and may appear at the end of a rule, to explain that rule's function, or on its own line. Any blank lines are ignored. The keywords which are used in rules must be written in a specific order, from left to right. Some keywords are mandatory while others are optional. Some keywords have sub-options which may be keywords themselves and also include more sub-options. The keyword order is as follows, where the words shown in uppercase represent a variable and the words shown in lowercase must precede the variable that follows it: `_ACTION DIRECTION OPTIONS proto PROTO_TYPE from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT TCP_FLAG|ICMP_TYPE keep state STATE_` This section describes each of these keywords and their options. It is not an exhaustive list of every possible option. Refer to man:ipf[5] for a complete description of the rule syntax that can be used when creating IPF rules and examples for using each keyword. ACTION:: The action keyword indicates what to do with the packet if it matches that rule. Every rule _must_ have an action. The following actions are recognized: + `block`: drops the packet. + `pass`: allows the packet. + `log`: generates a log record. + `count`: counts the number of packets and bytes which can provide an indication of how often a rule is used. + `auth`: queues the packet for further processing by another program. + `call`: provides access to functions built into IPF that allow more complex actions. + `decapsulate`: removes any headers in order to process the contents of the packet. DIRECTION:: Next, each rule must explicitly state the direction of traffic using one of these keywords: + `in`: the rule is applied against an inbound packet. + `out`: the rule is applied against an outbound packet. + `all`: the rule applies to either direction. + If the system has multiple interfaces, the interface can be specified along with the direction. An example would be `in on fxp0`. OPTIONS:: Options are optional. However, if multiple options are specified, they must be used in the order shown here. + `log`: when performing the specified ACTION, the contents of the packet's headers will be written to the man:ipl[4] packet log pseudo-device. + `quick`: if a packet matches this rule, the ACTION specified by the rule occurs and no further processing of any following rules will occur for this packet. + `on`: must be followed by the interface name as displayed by man:ifconfig[8]. The rule will only match if the packet is going through the specified interface in the specified direction. + When using the `log` keyword, the following qualifiers may be used in this order: + `body`: indicates that the first 128 bytes of the packet contents will be logged after the headers. + `first`: if the `log` keyword is being used in conjunction with a `keep state` option, this option is recommended so that only the triggering packet is logged and not every packet which matches the stateful connection. + Additional options are available to specify error return messages. Refer to man:ipf[5] for more details. PROTO_TYPE:: The protocol type is optional. However, it is mandatory if the rule needs to specify a SRC_PORT or a DST_PORT as it defines the type of protocol. When specifying the type of protocol, use the `proto` keyword followed by either a protocol number or name from [.filename]#/etc/protocols#. Example protocol names include `tcp`, `udp`, or `icmp`. If PROTO_TYPE is specified but no SRC_PORT or DST_PORT is specified, all port numbers for that protocol will match that rule. SRC_ADDR:: The `from` keyword is mandatory and is followed by a keyword which represents the source of the packet. The source can be a hostname, an IP address followed by the CIDR mask, an address pool, or the keyword `all`. Refer to man:ipf[5] for examples. + There is no way to match ranges of IP addresses which do not express themselves easily using the dotted numeric form / mask-length notation. The package:net-mgmt/ipcalc[] package or port may be used to ease the calculation of the CIDR mask. Additional information is available at the utility's web page: http://jodies.de/ipcalc[http://jodies.de/ipcalc]. SRC_PORT:: The port number of the source is optional. However, if it is used, it requires PROTO_TYPE to be first defined in the rule. The port number must also be preceded by the `proto` keyword. + A number of different comparison operators are supported: `=` (equal to), `!=` (not equal to), `<` (less than), `>` (greater than), `<=` (less than or equal to), and `>=` (greater than or equal to). + To specify port ranges, place the two port numbers between `<>` (less than and greater than ), `><` (greater than and less than ), or `:` (greater than or equal to and less than or equal to). DST_ADDR:: The `to` keyword is mandatory and is followed by a keyword which represents the destination of the packet. Similar to SRC_ADDR, it can be a hostname, an IP address followed by the CIDR mask, an address pool, or the keyword `all`. DST_PORT:: Similar to SRC_PORT, the port number of the destination is optional. However, if it is used, it requires PROTO_TYPE to be first defined in the rule. The port number must also be preceded by the `proto` keyword. TCP_FLAG|ICMP_TYPE:: If `tcp` is specified as the PROTO_TYPE, flags can be specified as letters, where each letter represents one of the possible TCP flags used to determine the state of a connection. Possible values are: `S` (SYN), `A` (ACK), `P` (PSH), `F` (FIN), `U` (URG), `R` (RST), `C` (CWN), and `E` (ECN). + If `icmp` is specified as the PROTO_TYPE, the ICMP type to match can be specified. Refer to man:ipf[5] for the allowable types. STATE:: If a `pass` rule contains `keep state`, IPF will add an entry to its dynamic state table and allow subsequent packets that match the connection. IPF can track state for TCP, UDP, and ICMP sessions. Any packet that IPF can be certain is part of an active session, even if it is a different protocol, will be allowed. + In IPF, packets destined to go out through the interface connected to the public Internet are first checked against the dynamic state table. If the packet matches the next expected packet comprising an active session conversation, it exits the firewall and the state of the session conversation flow is updated in the dynamic state table. Packets that do not belong to an already active session are checked against the outbound ruleset. Packets coming in from the interface connected to the public Internet are first checked against the dynamic state table. If the packet matches the next expected packet comprising an active session, it exits the firewall and the state of the session conversation flow is updated in the dynamic state table. Packets that do not belong to an already active session are checked against the inbound ruleset. + Several keywords can be added after `keep state`. If used, these keywords set various options that control stateful filtering, such as setting connection limits or connection age. Refer to man:ipf[5] for the list of available options and their descriptions. === Example Ruleset This section demonstrates how to create an example ruleset which only allows services matching `pass` rules and blocks all others. FreeBSD uses the loopback interface ([.filename]#lo0#) and the IP address `127.0.0.1` for internal communication. The firewall ruleset must contain rules to allow free movement of these internally used packets: [.programlisting] .... # no restrictions on loopback interface pass in quick on lo0 all pass out quick on lo0 all .... The public interface connected to the Internet is used to authorize and control access of all outbound and inbound connections. If one or more interfaces are cabled to private networks, those internal interfaces may require rules to allow packets originating from the LAN to flow between the internal networks or to the interface attached to the Internet. The ruleset should be organized into three major sections: any trusted internal interfaces, outbound connections through the public interface, and inbound connections through the public interface. These two rules allow all traffic to pass through a trusted LAN interface named [.filename]#xl0#: [.programlisting] .... # no restrictions on inside LAN interface for private network pass out quick on xl0 all pass in quick on xl0 all .... The rules for the public interface's outbound and inbound sections should have the most frequently matched rules placed before less commonly matched rules, with the last rule in the section blocking and logging all packets for that interface and direction. This set of rules defines the outbound section of the public interface named [.filename]#dc0#. These rules keep state and identify the specific services that internal systems are authorized for public Internet access. All the rules use `quick` and specify the appropriate port numbers and, where applicable, destination addresses. [.programlisting] .... # interface facing Internet (outbound) # Matches session start requests originating from or behind the # firewall, destined for the Internet. # Allow outbound access to public DNS servers. # Replace x.x.x.x with address listed in /etc/resolv.conf. # Repeat for each DNS server. pass out quick on dc0 proto tcp from any to x.x.x.x port = 53 flags S keep state pass out quick on dc0 proto udp from any to x.x.x.x port = 53 keep state # Allow access to ISP's specified DHCP server for cable or DSL networks. # Use the first rule, then check log for the IP address of DHCP server. # Then, uncomment the second rule, replace z.z.z.z with the IP address, # and comment out the first rule pass out log quick on dc0 proto udp from any to any port = 67 keep state #pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state # Allow HTTP and HTTPS pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state # Allow email pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state # Allow NTP pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state # Allow FTP pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state # Allow SSH pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state # Allow ping pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state # Block and log everything else block out log first quick on dc0 all .... This example of the rules in the inbound section of the public interface blocks all undesirable packets first. This reduces the number of packets that are logged by the last rule. [.programlisting] .... # interface facing Internet (inbound) # Block all inbound traffic from non-routable or reserved address spaces block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918 private IP block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918 private IP block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918 private IP block in quick on dc0 from 127.0.0.0/8 to any #loopback block in quick on dc0 from 0.0.0.0/8 to any #loopback block in quick on dc0 from 169.254.0.0/16 to any #DHCP auto-config block in quick on dc0 from 192.0.2.0/24 to any #reserved for docs block in quick on dc0 from 204.152.64.0/23 to any #Sun cluster interconnect block in quick on dc0 from 224.0.0.0/3 to any #Class D & E multicast # Block fragments and too short tcp packets block in quick on dc0 all with frags block in quick on dc0 proto tcp all with short # block source routed packets block in quick on dc0 all with opt lsrr block in quick on dc0 all with opt ssrr # Block OS fingerprint attempts and log first occurrence block in log first quick on dc0 proto tcp from any to any flags FUP # Block anything with special options block in quick on dc0 all with ipopts # Block public pings and ident block in quick on dc0 proto icmp all icmp-type 8 block in quick on dc0 proto tcp from any to any port = 113 # Block incoming Netbios services block in log first quick on dc0 proto tcp/udp from any to any port = 137 block in log first quick on dc0 proto tcp/udp from any to any port = 138 block in log first quick on dc0 proto tcp/udp from any to any port = 139 block in log first quick on dc0 proto tcp/udp from any to any port = 81 .... Any time there are logged messages on a rule with the `log first` option, run `ipfstat -hio` to evaluate how many times the rule has been matched. A large number of matches may indicate that the system is under attack. The rest of the rules in the inbound section define which connections are allowed to be initiated from the Internet. The last rule denies all connections which were not explicitly allowed by previous rules in this section. [.programlisting] .... # Allow traffic in from ISP's DHCP server. Replace z.z.z.z with # the same IP address used in the outbound section. pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state # Allow public connections to specified internal web server pass in quick on dc0 proto tcp from any to x.x.x.x port = 80 flags S keep state # Block and log only first occurrence of all remaining traffic. block in log first quick on dc0 all .... === Configuring NAT To enable NAT, add these statements to [.filename]#/etc/rc.conf# and specify the name of the file containing the NAT rules: [.programlisting] .... gateway_enable="YES" ipnat_enable="YES" ipnat_rules="/etc/ipnat.rules" .... NAT rules are flexible and can accomplish many different things to fit the needs of both commercial and home users. The rule syntax presented here has been simplified to demonstrate common usage. For a complete rule syntax description, refer to man:ipnat[5]. The basic syntax for a NAT rule is as follows, where `map` starts the rule and _IF_ should be replaced with the name of the external interface: [.programlisting] .... map IF LAN_IP_RANGE -> PUBLIC_ADDRESS .... The _LAN_IP_RANGE_ is the range of IP addresses used by internal clients. Usually, it is a private address range such as `192.168.1.0/24`. The _PUBLIC_ADDRESS_ can either be the static external IP address or the keyword `0/32` which represents the IP address assigned to _IF_. In IPF, when a packet arrives at the firewall from the LAN with a public destination, it first passes through the outbound rules of the firewall ruleset. Then, the packet is passed to the NAT ruleset which is read from the top down, where the first matching rule wins. IPF tests each NAT rule against the packet's interface name and source IP address. When a packet's interface name matches a NAT rule, the packet's source IP address in the private LAN is checked to see if it falls within the IP address range specified in _LAN_IP_RANGE_. On a match, the packet has its source IP address rewritten with the public IP address specified by _PUBLIC_ADDRESS_. IPF posts an entry in its internal NAT table so that when the packet returns from the Internet, it can be mapped back to its original private IP address before being passed to the firewall rules for further processing. For networks that have large numbers of internal systems or multiple subnets, the process of funneling every private IP address into a single public IP address becomes a resource problem. Two methods are available to relieve this issue. The first method is to assign a range of ports to use as source ports. By adding the `portmap` keyword, NAT can be directed to only use source ports in the specified range: [.programlisting] .... map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000 .... Alternately, use the `auto` keyword which tells NAT to determine the ports that are available for use: [.programlisting] .... map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto .... The second method is to use a pool of public addresses. This is useful when there are too many LAN addresses to fit into a single public address and a block of public IP addresses is available. These public addresses can be used as a pool from which NAT selects an IP address as a packet's address is mapped on its way out. The range of public IP addresses can be specified using a netmask or CIDR notation. These two rules are equivalent: [.programlisting] .... map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0 map dc0 192.168.1.0/24 -> 204.134.75.0/24 .... A common practice is to have a publicly accessible web server or mail server segregated to an internal network segment. The traffic from these servers still has to undergo NAT, but port redirection is needed to direct inbound traffic to the correct server. For example, to map a web server using the internal address `10.0.10.25` to its public IP address of `20.20.20.5`, use this rule: [.programlisting] .... rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 .... If it is the only web server, this rule would also work as it redirects all external HTTP requests to `10.0.10.25`: [.programlisting] .... rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80 .... IPF has a built in FTP proxy which can be used with NAT. It monitors all outbound traffic for active or passive FTP connection requests and dynamically creates temporary filter rules containing the port number used by the FTP data channel. This eliminates the need to open large ranges of high order ports for FTP connections. In this example, the first rule calls the proxy for outbound FTP traffic from the internal LAN. The second rule passes the FTP traffic from the firewall to the Internet, and the third rule handles all non-FTP traffic from the internal LAN: [.programlisting] .... map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp map dc0 10.0.10.0/29 -> 0/32 .... The FTP `map` rules go before the NAT rule so that when a packet matches an FTP rule, the FTP proxy creates temporary filter rules to let the FTP session packets pass and undergo NAT. All LAN packets that are not FTP will not match the FTP rules but will undergo NAT if they match the third rule. Without the FTP proxy, the following firewall rules would instead be needed. Note that without the proxy, all ports above `1024` need to be allowed: [.programlisting] .... # Allow out LAN PC client FTP to public Internet # Active and passive modes pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state # Allow out passive mode data channel high order port numbers pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state # Active mode let data channel in from FTP server pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state .... Whenever the file containing the NAT rules is edited, run `ipnat` with `-CF` to delete the current NAT rules and flush the contents of the dynamic translation table. Include `-f` and specify the name of the NAT ruleset to load: [source,shell] .... # ipnat -CF -f /etc/ipnat.rules .... To display the NAT statistics: [source,shell] .... # ipnat -s .... To list the NAT table's current mappings: [source,shell] .... # ipnat -l .... To turn verbose mode on and display information relating to rule processing and active rules and table entries: [source,shell] .... # ipnat -v .... === Viewing IPF Statistics IPF includes man:ipfstat[8] which can be used to retrieve and display statistics which are gathered as packets match rules as they go through the firewall. Statistics are accumulated since the firewall was last started or since the last time they were reset to zero using `ipf -Z`. The default `ipfstat` output looks like this: [source,shell] .... input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 input packets logged: blocked 99286 passed 0 output packets logged: blocked 0 passed 0 packets logged: input 0 output 0 log failures: input 3898 output 0 fragment state(in): kept 0 lost 0 fragment state(out): kept 0 lost 0 packet state(in): kept 169364 lost 0 packet state(out): kept 431395 lost 0 ICMP replies: 0 TCP RSTs sent: 0 Result cache hits(in): 1215208 (out): 1098963 IN Pullups succeeded: 2 failed: 0 OUT Pullups succeeded: 0 failed: 0 Fastroute successes: 0 failures: 0 TCP cksum fails(in): 0 (out): 0 Packet log flags set: (0) .... Several options are available. When supplied with either `-i` for inbound or `-o` for outbound, the command will retrieve and display the appropriate list of filter rules currently installed and in use by the kernel. To also see the rule numbers, include `-n`. For example, `ipfstat -on` displays the outbound rules table with rule numbers: [source,shell] .... @1 pass out on xl0 from any to any @2 block out on dc0 from any to any @3 pass out quick on dc0 proto tcp/udp from any to any keep state .... Include `-h` to prefix each rule with a count of how many times the rule was matched. For example, `ipfstat -oh` displays the outbound internal rules table, prefixing each rule with its usage count: [source,shell] .... 2451423 pass out on xl0 from any to any 354727 block out on dc0 from any to any 430918 pass out quick on dc0 proto tcp/udp from any to any keep state .... To display the state table in a format similar to man:top[1], use `ipfstat -t`. When the firewall is under attack, this option provides the ability to identify and see the attacking packets. The optional sub-flags give the ability to select the destination or source IP, port, or protocol to be monitored in real time. Refer to man:ipfstat[8] for details. === IPF Logging IPF provides `ipmon`, which can be used to write the firewall's logging information in a human readable format. It requires that `options IPFILTER_LOG` be first added to a custom kernel using the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]. This command is typically run in daemon mode in order to provide a continuous system log file so that logging of past events may be reviewed. Since FreeBSD has a built in man:syslogd[8] facility to automatically rotate system logs, the default [.filename]#rc.conf# `ipmon_flags` statement uses `-Ds`: [.programlisting] .... ipmon_flags="-Ds" # D = start as daemon # s = log to syslog # v = log tcp window, ack, seq # n = map IP & port to names .... Logging provides the ability to review, after the fact, information such as which packets were dropped, what addresses they came from, and where they were going. This information is useful in tracking down attackers. Once the logging facility is enabled in [.filename]#rc.conf# and started with `service ipmon start`, IPF will only log the rules which contain the `log` keyword. The firewall administrator decides which rules in the ruleset should be logged and normally only deny rules are logged. It is customary to include the `log` keyword in the last rule in the ruleset. This makes it possible to see all the packets that did not match any of the rules in the ruleset. By default, `ipmon -Ds` mode uses `local0` as the logging facility. The following logging levels can be used to further segregate the logged data: [source,shell] .... LOG_INFO - packets logged using the "log" keyword as the action rather than pass or block. LOG_NOTICE - packets logged which are also passed LOG_WARNING - packets logged which are also blocked LOG_ERR - packets which have been logged and which can be considered short due to an incomplete header .... In order to setup IPF to log all data to [.filename]#/var/log/ipfilter.log#, first create the empty file: [source,shell] .... # touch /var/log/ipfilter.log .... Then, to write all logged messages to the specified file, add the following statement to [.filename]#/etc/syslog.conf#: [.programlisting] .... local0.* /var/log/ipfilter.log .... To activate the changes and instruct man:syslogd[8] to read the modified [.filename]#/etc/syslog.conf#, run `service syslogd reload`. Do not forget to edit [.filename]#/etc/newsyslog.conf# to rotate the new log file. Messages generated by `ipmon` consist of data fields separated by white space. Fields common to all messages are: . The date of packet receipt. . The time of packet receipt. This is in the form HH:MM:SS.F, for hours, minutes, seconds, and fractions of a second. . The name of the interface that processed the packet. . The group and rule number of the rule in the format `@0:17`. . The action: `p` for passed, `b` for blocked, `S` for a short packet, `n` did not match any rules, and `L` for a log rule. . The addresses written as three fields: the source address and port separated by a comma, the -> symbol, and the destination address and port. For example: `209.53.17.22,80 -> 198.73.220.17,1722`. . `PR` followed by the protocol name or number: for example, `PR tcp`. . `len` followed by the header length and total length of the packet: for example, `len 20 40`. If the packet is a TCP packet, there will be an additional field starting with a hyphen followed by letters corresponding to any flags that were set. Refer to man:ipf[5] for a list of letters and their flags. If the packet is an ICMP packet, there will be two fields at the end: the first always being "icmp" and the next being the ICMP message and sub-message type, separated by a slash. For example: `icmp 3/3` for a port unreachable message. [[firewalls-blacklistd]] == Blacklistd Blacklistd is a daemon listening to sockets awaiting to receive notifications from other daemons about connection attempts that failed or were successful. It is most widely used in blocking too many connection attempts on open ports. A prime example is SSH running on the internet getting a lot of requests from bots or scripts trying to guess passwords and gain access. Using blacklistd, the daemon can notify the firewall to create a filter rule to block excessive connection attempts from a single source after a number of tries. Blacklistd was first developed on NetBSD and appeared there in version 7. FreeBSD 11 imported blacklistd from NetBSD. This chapter describes how to set up blacklistd, configure it, and provides examples on how to use it. Readers should be familiar with basic firewall concepts like rules. For details, refer to the firewall chapter. PF is used in the examples, but other firewalls available on FreeBSD should be able to work with blacklistd, too. === Enabling Blacklistd The main configuration for blacklistd is stored in man:blacklistd.conf[5]. Various command line options are also available to change blacklistd's run-time behavior. Persistent configuration across reboots should be stored in [.filename]#/etc/blacklistd.conf#. To enable the daemon during system boot, add a `blacklistd_enable` line to [.filename]#/etc/rc.conf# like this: [source,shell] .... # sysrc blacklistd_enable=yes .... To start the service manually, run this command: [source,shell] .... # service blacklistd start .... === Creating a Blacklistd Ruleset Rules for blacklistd are configured in man:blacklistd.conf[5] with one entry per line. Each rule contains a tuple separated by spaces or tabs. Rules either belong to a `local` or a `remote`, which applies to the machine where blacklistd is running or an outside source, respectively. ==== Local Rules An example blacklistd.conf entry for a local rule looks like this: [.programlisting] .... [local] ssh stream * * * 3 24h .... All rules that follow the `[local]` section are treated as local rules (which is the default), applying to the local machine. When a `[remote]` section is encountered, all rules that follow it are handled as remote machine rules. Seven fields separated by either tabs or spaces define a rule. The first four fields identify the traffic that should be blocklisted. The three fields that follow define backlistd's behavior. Wildcards are denoted as asterisks (`*`), matching anything in this field. The first field defines the location. In local rules, these are the network ports. The syntax for the location field is as follows: [.programlisting] .... [address|interface][/mask][:port] .... Addresses can be specified as IPv4 in numeric format or IPv6 in square brackets. An interface name like `_em0_` can also be used. The socket type is defined by the second field. TCP sockets are of type `stream`, whereas UDP is denoted as `dgram`. The example above uses TCP, since SSH is using that protocol. A protocol can be used in the third field of a blacklistd rule. The following protocols can be used: `tcp`, `udp`, `tcp6`, `udp6`, or numeric. A wildcard, like in the example, is typically used to match all protocols unless there is a reason to distinguish traffic by a certain protocol. In the fourth field, the effective user or owner of the daemon process that is reporting the event is defined. The username or UID can be used here, as well as a wildcard (see example rule above). The packet filter rule name is declared by the fifth field, which starts the behavior part of the rule. By default, blacklistd puts all blocks under a pf anchor called `blacklistd` in [.filename]#pf.conf# like this: [.programlisting] .... anchor "blacklistd/*" in on $ext_if block in pass out .... For separate blocklists, an anchor name can be used in this field. In other cases, the wildcard will suffice. When a name starts with a hyphen (`-`) it means that an anchor with the default rule name prepended should be used. A modified example from the above using the hyphen would look like this: [.programlisting] .... ssh stream * * -ssh 3 24h .... With such a rule, any new blocklist rules are added to an anchor called `blacklistd-ssh`. To block whole subnets for a single rule violation, a `/` in the rule name can be used. This causes the remaining portion of the name to be interpreted as the mask to be applied to the address specified in the rule. For example, this rule would block every address adjoining `/24`. [.programlisting] .... 22 stream tcp * */24 3 24h .... [NOTE] ==== It is important to specify the proper protocol here. IPv4 and IPv6 treat /24 differently, that is the reason why `*` cannot be used in the third field for this rule. ==== This rule defines that if any one host in that network is misbehaving, everything else on that network will be blocked, too. The sixth field, called `nfail`, sets the number of login failures required to blocklist the remote IP in question. When a wildcard is used at this position, it means that blocks will never happen. In the example rule above, a limit of three is defined meaning that after three attempts to log into SSH on one connection, the IP is blocked. The last field in a blacklistd rule definition specifies how long a host is blocklisted. The default unit is seconds, but suffixes like `m`, `h`, and `d` can also be specified for minutes, hours, and days, respectively. The example rule in its entirety means that after three times authenticating to SSH will result in a new PF block rule for that host. Rule matches are performed by first checking local rules one after another, from most specific to least specific. When a match occurs, the `remote` rules are applied and the name, `nfail`, and disable fields are changed by the `remote` rule that matched. ==== Remote Rules Remote rules are used to specify how blacklistd changes its behavior depending on the remote host currently being evaluated. Each field in a remote rule is the same as in a local rule. The only difference is in the way blacklistd is using them. To explain it, this example rule is used: [.programlisting] .... [remote] 203.0.113.128/25 * * * =/25 = 48h .... The address field can be an IP address (either v4 or v6), a port or both. This allows setting special rules for a specific remote address range like in this example. The fields for socket type, protocol and owner are identically interpreted as in the local rule. The name fields is different though: the equal sign (`=`) in a remote rule tells blacklistd to use the value from the matching local rule. It means that the firewall rule entry is taken and the `/25` prefix (a netmask of `255.255.255.128`) is added. When a connection from that address range is blocklisted, the entire subnet is affected. A PF anchor name can also be used here, in which case blacklistd will add rules for this address block to the anchor of that name. The default table is used when a wildcard is specified. A custom number of failures in the `nfail` column can be defined for an address. This is useful for exceptions to a specific rule, to maybe allow someone a less strict application of rules or a bit more leniency in login tries. Blocking is disabled when an asterisk is used in this sixth field. Remote rules allow a stricter enforcement of limits on attempts to log in compared to attempts coming from a local network like an office. === Blacklistd Client Configuration There are a few software packages in FreeBSD that can utilize blacklistd's functionality. The two most prominent ones are man:ftpd[8] and man:sshd[8] to block excessive connection attempts. To activate blacklistd in the SSH daemon, add the following line to [.filename]#/etc/ssh/sshd_config#: [.programlisting] .... UseBlacklist yes .... Restart sshd afterwards to make these changes take effect. Blacklisting for man:ftpd[8] is enabled using `-B`, either in [.filename]#/etc/inetd.conf# or as a flag in [.filename]#/etc/rc.conf# like this: [.programlisting] .... ftpd_flags="-B" .... That is all that is needed to make these programs talk to blacklistd. === Blacklistd Management Blacklistd provides the user with a management utility called man:blacklistctl[8]. It displays blocked addresses and networks that are blocklisted by the rules defined in man:blacklistd.conf[5]. To see the list of currently blocked hosts, use `dump` combined with `-b` like this. [source,shell] .... # blacklistctl dump -b address/ma:port id nfail last access 213.0.123.128/25:22 OK 6/3 2019/06/08 14:30:19 .... This example shows that there were 6 out of three permitted attempts on port 22 coming from the address range `213.0.123.128/25`. There are more attempts listed than are allowed because SSH allows a client to try multiple logins on a single TCP connection. A connection that is currently going on is not stopped by blacklistd. The last connection attempt is listed in the `last access` column of the output. To see the remaining time that this host will be on the blocklist, add `-r` to the previous command. [source,shell] .... # blacklistctl dump -br address/ma:port id nfail remaining time 213.0.123.128/25:22 OK 6/3 36s .... In this example, there are 36s seconds left until this host will not be blocked any more. === Removing Hosts from the Block List Sometimes it is necessary to remove a host from the block list before the remaining time expires. Unfortunately, there is no functionality in blacklistd to do that. However, it is possible to remove the address from the PF table using pfctl. For each blocked port, there is a child anchor inside the blacklistd anchor defined in [.filename]#/etc/pf.conf#. For example, if there is a child anchor for blocking port 22 it is called `blacklistd/22`. There is a table inside that child anchor that contains the blocked addresses. This table is called port followed by the port number. In this example, it would be called `port22`. With that information at hand, it is now possible to use man:pfctl[8] to display all addresses listed like this: [source,shell] .... # pfctl -a blacklistd/22 -t port22 -T show ... 213.0.123.128/25 ... .... After identifying the address to be unblocked from the list, the following command removes it from the list: [source,shell] .... # pfctl -a blacklistd/22 -t port22 -T delete 213.0.123.128/25 .... The address is now removed from PF, but will still show up in the blacklistctl list, since it does not know about any changes made in PF. The entry in blacklistd's database will eventually expire and be removed from its output. The entry will be added again if the host is matching one of the block rules in blacklistd again. diff --git a/documentation/content/en/books/handbook/geom/_index.adoc b/documentation/content/en/books/handbook/geom/_index.adoc index a13b1d626c..47fc93b6e4 100644 --- a/documentation/content/en/books/handbook/geom/_index.adoc +++ b/documentation/content/en/books/handbook/geom/_index.adoc @@ -1,1306 +1,1306 @@ --- title: "Chapter 21. GEOM: Modular Disk Transformation Framework" part: Part III. System Administration prev: books/handbook/disks next: books/handbook/zfs description: In FreeBSD, the GEOM framework permits access and control to classes, such as Master Boot Records and BSD labels, through the use of providers, or the disk devices in /dev. tags: ["GEOM", "RAID", "RAID0", "RAID1", "RAID3", "Striping", "bsdlabel", "newfs", "labelling", "UFS", "journaling"] showBookMenu: true weight: 25 params: path: "/books/handbook/geom/" --- [[geom]] = GEOM: Modular Disk Transformation Framework :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 21 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/geom/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[geom-synopsis]] == Synopsis In FreeBSD, the GEOM framework permits access and control to classes, such as Master Boot Records and BSD labels, through the use of providers, or the disk devices in [.filename]#/dev#. By supporting various software RAID configurations, GEOM transparently provides access to the operating system and operating system utilities. This chapter covers the use of disks under the GEOM framework in FreeBSD. This includes the major RAID control utilities which use the framework for configuration. This chapter is not a definitive guide to RAID configurations and only GEOM-supported RAID classifications are discussed. -After reading this chapter, you will know: +Read this chapter to learn: * What type of RAID support is available through GEOM. * How to use the base utilities to configure, maintain, and manipulate the various RAID levels. * How to mirror, stripe, encrypt, and remotely connect disk devices through GEOM. * How to troubleshoot disks attached to the GEOM framework. -Before reading this chapter, you should: +Before reading this chapter: * Understand how FreeBSD treats disk devices (crossref:disks[disks,Storage]). * Know how to configure and install a new kernel (crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]). [[geom-striping]] == RAID0 - Striping Striping combines several disk drives into a single volume. Striping can be performed through the use of hardware RAID controllers. The GEOM disk subsystem provides software support for disk striping, also known as RAID0, without the need for a RAID disk controller. In RAID0, data is split into blocks that are written across all the drives in the array. As seen in the following illustration, instead of having to wait on the system to write 256k to one disk, RAID0 can simultaneously write 64k to each of the four disks in the array, offering superior I/O performance. This performance can be enhanced further by using multiple disk controllers. image::striping.png[Disk Striping Illustration] Each disk in a RAID0 stripe must be of the same size, since I/O requests are interleaved to read or write to multiple disks in parallel. [NOTE] ==== RAID0 does _not_ provide any redundancy. This means that if one disk in the array fails, all of the data on the disks is lost. If the data is important, implement a backup strategy that regularly saves backups to a remote system or device. ==== The process for creating a software, GEOM-based RAID0 on a FreeBSD system using commodity disks is as follows. Once the stripe is created, refer to man:gstripe[8] for more information on how to control an existing stripe. [.procedure] **** *Procedure: Creating a Stripe of Unformatted ATA Disks* . Load the [.filename]#geom_stripe.ko# module: + [source,shell] .... # kldload geom_stripe .... . Ensure that a suitable mount point exists. If this volume will become a root partition, then temporarily use another mount point such as [.filename]#/mnt#. . Determine the device names for the disks which will be striped, and create the new stripe device. For example, to stripe two unused and unpartitioned ATA disks with device names of [.filename]#/dev/ad2# and [.filename]#/dev/ad3#: + [source,shell] .... # gstripe label -v st0 /dev/ad2 /dev/ad3 Metadata value stored on /dev/ad2. Metadata value stored on /dev/ad3. Done. .... . Write a standard label, also known as a partition table, on the new volume and install the default bootstrap code: + [source,shell] .... # bsdlabel -wB /dev/stripe/st0 .... . This process should create two other devices in [.filename]#/dev/stripe# in addition to [.filename]#st0#. Those include [.filename]#st0a# and [.filename]#st0c#. At this point, a UFS file system can be created on [.filename]#st0a# using `newfs`: + [source,shell] .... # newfs -U /dev/stripe/st0a .... + Many numbers will glide across the screen, and after a few seconds, the process will be complete. The volume has been created and is ready to be mounted. . To manually mount the created disk stripe: + [source,shell] .... # mount /dev/stripe/st0a /mnt .... . To mount this striped file system automatically during the boot process, place the volume information in [.filename]#/etc/fstab#. In this example, a permanent mount point, named [.filename]#stripe#, is created: + [source,shell] .... # mkdir /stripe # echo "/dev/stripe/st0a /stripe ufs rw 2 2" \ >> /etc/fstab .... . The [.filename]#geom_stripe.ko# module must also be automatically loaded during system initialization, by adding a line to [.filename]#/boot/loader.conf#: + [source,shell] .... # echo 'geom_stripe_load="YES"' >> /boot/loader.conf .... **** [[geom-mirror]] == RAID1 - Mirroring RAID1, or _mirroring_, is the technique of writing the same data to more than one disk drive. Mirrors are usually used to guard against data loss due to drive failure. Each drive in a mirror contains an identical copy of the data. When an individual drive fails, the mirror continues to work, providing data from the drives that are still functioning. The computer keeps running, and the administrator has time to replace the failed drive without user interruption. Two common situations are illustrated in these examples. The first creates a mirror out of two new drives and uses it as a replacement for an existing single drive. The second example creates a mirror on a single new drive, copies the old drive's data to it, then inserts the old drive into the mirror. While this procedure is slightly more complicated, it only requires one new drive. Traditionally, the two drives in a mirror are identical in model and capacity, but man:gmirror[8] does not require that. Mirrors created with dissimilar drives will have a capacity equal to that of the smallest drive in the mirror. Extra space on larger drives will be unused. Drives inserted into the mirror later must have at least as much capacity as the smallest drive already in the mirror. [WARNING] ==== The mirroring procedures shown here are non-destructive, but as with any major disk operation, make a full backup first. ==== [WARNING] ==== While man:dump[8] is used in these procedures to copy file systems, it does not work on file systems with soft updates journaling. See man:tunefs[8] for information on detecting and disabling soft updates journaling. ==== [[geom-mirror-metadata]] === Metadata Issues Many disk systems store metadata at the end of each disk. Old metadata should be erased before reusing the disk for a mirror. Most problems are caused by two particular types of leftover metadata: GPT partition tables and old metadata from a previous mirror. GPT metadata can be erased with man:gpart[8]. This example erases both primary and backup GPT partition tables from disk [.filename]#ada8#: [source,shell] .... # gpart destroy -F ada8 .... A disk can be removed from an active mirror and the metadata erased in one step using man:gmirror[8]. Here, the example disk [.filename]#ada8# is removed from the active mirror [.filename]#gm4#: [source,shell] .... # gmirror remove gm4 ada8 .... If the mirror is not running, but old mirror metadata is still on the disk, use `gmirror clear` to remove it: [source,shell] .... # gmirror clear ada8 .... man:gmirror[8] stores one block of metadata at the end of the disk. As GPT partition schemes also store metadata at the end of the disk, mirroring entire GPT disks with man:gmirror[8] is not recommended. MBR partitioning is used here because it only stores a partition table at the start of the disk and does not conflict with the mirror metadata. [[geom-mirror-two-new-disks]] === Creating a Mirror with Two New Disks In this example, FreeBSD has already been installed on a single disk, [.filename]#ada0#. Two new disks, [.filename]#ada1# and [.filename]#ada2#, have been connected to the system. A new mirror will be created on these two disks and used to replace the old single disk. The [.filename]#geom_mirror.ko# kernel module must either be built into the kernel or loaded at boot- or run-time. Manually load the kernel module now: [source,shell] .... # gmirror load .... Create the mirror with the two new drives: [source,shell] .... # gmirror label -v gm0 /dev/ada1 /dev/ada2 .... [.filename]#gm0# is a user-chosen device name assigned to the new mirror. After the mirror has been started, this device name appears in [.filename]#/dev/mirror/#. MBR and bsdlabel partition tables can now be created on the mirror with man:gpart[8]. This example uses a traditional file system layout, with partitions for [.filename]#/#, swap, [.filename]#/var#, [.filename]#/tmp#, and [.filename]#/usr#. A single [.filename]#/# and a swap partition will also work. Partitions on the mirror do not have to be the same size as those on the existing disk, but they must be large enough to hold all the data already present on [.filename]#ada0#. [source,shell] .... # gpart create -s MBR mirror/gm0 # gpart add -t freebsd -a 4k mirror/gm0 # gpart show mirror/gm0 => 63 156301423 mirror/gm0 MBR (74G) 63 63 - free - (31k) 126 156301299 1 freebsd (74G) 156301425 61 - free - (30k) .... [source,shell] .... # gpart create -s BSD mirror/gm0s1 # gpart add -t freebsd-ufs -a 4k -s 2g mirror/gm0s1 # gpart add -t freebsd-swap -a 4k -s 4g mirror/gm0s1 # gpart add -t freebsd-ufs -a 4k -s 2g mirror/gm0s1 # gpart add -t freebsd-ufs -a 4k -s 1g mirror/gm0s1 # gpart add -t freebsd-ufs -a 4k mirror/gm0s1 # gpart show mirror/gm0s1 => 0 156301299 mirror/gm0s1 BSD (74G) 0 2 - free - (1.0k) 2 4194304 1 freebsd-ufs (2.0G) 4194306 8388608 2 freebsd-swap (4.0G) 12582914 4194304 4 freebsd-ufs (2.0G) 16777218 2097152 5 freebsd-ufs (1.0G) 18874370 137426928 6 freebsd-ufs (65G) 156301298 1 - free - (512B) .... Make the mirror bootable by installing bootcode in the MBR and bsdlabel and setting the active slice: [source,shell] .... # gpart bootcode -b /boot/mbr mirror/gm0 # gpart set -a active -i 1 mirror/gm0 # gpart bootcode -b /boot/boot mirror/gm0s1 .... Format the file systems on the new mirror, enabling soft-updates. [source,shell] .... # newfs -U /dev/mirror/gm0s1a # newfs -U /dev/mirror/gm0s1d # newfs -U /dev/mirror/gm0s1e # newfs -U /dev/mirror/gm0s1f .... File systems from the original [.filename]#ada0# disk can now be copied onto the mirror with man:dump[8] and man:restore[8]. [source,shell] .... # mount /dev/mirror/gm0s1a /mnt # dump -C16 -b64 -0aL -f - / | (cd /mnt && restore -rf -) # mount /dev/mirror/gm0s1d /mnt/var # mount /dev/mirror/gm0s1e /mnt/tmp # mount /dev/mirror/gm0s1f /mnt/usr # dump -C16 -b64 -0aL -f - /var | (cd /mnt/var && restore -rf -) # dump -C16 -b64 -0aL -f - /tmp | (cd /mnt/tmp && restore -rf -) # dump -C16 -b64 -0aL -f - /usr | (cd /mnt/usr && restore -rf -) .... Edit [.filename]#/mnt/etc/fstab# to point to the new mirror file systems: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# /dev/mirror/gm0s1a / ufs rw 1 1 /dev/mirror/gm0s1b none swap sw 0 0 /dev/mirror/gm0s1d /var ufs rw 2 2 /dev/mirror/gm0s1e /tmp ufs rw 2 2 /dev/mirror/gm0s1f /usr ufs rw 2 2 .... If the [.filename]#geom_mirror.ko# kernel module has not been built into the kernel, [.filename]#/mnt/boot/loader.conf# is edited to load the module at boot: [.programlisting] .... geom_mirror_load="YES" .... Reboot the system to test the new mirror and verify that all data has been copied. The BIOS will see the mirror as two individual drives rather than a mirror. Since the drives are identical, it does not matter which is selected to boot. See crossref:geom[gmirror-troubleshooting, Troubleshooting] if there are problems booting. Powering down and disconnecting the original [.filename]#ada0# disk will allow it to be kept as an offline backup. In use, the mirror will behave just like the original single drive. [[geom-mirror-existing-drive]] === Creating a Mirror with an Existing Drive In this example, FreeBSD has already been installed on a single disk, [.filename]#ada0#. A new disk, [.filename]#ada1#, has been connected to the system. A one-disk mirror will be created on the new disk, the existing system copied onto it, and then the old disk will be inserted into the mirror. This slightly complex procedure is required because `gmirror` needs to put a 512-byte block of metadata at the end of each disk, and the existing [.filename]#ada0# has usually had all of its space already allocated. Load the [.filename]#geom_mirror.ko# kernel module: [source,shell] .... # gmirror load .... Check the media size of the original disk with `diskinfo`: [source,shell] .... # diskinfo -v ada0 | head -n3 /dev/ada0 512 # sectorsize 1000204821504 # mediasize in bytes (931G) .... Create a mirror on the new disk. To make certain that the mirror capacity is not any larger than the original [.filename]#ada0# drive, man:gnop[8] is used to create a fake drive of the same size. This drive does not store any data, but is used only to limit the size of the mirror. When man:gmirror[8] creates the mirror, it will restrict the capacity to the size of [.filename]#gzero.nop#, even if the new [.filename]#ada1# drive has more space. Note that the _1000204821504_ in the second line is equal to [.filename]#ada0#'s media size as shown by `diskinfo` above. [source,shell] .... # geom zero load # gnop create -s 1000204821504 gzero # gmirror label -v gm0 gzero.nop ada1 # gmirror forget gm0 .... Since [.filename]#gzero.nop# does not store any data, the mirror does not see it as connected. The mirror is told to "forget" unconnected components, removing references to [.filename]#gzero.nop#. The result is a mirror device containing only a single disk, [.filename]#ada1#. After creating [.filename]#gm0#, view the partition table on [.filename]#ada0#. This output is from a 1 TB drive. If there is some unallocated space at the end of the drive, the contents may be copied directly from [.filename]#ada0# to the new mirror. However, if the output shows that all of the space on the disk is allocated, as in the following listing, there is no space available for the 512-byte mirror metadata at the end of the disk. [source,shell] .... # gpart show ada0 => 63 1953525105 ada0 MBR (931G) 63 1953525105 1 freebsd [active] (931G) .... In this case, the partition table must be edited to reduce the capacity by one sector on [.filename]#mirror/gm0#. The procedure will be explained later. In either case, partition tables on the primary disk should be first copied using `gpart backup` and `gpart restore`. [source,shell] .... # gpart backup ada0 > table.ada0 # gpart backup ada0s1 > table.ada0s1 .... These commands create two files, [.filename]#table.ada0# and [.filename]#table.ada0s1#. This example is from a 1 TB drive: [source,shell] .... # cat table.ada0 MBR 4 1 freebsd 63 1953525105 [active] .... [source,shell] .... # cat table.ada0s1 BSD 8 1 freebsd-ufs 0 4194304 2 freebsd-swap 4194304 33554432 4 freebsd-ufs 37748736 50331648 5 freebsd-ufs 88080384 41943040 6 freebsd-ufs 130023424 838860800 7 freebsd-ufs 968884224 984640881 .... If no free space is shown at the end of the disk, the size of both the slice and the last partition must be reduced by one sector. Edit the two files, reducing the size of both the slice and last partition by one. These are the last numbers in each listing. [source,shell] .... # cat table.ada0 MBR 4 1 freebsd 63 1953525104 [active] .... [source,shell] .... # cat table.ada0s1 BSD 8 1 freebsd-ufs 0 4194304 2 freebsd-swap 4194304 33554432 4 freebsd-ufs 37748736 50331648 5 freebsd-ufs 88080384 41943040 6 freebsd-ufs 130023424 838860800 7 freebsd-ufs 968884224 984640880 .... If at least one sector was unallocated at the end of the disk, these two files can be used without modification. Now restore the partition table into [.filename]#mirror/gm0#: [source,shell] .... # gpart restore mirror/gm0 < table.ada0 # gpart restore mirror/gm0s1 < table.ada0s1 .... Check the partition table with `gpart show`. This example has [.filename]#gm0s1a# for [.filename]#/#, [.filename]#gm0s1d# for [.filename]#/var#, [.filename]#gm0s1e# for [.filename]#/usr#, [.filename]#gm0s1f# for [.filename]#/data1#, and [.filename]#gm0s1g# for [.filename]#/data2#. [source,shell] .... # gpart show mirror/gm0 => 63 1953525104 mirror/gm0 MBR (931G) 63 1953525042 1 freebsd [active] (931G) 1953525105 62 - free - (31k) # gpart show mirror/gm0s1 => 0 1953525042 mirror/gm0s1 BSD (931G) 0 2097152 1 freebsd-ufs (1.0G) 2097152 16777216 2 freebsd-swap (8.0G) 18874368 41943040 4 freebsd-ufs (20G) 60817408 20971520 5 freebsd-ufs (10G) 81788928 629145600 6 freebsd-ufs (300G) 710934528 1242590514 7 freebsd-ufs (592G) 1953525042 63 - free - (31k) .... Both the slice and the last partition must have at least one free block at the end of the disk. Create file systems on these new partitions. The number of partitions will vary to match the original disk, [.filename]#ada0#. [source,shell] .... # newfs -U /dev/mirror/gm0s1a # newfs -U /dev/mirror/gm0s1d # newfs -U /dev/mirror/gm0s1e # newfs -U /dev/mirror/gm0s1f # newfs -U /dev/mirror/gm0s1g .... Make the mirror bootable by installing bootcode in the MBR and bsdlabel and setting the active slice: [source,shell] .... # gpart bootcode -b /boot/mbr mirror/gm0 # gpart set -a active -i 1 mirror/gm0 # gpart bootcode -b /boot/boot mirror/gm0s1 .... Adjust [.filename]#/etc/fstab# to use the new partitions on the mirror. Back up this file first by copying it to [.filename]#/etc/fstab.orig#. [source,shell] .... # cp /etc/fstab /etc/fstab.orig .... Edit [.filename]#/etc/fstab#, replacing [.filename]#/dev/ada0# with [.filename]#mirror/gm0#. [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# /dev/mirror/gm0s1a / ufs rw 1 1 /dev/mirror/gm0s1b none swap sw 0 0 /dev/mirror/gm0s1d /var ufs rw 2 2 /dev/mirror/gm0s1e /usr ufs rw 2 2 /dev/mirror/gm0s1f /data1 ufs rw 2 2 /dev/mirror/gm0s1g /data2 ufs rw 2 2 .... If the [.filename]#geom_mirror.ko# kernel module has not been built into the kernel, edit [.filename]#/boot/loader.conf# to load it at boot: [.programlisting] .... geom_mirror_load="YES" .... File systems from the original disk can now be copied onto the mirror with man:dump[8] and man:restore[8]. Each file system dumped with `dump -L` will create a snapshot first, which can take some time. [source,shell] .... # mount /dev/mirror/gm0s1a /mnt # dump -C16 -b64 -0aL -f - / | (cd /mnt && restore -rf -) # mount /dev/mirror/gm0s1d /mnt/var # mount /dev/mirror/gm0s1e /mnt/usr # mount /dev/mirror/gm0s1f /mnt/data1 # mount /dev/mirror/gm0s1g /mnt/data2 # dump -C16 -b64 -0aL -f - /usr | (cd /mnt/usr && restore -rf -) # dump -C16 -b64 -0aL -f - /var | (cd /mnt/var && restore -rf -) # dump -C16 -b64 -0aL -f - /data1 | (cd /mnt/data1 && restore -rf -) # dump -C16 -b64 -0aL -f - /data2 | (cd /mnt/data2 && restore -rf -) .... Restart the system, booting from [.filename]#ada1#. If everything is working, the system will boot from [.filename]#mirror/gm0#, which now contains the same data as [.filename]#ada0# had previously. See crossref:geom[gmirror-troubleshooting, Troubleshooting] if there are problems booting. At this point, the mirror still consists of only the single [.filename]#ada1# disk. After booting from [.filename]#mirror/gm0# successfully, the final step is inserting [.filename]#ada0# into the mirror. [IMPORTANT] ==== When [.filename]#ada0# is inserted into the mirror, its former contents will be overwritten by data from the mirror. Make certain that [.filename]#mirror/gm0# has the same contents as [.filename]#ada0# before adding [.filename]#ada0# to the mirror. If the contents previously copied by man:dump[8] and man:restore[8] are not identical to what was on [.filename]#ada0#, revert [.filename]#/etc/fstab# to mount the file systems on [.filename]#ada0#, reboot, and start the whole procedure again. ==== [source,shell] .... # gmirror insert gm0 ada0 GEOM_MIRROR: Device gm0: rebuilding provider ada0 .... Synchronization between the two disks will start immediately. Use `gmirror status` to view the progress. [source,shell] .... # gmirror status Name Status Components mirror/gm0 DEGRADED ada1 (ACTIVE) ada0 (SYNCHRONIZING, 64%) .... After a while, synchronization will finish. [source,shell] .... GEOM_MIRROR: Device gm0: rebuilding provider ada0 finished. # gmirror status Name Status Components mirror/gm0 COMPLETE ada1 (ACTIVE) ada0 (ACTIVE) .... [.filename]#mirror/gm0# now consists of the two disks [.filename]#ada0# and [.filename]#ada1#, and the contents are automatically synchronized with each other. In use, [.filename]#mirror/gm0# will behave just like the original single drive. [[gmirror-troubleshooting]] === Troubleshooting If the system no longer boots, BIOS settings may have to be changed to boot from one of the new mirrored drives. Either mirror drive can be used for booting, as they contain identical data. If the boot stops with this message, something is wrong with the mirror device: [source,shell] .... Mounting from ufs:/dev/mirror/gm0s1a failed with error 19. Loader variables: vfs.root.mountfrom=ufs:/dev/mirror/gm0s1a vfs.root.mountfrom.options=rw Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. e.g. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> .... Forgetting to load the [.filename]#geom_mirror.ko# module in [.filename]#/boot/loader.conf# can cause this problem. To fix it, boot from a FreeBSD installation media and choose `Shell` at the first prompt. Then load the mirror module and mount the mirror device: [source,shell] .... # gmirror load # mount /dev/mirror/gm0s1a /mnt .... Edit [.filename]#/mnt/boot/loader.conf#, adding a line to load the mirror module: [.programlisting] .... geom_mirror_load="YES" .... Save the file and reboot. Other problems that cause `error 19` require more effort to fix. Although the system should boot from [.filename]#ada0#, another prompt to select a shell will appear if [.filename]#/etc/fstab# is incorrect. Enter `ufs:/dev/ada0s1a` at the boot loader prompt and press kbd:[Enter]. Undo the edits in [.filename]#/etc/fstab# then mount the file systems from the original disk ([.filename]#ada0#) instead of the mirror. Reboot the system and try the procedure again. [source,shell] .... Enter full pathname of shell or RETURN for /bin/sh: # cp /etc/fstab.orig /etc/fstab # reboot .... === Recovering from Disk Failure The benefit of disk mirroring is that an individual disk can fail without causing the mirror to lose any data. In the above example, if [.filename]#ada0# fails, the mirror will continue to work, providing data from the remaining working drive, [.filename]#ada1#. To replace the failed drive, shut down the system and physically replace the failed drive with a new drive of equal or greater capacity. Manufacturers use somewhat arbitrary values when rating drives in gigabytes, and the only way to really be sure is to compare the total count of sectors shown by `diskinfo -v`. A drive with larger capacity than the mirror will work, although the extra space on the new drive will not be used. After the computer is powered back up, the mirror will be running in a "degraded" mode with only one drive. The mirror is told to forget drives that are not currently connected: [source,shell] .... # gmirror forget gm0 .... Any old metadata should be cleared from the replacement disk using the instructions in crossref:geom[geom-mirror-metadata, Metadata Issues]. Then the replacement disk, [.filename]#ada4# for this example, is inserted into the mirror: [source,shell] .... # gmirror insert gm0 /dev/ada4 .... Resynchronization begins when the new drive is inserted into the mirror. This process of copying mirror data to a new drive can take a while. Performance of the mirror will be greatly reduced during the copy, so inserting new drives is best done when there is low demand on the computer. Progress can be monitored with `gmirror status`, which shows drives that are being synchronized and the percentage of completion. During resynchronization, the status will be `DEGRADED`, changing to `COMPLETE` when the process is finished. [[geom-raid3]] == RAID3 - Byte-level Striping with Dedicated Parity RAID3 is a method used to combine several disk drives into a single volume with a dedicated parity disk. In a RAID3 system, data is split up into a number of bytes that are written across all the drives in the array except for one disk which acts as a dedicated parity disk. This means that disk reads from a RAID3 implementation access all disks in the array. Performance can be enhanced by using multiple disk controllers. The RAID3 array provides a fault tolerance of 1 drive, while providing a capacity of 1 - 1/n times the total capacity of all drives in the array, where n is the number of hard drives in the array. Such a configuration is mostly suitable for storing data of larger sizes such as multimedia files. At least 3 physical hard drives are required to build a RAID3 array. Each disk must be of the same size, since I/O requests are interleaved to read or write to multiple disks in parallel. Also, due to the nature of RAID3, the number of drives must be equal to 3, 5, 9, 17, and so on, or 2^n + 1. This section demonstrates how to create a software RAID3 on a FreeBSD system. [NOTE] ==== While it is theoretically possible to boot from a RAID3 array on FreeBSD, that configuration is uncommon and is not advised. ==== === Creating a Dedicated RAID3 Array In FreeBSD, support for RAID3 is implemented by the man:graid3[8] GEOM class. Creating a dedicated RAID3 array on FreeBSD requires the following steps. [.procedure] . First, load the [.filename]#geom_raid3.ko# kernel module by issuing one of the following commands: + [source,shell] .... # graid3 load .... + or: + [source,shell] .... # kldload geom_raid3 .... . Ensure that a suitable mount point exists. This command creates a new directory to use as the mount point: + [source,shell] .... # mkdir /multimedia .... . Determine the device names for the disks which will be added to the array, and create the new RAID3 device. The final device listed will act as the dedicated parity disk. This example uses three unpartitioned ATA drives: [.filename]#ada1# and [.filename]#ada2# for data, and [.filename]#ada3# for parity. + [source,shell] .... # graid3 label -v gr0 /dev/ada1 /dev/ada2 /dev/ada3 Metadata value stored on /dev/ada1. Metadata value stored on /dev/ada2. Metadata value stored on /dev/ada3. Done. .... . Partition the newly created [.filename]#gr0# device and put a UFS file system on it: + [source,shell] .... # gpart create -s GPT /dev/raid3/gr0 # gpart add -t freebsd-ufs /dev/raid3/gr0 # newfs -j /dev/raid3/gr0p1 .... + Many numbers will glide across the screen, and after a bit of time, the process will be complete. The volume has been created and is ready to be mounted: + [source,shell] .... # mount /dev/raid3/gr0p1 /multimedia/ .... + The RAID3 array is now ready to use. Additional configuration is needed to retain this setup across system reboots. [.procedure] . The [.filename]#geom_raid3.ko# module must be loaded before the array can be mounted. To automatically load the kernel module during system initialization, add the following line to [.filename]#/boot/loader.conf#: + [.programlisting] .... geom_raid3_load="YES" .... . The following volume information must be added to [.filename]#/etc/fstab# in order to automatically mount the array's file system during the system boot process: + [.programlisting] .... /dev/raid3/gr0p1 /multimedia ufs rw 2 2 .... [[geom-graid]] == Software RAID Devices Some motherboards and expansion cards add some simple hardware, usually just a ROM, that allows the computer to boot from a RAID array. After booting, access to the RAID array is handled by software running on the computer's main processor. This "hardware-assisted software RAID" gives RAID arrays that are not dependent on any particular operating system, and which are functional even before an operating system is loaded. Several levels of RAID are supported, depending on the hardware in use. See man:graid[8] for a complete list. man:graid[8] requires the [.filename]#geom_raid.ko# kernel module, which is included in the [.filename]#GENERIC# kernel starting with FreeBSD 9.1. If needed, it can be loaded manually with `graid load`. [[geom-graid-creating]] === Creating an Array Software RAID devices often have a menu that can be entered by pressing special keys when the computer is booting. The menu can be used to create and delete RAID arrays. man:graid[8] can also create arrays directly from the command line. `graid label` is used to create a new array. The motherboard used for this example has an Intel software RAID chipset, so the Intel metadata format is specified. The new array is given a label of [.filename]#gm0#, it is a mirror (RAID1), and uses drives [.filename]#ada0# and [.filename]#ada1#. [CAUTION] ==== Some space on the drives will be overwritten when they are made into a new array. Back up existing data first! ==== [source,shell] .... # graid label Intel gm0 RAID1 ada0 ada1 GEOM_RAID: Intel-a29ea104: Array Intel-a29ea104 created. GEOM_RAID: Intel-a29ea104: Disk ada0 state changed from NONE to ACTIVE. GEOM_RAID: Intel-a29ea104: Subdisk gm0:0-ada0 state changed from NONE to ACTIVE. GEOM_RAID: Intel-a29ea104: Disk ada1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-a29ea104: Subdisk gm0:1-ada1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-a29ea104: Array started. GEOM_RAID: Intel-a29ea104: Volume gm0 state changed from STARTING to OPTIMAL. Intel-a29ea104 created GEOM_RAID: Intel-a29ea104: Provider raid/r0 for volume gm0 created. .... A status check shows the new mirror is ready for use: [source,shell] .... # graid status Name Status Components raid/r0 OPTIMAL ada0 (ACTIVE (ACTIVE)) ada1 (ACTIVE (ACTIVE)) .... The array device appears in [.filename]#/dev/raid/#. The first array is called [.filename]#r0#. Additional arrays, if present, will be [.filename]#r1#, [.filename]#r2#, and so on. The BIOS menu on some of these devices can create arrays with special characters in their names. To avoid problems with those special characters, arrays are given simple numbered names like [.filename]#r0#. To show the actual labels, like [.filename]#gm0# in the example above, use man:sysctl[8]: [source,shell] .... # sysctl kern.geom.raid.name_format=1 .... [[geom-graid-volumes]] === Multiple Volumes Some software RAID devices support more than one _volume_ on an array. Volumes work like partitions, allowing space on the physical drives to be split and used in different ways. For example, Intel software RAID devices support two volumes. This example creates a 40 G mirror for safely storing the operating system, followed by a 20 G RAID0 (stripe) volume for fast temporary storage: [source,shell] .... # graid label -S 40G Intel gm0 RAID1 ada0 ada1 # graid add -S 20G gm0 RAID0 .... Volumes appear as additional [.filename]#rX# entries in [.filename]#/dev/raid/#. An array with two volumes will show [.filename]#r0# and [.filename]#r1#. See man:graid[8] for the number of volumes supported by different software RAID devices. [[geom-graid-converting]] === Converting a Single Drive to a Mirror Under certain specific conditions, it is possible to convert an existing single drive to a man:graid[8] array without reformatting. To avoid data loss during the conversion, the existing drive must meet these minimum requirements: * The drive must be partitioned with the MBR partitioning scheme. GPT or other partitioning schemes with metadata at the end of the drive will be overwritten and corrupted by the man:graid[8] metadata. * There must be enough unpartitioned and unused space at the end of the drive to hold the man:graid[8] metadata. This metadata varies in size, but the largest occupies 64 M, so at least that much free space is recommended. If the drive meets these requirements, start by making a full backup. Then create a single-drive mirror with that drive: [source,shell] .... # graid label Intel gm0 RAID1 ada0 NONE .... man:graid[8] metadata was written to the end of the drive in the unused space. A second drive can now be inserted into the mirror: [source,shell] .... # graid insert raid/r0 ada1 .... Data from the original drive will immediately begin to be copied to the second drive. The mirror will operate in degraded status until the copy is complete. [[geom-graid-inserting]] === Inserting New Drives into the Array Drives can be inserted into an array as replacements for drives that have failed or are missing. If there are no failed or missing drives, the new drive becomes a spare. For example, inserting a new drive into a working two-drive mirror results in a two-drive mirror with one spare drive, not a three-drive mirror. In the example mirror array, data immediately begins to be copied to the newly-inserted drive. Any existing information on the new drive will be overwritten. [source,shell] .... # graid insert raid/r0 ada1 GEOM_RAID: Intel-a29ea104: Disk ada1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-a29ea104: Subdisk gm0:1-ada1 state changed from NONE to NEW. GEOM_RAID: Intel-a29ea104: Subdisk gm0:1-ada1 state changed from NEW to REBUILD. GEOM_RAID: Intel-a29ea104: Subdisk gm0:1-ada1 rebuild start at 0. .... [[geom-graid-removing]] === Removing Drives from the Array Individual drives can be permanently removed from a from an array and their metadata erased: [source,shell] .... # graid remove raid/r0 ada1 GEOM_RAID: Intel-a29ea104: Disk ada1 state changed from ACTIVE to OFFLINE. GEOM_RAID: Intel-a29ea104: Subdisk gm0:1-[unknown] state changed from ACTIVE to NONE. GEOM_RAID: Intel-a29ea104: Volume gm0 state changed from OPTIMAL to DEGRADED. .... [[geom-graid-stopping]] === Stopping the Array An array can be stopped without removing metadata from the drives. The array will be restarted when the system is booted. [source,shell] .... # graid stop raid/r0 .... [[geom-graid-status]] === Checking Array Status Array status can be checked at any time. After a drive was added to the mirror in the example above, data is being copied from the original drive to the new drive: [source,shell] .... # graid status Name Status Components raid/r0 DEGRADED ada0 (ACTIVE (ACTIVE)) ada1 (ACTIVE (REBUILD 28%)) .... Some types of arrays, like `RAID0` or `CONCAT`, may not be shown in the status report if disks have failed. To see these partially-failed arrays, add `-ga`: [source,shell] .... # graid status -ga Name Status Components Intel-e2d07d9a BROKEN ada6 (ACTIVE (ACTIVE)) .... [[geom-graid-deleting]] === Deleting Arrays Arrays are destroyed by deleting all of the volumes from them. When the last volume present is deleted, the array is stopped and metadata is removed from the drives: [source,shell] .... # graid delete raid/r0 .... [[geom-graid-unexpected]] === Deleting Unexpected Arrays Drives may unexpectedly contain man:graid[8] metadata, either from previous use or manufacturer testing. man:graid[8] will detect these drives and create an array, interfering with access to the individual drive. To remove the unwanted metadata: [.procedure] . Boot the system. At the boot menu, select `2` for the loader prompt. Enter: + [source,shell] .... OK set kern.geom.raid.enable=0 OK boot .... + The system will boot with man:graid[8] disabled. . Back up all data on the affected drive. . As a workaround, man:graid[8] array detection can be disabled by adding + [.programlisting] .... kern.geom.raid.enable=0 .... + to [.filename]#/boot/loader.conf#. + To permanently remove the man:graid[8] metadata from the affected drive, boot a FreeBSD installation CD-ROM or memory stick, and select `Shell`. Use `status` to find the name of the array, typically `raid/r0`: + [source,shell] .... # graid status Name Status Components raid/r0 OPTIMAL ada0 (ACTIVE (ACTIVE)) ada1 (ACTIVE (ACTIVE)) .... + Delete the volume by name: + [source,shell] .... # graid delete raid/r0 .... + If there is more than one volume shown, repeat the process for each volume. After the last array has been deleted, the volume will be destroyed. + Reboot and verify data, restoring from backup if necessary. After the metadata has been removed, the `kern.geom.raid.enable=0` entry in [.filename]#/boot/loader.conf# can also be removed. [[geom-ggate]] == GEOM Gate Network GEOM provides a simple mechanism for providing remote access to devices such as disks, CDs, and file systems through the use of the GEOM Gate network daemon, ggated. The system with the device runs the server daemon which handles requests made by clients using ggatec. The devices should not contain any sensitive data as the connection between the client and the server is not encrypted. Similar to NFS, which is discussed in crossref:network-servers[network-nfs,"Network File System (NFS)"], ggated is configured using an exports file. This file specifies which systems are permitted to access the exported resources and what level of access they are offered. For example, to give the client `192.168.1.5` read and write access to the fourth slice on the first SCSI disk, create [.filename]#/etc/gg.exports# with this line: [.programlisting] .... 192.168.1.5 RW /dev/da0s4d .... Before exporting the device, ensure it is not currently mounted. Then, start ggated: [source,shell] .... # ggated .... Several options are available for specifying an alternate listening port or changing the default location of the exports file. Refer to man:ggated[8] for details. To access the exported device on the client machine, first use `ggatec` to specify the IP address of the server and the device name of the exported device. If successful, this command will display a `ggate` device name to mount. Mount that specified device name on a free mount point. This example connects to the [.filename]#/dev/da0s4d# partition on `192.168.1.1`, then mounts [.filename]#/dev/ggate0# on [.filename]#/mnt#: [source,shell] .... # ggatec create -o rw 192.168.1.1 /dev/da0s4d ggate0 # mount /dev/ggate0 /mnt .... The device on the server may now be accessed through [.filename]#/mnt# on the client. For more details about `ggatec` and a few usage examples, refer to man:ggatec[8]. [NOTE] ==== The mount will fail if the device is currently mounted on either the server or any other client on the network. If simultaneous access is needed to network resources, use NFS instead. ==== When the device is no longer needed, unmount it with `umount` so that the resource is available to other clients. [[geom-glabel]] == Labeling Disk Devices During system initialization, the FreeBSD kernel creates device nodes as devices are found. This method of probing for devices raises some issues. For instance, what if a new disk device is added via USB? It is likely that a flash device may be handed the device name of [.filename]#da0# and the original [.filename]#da0# shifted to [.filename]#da1#. This will cause issues mounting file systems if they are listed in [.filename]#/etc/fstab# which may also prevent the system from booting. One solution is to chain SCSI devices in order so a new device added to the SCSI card will be issued unused device numbers. But what about USB devices which may replace the primary SCSI disk? This happens because USB devices are usually probed before the SCSI card. One solution is to only insert these devices after the system has been booted. Another method is to use only a single ATA drive and never list the SCSI devices in [.filename]#/etc/fstab#. A better solution is to use `glabel` to label the disk devices and use the labels in [.filename]#/etc/fstab#. Since `glabel` stores the label in the last sector of a given provider, the label will remain persistent across reboots. By using this label as a device, the file-system may always be mounted regardless of what device node it is accessed through. [NOTE] ==== `glabel` can create both transient and permanent labels. Only permanent labels are consistent across reboots. Refer to man:glabel[8] for more information on the differences between labels. ==== === Label Types and Examples Permanent labels can be a generic or a file system label. Permanent file system labels can be created with man:tunefs[8] or man:newfs[8]. These types of labels are created in a sub-directory of [.filename]#/dev#, and will be named according to the file system type. For example, UFS2 file system labels will be created in [.filename]#/dev/ufs#. Generic permanent labels can be created with `glabel label`. These are not file system specific and will be created in [.filename]#/dev/label#. Temporary labels are destroyed at the next reboot. These labels are created in [.filename]#/dev/label# and are suited to experimentation. A temporary label can be created using `glabel create`. To create a permanent label for a UFS2 file system without destroying any data, issue the following command: [source,shell] .... # tunefs -L home /dev/da3 .... A label should now exist in [.filename]#/dev/ufs# which may be added to [.filename]#/etc/fstab#: [.programlisting] .... /dev/ufs/home /home ufs rw 2 2 .... [NOTE] ==== The file system must not be mounted while attempting to run `tunefs`. ==== Now the file system may be mounted: [source,shell] .... # mount /home .... From this point on, so long as the [.filename]#geom_label.ko# kernel module is loaded at boot with [.filename]#/boot/loader.conf# or the `GEOM_LABEL` kernel option is present, the device node may change without any ill effect on the system. File systems may also be created with a default label by using the `-L` flag with `newfs`. Refer to man:newfs[8] for more information. The following command can be used to destroy the label: [source,shell] .... # glabel destroy home .... The following example shows how to label the partitions of a boot disk. .Labeling Partitions on the Boot Disk [example] ==== By permanently labeling the partitions on the boot disk, the system should be able to continue to boot normally, even if the disk is moved to another controller or transferred to a different system. For this example, it is assumed that a single ATA disk is used, which is currently recognized by the system as [.filename]#ad0#. It is also assumed that the standard FreeBSD partition scheme is used, with [.filename]#/#, [.filename]#/var#, [.filename]#/usr# and [.filename]#/tmp#, as well as a swap partition. Reboot the system, and at the man:loader[8] prompt, press kbd:[4] to boot into single user mode. Then enter the following commands: [source,shell] .... # glabel label rootfs /dev/ad0s1a GEOM_LABEL: Label for provider /dev/ad0s1a is label/rootfs # glabel label var /dev/ad0s1d GEOM_LABEL: Label for provider /dev/ad0s1d is label/var # glabel label usr /dev/ad0s1f GEOM_LABEL: Label for provider /dev/ad0s1f is label/usr # glabel label tmp /dev/ad0s1e GEOM_LABEL: Label for provider /dev/ad0s1e is label/tmp # glabel label swap /dev/ad0s1b GEOM_LABEL: Label for provider /dev/ad0s1b is label/swap # exit .... The system will continue with multi-user boot. After the boot completes, edit [.filename]#/etc/fstab# and replace the conventional device names, with their respective labels. The final [.filename]#/etc/fstab# will look like this: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# /dev/label/swap none swap sw 0 0 /dev/label/rootfs / ufs rw 1 1 /dev/label/tmp /tmp ufs rw 2 2 /dev/label/usr /usr ufs rw 2 2 /dev/label/var /var ufs rw 2 2 .... The system can now be rebooted. If everything went well, it will come up normally and `mount` will show: [source,shell] .... # mount /dev/label/rootfs on / (ufs, local) devfs on /dev (devfs, local) /dev/label/tmp on /tmp (ufs, local, soft-updates) /dev/label/usr on /usr (ufs, local, soft-updates) /dev/label/var on /var (ufs, local, soft-updates) .... ==== The man:glabel[8] class supports a label type for UFS file systems, based on the unique file system id, `ufsid`. These labels may be found in [.filename]#/dev/ufsid# and are created automatically during system startup. It is possible to use `ufsid` labels to mount partitions using [.filename]#/etc/fstab#. Use `glabel status` to receive a list of file systems and their corresponding `ufsid` labels: [source,shell] .... % glabel status Name Status Components ufsid/486b6fc38d330916 N/A ad4s1d ufsid/486b6fc16926168e N/A ad4s1f .... In the above example, [.filename]#ad4s1d# represents [.filename]#/var#, while [.filename]#ad4s1f# represents [.filename]#/usr#. Using the `ufsid` values shown, these partitions may now be mounted with the following entries in [.filename]#/etc/fstab#: [.programlisting] .... /dev/ufsid/486b6fc38d330916 /var ufs rw 2 2 /dev/ufsid/486b6fc16926168e /usr ufs rw 2 2 .... Any partitions with `ufsid` labels can be mounted in this way, eliminating the need to manually create permanent labels, while still enjoying the benefits of device name independent mounting. [[geom-gjournal]] == UFS Journaling Through GEOM Support for journals on UFS file systems is available on FreeBSD. The implementation is provided through the GEOM subsystem and is configured using `gjournal`. Unlike other file system journaling implementations, the `gjournal` method is block based and not implemented as part of the file system. It is a GEOM extension. Journaling stores a log of file system transactions, such as changes that make up a complete disk write operation, before meta-data and file writes are committed to the disk. This transaction log can later be replayed to redo file system transactions, preventing file system inconsistencies. This method provides another mechanism to protect against data loss and inconsistencies of the file system. Unlike Soft Updates, which tracks and enforces meta-data updates, and snapshots, which create an image of the file system, a log is stored in disk space specifically for this task. For better performance, the journal may be stored on another disk. In this configuration, the journal provider or storage device should be listed after the device to enable journaling on. The [.filename]#GENERIC# kernel provides support for `gjournal`. To automatically load the [.filename]#geom_journal.ko# kernel module at boot time, add the following line to [.filename]#/boot/loader.conf#: [.programlisting] .... geom_journal_load="YES" .... If a custom kernel is used, ensure the following line is in the kernel configuration file: [.programlisting] .... options GEOM_JOURNAL .... Once the module is loaded, a journal can be created on a new file system using the following steps. In this example, [.filename]#da4# is a new SCSI disk: [source,shell] .... # gjournal load # gjournal label /dev/da4 .... This will load the module and create a [.filename]#/dev/da4.journal# device node on [.filename]#/dev/da4#. A UFS file system may now be created on the journaled device, then mounted on an existing mount point: [source,shell] .... # newfs -O 2 -J /dev/da4.journal # mount /dev/da4.journal /mnt .... [NOTE] ==== In the case of several slices, a journal will be created for each individual slice. For instance, if [.filename]#ad4s1# and [.filename]#ad4s2# are both slices, then `gjournal` will create [.filename]#ad4s1.journal# and [.filename]#ad4s2.journal#. ==== Journaling may also be enabled on current file systems by using `tunefs`. However, _always_ make a backup before attempting to alter an existing file system. In most cases, `gjournal` will fail if it is unable to create the journal, but this does not protect against data loss incurred as a result of misusing `tunefs`. Refer to man:gjournal[8] and man:tunefs[8] for more information about these commands. It is possible to journal the boot disk of a FreeBSD system. Refer to the article extref:{gjournal-desktop}[Implementing UFS Journaling on a Desktop PC] for detailed instructions. diff --git a/documentation/content/en/books/handbook/kernelconfig/_index.adoc b/documentation/content/en/books/handbook/kernelconfig/_index.adoc index 5e035105b6..9769a57018 100644 --- a/documentation/content/en/books/handbook/kernelconfig/_index.adoc +++ b/documentation/content/en/books/handbook/kernelconfig/_index.adoc @@ -1,365 +1,365 @@ --- title: Chapter 10. Configuring the FreeBSD Kernel part: Part II. Common Tasks prev: books/handbook/multimedia next: books/handbook/printing description: This chapter covers how to configure the FreeBSD Kernel. When to build a custom kernel, how to take a hardware inventory, how to customize a kernel configuration file, etc tags: ["configuring", "kernel", "custom kernel", "hardware requirements", "pciconf"] showBookMenu: true weight: 13 params: path: "/books/handbook/kernelconfig/" --- [[kernelconfig]] = Configuring the FreeBSD Kernel :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 10 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/kernelconfig/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[kernelconfig-synopsis]] == Synopsis The kernel is the core of the FreeBSD operating system. It is responsible for managing memory, enforcing security controls, networking, disk access, and much more. While much of FreeBSD is dynamically configurable, some users may wish to configure and compile a custom kernel. -After reading this chapter, you will know: +Read this chapter to learn: * When to build a custom kernel. * How to take a hardware inventory. * How to customize a kernel configuration file. * How to use the kernel configuration file to create and build a new kernel. * How to install the new kernel. * How to troubleshoot if things go wrong. All of the commands listed in the examples in this chapter should be executed as `root`. [[kernelconfig-custom-kernel]] == Why Build a Custom Kernel? Traditionally, FreeBSD used a monolithic kernel. The kernel was one large program, supported a fixed list of devices, and in order to change the kernel's behavior, one had to compile and then reboot into a new kernel. Today, most of the functionality in the FreeBSD kernel is contained in modules which can be dynamically loaded and unloaded from the kernel as necessary. This allows the running kernel to adapt immediately to new hardware and for new functionality to be brought into the kernel. This is known as a modular kernel. Occasionally, it is still necessary to perform static kernel configuration. Sometimes the needed functionality is so tied to the kernel that it can not be made dynamically loadable. Some security environments prevent the loading and unloading of kernel modules and require that only needed functionality is statically compiled into the kernel. Building a custom kernel is often a rite of passage for advanced BSD users. This process, while time consuming, can provide benefits to the FreeBSD system. Unlike the [.filename]#GENERIC# kernel, which must support a wide range of hardware, a custom kernel can be stripped down to only provide support for that computer's hardware. This has a number of benefits, such as: * Faster boot time. Since the kernel will only probe the hardware on the system, the time it takes the system to boot can decrease. * Lower memory usage. A custom kernel often uses less memory than the [.filename]#GENERIC# kernel by omitting unused features and device drivers. This is important because the kernel code remains resident in physical memory at all times, preventing that memory from being used by applications. For this reason, a custom kernel is useful on a system with a small amount of RAM. * Additional hardware support. A custom kernel can add support for devices which are not present in the [.filename]#GENERIC# kernel. [WARNING] ==== When building a custom kernel, it is important to note that non-default configurations are less thoroughly tested than the GENERIC configuration. While customizing the kernel can provide specific benefits it also increases the risk of encountering build or runtime issues. Custom kernel configurations are recommended only for advanced users who have a specific reason for making changes and are willing to engage in the debugging process if necessary. ==== Before building a custom kernel, consider the reason for doing so. If there is a need for specific hardware support, it may already exist as a module. Kernel modules exist in [.filename]#/boot/kernel# and may be dynamically loaded into the running kernel using man:kldload[8]. Most kernel drivers have a loadable module and manual page. For example, the man:ath[4] wireless network driver has the following information in its manual page: [source,shell,subs="macros"] .... Alternatively, to load the driver as a module at boot time, place the following line in man:loader.conf[5]: if_ath_load="YES" .... Adding `if_ath_load="YES"` to [.filename]#/boot/loader.conf# will load this module dynamically at boot time. In some cases, there is no associated module in [.filename]#/boot/kernel#. This is mostly true for certain subsystems. [[kernelconfig-devices]] == Finding the System Hardware Before editing the kernel configuration file, it is recommended to perform an inventory of the machine's hardware. On a dual-boot system, the inventory can be created from the other operating system. For example, Microsoft(R)'s Device Manager contains information about installed devices. [NOTE] ==== Some versions of Microsoft(R) Windows(R) have a System icon which can be used to access Device Manager. ==== If FreeBSD is the only installed operating system, use man:dmesg[8] to determine the hardware that was found and listed during the boot probe. Most device drivers on FreeBSD have a manual page which lists the hardware supported by that driver. For example, the following lines indicate that the man:psm[4] driver found a mouse: [source,shell] .... psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 .... Since this hardware exists, this driver should not be removed from a custom kernel configuration file. If the output of `dmesg` does not display the results of the boot probe output, instead read the contents of [.filename]#/var/run/dmesg.boot#. Another tool for finding hardware is man:pciconf[8], which provides more verbose output. For example: [source,shell] .... % pciconf -lv ath0@pci0:3:0:0: class=0x020000 card=0x058a1014 chip=0x1014168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212 Atheros AR5212 802.11abg wireless' class = network subclass = ethernet .... This output shows that the [.filename]#ath# driver located a wireless Ethernet device. The `-k` flag of man:man[1] can be used to provide useful information. For example, it can be used to display a list of manual pages which contain a particular device brand or name: [source,shell] .... # man -k Atheros ath(4) - Atheros IEEE 802.11 wireless network driver ath_hal(4) - Atheros Hardware Access Layer (HAL) .... Once the hardware inventory list is created, refer to it to ensure that drivers for installed hardware are not removed as the custom kernel configuration is edited. [[kernelconfig-config]] == The Configuration File In order to create a custom kernel configuration file and build a custom kernel, the full FreeBSD source tree must first be installed. If [.filename]#/usr/src/# does not exist or it is empty, source has not been installed. Source can be installed with Git using the instructions in crossref:mirrors[git,“Using Git”]. Once source is installed, review the contents of [.filename]#/usr/src/sys#. This directory contains a number of subdirectories, including those which represent the following supported architectures: [.filename]#amd64#, [.filename]#i386#, [.filename]#powerpc#, and [.filename]#sparc64#. Everything inside a particular architecture's directory deals with that architecture only and the rest of the code is machine independent code common to all platforms. Each supported architecture has a [.filename]#conf# subdirectory which contains the [.filename]#GENERIC# kernel configuration file for that architecture. Do not make edits to [.filename]#GENERIC#. Instead, copy the file to a different name and make edits to the copy. The convention is to use a name with all capital letters. When maintaining multiple FreeBSD machines with different hardware, it is a good idea to name it after the machine's hostname. This example creates a copy, named [.filename]#MYKERNEL#, of the [.filename]#GENERIC# configuration file for the `amd64` architecture: [source,shell] .... # cd /usr/src/sys/amd64/conf # cp GENERIC MYKERNEL .... [.filename]#MYKERNEL# can now be customized with any `ASCII` text editor. The default editor is vi, though an easier editor for beginners, called ee, is also installed with FreeBSD. The format of the kernel configuration file is simple. Each line contains a keyword that represents a device or subsystem, an argument, and a brief description. Any text after a `+#+` is considered a comment and ignored. To remove kernel support for a device or subsystem, put a `+#+` at the beginning of the line representing that device or subsystem. -Do not add or remove a `+#+` for any line that you do not understand. +Do not add or remove a `+#+` for any line that is not understand. [WARNING] ==== It is easy to remove support for a device or option and end up with a broken kernel. For example, if the man:ata[4] driver is removed from the kernel configuration file, a system using `ATA` disk drivers may not boot. When in doubt, just leave support in the kernel. ==== In addition to the brief descriptions provided in this file, additional descriptions are contained in [.filename]#NOTES#, which can be found in the same directory as [.filename]#GENERIC# for that architecture. For architecture independent options, refer to [.filename]#/usr/src/sys/conf/NOTES#. [TIP] ==== When finished customizing the kernel configuration file, save a backup copy to a location outside of [.filename]#/usr/src#. Alternately, keep the kernel configuration file elsewhere and create a symbolic link to the file: [source,shell] .... # cd /usr/src/sys/amd64/conf # mkdir /root/kernels # cp GENERIC /root/kernels/MYKERNEL # ln -s /root/kernels/MYKERNEL .... ==== An `include` directive is available for use in configuration files. This allows another configuration file to be included in the current one, making it easy to maintain small changes relative to an existing file. If only a small number of additional options or drivers are required, this allows a delta to be maintained with respect to [.filename]#GENERIC#, as seen in this example: [.programlisting] .... include GENERIC ident MYKERNEL options IPFIREWALL options DUMMYNET options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT .... Using this method, the local configuration file expresses local differences from a [.filename]#GENERIC# kernel. As upgrades are performed, new features added to [.filename]#GENERIC# will also be added to the local kernel unless they are specifically prevented using `nooptions` or `nodevice`. A comprehensive list of configuration directives and their descriptions may be found in man:config[5]. [NOTE] ==== To build a file which contains all available options, run the following command as `root`: [source,shell] .... # cd /usr/src/sys/arch/conf && make LINT .... ==== [[kernelconfig-building]] == Building and Installing a Custom Kernel Once the edits to the custom configuration file have been saved, the source code for the kernel can be compiled using the following steps: [.procedure] ==== *Procedure: Building a Kernel* . Change to this directory: + [source,shell] .... # cd /usr/src .... + . Compile the new kernel by specifying the name of the custom kernel configuration file: + [source,shell] .... # make buildkernel KERNCONF=MYKERNEL .... + . Install the new kernel associated with the specified kernel configuration file. This command will copy the new kernel to [.filename]#/boot/kernel/kernel# and save the old kernel to [.filename]#/boot/kernel.old/kernel#: + [source,shell] .... # make installkernel KERNCONF=MYKERNEL .... + . Shutdown the system and reboot into the new kernel. If something goes wrong, refer to crossref:kernelconfig[kernelconfig-noboot, The kernel does not boot]. ==== By default, when a custom kernel is compiled, all kernel modules are rebuilt. To update a kernel faster or to build only custom modules, edit [.filename]#/etc/make.conf# before starting to build the kernel. For example, this variable specifies the list of modules to build instead of using the default of building all modules: [.programlisting] .... MODULES_OVERRIDE = linux acpi .... Alternately, this variable lists which modules to exclude from the build process: [.programlisting] .... WITHOUT_MODULES = linux acpi sound .... Additional variables are available. Refer to man:make.conf[5] for details. [[kernelconfig-trouble]] == If Something Goes Wrong There are four categories of trouble that can occur when building a custom kernel: `config` fails:: If `config` fails, it will print the line number that is incorrect. As an example, for the following message, make sure that line 17 is typed correctly by comparing it to [.filename]#GENERIC# or [.filename]#NOTES#: + [source,shell] .... config: line 17: syntax error .... `make` fails:: If `make` fails, it is usually due to an error in the kernel configuration file which is not severe enough for `config` to catch. Review the configuration, and if the problem is not apparent, send an email to the {freebsd-questions} which contains the kernel configuration file. [[kernelconfig-noboot]] The kernel does not boot:: If the new kernel does not boot or fails to recognize devices, do not panic! Fortunately, FreeBSD has an excellent mechanism for recovering from incompatible kernels. Simply choose the kernel to boot from at the FreeBSD boot loader. This can be accessed when the system boot menu appears by selecting the "Escape to a loader prompt" option. At the prompt, type `boot _kernel.old_`, or the name of any other kernel that is known to boot properly. + After booting with a good kernel, check over the configuration file and try to build it again. One helpful resource is [.filename]#/var/log/messages# which records the kernel messages from every successful boot. Also, man:dmesg[8] will print the kernel messages from the current boot. + [NOTE] ==== When troubleshooting a kernel make sure to keep a copy of a kernel that is known to work, such as [.filename]#GENERIC#. This is important because every time a new kernel is installed, [.filename]#kernel.old# is overwritten with the last installed kernel, which may or may not be bootable. As soon as possible, move the working kernel by renaming the directory containing the good kernel: [source,shell] .... # mv /boot/kernel /boot/kernel.bad # mv /boot/kernel.good /boot/kernel .... ==== The kernel works, but man:ps[1] does not:: If the kernel version differs from the one that the system utilities have been built with, for example, a kernel built from -CURRENT sources is installed on a -RELEASE system, many system status commands like man:ps[1] and man:vmstat[8] will not work. To fix this, crossref:cutting-edge[makeworld,recompile and install a world] built with the same version of the source tree as the kernel. It is never a good idea to use a different version of the kernel than the rest of the operating system. diff --git a/documentation/content/en/books/handbook/l10n/_index.adoc b/documentation/content/en/books/handbook/l10n/_index.adoc index 83ce371621..73d5f3cd99 100644 --- a/documentation/content/en/books/handbook/l10n/_index.adoc +++ b/documentation/content/en/books/handbook/l10n/_index.adoc @@ -1,645 +1,646 @@ --- title: Chapter 25. Localization - i18n/L10n Usage and Setup part: Part III. System Administration prev: books/handbook/virtualization next: books/handbook/cutting-edge description: FreeBSD supports localization into many languages, allowing users to view, input, or process data in non-English languages tags: ["i18n", "L10n", "localization", "Locale", "LANG", "MM_CHARSET", "cap_mkdb"] showBookMenu: true weight: 29 params: path: "/books/handbook/l10n/" --- [[l10n]] = Localization - i18n/L10n Usage and Setup :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 25 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/l10n/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[l10n-synopsis]] == Synopsis FreeBSD is a distributed project with users and contributors located all over the world. As such, FreeBSD supports localization into many languages, allowing users to view, input, or process data in non-English languages. One can choose from most of the major languages, including, but not limited to: Chinese, German, Japanese, Korean, French, Russian, and Vietnamese. The term internationalization has been shortened to i18n, which represents the number of letters between the first and the last letters of `internationalization`. L10n uses the same naming scheme, but from `localization`. The i18n/L10n methods, protocols, and applications allow users to use languages of their choice. This chapter discusses the internationalization and localization features of FreeBSD. -After reading this chapter, you will know: + +Read this chapter to learn: * How locale names are constructed. * How to set the locale for a login shell. * How to configure the console for non-English languages. * How to configure Xorg for different languages. * How to find i18n-compliant applications. * Where to find more information for configuring specific languages. -Before reading this chapter, you should: +Before reading this chapter: * Know how to crossref:ports[ports,install additional third-party applications]. [[using-localization]] == Using Localization Localization settings are based on three components: the language code, country code, and encoding. Locale names are constructed from these parts as follows: [.programlisting] .... LanguageCode_CountryCode.Encoding .... The _LanguageCode_ and _CountryCode_ are used to determine the country and the specific language variation. crossref:l10n[locale-lang-country,Common Language and Country Codes] provides some examples of __LanguageCode_CountryCode__: [[locale-lang-country]] .Common Language and Country Codes [cols="1,1", frame="none", options="header"] |=== | LanguageCode_Country Code | Description |en_US |English, United States |ru_RU |Russian, Russia |zh_TW |Traditional Chinese, Taiwan |=== A complete listing of available locales can be found by typing: [source,shell] .... % locale -a | more .... To determine the current locale setting: [source,shell] .... % locale .... Language specific character sets, such as ISO8859-1, ISO8859-15, KOI8-R, and CP437, are described in man:multibyte[3]. The active list of character sets can be found at the http://www.iana.org/assignments/character-sets[IANA Registry]. Some languages, such as Chinese or Japanese, cannot be represented using ASCII characters and require an extended language encoding using either wide or multibyte characters. Examples of wide or multibyte encodings include EUC and Big5. Older applications may mistake these encodings for control characters while newer applications usually recognize these characters. Depending on the implementation, users may be required to compile an application with wide or multibyte character support, or to configure it correctly. [NOTE] ==== FreeBSD uses Xorg-compatible locale encodings. ==== The rest of this section describes the various methods for configuring the locale on a FreeBSD system. The next section will discuss the considerations for finding and compiling applications with i18n support. [[setting-locale]] === Setting Locale for Login Shell Locale settings are configured either in a user's [.filename]#~/.login_conf# or in the startup file of the user's shell: [.filename]#~/.profile#, [.filename]#~/.bashrc#, or [.filename]#~/.cshrc#. Two environment variables should be set: * `LANG`, which sets the locale * `MM_CHARSET`, which sets the MIME character set used by applications In addition to the user's shell configuration, these variables should also be set for specific application configuration and Xorg configuration. Two methods are available for making the needed variable assignments: the crossref:l10n[login-class,login class] method, which is the recommended method, and the crossref:l10n[startup-file,startup file] method. The next two sections demonstrate how to use both methods. [[login-class]] ==== Login Classes Method This first method is the recommended method as it assigns the required environment variables for locale name and MIME character sets for every possible shell. This setup can either be performed by each user or it can be configured for all users by the superuser. This minimal example sets both variables for Latin-1 encoding in the [.filename]#.login_conf# of an individual user's home directory: [.programlisting] .... me:\ :charset=ISO-8859-1:\ :lang=de_DE.ISO8859-1: .... Here is an example of a user's [.filename]#~/.login_conf# that sets the variables for Traditional Chinese in BIG-5 encoding. More variables are needed because some applications do not correctly respect locale variables for Chinese, Japanese, and Korean: [.programlisting] .... #Users who do not wish to use monetary units or time formats #of Taiwan can manually change each variable me:\ :lang=zh_TW.Big5:\ :setenv=LC_ALL=zh_TW.Big5,LC_COLLATE=zh_TW.Big5,LC_CTYPE=zh_TW.Big5,LC_MESSAGES=zh_TW.Big5,LC_MONETARY=zh_TW.Big5,LC_NUMERIC=zh_TW.Big5,LC_TIME=zh_TW.Big5:\ :charset=big5:\ :xmodifiers="@im=gcin": #Set gcin as the XIM Input Server .... Alternately, the superuser can configure all users of the system for localization. The following variables in [.filename]#/etc/login.conf# are used to set the locale and MIME character set: [.programlisting] .... language_name|Account Type Description:\ :charset=MIME_charset:\ :lang=locale_name:\ :tc=default: .... So, the previous Latin-1 example would look like this: [.programlisting] .... german|German Users Accounts:\ :charset=ISO-8859-1:\ :lang=de_DE.ISO8859-1:\ :tc=default: .... See man:login.conf[5] for more details about these variables. Note that it already contains pre-defined _russian_ class. Whenever [.filename]#/etc/login.conf# is edited, remember to execute the following command to update the capability database: [source,shell] .... # cap_mkdb /etc/login.conf .... [NOTE] ==== For an end user, the `cap_mkdb` command will need to be run on their [.filename]#~/.login_conf# for any changes to take effect. ==== ===== Utilities Which Change Login Classes In addition to manually editing [.filename]#/etc/login.conf#, several utilities are available for setting the locale for newly created users. When using `vipw` to add new users, specify the _language_ to set the locale: [.programlisting] .... user:password:1111:11:language:0:0:User Name:/home/user:/bin/sh .... When using `adduser` to add new users, the default language can be pre-configured for all new users or specified for an individual user. If all new users use the same language, set `defaultclass=_language_` in [.filename]#/etc/adduser.conf#. To override this setting when creating a user, either input the required locale at this prompt: [source,shell] .... Enter login class: default []: .... or specify the locale to set when invoking `adduser`: [source,shell] .... # adduser -class language .... If `pw` is used to add new users, specify the locale as follows: [source,shell] .... # pw useradd user_name -L language .... To change the login class of an existing user, `chpass` can be used. Invoke it as superuser and provide the username to edit as the argument. [source,shell] .... # chpass user_name .... [[startup-file]] ==== Shell Startup File Method This second method is not recommended as each shell that is used requires manual configuration, where each shell has a different configuration file and differing syntax. As an example, to set the German language for the `sh` shell, these lines could be added to [.filename]#~/.profile# to set the shell for that user only. These lines could also be added to [.filename]#/etc/profile# or [.filename]#/usr/share/skel/dot.profile# to set that shell for all users: [.programlisting] .... LANG=de_DE.ISO8859-1; export LANG MM_CHARSET=ISO-8859-1; export MM_CHARSET .... However, the name of the configuration file and the syntax used differs for the `csh` shell. These are the equivalent settings for [.filename]#~/.login#, [.filename]#/etc/csh.login#, or [.filename]#/usr/share/skel/dot.login#: [.programlisting] .... setenv LANG de_DE.ISO8859-1 setenv MM_CHARSET ISO-8859-1 .... To complicate matters, the syntax needed to configure Xorg in [.filename]#~/.xinitrc# also depends upon the shell. The first example is for the `sh` shell and the second is for the `csh` shell: [.programlisting] .... LANG=de_DE.ISO8859-1; export LANG .... [.programlisting] .... setenv LANG de_DE.ISO8859-1 .... [[setting-console]] === Console Setup Several localized fonts are available for the console. To see a listing of available fonts, type `ls /usr/share/syscons/fonts`. To configure the console font, specify the _font_name_, without the [.filename]#.fnt# suffix, in [.filename]#/etc/rc.conf#: [.programlisting] .... font8x16=font_name font8x14=font_name font8x8=font_name .... The keymap and screenmap can be set by adding the following to [.filename]#/etc/rc.conf#: [.programlisting] .... scrnmap=screenmap_name keymap=keymap_name keychange="fkey_number sequence" .... To see the list of available screenmaps, type `ls /usr/share/syscons/scrnmaps`. Do not include the [.filename]#.scm# suffix when specifying _screenmap_name_. A screenmap with a corresponding mapped font is usually needed as a workaround for expanding bit 8 to bit 9 on a VGA adapter's font character matrix so that letters are moved out of the pseudographics area if the screen font uses a bit 8 column. To see the list of available keymaps, type `ls /usr/share/syscons/keymaps`. When specifying the _keymap_name_, do not include the [.filename]#.kbd# suffix. To test keymaps without rebooting, use man:kbdmap[1]. The `keychange` entry is usually needed to program function keys to match the selected terminal type because function key sequences cannot be defined in the keymap. Next, set the correct console terminal type in [.filename]#/etc/ttys# for all virtual terminal entries. crossref:l10n[locale-charset,Defined Terminal Types for Character Sets] summarizes the available terminal types.: [[locale-charset]] .Defined Terminal Types for Character Sets [cols="1,1", frame="none", options="header"] |=== | Character Set | Terminal Type |ISO8859-1 or ISO8859-15 |`cons25l1` |ISO8859-2 |`cons25l2` |ISO8859-7 |`cons25l7` |KOI8-R |`cons25r` |KOI8-U |`cons25u` |CP437 (VGA default) |`cons25` |US-ASCII |`cons25w` |=== For languages with wide or multibyte characters, install a console for that language from the FreeBSD Ports Collection. The available ports are summarized in crossref:l10n[locale-console,Available Console from Ports Collection]. Once installed, refer to the port's [.filename]#pkg-message# or man pages for configuration and usage instructions. [[locale-console]] .Available Console from Ports Collection [cols="1,1", frame="none", options="header"] |=== | Language | Port Location |Traditional Chinese (BIG-5) |package:chinese/big5con[] |Chinese/Japanese/Korean |package:chinese/cce[] |Chinese/Japanese/Korean |package:chinese/zhcon[] |Japanese |package:chinese/kon2[] |Japanese |package:japanese/kon2-14dot[] |Japanese |package:japanese/kon2-16dot[] |=== If moused is enabled in [.filename]#/etc/rc.conf#, additional configuration may be required. By default, the mouse cursor of the man:syscons[4] driver occupies the `0xd0`-`0xd3` range in the character set. If the language uses this range, move the cursor's range by adding the following line to [.filename]#/etc/rc.conf#: [.programlisting] .... mousechar_start=3 .... === Xorg Setup crossref:x11[x11,The X Window System] describes how to install and configure Xorg. When configuring Xorg for localization, additional fonts and input methods are available from the FreeBSD Ports Collection. Application specific i18n settings such as fonts and menus can be tuned in [.filename]#~/.Xresources# and should allow users to view their selected language in graphical application menus. The X Input Method (XIM) protocol is an Xorg standard for inputting non-English characters. crossref:l10n[locale-xim,Available Input Methods] summarizes the input method applications which are available in the FreeBSD Ports Collection. Additional Fcitx and Uim applications are also available. [[locale-xim]] .Available Input Methods [cols="1,1", frame="none", options="header"] |=== | Language | Input Method |Chinese |package:chinese/gcin[] |Chinese |package:chinese/ibus-chewing[] |Chinese |package:chinese/ibus-pinyin[] |Chinese |package:chinese/oxim[] |Chinese |package:chinese/scim-fcitx[] |Chinese |package:chinese/scim-pinyin[] |Chinese |package:chinese/scim-tables[] |Japanese |package:japanese/ibus-anthy[] |Japanese |package:japanese/ibus-mozc[] |Japanese |package:japanese/ibus-skk[] |Japanese |package:japanese/im-ja[] |Japanese |package:japanese/kinput2[] |Japanese |package:japanese/scim-anthy[] |Japanese |package:japanese/scim-canna[] |Japanese |package:japanese/scim-honoka[] |Japanese |package:japanese/scim-honoka-plugin-romkan[] |Japanese |package:japanese/scim-honoka-plugin-wnn[] |Japanese |package:japanese/scim-prime[] |Japanese |package:japanese/scim-skk[] |Japanese |package:japanese/scim-tables[] |Japanese |package:japanese/scim-tomoe[] |Japanese |package:japanese/scim-uim[] |Japanese |package:japanese/skkinput[] |Japanese |package:japanese/skkinput3[] |Japanese |package:japanese/uim-anthy[] |Korean |package:korean/ibus-hangul[] |Korean |package:korean/imhangul[] |Korean |package:korean/nabi[] |Korean |package:korean/scim-hangul[] |Korean |package:korean/scim-tables[] |Vietnamese |package:vietnamese/xvnkb[] |Vietnamese |package:vietnamese/x-unikey[] |=== [[l10n-compiling]] == Finding i18n Applications i18n applications are programmed using i18n kits under libraries. These allow developers to write a simple file and translate displayed menus and texts to each language. The link:https://ports.FreeBSD.org[FreeBSD Ports Collection] contains many applications with built-in support for wide or multibyte characters for several languages. Such applications include `i18n` in their names for easy identification. However, they do not always support the language needed. Some applications can be compiled with the specific charset. This is usually done in the port's [.filename]#Makefile# or by passing a value to configure. Refer to the i18n documentation in the respective FreeBSD port's source for more information on how to determine the needed configure value or the port's [.filename]#Makefile# to determine which compile options to use when building the port. [[lang-setup]] == Locale Configuration for Specific Languages This section provides configuration examples for localizing a FreeBSD system for the Russian language. It then provides some additional resources for localizing other languages. [[ru-localize]] === Russian Language (KOI8-R Encoding) This section shows the specific settings needed to localize a FreeBSD system for the Russian language. Refer to crossref:l10n[using-localization,Using Localization] for a complete description of each type of setting. To set this locale for the login shell, add the following lines to each user's [.filename]#~/.login_conf#: [.programlisting] .... me:My Account:\ :charset=KOI8-R:\ :lang=ru_RU.KOI8-R: .... To configure the console, add the following lines to [.filename]#/etc/rc.conf#: [.programlisting] .... keymap="ru.utf-8" scrnmap="utf-82cp866" font8x16="cp866b-8x16" font8x14="cp866-8x14" font8x8="cp866-8x8" mousechar_start=3 .... For each `ttyv` entry in [.filename]#/etc/ttys#, use `cons25r` as the terminal type. To configure printing, a special output filter is needed to convert from KOI8-R to CP866 since most printers with Russian characters come with hardware code page CP866. FreeBSD includes a default filter for this purpose, [.filename]#/usr/libexec/lpr/ru/koi2alt#. To use this filter, add this entry to [.filename]#/etc/printcap#: [.programlisting] .... lp|Russian local line printer:\ :sh:of=/usr/libexec/lpr/ru/koi2alt:\ :lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: .... Refer to man:printcap[5] for a more detailed explanation. To configure support for Russian filenames in mounted MS-DOS(R) file systems, include `-L` and the locale name when adding an entry to [.filename]#/etc/fstab#: [.programlisting] .... /dev/ad0s2 /dos/c msdos rw,-Lru_RU.KOI8-R 0 0 .... Refer to man:mount_msdosfs[8] for more details. To configure Russian fonts for Xorg, install the package:x11-fonts/xorg-fonts-cyrillic[] package. Then, check the `"Files"` section in [.filename]#/etc/X11/xorg.conf#. The following line must be added _before_ any other `FontPath` entries: [.programlisting] .... FontPath "/usr/local/lib/X11/fonts/cyrillic" .... Additional Cyrillic fonts are available in the Ports Collection. To activate a Russian keyboard, add the following to the `"Keyboard"` section of [.filename]#/etc/xorg.conf#: [.programlisting] .... Option "XkbLayout" "us,ru" Option "XkbOptions" "grp:toggle" .... Make sure that `XkbDisable` is commented out in that file. For `grp:toggle` use kbd:[Right Alt], for `grp:ctrl_shift_toggle` use kbd:[Ctrl+Shift]. For `grp:caps_toggle` use kbd:[CapsLock]. The old kbd:[CapsLock] function is still available in LAT mode only using kbd:[Shift+CapsLock]. `grp:caps_toggle` does not work in Xorg for some unknown reason. If the keyboard has "Windows(R)" keys, and some non-alphabetical keys are mapped incorrectly, add the following line to [.filename]#/etc/xorg.conf#: [.programlisting] .... Option "XkbVariant" ",winkeys" .... [NOTE] ==== The Russian XKB keyboard may not work with non-localized applications. Minimally localized applications should call a `XtSetLanguageProc (NULL, NULL, NULL);` function early in the program. ==== See http://koi8.pp.ru/xwin.html[http://koi8.pp.ru/xwin.html] for more instructions on localizing Xorg applications. For more general information about KOI8-R encoding, refer to http://koi8.pp.ru/[http://koi8.pp.ru/]. === Additional Language-Specific Resources This section lists some additional resources for configuring other locales. Traditional Chinese for Taiwan:: The FreeBSD-Taiwan Project has a Chinese HOWTO for FreeBSD at http://netlab.cse.yzu.edu.tw/\~statue/freebsd/zh-tut/[http://netlab.cse.yzu.edu.tw/~statue/freebsd/zh-tut/]. Greek Language Localization:: A complete article on Greek support in FreeBSD is available https://www.FreeBSD.org/doc/gr/articles/greek-language-support/[here], in Greek only, as part of the official FreeBSD Greek documentation. Japanese and Korean Language Localization:: For Japanese, refer to http://www.jp.FreeBSD.org/[http://www.jp.FreeBSD.org/], and for Korean, refer to http://www.kr.FreeBSD.org/[http://www.kr.FreeBSD.org/]. Non-English FreeBSD Documentation:: Some FreeBSD contributors have translated parts of the FreeBSD documentation to other languages. They are available through links on the link:https://www.FreeBSD.org/[FreeBSD web site] or in [.filename]#/usr/share/doc#. diff --git a/documentation/content/en/books/handbook/linuxemu/_index.adoc b/documentation/content/en/books/handbook/linuxemu/_index.adoc index 1f0c07c540..292af09e70 100644 --- a/documentation/content/en/books/handbook/linuxemu/_index.adoc +++ b/documentation/content/en/books/handbook/linuxemu/_index.adoc @@ -1,504 +1,504 @@ --- title: Chapter 12. Linux Binary Compatibility part: Part II. Common Tasks prev: books/handbook/printing next: books/handbook/wine description: FreeBSD provides binary compatibility with Linux, allowing users to install and run most Linux binaries on a FreeBSD system without having to first modify the binary tags: ["linux", "linuxulator", "emulation", "binary", "compatibility"] showBookMenu: true weight: 15 params: path: "/books/handbook/linuxemu/" --- [[linuxemu]] = Linux Binary Compatibility :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 12 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/linuxemu/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[linuxemu-synopsis]] == Synopsis FreeBSD provides *optional* binary compatibility with Linux(R), commonly referred to as Linuxulator, allowing users to install and run unmodified Linux binaries. It is available for the x86 (both 32 and 64 bit) and AArch64 architectures. Some Linux-specific operating system features are not yet supported; this mostly happens with functionality specific to hardware or related to system management, such as cgroups or namespaces. -Before reading this chapter, you should: +Before reading this chapter: * Know how to install crossref:ports[ports,additional third-party software]. -After reading this chapter, you will know: +Read this chapter to learn: * How to enable Linux binary compatibility on a FreeBSD system. * How to install additional Linux shared libraries. * How to install Linux applications on a FreeBSD system. * The implementation details of Linux compatibility in FreeBSD. [[linuxemu-lbc-install]] == Configuring Linux Binary Compatibility By default, man:linux[4] binary compatibility is not enabled. To enable the Linux ABI at boot time, execute the following command: [.programlisting] .... # sysrc linux_enable="YES" .... Once enabled, it can be started without rebooting by executing the following command: [source,shell] .... # service linux start .... This is enough for statically linked Linux binaries to work. The Linux service will load necessary kernel modules and mount filesystems expected by Linux applications under [.filename]#/compat/linux#. They can be started in the same way native FreeBSD binaries can; they behave almost exactly like native processes and can be traced and debugged the usual way. The current content of [.filename]#/compat/linux# can be checked executing the following command: [source,shell] .... # ls -l /compat/linux/ .... The output should be similar to the following: [.programlisting] .... total 1 dr-xr-xr-x 13 root wheel 512 Apr 11 19:12 dev dr-xr-xr-x 1 root wheel 0 Apr 11 21:03 proc dr-xr-xr-x 1 root wheel 0 Apr 11 21:03 sys .... [[linux-userlands]] == Linux userlands Linux software requires more than just an ABI to work. In order to run Linux software a Linux userland must be installed first. [TIP] ==== If all that is wanted is to run some software already included in the Ports tree, it can be installed via package manager and man:pkg[8] will automatically setup the required Linux userland. For example, to install Sublime Text 4, along with all the Linux libraries it depends on, run this command: [source,shell] .... # pkg install linux-sublime-text4 .... ==== [[linuxemu-rockylinux]] === Rocky Linux Base System from FreeBSD Packages To install the Rocky Linux 9 userland execute the following command: [source,shell] .... # pkg install linux_base-rl9 .... package:emulators/linux_base-rl9[] will place the base system derived from Rocky Linux 9 into [.filename]#/compat/linux#. After installing the package, the contents of [.filename]#/compat/linux# can be verified by running the following command to check that the Rocky Linux userland has been installed: [source,shell] .... # ls -l /compat/linux/ .... The output should be similar to the following: [.programlisting] .... total 36 drwxr-xr-x 2 root wheel 512 Oct 9 17:28 afs lrwxr-xr-x 1 root wheel 7 May 16 2022 bin -> usr/bin drwxr-xr-x 3 root wheel 512 Oct 9 17:28 dev drwxr-xr-x 24 root wheel 1536 Oct 9 17:28 etc lrwxr-xr-x 1 root wheel 7 May 16 2022 lib -> usr/lib lrwxr-xr-x 1 root wheel 9 May 16 2022 lib64 -> usr/lib64 drwxr-xr-x 2 root wheel 512 Oct 9 17:28 opt drwxr-xr-x 2 root wheel 512 Oct 9 17:28 proc lrwxr-xr-x 1 root wheel 8 Oct 1 03:11 run -> /var/run lrwxr-xr-x 1 root wheel 8 May 16 2022 sbin -> usr/sbin drwxr-xr-x 2 root wheel 512 Oct 9 17:28 srv drwxr-xr-x 2 root wheel 512 Oct 9 17:28 sys drwxr-xr-x 8 root wheel 512 Oct 9 17:28 usr drwxr-xr-x 16 root wheel 512 Oct 9 17:28 var .... [[linuxemu-centos]] === CentOS Base System from FreeBSD Packages [WARNING] ==== package:emulators/linux_base-c7[] has been deprecated following the deprecation of the upstream project. This means package:emulators/linux_base-c7[] will not receive security updates. The use of crossref:linuxemu[linuxemu-rockylinux, the Rocky Linux Base System] is recommended unless 32-bit compatibility is needed. ==== To install the CentOS userland execute the following command: [source,shell] .... # pkg install linux_base-c7 .... package:emulators/linux_base-c7[] will place the base system derived from CentOS 7 into [.filename]#/compat/linux#. After installing the package, the contents of [.filename]#/compat/linux# can be verified by running the following command to check that the CentOS userland has been installed: [source,shell] .... # ls -l /compat/linux/ .... The output should be similar to the following: [.programlisting] .... total 30 lrwxr-xr-x 1 root wheel 7 Apr 11 2018 bin -> usr/bin drwxr-xr-x 13 root wheel 512 Apr 11 21:10 dev drwxr-xr-x 25 root wheel 64 Apr 11 21:10 etc lrwxr-xr-x 1 root wheel 7 Apr 11 2018 lib -> usr/lib lrwxr-xr-x 1 root wheel 9 Apr 11 2018 lib64 -> usr/lib64 drwxr-xr-x 2 root wheel 2 Apr 11 21:10 opt dr-xr-xr-x 1 root wheel 0 Apr 11 21:25 proc lrwxr-xr-x 1 root wheel 8 Feb 18 02:10 run -> /var/run lrwxr-xr-x 1 root wheel 8 Apr 11 2018 sbin -> usr/sbin drwxr-xr-x 2 root wheel 2 Apr 11 21:10 srv dr-xr-xr-x 1 root wheel 0 Apr 11 21:25 sys drwxr-xr-x 8 root wheel 9 Apr 11 21:10 usr drwxr-xr-x 16 root wheel 17 Apr 11 21:10 var .... [[linuxemu-debootstrap]] === Debian / Ubuntu Base System with debootstrap An alternative way of providing Linux shared libraries is by using package:sysutils/debootstrap[]. This has the advantage of providing a full Debian or Ubuntu distribution. To install debootstrap execute the following command: [source,shell] .... # pkg install debootstrap .... man:debootstrap[8] needs man:linux[4] ABI enabled. Once enabled, execute the following command to install Ubuntu or Debian in [.filename]#/compat/ubuntu#: [source,shell] .... # debootstrap jammy /compat/ubuntu .... [NOTE] ==== While it is technically possible to install into [.filename]#/compat/linux# instead, it's discouraged due to possible clashes with CentOS-based packages. Instead, derive the directory name from the distribution or version name, e.g., [.filename]#/compat/ubuntu#. ==== The output should be similar to the following: [.programlisting] .... I: Retrieving InRelease I: Checking Release signature I: Valid Release signature (key id F6ECB3762474EDA9D21B7022871920D1991BC93C) I: Retrieving Packages I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Checking component main on http://archive.ubuntu.com/ubuntu... [...] I: Configuring console-setup... I: Configuring kbd... I: Configuring ubuntu-minimal... I: Configuring libc-bin... I: Configuring ca-certificates... I: Base system installed successfully. .... Then set up mounts in [.filename]#/etc/fstab#. [TIP] ==== If the contents of the home directory should be shared and to be able to run X11 applications, [.filename]#/home# and [.filename]#/tmp# should be mounted in the linux compat area using man:nullfs[5] for loopback. The following example can be added to [.filename]#/etc/fstab#: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# devfs /compat/ubuntu/dev devfs rw,late 0 0 tmpfs /compat/ubuntu/dev/shm tmpfs rw,late,size=1g,mode=1777 0 0 fdescfs /compat/ubuntu/dev/fd fdescfs rw,late,linrdlnk 0 0 linprocfs /compat/ubuntu/proc linprocfs rw,late 0 0 linsysfs /compat/ubuntu/sys linsysfs rw,late 0 0 /tmp /compat/ubuntu/tmp nullfs rw,late 0 0 /home /compat/ubuntu/home nullfs rw,late 0 0 .... Then execute man:mount[8]: [source,shell] .... # mount -al .... ==== To access the system using man:chroot[8] execute the following command: [source,shell] .... # chroot /compat/ubuntu /bin/bash .... Then man:uname[1] can be executed to check the Linux environment: [source,shell] .... # uname -s -r -m .... The output should be similar to the following: [.programlisting] .... Linux 5.15.0 x86_64 .... Once inside the chroot, the system behaves as in a normal Ubuntu installation. While systemd doesn't work, the man:service[8] command works as usual. [TIP] ==== To add the package repositories missing from defaults edit the file [.filename]#/compat/ubuntu/etc/apt/sources.list#. For amd64 the following example can be used: [.programlisting] .... deb http://archive.ubuntu.com/ubuntu jammy main universe restricted multiverse deb http://security.ubuntu.com/ubuntu/ jammy-security universe multiverse restricted main deb http://archive.ubuntu.com/ubuntu jammy-backports universe multiverse restricted main deb http://archive.ubuntu.com/ubuntu jammy-updates universe multiverse restricted main .... For arm64 this other example can be used: [.programlisting] .... deb http://ports.ubuntu.com/ubuntu-ports bionic main universe restricted multiverse .... ==== [[linuxemu-advanced]] == Advanced Topics A list of all Linux-related man:sysctl[8] knobs can be found in man:linux[4]. Some applications require specific filesystems to be mounted. This is normally handled by the [.filename]#/etc/rc.d/linux# script but can be disabled at boot executing the following command: [.programlisting] .... sysrc linux_mounts_enable="NO" .... Filesystems mounted by the rc script will not work for Linux processes inside chroots or jails; if needed, configure them in [.filename]#/etc/fstab#: [.programlisting] .... devfs /compat/linux/dev devfs rw,late 0 0 tmpfs /compat/linux/dev/shm tmpfs rw,late,size=1g,mode=1777 0 0 fdescfs /compat/linux/dev/fd fdescfs rw,late,linrdlnk 0 0 linprocfs /compat/linux/proc linprocfs rw,late 0 0 linsysfs /compat/linux/sys linsysfs rw,late 0 0 .... Since the Linux binary compatibility layer has gained support for running both 32- and 64-bit Linux binaries, it is no longer possible to link the emulation functionality statically into a custom kernel. [[linuxemu-libs-manually]] === Installing Additional Libraries Manually [NOTE] ==== For base system subdirectories created with man:debootstrap[8], use the instructions above instead. ==== If a Linux application complains about missing shared libraries after configuring Linux binary compatibility, determine which shared libraries the Linux binary needs and install them manually. From a Linux system using the same CPU architecture, `ldd` can be used to determine which shared libraries the application needs. For example, to check which shared libraries `linuxdoom` needs, run this command from a Linux system that has Doom installed: [source,shell] .... % ldd linuxdoom .... The output should be similar to the following: [.programlisting] .... libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 .... Then, copy all the files in the last column of the output from the Linux system into [.filename]#/compat/linux# on the FreeBSD system. Once copied, create symbolic links to the names in the first column. This example will result in the following files on the FreeBSD system: [.programlisting] .... /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29 .... If a Linux shared library already exists with a matching major revision number to the first column of the `ldd` output, it does not need to be copied to the file named in the last column, as the existing library should work. It is advisable to copy the shared library if it is a newer version, though. The old one can be removed, as long as the symbolic link points to the new one. For example, these libraries already exist on the FreeBSD system: [.programlisting] .... /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 .... and `ldd` indicates that a binary requires a later version: [.programlisting] .... libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 .... Since the existing library is only one or two versions out of date in the last digit, the program should still work with the slightly older version. However, it is safe to replace the existing [.filename]#libc.so# with the newer version: [.programlisting] .... /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29 .... Generally, one will need to look for the shared libraries that Linux binaries depend on only the first few times that a Linux program is installed on FreeBSD. After a while, there will be a sufficient set of Linux shared libraries on the system to be able to run newly installed Linux binaries without any extra work. === Branding Linux ELF Binaries The FreeBSD kernel uses several methods to determine if the binary to be executed is a Linux one: it checks the brand in the ELF file header, looks for known ELF interpreter paths and checks ELF notes; finally, by default, unbranded ELF executables are assumed to be Linux anyway. Should all those methods fail, an attempt to execute the binary might result in error message: [source,shell] .... % ./my-linux-elf-binary .... The output should be similar to the following: [.programlisting] .... ELF binary type not known Abort .... To help the FreeBSD kernel distinguish between a FreeBSD ELF binary and a Linux binary, use man:brandelf[1]: [source,shell] .... % brandelf -t Linux my-linux-elf-binary .... === Installing a Linux RPM Based Application To install a Linux RPM-based application, first install the package:archivers/rpm4[] package or port. Once installed, `root` can use this command to install a [.filename]#.rpm#: [source,shell] .... # cd /compat/linux # rpm2cpio < /path/to/linux.archive.rpm | cpio -id .... If necessary, `brandelf` the installed ELF binaries. Note that this will prevent a clean uninstall. === Configuring the Hostname Resolver If DNS does not work or this error appears: [.programlisting] .... resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword .... configure [.filename]#/compat/linux/etc/host.conf# as follows: [.programlisting] .... order hosts, bind multi on .... This specifies that [.filename]#/etc/hosts# is searched first and DNS is searched second. When [.filename]#/compat/linux/etc/host.conf# does not exist, Linux applications use [.filename]#/etc/host.conf# in the host system but they complain since that file does not exist in FreeBSD. Remove `bind` if a name server is not configured using [.filename]#/etc/resolv.conf#. [[linuxemu-misc]] === Miscellaneous More information on how binary compatibility works with Linux(R) can be found in the article link:{linux-emulation}[Linux emulation in FreeBSD]. diff --git a/documentation/content/en/books/handbook/mac/_index.adoc b/documentation/content/en/books/handbook/mac/_index.adoc index 8a99185537..79745411de 100644 --- a/documentation/content/en/books/handbook/mac/_index.adoc +++ b/documentation/content/en/books/handbook/mac/_index.adoc @@ -1,968 +1,968 @@ --- title: Chapter 18. Mandatory Access Control part: Part III. System Administration prev: books/handbook/jails next: books/handbook/audit description: "This chapter focuses on the MAC framework and the set of pluggable security policy modules FreeBSD provides for enabling various security mechanisms" tags: ["MAC", "labels", "security", "configuration", "nagios"] showBookMenu: true weight: 22 params: path: "/books/handbook/mac/" --- [[mac]] = Mandatory Access Control :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 18 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/mac/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[mac-synopsis]] == Synopsis FreeBSD supports security extensions based on the POSIX(R).1e draft. These security mechanisms include file system Access Control Lists (crossref:security[fs-acl,“Access Control Lists”]) and Mandatory Access Control (MAC). MAC allows access control modules to be loaded in order to implement security policies. Some modules provide protections for a narrow subset of the system, hardening a particular service. Others provide comprehensive labeled security across all subjects and objects. The mandatory part of the definition indicates that enforcement of controls is performed by administrators and the operating system. This is in contrast to the default security mechanism of Discretionary Access Control (DAC) where enforcement is left to the discretion of users. This chapter focuses on the MAC framework and the set of pluggable security policy modules FreeBSD provides for enabling various security mechanisms. -After reading this chapter, you will know: +Read this chapter to learn: * The terminology associated with the MAC framework. * The capabilities of MAC security policy modules as well as the difference between a labeled and non-labeled policy. * The considerations to take into account before configuring a system to use the MAC framework. * Which MAC security policy modules are included in FreeBSD and how to configure them. * How to implement a more secure environment using the MAC framework. * How to test the MAC configuration to ensure the framework has been properly implemented. -Before reading this chapter, you should: +Before reading this chapter: * Understand UNIX(R) and FreeBSD basics (crossref:basics[basics,FreeBSD Basics]). * Have some familiarity with security and how it pertains to FreeBSD (crossref:security[security,Security]). [WARNING] ==== Improper MAC configuration may cause loss of system access, aggravation of users, or inability to access the features provided by Xorg. More importantly, MAC should not be relied upon to completely secure a system. The MAC framework only augments an existing security policy. Without sound security practices and regular security checks, the system will never be completely secure. The examples contained within this chapter are for demonstration purposes and the example settings should _not_ be implemented on a production system. Implementing any security policy takes a good deal of understanding, proper design, and thorough testing. ==== While this chapter covers a broad range of security issues relating to the MAC framework, the development of new MAC security policy modules will not be covered. A number of security policy modules included with the MAC framework have specific characteristics which are provided for both testing and new module development. Refer to man:mac_test[4], man:mac_stub[4] and man:mac_none[4] for more information on these security policy modules and the various mechanisms they provide. [[mac-inline-glossary]] == Key Terms The following key terms are used when referring to the MAC framework: * _compartment_: a set of programs and data to be partitioned or separated, where users are given explicit access to specific component of a system. A compartment represents a grouping, such as a work group, department, project, or topic. Compartments make it possible to implement a need-to-know-basis security policy. * _integrity_: the level of trust which can be placed on data. As the integrity of the data is elevated, so does the ability to trust that data. * _level_: the increased or decreased setting of a security attribute. As the level increases, its security is considered to elevate as well. * _label_: a security attribute which can be applied to files, directories, or other items in the system. It could be considered a confidentiality stamp. When a label is placed on a file, it describes the security properties of that file and will only permit access by files, users, and resources with a similar security setting. The meaning and interpretation of label values depends on the policy configuration. Some policies treat a label as representing the integrity or secrecy of an object while other policies might use labels to hold rules for access. * _multilabel_: this property is a file system option which can be set in single-user mode using man:tunefs[8], during boot using man:fstab[5], or during the creation of a new file system. This option permits an administrator to apply different MAC labels on different objects. This option only applies to security policy modules which support labeling. * _single label_: a policy where the entire file system uses one label to enforce access control over the flow of data. Whenever `multilabel` is not set, all files will conform to the same label setting. * _object_: an entity through which information flows under the direction of a _subject_. This includes directories, files, fields, screens, keyboards, memory, magnetic storage, printers or any other data storage or moving device. An object is a data container or a system resource. Access to an object effectively means access to its data. * _subject_: any active entity that causes information to flow between _objects_ such as a user, user process, or system process. On FreeBSD, this is almost always a thread acting in a process on behalf of a user. * _policy_: a collection of rules which defines how objectives are to be achieved. A policy usually documents how certain items are to be handled. This chapter considers a policy to be a collection of rules which controls the flow of data and information and defines who has access to that data and information. * _high-watermark_: this type of policy permits the raising of security levels for the purpose of accessing higher level information. In most cases, the original level is restored after the process is complete. Currently, the FreeBSD MAC framework does not include this type of policy. * _low-watermark_: this type of policy permits lowering security levels for the purpose of accessing information which is less secure. In most cases, the original security level of the user is restored after the process is complete. The only security policy module in FreeBSD to use this is man:mac_lomac[4]. * _sensitivity_: usually used when discussing Multilevel Security (MLS). A sensitivity level describes how important or secret the data should be. As the sensitivity level increases, so does the importance of the secrecy, or confidentiality, of the data. [[mac-understandlabel]] == Understanding MAC Labels A MAC label is a security attribute which may be applied to subjects and objects throughout the system. When setting a label, the administrator must understand its implications in order to prevent unexpected or undesired behavior of the system. The attributes available on an object depend on the loaded policy module, as policy modules interpret their attributes in different ways. The security label on an object is used as a part of a security access control decision by a policy. With some policies, the label contains all of the information necessary to make a decision. In other policies, the labels may be processed as part of a larger rule set. There are two types of label policies: single label and multi label. By default, the system will use single label. The administrator should be aware of the pros and cons of each in order to implement policies which meet the requirements of the system's security model. A single label security policy only permits one label to be used for every subject or object. Since a single label policy enforces one set of access permissions across the entire system, it provides lower administration overhead, but decreases the flexibility of policies which support labeling. However, in many environments, a single label policy may be all that is required. A single label policy is somewhat similar to DAC as `root` configures the policies so that users are placed in the appropriate categories and access levels. A notable difference is that many policy modules can also restrict `root`. Basic control over objects will then be released to the group, but `root` may revoke or modify the settings at any time. When appropriate, a multi label policy can be set on a UFS file system by passing `multilabel` to man:tunefs[8]. A multi label policy permits each subject or object to have its own independent MAC label. The decision to use a multi label or single label policy is only required for policies which implement the labeling feature, such as `biba`, `lomac`, and `mls`. Some policies, such as `seeotheruids`, `portacl` and `partition`, do not use labels at all. Using a multi label policy on a partition and establishing a multi label security model can increase administrative overhead as everything in that file system has a label. This includes directories, files, and even device nodes. The following command will set `multilabel` on the specified UFS file system. This may only be done in single-user mode and is not a requirement for the swap file system: [source,shell] .... # tunefs -l enable / .... [NOTE] ==== Some users have experienced problems with setting the `multilabel` flag on the root partition. If this is the case, please review crossref:mac[mac-troubleshoot, Troubleshooting the MAC Framework]. ==== Since the multi label policy is set on a per-file system basis, a multi label policy may not be needed if the file system layout is well designed. Consider an example security MAC model for a FreeBSD web server. This machine uses the single label, `biba/high`, for everything in the default file systems. If the web server needs to run at `biba/low` to prevent write up capabilities, it could be installed to a separate UFS [.filename]#/usr/local# file system set at `biba/low`. === Label Configuration Virtually all aspects of label policy module configuration will be performed using the base system utilities. These commands provide a simple interface for object or subject configuration or the manipulation and verification of the configuration. All configuration may be done using `setfmac`, which is used to set MAC labels on system objects, and `setpmac`, which is used to set the labels on system subjects. For example, to set the `biba` MAC label to `high` on [.filename]#test#: [source,shell] .... # setfmac biba/high test .... If the configuration is successful, the prompt will be returned without error. A common error is `Permission denied` which usually occurs when the label is being set or modified on a restricted object. Other conditions may produce different failures. For instance, the file may not be owned by the user attempting to relabel the object, the object may not exist, or the object may be read-only. A mandatory policy will not allow the process to relabel the file, maybe because of a property of the file, a property of the process, or a property of the proposed new label value. For example, if a user running at low integrity tries to change the label of a high integrity file, or a user running at low integrity tries to change the label of a low integrity file to a high integrity label, these operations will fail. The system administrator may use `setpmac` to override the policy module's settings by assigning a different label to the invoked process: [source,shell] .... # setfmac biba/high test Permission denied # setpmac biba/low setfmac biba/high test # getfmac test test: biba/high .... For currently running processes, such as sendmail, `getpmac` is usually used instead. This command takes a process ID (PID) in place of a command name. If users attempt to manipulate a file not in their access, subject to the rules of the loaded policy modules, the `Operation not permitted` error will be displayed. === Predefined Labels A few FreeBSD policy modules which support the labeling feature offer three predefined labels: `low`, `equal`, and `high`, where: * `low` is considered the lowest label setting an object or subject may have. Setting this on objects or subjects blocks their access to objects or subjects marked high. * `equal` sets the subject or object to be disabled or unaffected and should only be placed on objects considered to be exempt from the policy. * `high` grants an object or subject the highest setting available in the Biba and MLS policy modules. Such policy modules include man:mac_biba[4], man:mac_mls[4] and man:mac_lomac[4]. Each of the predefined labels establishes a different information flow directive. Refer to the manual page of the module to determine the traits of the generic label configurations. === Numeric Labels The Biba and MLS policy modules support a numeric label which may be set to indicate the precise level of hierarchical control. This numeric level is used to partition or sort information into different groups of classification, only permitting access to that group or a higher group level. For example: [.programlisting] .... biba/10:2+3+6(5:2+3-20:2+3+4+5+6) .... may be interpreted as "Biba Policy Label/Grade 10:Compartments 2, 3 and 6: (grade 5 ...") In this example, the first grade would be considered the effective grade with effective compartments, the second grade is the low grade, and the last one is the high grade. In most configurations, such fine-grained settings are not needed as they are considered to be advanced configurations. System objects only have a current grade and compartment. System subjects reflect the range of available rights in the system, and network interfaces, where they are used for access control. The grade and compartments in a subject and object pair are used to construct a relationship known as _dominance_, in which a subject dominates an object, the object dominates the subject, neither dominates the other, or both dominate each other. The "both dominate" case occurs when the two labels are equal. Due to the information flow nature of Biba, a user has rights to a set of compartments that might correspond to projects, but objects also have a set of compartments. Users may have to subset their rights using `su` or `setpmac` in order to access objects in a compartment from which they are not restricted. === User Labels Users are required to have labels so that their files and processes properly interact with the security policy defined on the system. This is configured in [.filename]#/etc/login.conf# using login classes. Every policy module that uses labels will implement the user class setting. To set the user class default label which will be enforced by MAC, add a `label` entry. An example `label` entry containing every policy module is displayed below. Note that in a real configuration, the administrator would never enable every policy module. It is recommended that the rest of this chapter be reviewed before any configuration is implemented. [.programlisting] .... default:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\ :manpath=/usr/share/man /usr/local/man:\ :nologin=/usr/sbin/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :vmemoryuse=100M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=91d:\ :umask=022:\ :ignoretime@:\ :label=partition/13,mls/5,biba/10(5-15),lomac/10[2]: .... While users can not modify the default value, they may change their label after they login, subject to the constraints of the policy. The example above tells the Biba policy that a process's minimum integrity is `5`, its maximum is `15`, and the default effective label is `10`. The process will run at `10` until it chooses to change label, perhaps due to the user using `setpmac`, which will be constrained by Biba to the configured range. After any change to [.filename]#login.conf#, the login class capability database must be rebuilt using `cap_mkdb`. Many sites have a large number of users requiring several different user classes. In depth planning is required as this can become difficult to manage. === Network Interface Labels Labels may be set on network interfaces to help control the flow of data across the network. Policies using network interface labels function in the same way that policies function with respect to objects. Users at high settings in Biba, for example, will not be permitted to access network interfaces with a label of `low`. When setting the MAC label on network interfaces, `maclabel` may be passed to `ifconfig`: [source,shell] .... # ifconfig bge0 maclabel biba/equal .... This example will set the MAC label of `biba/equal` on the `bge0` interface. When using a setting similar to `biba/high(low-high)`, the entire label should be quoted to prevent an error from being returned. Each policy module which supports labeling has a tunable which may be used to disable the MAC label on network interfaces. Setting the label to `equal` will have a similar effect. Review the output of `sysctl`, the policy manual pages, and the information in the rest of this chapter for more information on those tunables. [[mac-planning]] == Planning the Security Configuration Before implementing any MAC policies, a planning phase is recommended. During the planning stages, an administrator should consider the implementation requirements and goals, such as: * How to classify information and resources available on the target systems. * Which information or resources to restrict access to along with the type of restrictions that should be applied. * Which MAC modules will be required to achieve this goal. A trial run of the trusted system and its configuration should occur _before_ a MAC implementation is used on production systems. Since different environments have different needs and requirements, establishing a complete security profile will decrease the need of changes once the system goes live. Consider how the MAC framework augments the security of the system as a whole. The various security policy modules provided by the MAC framework could be used to protect the network and file systems or to block users from accessing certain ports and sockets. Perhaps the best use of the policy modules is to load several security policy modules at a time in order to provide a MLS environment. This approach differs from a hardening policy, which typically hardens elements of a system which are used only for specific purposes. The downside to MLS is increased administrative overhead. The overhead is minimal when compared to the lasting effect of a framework which provides the ability to pick and choose which policies are required for a specific configuration and which keeps performance overhead down. The reduction of support for unneeded policies can increase the overall performance of the system as well as offer flexibility of choice. A good implementation would consider the overall security requirements and effectively implement the various security policy modules offered by the framework. A system utilizing MAC guarantees that a user will not be permitted to change security attributes at will. All user utilities, programs, and scripts must work within the constraints of the access rules provided by the selected security policy modules and control of the MAC access rules is in the hands of the system administrator. It is the duty of the system administrator to carefully select the correct security policy modules. For an environment that needs to limit access control over the network, the man:mac_portacl[4], man:mac_ifoff[4], and man:mac_biba[4] policy modules make good starting points. For an environment where strict confidentiality of file system objects is required, consider the man:mac_bsdextended[4] and man:mac_mls[4] policy modules. Policy decisions could be made based on network configuration. If only certain users should be permitted access to man:ssh[1], the man:mac_portacl[4] policy module is a good choice. In the case of file systems, access to objects might be considered confidential to some users, but not to others. As an example, a large development team might be broken off into smaller projects where developers in project A might not be permitted to access objects written by developers in project B. Yet both projects might need to access objects created by developers in project C. Using the different security policy modules provided by the MAC framework, users could be divided into these groups and then given access to the appropriate objects. Each security policy module has a unique way of dealing with the overall security of a system. Module selection should be based on a well thought out security policy which may require revision and reimplementation. Understanding the different security policy modules offered by the MAC framework will help administrators choose the best policies for their situations. The rest of this chapter covers the available modules, describes their use and configuration, and in some cases, provides insight on applicable situations. [CAUTION] ==== Implementing MAC is much like implementing a firewall since care must be taken to prevent being completely locked out of the system. The ability to revert back to a previous configuration should be considered and the implementation of MAC over a remote connection should be done with extreme caution. ==== [[mac-policies]] == Available MAC Policies The default FreeBSD kernel includes `options MAC`. This means that every module included with the MAC framework can be loaded with `kldload` as a run-time kernel module. After testing the module, add the module name to [.filename]#/boot/loader.conf# so that it will load during boot. Each module also provides a kernel option for those administrators who choose to compile their own custom kernel. FreeBSD includes a group of policies that will cover most security requirements. Each policy is summarized below. The last three policies support integer settings in place of the three default labels. [[mac-seeotheruids]] === The MAC See Other UIDs Policy Module name: [.filename]#mac_seeotheruids.ko# Kernel configuration line: `options MAC_SEEOTHERUIDS` Boot option: `mac_seeotheruids_load="YES"` The man:mac_seeotheruids[4] module extends the `security.bsd.see_other_uids` and `security.bsd.see_other_gids sysctl` tunables. This option does not require any labels to be set before configuration and can operate transparently with other modules. After loading the module, the following `sysctl` tunables may be used to control its features: * `security.mac.seeotheruids.enabled` enables the module and implements the default settings which deny users the ability to view processes and sockets owned by other users. * `security.mac.seeotheruids.specificgid_enabled` allows specified groups to be exempt from this policy. To exempt specific groups, use the `security.mac.seeotheruids.specificgid=_XXX_ sysctl` tunable, replacing _XXX_ with the numeric group ID to be exempted. * `security.mac.seeotheruids.primarygroup_enabled` is used to exempt specific primary groups from this policy. When using this tunable, `security.mac.seeotheruids.specificgid_enabled` may not be set. [[mac-bsdextended]] === The MAC BSD Extended Policy Module name: [.filename]#mac_bsdextended.ko# Kernel configuration line: `options MAC_BSDEXTENDED` Boot option: `mac_bsdextended_load="YES"` The man:mac_bsdextended[4] module enforces a file system firewall. It provides an extension to the standard file system permissions model, permitting an administrator to create a firewall-like ruleset to protect files, utilities, and directories in the file system hierarchy. When access to a file system object is attempted, the list of rules is iterated until either a matching rule is located or the end is reached. This behavior may be changed using `security.mac.bsdextended.firstmatch_enabled`. Similar to other firewall modules in FreeBSD, a file containing the access control rules can be created and read by the system at boot time using an man:rc.conf[5] variable. The rule list may be entered using man:ugidfw[8] which has a syntax similar to man:ipfw[8]. More tools can be written by using the functions in the man:libugidfw[3] library. After the man:mac_bsdextended[4] module has been loaded, the following command may be used to list the current rule configuration: [source,shell] .... # ugidfw list 0 slots, 0 rules .... By default, no rules are defined and everything is completely accessible. To create a rule which blocks all access by users but leaves `root` unaffected: [source,shell] .... # ugidfw add subject not uid root new object not uid root mode n .... While this rule is simple to implement, it is a very bad idea as it blocks all users from issuing any commands. A more realistic example blocks `user1` all access, including directory listings, to ``_user2_``'s home directory: [source,shell] .... # ugidfw set 2 subject uid user1 object uid user2 mode n # ugidfw set 3 subject uid user1 object gid user2 mode n .... Instead of `user1`, `not uid _user2_` could be used in order to enforce the same access restrictions for all users. However, the `root` user is unaffected by these rules. [NOTE] ==== Extreme caution should be taken when working with this module as incorrect use could block access to certain parts of the file system. ==== [[mac-ifoff]] === The MAC Interface Silencing Policy Module name: [.filename]#mac_ifoff.ko# Kernel configuration line: `options MAC_IFOFF` Boot option: `mac_ifoff_load="YES"` The man:mac_ifoff[4] module is used to disable network interfaces on the fly and to keep network interfaces from being brought up during system boot. It does not use labels and does not depend on any other MAC modules. Most of this module's control is performed through these `sysctl` tunables: * `security.mac.ifoff.lo_enabled` enables or disables all traffic on the loopback, man:lo[4], interface. * `security.mac.ifoff.bpfrecv_enabled` enables or disables all traffic on the Berkeley Packet Filter interface, man:bpf[4]. * `security.mac.ifoff.other_enabled` enables or disables traffic on all other interfaces. One of the most common uses of man:mac_ifoff[4] is network monitoring in an environment where network traffic should not be permitted during the boot sequence. Another use would be to write a script which uses an application such as package:security/aide[] to automatically block network traffic if it finds new or altered files in protected directories. [[mac-portacl]] === The MAC Port Access Control List Policy Module name: [.filename]#mac_portacl.ko# Kernel configuration line: `MAC_PORTACL` Boot option: `mac_portacl_load="YES"` The man:mac_portacl[4] module is used to limit binding to local TCP and UDP ports, making it possible to allow non-`root` users to bind to specified privileged ports below 1024. Once loaded, this module enables the MAC policy on all sockets. The following tunables are available: * `security.mac.portacl.enabled` enables or disables the policy completely. * `security.mac.portacl.port_high` sets the highest port number that man:mac_portacl[4] protects. * `security.mac.portacl.suser_exempt`, when set to a non-zero value, exempts the `root` user from this policy. * `security.mac.portacl.rules` specifies the policy as a text string of the form `rule[,rule,...]`, with as many rules as needed, and where each rule is of the form `idtype:id:protocol:port`. The `idtype` is either `uid` or `gid`. The `protocol` parameter can be `tcp` or `udp`. The `port` parameter is the port number to allow the specified user or group to bind to. Only numeric values can be used for the user ID, group ID, and port parameters. By default, ports below 1024 can only be used by privileged processes which run as `root`. For man:mac_portacl[4] to allow non-privileged processes to bind to ports below 1024, set the following tunables as follows: [source,shell] .... # sysctl security.mac.portacl.port_high=1023 # sysctl net.inet.ip.portrange.reservedlow=0 # sysctl net.inet.ip.portrange.reservedhigh=0 .... To prevent the `root` user from being affected by this policy, set `security.mac.portacl.suser_exempt` to a non-zero value. [source,shell] .... # sysctl security.mac.portacl.suser_exempt=1 .... To allow the `www` user with UID 80 to bind to port 80 without ever needing `root` privilege: [source,shell] .... # sysctl security.mac.portacl.rules=uid:80:tcp:80 .... This next example permits the user with the UID of 1001 to bind to TCP ports 110 (POP3) and 995 (POP3s): [source,shell] .... # sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995 .... [[mac-partition]] === The MAC Partition Policy Module name: [.filename]#mac_partition.ko# Kernel configuration line: `options MAC_PARTITION` Boot option: `mac_partition_load="YES"` The man:mac_partition[4] policy drops processes into specific "partitions" based on their MAC label. Most configuration for this policy is done using man:setpmac[8]. One `sysctl` tunable is available for this policy: * `security.mac.partition.enabled` enables the enforcement of MAC process partitions. When this policy is enabled, users will only be permitted to see their processes, and any others within their partition, but will not be permitted to work with utilities outside the scope of this partition. For instance, a user in the `insecure` class will not be permitted to access `top` as well as many other commands that must spawn a process. This example adds `top` to the label set on users in the `insecure` class. All processes spawned by users in the `insecure` class will stay in the `partition/13` label. [source,shell] .... # setpmac partition/13 top .... This command displays the partition label and the process list: [source,shell] .... # ps Zax .... This command displays another user's process partition label and that user's currently running processes: [source,shell] .... # ps -ZU trhodes .... [NOTE] ==== Users can see processes in ``root``'s label unless the man:mac_seeotheruids[4] policy is loaded. ==== [[mac-mls]] === The MAC Multi-Level Security Module Module name: [.filename]#mac_mls.ko# Kernel configuration line: `options MAC_MLS` Boot option: `mac_mls_load="YES"` The man:mac_mls[4] policy controls access between subjects and objects in the system by enforcing a strict information flow policy. In MLS environments, a "clearance" level is set in the label of each subject or object, along with compartments. Since these clearance levels can reach numbers greater than several thousand, it would be a daunting task to thoroughly configure every subject or object. To ease this administrative overhead, three labels are included in this policy: `mls/low`, `mls/equal`, and `mls/high`, where: * Anything labeled with `mls/low` will have a low clearance level and not be permitted to access information of a higher level. This label also prevents objects of a higher clearance level from writing or passing information to a lower level. * `mls/equal` should be placed on objects which should be exempt from the policy. * `mls/high` is the highest level of clearance possible. Objects assigned this label will hold dominance over all other objects in the system; however, they will not permit the leaking of information to objects of a lower class. MLS provides: * A hierarchical security level with a set of non-hierarchical categories. * Fixed rules of `no read up, no write down`. This means that a subject can have read access to objects on its own level or below, but not above. Similarly, a subject can have write access to objects on its own level or above, but not beneath. * Secrecy, or the prevention of inappropriate disclosure of data. * A basis for the design of systems that concurrently handle data at multiple sensitivity levels without leaking information between secret and confidential. The following `sysctl` tunables are available: * `security.mac.mls.enabled` is used to enable or disable the MLS policy. * `security.mac.mls.ptys_equal` labels all man:pty[4] devices as `mls/equal` during creation. * `security.mac.mls.revocation_enabled` revokes access to objects after their label changes to a label of a lower grade. * `security.mac.mls.max_compartments` sets the maximum number of compartment levels allowed on a system. To manipulate MLS labels, use man:setfmac[8]. To assign a label to an object: [source,shell] .... # setfmac mls/5 test .... To get the MLS label for the file [.filename]#test#: [source,shell] .... # getfmac test .... Another approach is to create a master policy file in [.filename]#/etc/# which specifies the MLS policy information and to feed that file to `setfmac`. When using the MLS policy module, an administrator plans to control the flow of sensitive information. The default `block read up block write down` sets everything to a low state. Everything is accessible and an administrator slowly augments the confidentiality of the information. Beyond the three basic label options, an administrator may group users and groups as required to block the information flow between them. It might be easier to look at the information in clearance levels using descriptive words, such as classifications of `Confidential`, `Secret`, and `Top Secret`. Some administrators instead create different groups based on project levels. Regardless of the classification method, a well thought out plan must exist before implementing a restrictive policy. Some example situations for the MLS policy module include an e-commerce web server, a file server holding critical company information, and financial institution environments. [[mac-biba]] === The MAC Biba Module Module name: [.filename]#mac_biba.ko# Kernel configuration line: `options MAC_BIBA` Boot option: `mac_biba_load="YES"` The man:mac_biba[4] module loads the MAC Biba policy. This policy is similar to the MLS policy with the exception that the rules for information flow are slightly reversed. This is to prevent the downward flow of sensitive information whereas the MLS policy prevents the upward flow of sensitive information. In Biba environments, an "integrity" label is set on each subject or object. These labels are made up of hierarchical grades and non-hierarchical components. As a grade ascends, so does its integrity. Supported labels are `biba/low`, `biba/equal`, and `biba/high`, where: * `biba/low` is considered the lowest integrity an object or subject may have. Setting this on objects or subjects blocks their write access to objects or subjects marked as `biba/high`, but will not prevent read access. * `biba/equal` should only be placed on objects considered to be exempt from the policy. * `biba/high` permits writing to objects set at a lower label, but does not permit reading that object. It is recommended that this label be placed on objects that affect the integrity of the entire system. Biba provides: * Hierarchical integrity levels with a set of non-hierarchical integrity categories. * Fixed rules are `no write up, no read down`, the opposite of MLS. A subject can have write access to objects on its own level or below, but not above. Similarly, a subject can have read access to objects on its own level or above, but not below. * Integrity by preventing inappropriate modification of data. * Integrity levels instead of MLS sensitivity levels. The following tunables can be used to manipulate the Biba policy: * `security.mac.biba.enabled` is used to enable or disable enforcement of the Biba policy on the target machine. * `security.mac.biba.ptys_equal` is used to disable the Biba policy on man:pty[4] devices. * `security.mac.biba.revocation_enabled` forces the revocation of access to objects if the label is changed to dominate the subject. To access the Biba policy setting on system objects, use `setfmac` and `getfmac`: [source,shell] .... # setfmac biba/low test # getfmac test test: biba/low .... Integrity, which is different from sensitivity, is used to guarantee that information is not manipulated by untrusted parties. This includes information passed between subjects and objects. It ensures that users will only be able to modify or access information they have been given explicit access to. The man:mac_biba[4] security policy module permits an administrator to configure which files and programs a user may see and invoke while assuring that the programs and files are trusted by the system for that user. During the initial planning phase, an administrator must be prepared to partition users into grades, levels, and areas. The system will default to a high label once this policy module is enabled, and it is up to the administrator to configure the different grades and levels for users. Instead of using clearance levels, a good planning method could include topics. For instance, only allow developers modification access to the source code repository, source code compiler, and other development utilities. Other users would be grouped into other categories such as testers, designers, or end users and would only be permitted read access. A lower integrity subject is unable to write to a higher integrity subject and a higher integrity subject cannot list or read a lower integrity object. Setting a label at the lowest possible grade could make it inaccessible to subjects. Some prospective environments for this security policy module would include a constrained web server, a development and test machine, and a source code repository. A less useful implementation would be a personal workstation, a machine used as a router, or a network firewall. [[mac-lomac]] === The MAC Low-watermark Module Module name: [.filename]#mac_lomac.ko# Kernel configuration line: `options MAC_LOMAC` Boot option: `mac_lomac_load="YES"` Unlike the MAC Biba policy, the man:mac_lomac[4] policy permits access to lower integrity objects only after decreasing the integrity level to not disrupt any integrity rules. The Low-watermark integrity policy works almost identically to Biba, with the exception of using floating labels to support subject demotion via an auxiliary grade compartment. This secondary compartment takes the form `[auxgrade]`. When assigning a policy with an auxiliary grade, use the syntax `lomac/10[2]`, where `2` is the auxiliary grade. This policy relies on the ubiquitous labeling of all system objects with integrity labels, permitting subjects to read from low integrity objects and then downgrading the label on the subject to prevent future writes to high integrity objects using `[auxgrade]`. The policy may provide greater compatibility and require less initial configuration than Biba. Like the Biba and MLS policies, `setfmac` and `setpmac` are used to place labels on system objects: [source,shell] .... # setfmac /usr/home/trhodes lomac/high[low] # getfmac /usr/home/trhodes lomac/high[low] .... The auxiliary grade `low` is a feature provided only by the MACLOMAC policy. [[mac-userlocked]] == User Lock Down This example considers a relatively small storage system with fewer than fifty users. Users will have login capabilities and are permitted to store data and access resources. For this scenario, the man:mac_bsdextended[4] and man:mac_seeotheruids[4] policy modules could co-exist and block access to system objects while hiding user processes. Begin by adding the following line to [.filename]#/boot/loader.conf#: [.programlisting] .... mac_seeotheruids_load="YES" .... The man:mac_bsdextended[4] security policy module may be activated by adding this line to [.filename]#/etc/rc.conf#: [.programlisting] .... ugidfw_enable="YES" .... Default rules stored in [.filename]#/etc/rc.bsdextended# will be loaded at system initialization. However, the default entries may need modification. Since this machine is expected only to service users, everything may be left commented out except the last two lines in order to force the loading of user owned system objects by default. Add the required users to this machine and reboot. For testing purposes, try logging in as a different user across two consoles. Run `ps aux` to see if processes of other users are visible. Verify that running man:ls[1] on another user's home directory fails. Do not try to test with the `root` user unless the specific ``sysctl``s have been modified to block super user access. [NOTE] ==== When a new user is added, their man:mac_bsdextended[4] rule will not be in the ruleset list. To update the ruleset quickly, unload the security policy module and reload it again using man:kldunload[8] and man:kldload[8]. ==== [[mac-implementing]] == Nagios in a MAC Jail This section demonstrates the steps that are needed to implement the Nagios network monitoring system in a MAC environment. This is meant as an example which still requires the administrator to test that the implemented policy meets the security requirements of the network before using in a production environment. This example requires `multilabel` to be set on each file system. It also assumes that package:net-mgmt/nagios-plugins[], package:net-mgmt/nagios[], and package:www/apache22[] are all installed, configured, and working correctly before attempting the integration into the MAC framework. === Create an Insecure User Class Begin the procedure by adding the following user class to [.filename]#/etc/login.conf#: [.programlisting] .... insecure:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin :manpath=/usr/share/man /usr/local/man:\ :nologin=/usr/sbin/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :vmemoryuse=100M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=91d:\ :umask=022:\ :ignoretime@:\ :label=biba/10(10-10): .... Then, add the following line to the default user class section: [.programlisting] .... :label=biba/high: .... Save the edits and issue the following command to rebuild the database: [source,shell] .... # cap_mkdb /etc/login.conf .... === Configure Users Set the `root` user to the default class using: [source,shell] .... # pw usermod root -L default .... All user accounts that are not `root` will now require a login class. The login class is required, otherwise users will be refused access to common commands. The following `sh` script should do the trick: [source,shell] .... # for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \ /etc/passwd`; do pw usermod $x -L default; done; .... Next, drop the `nagios` and `www` accounts into the insecure class: [source,shell] .... # pw usermod nagios -L insecure # pw usermod www -L insecure .... === Create the Contexts File A contexts file should now be created as [.filename]#/etc/policy.contexts#: [.programlisting] .... # This is the default BIBA policy for this system. # System: /var/run(/.*)? biba/equal /dev/(/.*)? biba/equal /var biba/equal /var/spool(/.*)? biba/equal /var/log(/.*)? biba/equal /tmp(/.*)? biba/equal /var/tmp(/.*)? biba/equal /var/spool/mqueue biba/equal /var/spool/clientmqueue biba/equal # For Nagios: /usr/local/etc/nagios(/.*)? biba/10 /var/spool/nagios(/.*)? biba/10 # For apache /usr/local/etc/apache(/.*)? biba/10 .... This policy enforces security by setting restrictions on the flow of information. In this specific configuration, users, including `root`, should never be allowed to access Nagios. Configuration files and processes that are a part of Nagios will be completely self contained or jailed. This file will be read after running `setfsmac` on every file system. This example sets the policy on the root file system: [source,shell] .... # setfsmac -ef /etc/policy.contexts / .... Next, add these edits to the main section of [.filename]#/etc/mac.conf#: [.programlisting] .... default_labels file ?biba default_labels ifnet ?biba default_labels process ?biba default_labels socket ?biba .... === Loader Configuration To finish the configuration, add the following lines to [.filename]#/boot/loader.conf#: [.programlisting] .... mac_biba_load="YES" mac_seeotheruids_load="YES" security.mac.biba.trust_all_interfaces=1 .... And the following line to the network card configuration stored in [.filename]#/etc/rc.conf#. If the primary network configuration is done via DHCP, this may need to be configured manually after every system boot: [.programlisting] .... maclabel biba/equal .... === Testing the Configuration First, ensure that the web server and Nagios will not be started on system initialization and reboot. Ensure that `root` cannot access any of the files in the Nagios configuration directory. If `root` can list the contents of [.filename]#/var/spool/nagios#, something is wrong. Instead, a "permission denied" error should be returned. If all seems well, Nagios, Apache, and Sendmail can now be started: [source,shell] .... # cd /etc/mail && make stop && \ setpmac biba/equal make start && setpmac biba/10\(10-10\) apachectl start && \ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart .... Double check to ensure that everything is working properly. If not, check the log files for error messages. If needed, use man:sysctl[8] to disable the man:mac_biba[4] security policy module and try starting everything again as usual. [NOTE] ==== The `root` user can still change the security enforcement and edit its configuration files. The following command will permit the degradation of the security policy to a lower grade for a newly spawned shell: [source,shell] .... # setpmac biba/10 csh .... To block this from happening, force the user into a range using man:login.conf[5]. If man:setpmac[8] attempts to run a command outside of the compartment's range, an error will be returned and the command will not be executed. In this case, set root to `biba/high(high-high)`. ==== [[mac-troubleshoot]] == Troubleshooting the MAC Framework This section discusses common configuration errors and how to resolve them. The `multilabel` flag does not stay enabled on the root ([.filename]#/#) partition::: The following steps may resolve this transient error: [.procedure] ==== . Edit [.filename]#/etc/fstab# and set the root partition to `ro` for read-only. . Reboot into single user mode. . Run `tunefs -l enable` on [.filename]#/#. . Reboot the system. . Run `mount -urw`[.filename]#/# and change the `ro` back to `rw` in [.filename]#/etc/fstab# and reboot the system again. . Double-check the output from `mount` to ensure that `multilabel` has been properly set on the root file system. ==== After establishing a secure environment with MAC, Xorg no longer starts::: This could be caused by the MAC `partition` policy or by a mislabeling in one of the MAC labeling policies. To debug, try the following: [.procedure] ==== . Check the error message. If the user is in the `insecure` class, the `partition` policy may be the culprit. Try setting the user's class back to the `default` class and rebuild the database with `cap_mkdb`. If this does not alleviate the problem, go to step two. . Double-check that the label policies are set correctly for the user, Xorg, and the [.filename]#/dev# entries. . If neither of these resolve the problem, send the error message and a description of the environment to the {freebsd-questions}. ==== The `_secure_path: unable to stat .login_conf` error appears::: This error can appear when a user attempts to switch from the `root` user to another user in the system. This message usually occurs when the user has a higher label setting than that of the user they are attempting to become. For instance, if `joe` has a default label of `biba/low` and `root` has a label of `biba/high`, `root` cannot view ``joe``'s home directory. This will happen whether or not `root` has used `su` to become `joe` as the Biba integrity model will not permit `root` to view objects set at a lower integrity level. The system no longer recognizes `root`::: When this occurs, `whoami` returns `0` and `su` returns `who are you?`. + This can happen if a labeling policy has been disabled by man:sysctl[8] or the policy module was unloaded. If the policy is disabled, the login capabilities database needs to be reconfigured. Double check [.filename]#/etc/login.conf# to ensure that all `label` options have been removed and rebuild the database with `cap_mkdb`. + This may also happen if a policy restricts access to [.filename]#master.passwd#. This is usually caused by an administrator altering the file under a label which conflicts with the general policy being used by the system. In these cases, the user information would be read by the system and access would be blocked as the file has inherited the new label. Disable the policy using man:sysctl[8] and everything should return to normal.