git: 99333306b8 - main - Handbook - Security: Upgrade the chapter
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 27 Sep 2023 16:57:29 UTC
The branch main has been updated by carlavilla:
URL: https://cgit.FreeBSD.org/doc/commit/?id=99333306b8924d300ffd745bf5e1e139e337e830
commit 99333306b8924d300ffd745bf5e1e139e337e830
Author: Sergio Carlavilla Delgado <carlavilla@FreeBSD.org>
AuthorDate: 2023-09-27 16:46:56 +0000
Commit: Sergio Carlavilla Delgado <carlavilla@FreeBSD.org>
CommitDate: 2023-09-27 16:46:56 +0000
Handbook - Security: Upgrade the chapter
Upgrade Security chapter as part of the Handbook Working Group.
This is a first approximation, there are things to improve and
add to the chapter, but we can continue from here :)
Changes:
- Move VPN over IPSec to an article, in the future we will add too
OpenVPN (DCO) and WireGuard to the article
- Rework Securing Accounts section
- Upgrade Password Hashes algorithms
- Improve sudo/doas section
- Add new Intrusion Detection System (IDS) section
- Add new Secure levels section
- Add new File flags section
- Rework OpenSSH and OpenSSL sections
- Rework Access Control Lists and add NFSv4 ACLs
- Add Capsicum introduction section
- Upgrade Resource Limits section
- Improve Asciidoc syntax
Documentation checked:
- https://man.freebsd.org/security
- https://calomel.org/ids_mtree.html
- https://calomel.org/openssh.html
- https://calomel.org/openssh_distributed.html
- https://man.freebsd.org/cgi/man.cgi?query=chflags&sektion=1&apropos=0&manpath=FreeBSD+13.2-RELEASE+and+Ports
- https://www.cyberciti.biz/tips/howto-write-protect-file-with-immutable-bit.html
- https://wiki.gentoo.org/wiki/Doas
- https://people.freebsd.org/~dannyboy/articles/freebsd_acls.pdf
- https://wiki.freebsd.org/NFSv4_ACLs
- https://man.freebsd.org/cgi/man.cgi?setfacl
Reviewed by: emaste, karels, philip (first draft)
Differential Revision: https://reviews.freebsd.org/D41620
Sponsored by: Daifressh
---
.../content/en/articles/vpn-ipsec/_index.adoc | 326 +++
.../content/en/books/handbook/security/_index.adoc | 2811 +++++++++-----------
shared/en/urls.adoc | 1 +
3 files changed, 1568 insertions(+), 1570 deletions(-)
diff --git a/documentation/content/en/articles/vpn-ipsec/_index.adoc b/documentation/content/en/articles/vpn-ipsec/_index.adoc
new file mode 100644
index 0000000000..882a4c0f34
--- /dev/null
+++ b/documentation/content/en/articles/vpn-ipsec/_index.adoc
@@ -0,0 +1,326 @@
+---
+title: VPN over IPsec
+authors:
+ - author: The FreeBSD Documentation Project
+copyright: 2023 The FreeBSD Documentation Project
+description: VPN over IPsec
+trademarks: ["freebsd", "general"]
+---
+
+= VPN over IPsec
+:doctype: article
+:toc: macro
+:toclevels: 1
+:icons: font
+:sectnums:
+:sectnumlevels: 6
+:source-highlighter: rouge
+:experimental:
+
+'''
+
+toc::[]
+
+Internet Protocol Security (IPsec) is a set of protocols which sit on top of the Internet Protocol (IP) layer.
+It allows two or more hosts to communicate in a secure manner by authenticating and encrypting each IP packet of a communication session.
+The FreeBSD IPsec network stack is based on the http://www.kame.net/[http://www.kame.net/] implementation and supports both IPv4 and IPv6 sessions.
+
+IPsec is comprised of the following sub-protocols:
+
+* _Encapsulated Security Payload (ESP)_: this protocol protects the IP packet data from third party interference by encrypting the contents using symmetric cryptography algorithms such as Blowfish and 3DES.
+* _Authentication Header (AH)_: this protocol protects the IP packet header from third party interference and spoofing by computing a cryptographic checksum and hashing the IP packet header fields with a secure hashing function. This is then followed by an additional header that contains the hash, to allow the information in the packet to be authenticated.
+* _IP Payload Compression Protocol (IPComp_): this protocol tries to increase communication performance by compressing the IP payload in order to reduce the amount of data sent.
+
+These protocols can either be used together or separately, depending on the environment.
+
+IPsec supports two modes of operation.
+The first mode, _Transport Mode_, protects communications between two hosts.
+The second mode, _Tunnel Mode_, is used to build virtual tunnels, commonly known as Virtual Private Networks (VPNs).
+Consult man:ipsec[4] for detailed information on the IPsec subsystem in FreeBSD.
+
+The article demonstrates the process of setting up an IPsecVPN between a home network and a corporate network.
+
+In the example scenario:
+
+* Both sites are connected to the Internet through a gateway that is running FreeBSD.
+* The gateway on each network has at least one external IP address. In this example, the corporate LAN's external IP address is `172.16.5.4` and the home LAN's external IP address is `192.168.1.12`.
+* The internal addresses of the two networks can be either public or private IP addresses. However, the address space must not overlap. In this example, the corporate LAN's internal IP address is `10.246.38.1` and the home LAN's internal IP address is `10.0.0.5`.
+
+[.programlisting]
+....
+ corporate home
+10.246.38.1/24 -- 172.16.5.4 <--> 192.168.1.12 -- 10.0.0.5/24
+....
+
+== Configuring a VPN on FreeBSD
+
+To begin, package:security/ipsec-tools[] must be installed from the Ports Collection.
+This software provides a number of applications which support the configuration.
+
+The next requirement is to create two man:gif[4] pseudo-devices which will be used to tunnel packets and allow both networks to communicate properly.
+As `root`, run the following command on each gateway:
+
+[source,shell]
+....
+corp-gw# ifconfig gif0 create
+corp-gw# ifconfig gif0 10.246.38.1 10.0.0.5
+corp-gw# ifconfig gif0 tunnel 172.16.5.4 192.168.1.12
+....
+
+[source,shell]
+....
+home-gw# ifconfig gif0 create
+home-gw# ifconfig gif0 10.0.0.5 10.246.38.1
+home-gw# ifconfig gif0 tunnel 192.168.1.12 172.16.5.4
+....
+
+Verify the setup on each gateway, using `ifconfig gif0`.
+Here is the output from the home gateway:
+
+[.programlisting]
+....
+gif0: flags=8051 mtu 1280
+tunnel inet 172.16.5.4 --> 192.168.1.12
+inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6
+inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00
+....
+
+Here is the output from the corporate gateway:
+
+[.programlisting]
+....
+gif0: flags=8051 mtu 1280
+tunnel inet 192.168.1.12 --> 172.16.5.4
+inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00
+inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4
+....
+
+Once complete, both internal IP addresses should be reachable using man:ping[8]:
+
+[source,shell]
+....
+home-gw# ping 10.0.0.5
+PING 10.0.0.5 (10.0.0.5): 56 data bytes
+64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms
+64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms
+64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms
+64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms
+--- 10.0.0.5 ping statistics ---
+4 packets transmitted, 4 packets received, 0% packet loss
+round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms
+
+corp-gw# ping 10.246.38.1
+PING 10.246.38.1 (10.246.38.1): 56 data bytes
+64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms
+64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms
+64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms
+64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms
+64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms
+--- 10.246.38.1 ping statistics ---
+5 packets transmitted, 5 packets received, 0% packet loss
+round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms
+....
+
+As expected, both sides have the ability to send and receive ICMP packets from the privately configured addresses.
+Next, both gateways must be told how to route packets in order to correctly send traffic from the networks behind each gateway.
+The following commands will achieve this goal:
+
+[source,shell]
+....
+corp-gw# route add 10.0.0.0 10.0.0.5 255.255.255.0
+corp-gw# route add net 10.0.0.0: gateway 10.0.0.5
+home-gw# route add 10.246.38.0 10.246.38.1 255.255.255.0
+home-gw# route add host 10.246.38.0: gateway 10.246.38.1
+....
+
+Internal machines should be reachable from each gateway as well as from machines behind the gateways.
+Again, use man:ping[8] to confirm:
+
+[source,shell]
+....
+corp-gw# ping -c 3 10.0.0.8
+PING 10.0.0.8 (10.0.0.8): 56 data bytes
+64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms
+64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms
+64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms
+--- 10.0.0.8 ping statistics ---
+3 packets transmitted, 3 packets received, 0% packet loss
+round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms
+
+home-gw# ping -c 3 10.246.38.107
+PING 10.246.38.1 (10.246.38.107): 56 data bytes
+64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms
+64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms
+64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms
+--- 10.246.38.107 ping statistics ---
+3 packets transmitted, 3 packets received, 0% packet loss
+round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms
+....
+
+At this point, traffic is flowing between the networks encapsulated in a gif tunnel but without any encryption.
+Next, use IPSec to encrypt traffic using pre-shared keys (PSK).
+Other than the IP addresses, [.filename]#/usr/local/etc/racoon/racoon.conf# on both gateways will be identical and look similar to:
+
+[.programlisting]
+....
+path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file
+log debug; #log verbosity setting: set to 'notify' when testing and debugging is complete
+
+padding # options are not to be changed
+{
+ maximum_length 20;
+ randomize off;
+ strict_check off;
+ exclusive_tail off;
+}
+
+timer # timing options. change as needed
+{
+ counter 5;
+ interval 20 sec;
+ persend 1;
+# natt_keepalive 15 sec;
+ phase1 30 sec;
+ phase2 15 sec;
+}
+
+listen # address [port] that racoon will listen on
+{
+ isakmp 172.16.5.4 [500];
+ isakmp_natt 172.16.5.4 [4500];
+}
+
+remote 192.168.1.12 [500]
+{
+ exchange_mode main,aggressive;
+ doi ipsec_doi;
+ situation identity_only;
+ my_identifier address 172.16.5.4;
+ peers_identifier address 192.168.1.12;
+ lifetime time 8 hour;
+ passive off;
+ proposal_check obey;
+# nat_traversal off;
+ generate_policy off;
+
+ proposal {
+ encryption_algorithm blowfish;
+ hash_algorithm md5;
+ authentication_method pre_shared_key;
+ lifetime time 30 sec;
+ dh_group 1;
+ }
+}
+
+sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $network/$netmask $type address $network/$netmask $type ( $type being any or esp)
+{ # $network must be the two internal networks you are joining.
+ pfs_group 1;
+ lifetime time 36000 sec;
+ encryption_algorithm blowfish,3des;
+ authentication_algorithm hmac_md5,hmac_sha1;
+ compression_algorithm deflate;
+}
+....
+
+For descriptions of each available option, refer to the manual page for [.filename]#racoon.conf#.
+
+The Security Policy Database (SPD) needs to be configured so that FreeBSD and racoon are able to encrypt and decrypt network traffic between the hosts.
+
+This can be achieved with a shell script, similar to the following, on the corporate gateway.
+This file will be used during system initialization and should be saved as [.filename]#/usr/local/etc/racoon/setkey.conf#.
+
+[.programlisting]
+....
+flush;
+spdflush;
+# To the home network
+spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use;
+spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use;
+....
+
+Once in place, racoon may be started on both gateways using the following command:
+
+[source,shell]
+....
+# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log
+....
+
+The output should be similar to the following:
+
+[source,shell]
+....
+corp-gw# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf
+Foreground mode.
+2006-01-30 01:35:47: INFO: begin Identity Protection mode.
+2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon
+2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon
+2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a
+2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0]
+2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2)
+2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426)
+2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0]
+2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b)
+2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66)
+....
+
+To ensure the tunnel is working properly, switch to another console and use man:tcpdump[1] to view network traffic using the following command.
+Replace `em0` with the network interface card as required:
+
+[source,shell]
+....
+corp-gw# tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12
+....
+
+Data similar to the following should appear on the console.
+If not, there is an issue and debugging the returned data will be required.
+
+[.programlisting]
+....
+01:47:32.021683 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa)
+01:47:33.022442 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb)
+01:47:34.024218 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc)
+....
+
+At this point, both networks should be available and seem to be part of the same network.
+Most likely both networks are protected by a firewall.
+To allow traffic to flow between them, rules need to be added to pass packets.
+For the man:ipfw[8] firewall, add the following lines to the firewall configuration file:
+
+[.programlisting]
+....
+ipfw add 00201 allow log esp from any to any
+ipfw add 00202 allow log ah from any to any
+ipfw add 00203 allow log ipencap from any to any
+ipfw add 00204 allow log udp from any 500 to any
+....
+
+[NOTE]
+====
+The rule numbers may need to be altered depending on the current host configuration.
+====
+
+For users of man:pf[4] or man:ipf[8], the following rules should do the trick:
+
+[.programlisting]
+....
+pass in quick proto esp from any to any
+pass in quick proto ah from any to any
+pass in quick proto ipencap from any to any
+pass in quick proto udp from any port = 500 to any port = 500
+pass in quick on gif0 from any to any
+pass out quick proto esp from any to any
+pass out quick proto ah from any to any
+pass out quick proto ipencap from any to any
+pass out quick proto udp from any port = 500 to any port = 500
+pass out quick on gif0 from any to any
+....
+
+Finally, to allow the machine to start support for the VPN during system initialization, add the following lines to [.filename]#/etc/rc.conf#:
+
+[.programlisting]
+....
+ipsec_enable="YES"
+ipsec_program="/usr/local/sbin/setkey"
+ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot
+racoon_enable="yes"
+....
diff --git a/documentation/content/en/books/handbook/security/_index.adoc b/documentation/content/en/books/handbook/security/_index.adoc
index 93a81d0ad6..78d502c2e6 100644
--- a/documentation/content/en/books/handbook/security/_index.adoc
+++ b/documentation/content/en/books/handbook/security/_index.adoc
@@ -4,7 +4,7 @@ part: Part III. System Administration
prev: books/handbook/boot
next: books/handbook/jails
description: Hundreds of standard practices have been authored about how to secure systems and networks, and as a user of FreeBSD, understanding how to protect against attacks and intruders is a must
-tags: ["security", "one-time passwords", "TCP Wrapper", "Kerberos", "OpenSSL", "IPsec", "OpenSSH", "ACL", "advisories", "sudo", "doas", "monitoring"]
+tags: ["security", "TCP Wrappers", "Kerberos", "OpenSSL", "OpenSSH", "ACL", "NFSv4 ACLs", "advisories", "sudo", "doas", "capsicum", "monitoring"]
showBookMenu: true
weight: 20
path: "/books/handbook/"
@@ -51,33 +51,27 @@ endif::[]
[[security-synopsis]]
== Synopsis
-Security, whether physical or virtual, is a topic so broad that an entire industry has evolved around it.
Hundreds of standard practices have been authored about how to secure systems and networks, and as a user of FreeBSD, understanding how to protect against attacks and intruders is a must.
In this chapter, several fundamentals and techniques will be discussed.
The FreeBSD system comes with multiple layers of security, and many more third party utilities may be added to enhance security.
-After reading this chapter, you will know:
+This chapter covers:
* Basic FreeBSD system security concepts.
* The various crypt mechanisms available in FreeBSD.
-* How to set up one-time password authentication.
-* How to configure TCP Wrapper for use with man:inetd[8].
+* How to configure TCP Wrappers for use with man:inetd[8].
* How to set up Kerberos on FreeBSD.
-* How to configure IPsec and create a VPN.
* How to configure and use OpenSSH on FreeBSD.
+* How to use OpenSSL on FreeBSD.
* How to use file system ACLs.
* How to use pkg to audit third party software packages installed from the Ports Collection.
* How to utilize FreeBSD security advisories.
* What Process Accounting is and how to enable it on FreeBSD.
* How to control user resources using login classes or the resource limits database.
+* What is Capsicum and a basic example.
-Before reading this chapter, you should:
-
-* Understand basic FreeBSD and Internet concepts.
-
-Additional security topics are covered elsewhere in this Handbook.
-For example, Mandatory Access Control is discussed in crossref:mac[mac,Mandatory Access Control] and Internet firewalls are discussed in crossref:firewalls[firewalls,Firewalls].
+Certain topics due to their complexity are found in dedicated chapters such as crossref:firewalls[firewalls,Firewalls], crossref:mac[mac,Mandatory Access Control] and articles like extref:{vpn-ipsec}[VPN over IPsec].
[[security-intro]]
== Introduction
@@ -108,57 +102,39 @@ The policy should include the security configuration of workstations, desktops,
In many cases, standard operating procedures (SOPs) already exist.
When in doubt, ask the security team.
-The rest of this introduction describes how some of these basic security configurations are performed on a FreeBSD system.
-The rest of this chapter describes some specific tools which can be used when implementing a security policy on a FreeBSD system.
+[[sec-accounts]]
+== Securing Accounts
+
+Maintaining secure accounts in FreeBSD is crucial for data confidentiality, system integrity, and privilege separation, as it prevents unauthorized access, malware, and data breaches while ensuring compliance and protecting an organization's reputation.
[[security-accounts]]
=== Preventing Logins
In securing a system, a good starting point is an audit of accounts.
-Ensure that `root` has a strong password and that this password is not shared.
Disable any accounts that do not need login access.
-To deny login access to accounts, two methods exist.
-The first is to lock the account.
-This example locks the `toor` account:
+[TIP]
+====
+Ensure that `root` has a strong password and that this password is not shared.
+====
-[source,shell]
-....
-# pw lock toor
-....
+To deny login access to accounts, two methods exist.
-The second method is to prevent login access by changing the shell to [.filename]#/usr/sbin/nologin#.
-Only the superuser can change the shell for other users:
+The first is to lock the account, this example shows how to lock the `imani` account:
[source,shell]
....
-# chsh -s /usr/sbin/nologin toor
+# pw lock imani
....
-The [.filename]#/usr/sbin/nologin# shell prevents the system from assigning a shell to the user when they attempt to login.
-
-[[security-accountmgmt]]
-=== Permitted Account Escalation
-
-In some cases, system administration needs to be shared with other users.
-FreeBSD has two methods to handle this.
-The first one, which is not recommended, is a shared root password used by members of the `wheel` group.
-With this method, a user types `su` and enters the password for `wheel` whenever superuser access is needed.
-The user should then type `exit` to leave privileged access after finishing the commands that required administrative access.
-To add a user to this group, edit [.filename]#/etc/group# and add the user to the end of the `wheel` entry.
-The user must be separated by a comma character with no space.
-
-The second, and recommended, method to permit privilege escalation is to install the package:security/sudo[] package or port.
-This software provides additional auditing, more fine-grained user control, and can be configured to lock users into running only the specified privileged commands.
+The second method is to prevent login access by changing the shell to [.filename]#/usr/sbin/nologin#.
+The man:nologin[8] shell prevents the system from assigning a shell to the user when they attempt to login.
-After installation, use `visudo` to edit [.filename]#/usr/local/etc/sudoers#.
-This example creates a new `webadmin` group, adds the `trhodes` account to that group, and configures that group access to restart package:apache24[]:
+Only the superuser can change the shell for other users:
[source,shell]
....
-# pw groupadd webadmin -M trhodes -g 6000
-# visudo
-%webadmin ALL=(ALL) /usr/sbin/service apache24 *
+# chsh -s /usr/sbin/nologin imani
....
[[security-passwords]]
@@ -166,7 +142,8 @@ This example creates a new `webadmin` group, adds the `trhodes` account to that
Passwords are a necessary evil of technology.
When they must be used, they should be complex and a powerful hash mechanism should be used to encrypt the version that is stored in the password database.
-FreeBSD supports the DES, MD5, SHA256, SHA512, and Blowfish hash algorithms in its `crypt()` library.
+FreeBSD supports several algorithms, including SHA256, SHA512 and Blowfish hash algorithms in its `crypt()` library, see man:crypt[3] for details.
+
The default of SHA512 should not be changed to a less secure hashing algorithm, but can be changed to the more secure Blowfish algorithm.
[NOTE]
@@ -177,55 +154,70 @@ Its use may not be permitted in some environments.
To determine which hash algorithm is used to encrypt a user's password, the superuser can view the hash for the user in the FreeBSD password database.
Each hash starts with a symbol which indicates the type of hash mechanism used to encrypt the password.
+
If DES is used, there is no beginning symbol.
For MD5, the symbol is `$`.
For SHA256 and SHA512, the symbol is `$6$`.
For Blowfish, the symbol is `$2a$`.
-In this example, the password for `dru` is hashed using the default SHA512 algorithm as the hash starts with `$6$`.
+In this example, the password for `imani` is hashed using the default SHA512 algorithm as the hash starts with `$6$`.
Note that the encrypted hash, not the password itself, is stored in the password database:
[source,shell]
....
-# grep dru /etc/master.passwd
-dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh
+# grep imani /etc/master.passwd
+....
+
+The output should be similar to the following:
+
+[.programlisting]
+....
+imani:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:imani:/usr/home/imani:/bin/sh
....
The hash mechanism is set in the user's login class.
-For this example, the user is in the `default` login class and the hash algorithm is set with this line in [.filename]#/etc/login.conf#:
+
+The following command can be run to check which hash mechanism is currently being used:
+
+[source,shell]
+....
+# grep user /etc/master.passwd
+....
+
+The output should be similar to the following:
[.programlisting]
....
- :passwd_format=sha512:\
+:passwd_format=sha512:\
....
-To change the algorithm to Blowfish, modify that line to look like this:
+For example, to change the algorithm to Blowfish, modify that line to look like this:
[.programlisting]
....
- :passwd_format=blf:\
+:passwd_format=blf:\
+....
+
+Then, man:cap_mkdb[1] must be executed to upgrade the login.conf database:
+
+[source,shell]
+....
+# cap_mkdb /etc/login.conf
....
-Then run `cap_mkdb /etc/login.conf` as described in <<users-limiting>>.
Note that this change will not affect any existing password hashes.
This means that all passwords should be re-hashed by asking users to run `passwd` in order to change their password.
-For remote logins, two-factor authentication should be used.
-An example of two-factor authentication is "something you have", such as a key, and "something you know", such as the passphrase for that key.
-Since OpenSSH is part of the FreeBSD base system, all network logins should be over an encrypted connection and use key-based authentication instead of passwords.
-For more information, refer to <<openssh>>.
-Kerberos users may need to make additional changes to implement OpenSSH in their network.
-These changes are described in <<kerberos5>>.
-
[[security-pwpolicy]]
=== Password Policy Enforcement
Enforcing a strong password policy for local accounts is a fundamental aspect of system security.
In FreeBSD, password length, password strength, and password complexity can be implemented using built-in Pluggable Authentication Modules (PAM).
-This section demonstrates how to configure the minimum and maximum password length and the enforcement of mixed characters using the [.filename]#pam_passwdqc.so# module.
+This section demonstrates how to configure the minimum and maximum password length and the enforcement of mixed characters using the man:pam_passwdqc[8] module.
This module is enforced when a user changes their password.
To configure this module, become the superuser and uncomment the line containing `pam_passwdqc.so` in [.filename]#/etc/pam.d/passwd#.
+
Then, edit that line to match the password policy:
[.programlisting]
@@ -233,24 +225,20 @@ Then, edit that line to match the password policy:
password requisite pam_passwdqc.so min=disabled,disabled,disabled,12,10 similar=deny retry=3 enforce=users
....
-This example sets several requirements for new passwords.
-The `min` setting controls the minimum password length.
-It has five values because this module defines five different types of passwords based on their complexity.
-Complexity is defined by the type of characters that must exist in a password, such as letters, numbers, symbols, and case.
-The types of passwords are described in man:pam_passwdqc[8].
-In this example, the first three types of passwords are disabled, meaning that passwords that meet those complexity requirements will not be accepted, regardless of their length.
-The `12` sets a minimum password policy of at least twelve characters, if the password also contains characters with three types of complexity.
-The `10` sets the password policy to also allow passwords of at least ten characters, if the password contains characters with four types of complexity.
-
-The `similar` setting denies passwords that are similar to the user's previous password.
-The `retry` setting provides a user with three opportunities to enter a new password.
+The explanation of the parameters can be found in man:pam_passwdqc[8].
Once this file is saved, a user changing their password will see a message similar to the following:
[source,shell]
....
% passwd
-Changing local password for trhodes
+....
+
+The output should be similar to the following:
+
+[.programlisting]
+....
+Changing local password for user
Old Password:
You can now choose the new password.
@@ -267,8 +255,8 @@ Enter new password:
If a password that does not match the policy is entered, it will be rejected with a warning and the user will have an opportunity to try again, up to the configured number of retries.
-Most password policies require passwords to expire after so many days.
-To set a password age time in FreeBSD, set `passwordtime` for the user's login class in [.filename]#/etc/login.conf#.
+If your organization's policy requires passwords to expire, FreeBSD supports the `passwordtime` in the user's login class in [.filename]#/etc/login.conf#
+
The `default` login class contains an example:
[.programlisting]
@@ -276,1767 +264,1357 @@ The `default` login class contains an example:
# :passwordtime=90d:\
....
-So, to set an expiry of 90 days for this login class, remove the comment symbol (`+#+`), save the edit, and run `cap_mkdb /etc/login.conf`.
+So, to set an expiry of 90 days for this login class, remove the comment symbol (#), save the edit, and execute the following command:
+
+[source,shell]
+....
+# cap_mkdb /etc/login.conf
+....
To set the expiration on individual users, pass an expiration date or the number of days to expiry and a username to `pw`:
[source,shell]
....
-# pw usermod -p 30-apr-2015 -n trhodes
+# pw usermod -p 30-apr-2025 -n user
....
As seen here, an expiration date is set in the form of day, month, and year.
For more information, see man:pw[8].
-[[security-rkhunter]]
-=== Detecting Rootkits
+[[security-sudo]]
+=== Shared Administration with sudo
+
+System administrators often need the ability to grant enhanced permissions to users so they may perform privileged tasks.
+The idea that team members are provided access to a FreeBSD system to perform their specific tasks opens up unique challenges to every administrator.
+These team members only need a subset of access beyond normal end user levels; however, they almost always tell management they are unable to perform their tasks without superuser access.
+Thankfully, there is no reason to provide such access to end users because tools exist to manage this exact requirement.
+
+[TIP]
+====
+Even administrators should limit their privileges when not needed.
+====
-A _rootkit_ is any unauthorized software that attempts to gain `root` access to a system.
-Once installed, this malicious software will normally open up another avenue of entry for an attacker.
-Realistically, once a system has been compromised by a rootkit and an investigation has been performed, the system should be reinstalled from scratch.
-There is tremendous risk that even the most prudent security or systems engineer will miss something an attacker left behind.
+Up to this point, the security chapter has covered permitting access to authorized users and attempting to prevent unauthorized access.
+Another problem arises once authorized users have access to the system resources.
+In many cases, some users may need access to application startup scripts, or a team of administrators need to maintain the system.
+Traditionally, the standard users and groups, file permissions, and even the man:su[1] command would manage this access.
+And as applications required more access, as more users needed to use system resources, a better solution was required.
+The most used application is currently Sudo.
-A rootkit does do one thing useful for administrators: once detected, it is a sign that a compromise happened at some point.
-But, these types of applications tend to be very well hidden.
-This section demonstrates a tool that can be used to detect rootkits, package:security/rkhunter[].
+Sudo allows administrators to configure more rigid access to system commands and provide for some advanced logging features.
+As a tool, it is available from the Ports Collection as package:security/sudo[] or by use of the man:pkg[8] utility.
-After installation of this package or port, the system may be checked using the following command.
-It will produce a lot of information and will require some manual pressing of kbd:[ENTER]:
+Execute the following command to install it:
[source,shell]
....
-# rkhunter -c
+# pkg install sudo
....
-After the process completes, a status message will be printed to the screen.
-This message will include the amount of files checked, suspect files, possible rootkits, and more.
-During the check, some generic security warnings may be produced about hidden files, the OpenSSH protocol selection, and known vulnerable versions of installed software.
-These can be handled now or after a more detailed analysis has been performed.
+After the installation is complete, the installed `visudo` will open the configuration file with a text editor.
+Using `visudo` is highly recommended as it comes with a built in syntax checker to verify there are no errors before the file is saved.
-Every administrator should know what is running on the systems they are responsible for.
-Third-party tools like rkhunter and package:sysutils/lsof[], and native commands such as `netstat` and `ps`, can show a great deal of information on the system.
-Take notes on what is normal, ask questions when something seems out of place, and be paranoid.
-While preventing a compromise is ideal, detecting a compromise is a must.
+The configuration file is made up of several small sections which allow for extensive configuration.
+In the following example, web application maintainer, user1, needs to start, stop, and restart the web application known as _webservice_.
+To grant this user permission to perform these tasks, add this line to the end of [.filename]#/usr/local/etc/sudoers#:
-[[security-ids]]
-=== Binary Verification
+[.programlisting]
+....
+user1 ALL=(ALL) /usr/sbin/service webservice *
+....
-Verification of system files and binaries is important because it provides the system administration and security teams information about system changes.
-A software application that monitors the system for changes is called an Intrusion Detection System (IDS).
+The user may now start _webservice_ using this command:
-FreeBSD provides native support for a basic IDS system.
-While the nightly security emails will notify an administrator of changes, the information is stored locally and there is a chance that a malicious user could modify this information in order to hide their changes to the system.
-As such, it is recommended to create a separate set of binary signatures and store them on a read-only, root-owned directory or, preferably, on a removable USB disk or remote rsync server.
+[source,shell]
+....
+% sudo /usr/sbin/service webservice start
+....
-The built-in `mtree` utility can be used to generate a specification of the contents of a directory.
-A seed, or a numeric constant, is used to generate the specification and is required to check that the specification has not changed.
-This makes it possible to determine if a file or binary has been modified.
-Since the seed value is unknown by an attacker, faking or checking the checksum values of files will be difficult to impossible.
-The following example generates a set of SHA256 hashes, one for each system binary in [.filename]#/bin#, and saves those values to a hidden file in ``root``'s home directory, [.filename]#/root/.bin_chksum_mtree#:
+While this configuration allows a single user access to the webservice service;
+however, in most organizations, there is an entire web team in charge of managing the service.
+A single line can also give access to an entire group.
+These steps will create a web group, add a user to this group, and allow all members of the group to manage the service:
[source,shell]
....
-# mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > /root/.bin_chksum_mtree
-# mtree: /bin checksum: 3427012225
+# pw groupadd -g 6001 -n webteam
....
-The _3483151339707503_ represents the seed.
-This value should be remembered, but not shared.
+Using the same man:pw[8] command, the user is added to the webteam group:
+
+[source,shell]
+....
+# pw groupmod -m user1 -n webteam
+....
-Viewing [.filename]#/root/.bin_cksum_mtree# should yield output similar to the following:
+Finally, this line in [.filename]#/usr/local/etc/sudoers# allows any member of the webteam group to manage _webservice_:
[.programlisting]
....
-# user: root
-# machine: dreadnaught
-# tree: /bin
-# date: Mon Feb 3 10:19:53 2014
+%webteam ALL=(ALL) /usr/sbin/service webservice *
+....
-# .
-/set type=file uid=0 gid=0 mode=0555 nlink=1 flags=none
-. type=dir mode=0755 nlink=2 size=1024 \
- time=1380277977.000000000
- \133 nlink=2 size=11704 time=1380277977.000000000 \
- cksum=484492447 \
- sha256digest=6207490fbdb5ed1904441fbfa941279055c3e24d3a4049aeb45094596400662a
- cat size=12096 time=1380277975.000000000 cksum=3909216944 \
- sha256digest=65ea347b9418760b247ab10244f47a7ca2a569c9836d77f074e7a306900c1e69
- chflags size=8168 time=1380277975.000000000 cksum=3949425175 \
- sha256digest=c99eb6fc1c92cac335c08be004a0a5b4c24a0c0ef3712017b12c89a978b2dac3
- chio size=18520 time=1380277975.000000000 cksum=2208263309 \
- sha256digest=ddf7c8cb92a58750a675328345560d8cc7fe14fb3ccd3690c34954cbe69fc964
- chmod size=8640 time=1380277975.000000000 cksum=2214429708 \
- sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7
-....
-
-The machine's hostname, the date and time the specification was created, and the name of the user who created the specification are included in this report.
-There is a checksum, size, time, and SHA256 digest for each binary in the directory.
+Unlike man:su[1], man:sudo[8] only requires the end user password.
+This avoids sharing passwords, which is a poor practice.
-To verify that the binary signatures have not changed, compare the current contents of the directory to the previously generated specification, and save the results to a file.
-This command requires the seed that was used to generate the original specification:
+Users permitted to run applications with man:sudo[8] only enter their own passwords.
+This is more secure and gives better control than man:su[1],
+where the `root` password is entered and the user acquires all `root` permissions.
-[source,shell]
+[TIP]
+====
+Most organizations are moving or have moved toward a two factor authentication model.
+In these cases, the user may not have a password to enter.
+
+man:sudo[8] can be configured to permit two factor authentication model by using the `NOPASSWD` variable.
+Adding it to the configuration above will allow all members of the _webteam_ group to manage the service without the password requirement:
+
+[.programlisting]
....
-# mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output
-# mtree: /bin checksum: 3427012225
+%webteam ALL=(ALL) NOPASSWD: /usr/sbin/service webservice *
....
+====
-This should produce the same checksum for [.filename]#/bin# that was produced when the specification was created.
-If no changes have occurred to the binaries in this directory, the [.filename]#/root/.bin_chksum_output# output file will be empty.
-To simulate a change, change the date on [.filename]#/bin/cat# using `touch` and run the verification command again:
+[[security-doas]]
+=== Shared Administration with Doas
+
+man:doas[1] is a command-line utility ported from OpenBSD.
+It serves as an alternative to the widely used man:sudo[8] command in Unix-like systems.
+
+With doas, users can execute commands with elevated privileges, typically as the root user, while maintaining a simplified and security-conscious approach.
+Unlike man:sudo[8], doas emphasizes simplicity and minimalism, focusing on streamlined privilege delegation without an overwhelming array of configuration options.
+
+Execute the following command to install it:
[source,shell]
....
-# touch /bin/cat
-# mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output
-# more /root/.bin_chksum_output
-cat changed
- modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014
+# pkg install doas
....
-It is recommended to create specifications for the directories which contain binaries and configuration files, as well as any directories containing sensitive data.
-Typically, specifications are created for [.filename]#/bin#, [.filename]#/sbin#, [.filename]#/usr/bin#, [.filename]#/usr/sbin#, [.filename]#/usr/local/bin#, [.filename]#/etc#, and [.filename]#/usr/local/etc#.
-
-More advanced IDS systems exist, such as package:security/aide[].
-In most cases, `mtree` provides the functionality administrators need.
-It is important to keep the seed value and the checksum output hidden from malicious users.
-More information about `mtree` can be found in man:mtree[8].
+After the installation [.filename]#/usr/local/etc/doas.conf# must be configured to grant access for users for specific commands, or roles.
-[[security-tuning]]
-=== System Tuning for Security
+The simpliest entry could be the following, which grants the user `local_user` with `root` permissions without asking for its password when executing the doas command.
-In FreeBSD, many system features can be tuned using `sysctl`.
-A few of the security features which can be tuned to prevent Denial of Service (DoS) attacks will be covered in this section.
-More information about using `sysctl`, including how to temporarily change values and how to make the changes permanent after testing, can be found in crossref:config[configtuning-sysctl,“Tuning with sysctl(8)”].
+[.programlisting]
+....
+permit nopass local_user as root
+....
-[NOTE]
-====
-Any time a setting is changed with `sysctl`, the chance to cause undesired harm is increased, affecting the availability of the system.
-All changes should be monitored and, if possible, tried on a testing system before being used on a production system.
-====
+After the installation and configuration of the `doas` utility, a command can now be executed with enhanced privileges, for example:
-By default, the FreeBSD kernel boots with a security level of `-1`.
-This is called "insecure mode" because immutable file flags may be turned off and all devices may be read from or written to.
-The security level will remain at `-1` unless it is altered through `sysctl` or by a setting in the startup scripts.
-The security level may be increased during system startup by setting `kern_securelevel_enable` to `YES` in [.filename]#/etc/rc.conf#, and the value of `kern_securelevel` to the desired security level.
-See man:security[7] and man:init[8] for more information on these settings and the available security levels.
+[source,shell]
+....
+$ doas vi /etc/rc.conf
+....
-[WARNING]
-====
-Increasing the `securelevel` can break Xorg and cause other issues.
-Be prepared to do some debugging.
-====
+For more configuration examples, please read man:doas.conf[5].
-The `net.inet.tcp.blackhole` and `net.inet.udp.blackhole` settings can be used to drop incoming SYN packets on closed ports without sending a return RST response.
-The default behavior is to return an RST to show a port is closed.
-Changing the default provides some level of protection against ports scans, which are used to determine which applications are running on a system.
-Set `net.inet.tcp.blackhole` to `2` and `net.inet.udp.blackhole` to `1`.
-Refer to man:blackhole[4] for more information about these settings.
+[[security-ids]]
+== Intrusion Detection System (IDS)
-The `net.inet.icmp.drop_redirect` and `net.inet.ip.redirect` settings help prevent against _redirect attacks_.
-A redirect attack is a type of DoS which sends mass numbers of ICMP type 5 packets.
-Since these packets are not required, set `net.inet.icmp.drop_redirect` to `1` and set `net.inet.ip.redirect` to `0`.
+Verification of system files and binaries is important because it provides the system administration and security teams information about system changes.
+A software application that monitors the system for changes is called an Intrusion Detection System (IDS).
-Source routing is a method for detecting and accessing non-routable addresses on the internal network.
-This should be disabled as non-routable addresses are normally not routable on purpose.
-To disable this feature, set `net.inet.ip.sourceroute` and `net.inet.ip.accept_sourceroute` to `0`.
+FreeBSD provides native support for a basic IDS system called man:mtree[8].
+While the nightly security emails will notify an administrator of changes, the information is stored locally and there is a chance that a malicious user could modify this information in order to hide their changes to the system.
+As such, it is recommended to create a separate set of binary signatures and store them on a read-only, root-owned directory or, preferably, on a removable USB disk or remote server.
-When a machine on the network needs to send messages to all hosts on a subnet, an ICMP echo request message is sent to the broadcast address.
-However, there is no reason for an external host to perform such an action.
-To reject all external broadcast requests, set `net.inet.icmp.bmcastecho` to `0`.
+It is also recommended to run `freebsd-update IDS` after each update.
-Some additional settings are documented in man:security[7].
+[[security-ids-generate-spec-file]]
+=== Generating the Specification File
-[[tcpwrappers]]
-== TCP Wrapper
+The built-in man:mtree[8] utility can be used to generate a specification of the contents of a directory.
+A seed, or a numeric constant, is used to generate the specification and is required to check that the specification has not changed.
+This makes it possible to determine if a file or binary has been modified.
+Since the seed value is unknown by an attacker, faking or checking the checksum values of files will be difficult to impossible.
-TCP Wrapper is a host-based access control system which extends the abilities of crossref:network-servers[network-inetd,“The inetd Super-Server”].
-It can be configured to provide logging support, return messages, and connection restrictions for the server daemons under the control of inetd.
-Refer to man:tcpd[8] for more information about TCP Wrapper and its features.
+[TIP]
+====
+It is recommended to create specifications for the directories which contain binaries and configuration files, as well as any directories containing sensitive data.
+Typically, specifications are created for [.filename]#/bin#, [.filename]#/sbin#, [.filename]#/usr/bin#, [.filename]#/usr/sbin#, [.filename]#/usr/local/bin#, [.filename]#/etc#, and [.filename]#/usr/local/etc#.
+====
-TCP Wrapper should not be considered a replacement for a properly configured firewall.
-Instead, TCP Wrapper should be used in conjunction with a firewall and other security enhancements in order to provide another layer of protection in the implementation of a security policy.
+The following example generates a set of `sha512` hashes, one for each system binary in [.filename]#/bin#, and saves those values to a hidden file in user's home directory, [.filename]#/home/user/.bin_chksum_mtree#:
-=== Initial Configuration
+[source,shell]
+....
+# mtree -s 123456789 -c -K cksum,sha512 -p /bin > /home/user/.bin_chksum_mtree
+....
-To enable TCP Wrapper in FreeBSD, add the following lines to [.filename]#/etc/rc.conf#:
+The output should be similar to the following:
[.programlisting]
....
-inetd_enable="YES"
-inetd_flags="-Ww"
+mtree: /bin checksum: 3427012225
....
-Then, properly configure [.filename]#/etc/hosts.allow#.
-
-[NOTE]
+[WARNING]
====
-Unlike other implementations of TCP Wrapper, the use of [.filename]#hosts.deny# is deprecated in FreeBSD.
-All configuration options should be placed in [.filename]#/etc/hosts.allow#.
+The `123456789` value represents the seed, and should be chosen randomly.
+This value should be remembered, *but not shared*.
+
+It is important to keep the seed value and the checksum output hidden from malicious users.
====
-In the simplest configuration, daemon connection policies are set to either permit or block, depending on the options in [.filename]#/etc/hosts.allow#.
-The default configuration in FreeBSD is to allow all connections to the daemons started with inetd.
+[[security-ids-spec-file-structure]]
+=== The Specification File Structure
-Basic configuration usually takes the form of `daemon : address : action`, where `daemon` is the daemon which inetd started, `address` is a valid hostname, IP address, or an IPv6 address enclosed in brackets ([ ]), and `action` is either `allow` or `deny`.
*** 2961 LINES SKIPPED ***