######################################################################### # FreeBSD - a lesson in poor defaults # # Published on 03/18/2016 # # Last updated 06/27/2018 # # https://twitter.com/blakkheim # ######################################################################### 00) Intro 01) OpenSSH Modifications 02) Mailer Daemon 03) Firewall 04) Ports and Packages 05) NTP 06) sysctl.conf 07) Periodic 08) SSL Library 09) Swap 10) Permissions 11) rc.conf 12) Closing 13) Addendum ######################################################################### # Intro # ######################################################################### This page is intended to list the major changes I used to make to a vanilla install of FreeBSD. Some are preferences, but the majority are for security. It only covers some basic high level changes that a sysadmin can easily make to a running system. It does not go in depth about FreeBSD's more serious low-level problems that require code changes. It could also be considered a commentary piece on the state of security in FreeBSD's development ecosystem, highlighting their strong resistance to change and unwillingness to replace old cruft with modern alternatives. Most of that is in the closing section towards the end. Their security page (https://www.freebsd.org/security/security.html) says the following: "FreeBSD takes security very seriously and its developers are constantly working on making the operating system as secure as possible." But is that really true? Let's find out. ######################################################################### # OpenSSH Modifications # ######################################################################### FreeBSD has a history of making "interesting" choices with regard to the version of OpenSSH they bundle in the base system, often deliberately going against upstream in the name of retaining backward compatibility or to gain perceived performance improvements. Disabling or ignoring security features in favor of performance seems to be a recurring theme with them. It is my belief that quite a few poor decisions have been made in this area. As a primary example, they insisted on maintaining the HPN-SSH patchset and enabling it by default for quite a long time. You might say "well ok, but what's actually *wrong* with those patches?" A few years ago, OpenSSH increased the channel limits enough to support a cross-country gigabit connection without slowdown. For most users, this means that the HPN patches are an unnecessary complexity with little to no benefit. In addition to that, they would frequently hold FreeBSD back from updating their version of OpenSSH because of HPN backporting and manual refactoring of the patchset. Support for tcp_wrappers was abandoned long ago in OpenSSH upstream, but FreeBSD still patched it back in and enabled it for everyone. https://svnweb.freebsd.org/base?view=revision&revision=294328 The same was true for weak DSA host keys, which they switched back on for compatibility with older clients. https://svnweb.freebsd.org/base?view=revision&revision=294495 FreeBSD also re-enabled insecure encryption ciphers in their build after they've been disabled upstream, with backward compatibility apparently being more important to them than the security of their users. https://svnweb.freebsd.org/base?view=revision&revision=296634 If we don't deprecate insecure options bit by bit somewhere in the ecosystem, we end up with a situation like OpenSSL. Pressure has to be applied somewhere. One can be part of that team, or one can play against them. FreeBSD is the team trying to increase the risk. They've made local changes to their ssh build and its default config files that left their users vulnerable when other platforms were unaffected. Here's a (possibly incomplete) list of examples: https://www.freebsd.org/security/advisories/FreeBSD-SA-00:21.ssh.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-03:15.openssh.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-06:09.openssh.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-08:05.openssh.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-14:24.sshd.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-16:14.openssh.asc And the PAM issues in these two: https://www.freebsd.org/security/advisories/FreeBSD-SA-15:16.openssh.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-15:22.openssh.asc A list of FreeBSD's modifications to both the code and config files can be seen here: (for the base system, has some outdated info) https://svnweb.freebsd.org/base/head/crypto/openssh/FREEBSD-upgrade?view=markup#l93 (for ports) https://svnweb.freebsd.org/ports/head/security/openssh-portable/files Thankfully, as hinted above, it's fairly easy to install OpenSSH from ports with all the FreeBSDisms removed. The "security/openssh-portable" port has a convenient set of options you can toggle. As of the time I'm writing this, the current list is as follows: ############################################################################### [ ] BSM OpenBSM Auditing [X] HPN HPN-SSH patch [ ] KERB_GSSAPI Kerberos/GSSAPI patch (req: GSSAPI) [X] LDNS SSHFP/LDNS support [X] LIBEDIT Command line editing via libedit [ ] NONECIPHER NONE Cipher support [ ] OVERWRITE_BASE EOL, No longer supported [X] PAM Pluggable authentication module support [ ] SCTP SCTP support [X] TCP_WRAPPERS tcp_wrappers support [ ] X509 x509 certificate patch ( ) MIT MIT Kerberos (security/krb5) ( ) HEIMDAL Heimdal Kerberos (security/heimdal) ( ) HEIMDAL_BASE Heimdal Kerberos (base) ############################################################################### An [X] means it's on by default for users of the project's binary pkg repo and ports/poudriere users that don't explicitly change their build options. More on all of those later. Besides the modifications mentioned above, two other patches in particular have been popular with FreeBSD users: - Threaded AES-CTR (an option in the port until semi-recently) - The NONE cipher (still an option in the port) Threaded AES-CTR, as the name might imply, introduces threads to the code. OpenSSH devs have publicly said threads are too risky and won't be added. What's more, it's largely obsoleted by AES-NI in modern CPUs and the fact that ChaCha20-Poly1305 (the current default cipher) is even faster when taking the Message Authentication Code into consideration. The NONE cipher is somewhat of a misfeature, removing the encryption bits and only keeping the data integrity. It allows users to accidentally shoot themselves in the foot pretty easily. The trade-off in performance isn't really worth it either, as the bottlenecks one might experience have a lot more to do with the MAC than the actual encryption. I have all of the port options disabled. The majority of users don't need the extra risk that any of these non-standard patches introduce. As for the (/usr/local/etc/ssh/)sshd_config file, I would recommend enabling only modern crypto. However, cryptography is a very complicated and important topic, so you would be better served to research each algorithm and come to your own conclusions instead of just taking my word for it. This isn't meant to be an entire ssh tutorial, but consider changing your default port to something other than 22 if you want less spam in your logs, set up public keys and disable password authentication... the usual stuff. The following config lines are just to revert FreeBSD's local changes that introduce new risks: ############################################################################### ChallengeResponseAuthentication no UsePAM no VersionAddendum none # Prevent some OS information from being # leaked by your sshd, another one of # FreeBSD's "enhancements" in both the # base system and ports version. X11Forwarding no ############################################################################### In addition to improved security, using the port of OpenSSH allows you to upgrade to newer versions much faster than waiting for a new release of the base system. Note that you may need further configuration changes if using the bundled OpenSSH, as its compile-time options aren't as easily fixable. ######################################################################### # Mailer Daemon # ######################################################################### FreeBSD includes Sendmail in the base system and enables it by default. https://security.freebsd.org/advisories/FreeBSD-SA-14:11.sendmail.asc https://security.freebsd.org/advisories/FreeBSD-SA-06:17.sendmail.asc https://security.freebsd.org/advisories/FreeBSD-SA-06:13.sendmail.asc https://security.freebsd.org/advisories/FreeBSD-SA-03:13.sendmail.asc https://security.freebsd.org/advisories/FreeBSD-SA-03:11.sendmail.asc https://security.freebsd.org/advisories/FreeBSD-SA-03:07.sendmail.asc https://security.freebsd.org/advisories/FreeBSD-SA-03:04.sendmail.asc https://security.freebsd.org/advisories/FreeBSD-SA-01:57.sendmail.asc I think most users will agree that Sendmail is mostly just a bother, and it shouldn't be in the base system at all if you ask me. I stop all the related services because it makes startup slower and I'd like as few things running in the background as possible. The lines to disable Sendmail will be in the rc.conf section towards the end. If you actually run a mail server, there are better options like Postfix or OpenSMTPD. If you only need to send mail through a third party provider like Gmail, ssmtp is a another lightweight alternative. All three are in ports. ######################################################################### # Firewall # ######################################################################### There are three firewalls included with FreeBSD: IPFW, PF, and IPFilter. None of them are enabled by default, but I guess it'd be hard to decide which one to choose, so that's understandable. I don't know anything about IPFilter, nor do I know anyone that uses it, so we'll pretend it doesn't exist. IPFW is the native firewall. It was written by FreeBSD for FreeBSD. PF is the OpenBSD firewall. It was ported from OpenBSD to FreeBSD. Both are fine choices, and it ultimately comes down to your preference between the two. Since I'm more familiar with PF, that's what I use. Unfortunately, the version of PF included with FreeBSD hasn't been synced with upstream since 2009. Do you want such a critical component of your OS (or network device) left largely unmaintained? I don't... A very simple example of a PF config file might look like this: ############################################################################### ext_if = "em0" # Replace with your interface name. trustedip = "1.2.3.4" # Replace with your IP. Could also be a list/table. set block-policy drop # Some may prefer "return" instead. set skip on lo0 scrub in all no-df random-id block all pass out quick on $ext_if inet pass in on $ext_if inet proto tcp from $trustedip to any port ssh ############################################################################### Check the documentation for whichever firewall you decide to use. ######################################################################### # Ports and Package # ######################################################################### There are three main ways to install software on FreeBSD, other than just manually compiling things yourself: - The "pkg" tool with binary packages built by the project infrastructure - The ports system, allowing for custom options in most applications - The "poudriere" tool for building binary packages from ports in bulk There are pros and cons to each. pkg pros: - Fast installation - Little effort required pkg cons: - Little or no flexibility with regard to which options are enabled or disabled - Must wait on the project to rebuild/update things - Security updates often left out due to carelessness of committers (This is mainly true of the "quarterly" branch, which is the default setting) ports pros: - Very good customization options - Control dependencies, only install what you need - Updates are available as soon as they're committed to svn - Only rebuild what actually needs to be updated ports cons: - It can take a long time to compile things, especially web browsers - Multiple unrelated tools involved (portsnap/svn, portmaster/portupgrade, etc) poudriere pros: - Build packages on one system, distribute them to many others - Still retains most of the pros of using ports - Little effort required, easily scriptable poudriere cons: - It still takes a long time to compile things - Things will get pointlessly rebuilt over and over, wasting a lot of time - French words are hard to spell If you only have one FreeBSD system, I think using ports is the best option. If you have multiple systems, poudriere makes the whole process a lot easier. If you're a total beginner or don't care what options things are built with, using pkg and the prebuilt binaries is the quickest and easiest option. However, more security concerns arise... Both the ports system and pkg will do a lot of things as root where it's not needed at all. I brought this up to a member of the ports security team and he just shrugged it off. Simply because portsnap checks the snapshots it fetches against a public key, he figured there was nothing to worry about. I have to question their credibility sometimes. It's true that verifying the files it fetches would indeed be a good countermeasure, if that was done before the more dangerous operations... but it wasn't. The data integrity check was done very late in the process, giving plenty of opportunity for exploits against the other tools, all running as root and taking untrusted input from the internet. Both portsnap and freebsd-update have a serious design flaw here that could be easily fixed. Perhaps they have the utmost confidence in the tools being bug-free. I try to be a bit more realistic, and it turns out I was right on the mark. https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f Similar issues were brought up on their mailing lists, though nothing ever came of that discussion either. https://lists.freebsd.org/pipermail/freebsd-questions/2014-April/257394.html https://lists.freebsd.org/pipermail/freebsd-security/2016-July/009016.html These bugs and poor design choices have left FreeBSD users vulnerable to root-level compromise every time they update their system or ports tree. Think about that for a second. Terrible, right? Despite the issues being brought up on their lists in April 2014, despite public exploits being published in May 2016, and despite multiple big news sites picking up the story, they were all left unfixed until October 2016. The FreeBSD security team left all users vulnerable to these exploits for a very long time. This goes well beyond just insecure default settings. But back to ports and pkg, where similar design flaws will probably never be fixed. There's more risk involved than just letting root go out to the internet to download files. Here's a summary of what happens in the process of building ports. - Fetch and update the ports tree (a collection of makefiles and patches) - Fetch the software's source code - Verify the checksum of the file(s) - Extract the source tarball - Run the configure script, apply local patches, and build the application - Create a package from the built files - Install the package to your system (if desired) So how many of these actually need to be done as root? Only the last one. And how many of these are done as root by default in FreeBSD? All of them! ############################################################################### PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 84266 root 1 52 0 36272K 8056K wait 0 0:00 0.68% cc 84191 root 1 52 0 9116K 1332K wait 0 0:00 0.29% make 84267 root 1 47 0 36416K 20484K zio->i 1 0:00 0.00% cc ############################################################################### Maybe people don't realize the risk of actually building all these third party tools with root privileges. Have you read every line of those 25,000+ configure scripts? I've seen some configure scripts running ping to phone home and all kinds of weird stuff. All it takes is one malicious command tucked away in a build script somewhere to completely compromise the host if you use ports in its default configuration. Surprisingly, FreeBSD does have *some* support for doing package builds as a normal user. https://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086346.html Though I'm told staging is integrated into all their ports now, the default is still to do everything as root. Why? To work around this issue, I tried manually introducing some privsep in the build process on my machine with a "_ports" user. You'd need to chown a few directories or make them writable by this user. Many changes were needed in the /etc/make.conf file, and it appears that it's really just not designed to be done this way, so I'd call it more of an experiment than a solution. Why is all this needed? It's like things were designed to be as troublesome to secure as possible so no one ever tries it. Hey, works as intended if so. The poudriere tool uses FreeBSD's jail system for some filesystem isolation during the process, so it's a little safer than using ports in this regard. However, the distfiles are still fetched as root, the portsnap/svn commands are run as root, etc. That's on the host system, by the way, not jailed. All these tasks are trivial to isolate with different users, but poudriere doesn't do that. The only operation that poudriere does as an unprivileged user is the compiling, and that change took years of pressure to make. The pkg tool itself also runs everything as root, from fetching and verifying the packages to untarring them and registering their installation. ############################################################################### PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 84554 root 1 22 0 42996K 7452K select 1 0:00 0.59% pkg ############################################################################### Just for comparison, let's look at the history of Debian's pkg equivalent. https://www.cvedetails.com/product/17236/Debian-APT.html The "but packages are signed!" defense I've gotten from some users really demonstrates a lack of understanding of what's actually going on when you run that pkg command. A side note: OpenBSD's dpb tool (similar to poudriere) really got all this privsep stuff right, even going as far as to use separate users to download and build the software, and recommending to disallow the build user from accessing the internet at all. It's cool stuff, especially when combined with pledge to restrict the system calls available to each sub-process. It would be nice to see more use of FreeBSD's Capsicum here, wouldn't it? ######################################################################### # NTP # ######################################################################### A lot of FreeBSD security advisories have been related to the NTP daemon included in the base system, known as the "reference implementation." Here's a (possibly incomplete) list: https://security.freebsd.org/advisories/FreeBSD-SA-01:31.ntpd.asc https://security.freebsd.org/advisories/FreeBSD-SA-09:03.ntpd.asc https://security.freebsd.org/advisories/FreeBSD-SA-09:11.ntpd.asc https://security.freebsd.org/advisories/FreeBSD-SA-10:02.ntpd.asc https://security.freebsd.org/advisories/FreeBSD-SA-14:02.ntpd.asc https://security.freebsd.org/advisories/FreeBSD-SA-14:31.ntp.asc https://security.freebsd.org/advisories/FreeBSD-SA-15:07.ntp.asc https://security.freebsd.org/advisories/FreeBSD-SA-15:25.ntp.asc https://security.freebsd.org/advisories/FreeBSD-SA-16:02.ntp.asc https://security.freebsd.org/advisories/FreeBSD-SA-16:09.ntp.asc https://security.freebsd.org/advisories/FreeBSD-SA-16:16.ntp.asc https://security.freebsd.org/advisories/FreeBSD-SA-16:24.ntp.asc https://security.freebsd.org/advisories/FreeBSD-SA-16:39.ntp.asc https://security.freebsd.org/advisories/FreeBSD-SA-17:03.ntp.asc I would not be surprised if there are currently more embargoed fixes which haven't been made public yet. It's really shitty code, written mainly by time geeks and scientists instead of people who actually run network-facing services. But I want to keep my clock synced to the correct time, so what do I do here? Luckily, there are a number of alternative NTP daemons to choose from. One FreeBSD committer is working on an NTP implementation called ntimed. I'm told that it's still in development, but you can install it from ports if you want an early preview. I haven't tried it myself, but everyone seems to have high hopes for it eventually replacing the one currently in base. Can't be any worse than what FreeBSD ships now, so I'm all for it. Another option, the one I use, is called OpenNTPD. Based on the name, see if you can guess where it originates. A simple /usr/local/etc/ntp.conf may look something like this: ############################################################################### constraints from "https://www.freebsd.org" servers pool.ntp.org ############################################################################### Much like the firewall section, this is up to your personal preference. There are trade-offs for both. OpenNTPD has an excellent security track record and a simple config syntax, but ntimed will likely give you better microsecond precision. Whichever you choose, just don't use the base one. ######################################################################### # sysctl.conf # ######################################################################### The /etc/sysctl.conf file is a great place to tweak lots of things, but my example is mainly to fix poor defaults related to networking and security. The documentation isn't great here, but this is what I came up with. ############################################################################### kern.randompid=1 kern.random.fortuna.minpoolsize=128 net.inet.ip.check_interface=1 net.inet.ip.process_options=0 # Enable if you need IGMP or multicast. net.inet.ip.random_id=1 net.inet.ip.redirect=0 net.inet.tcp.cc.algorithm=cubic # Requires that you run "kldload cc_cubic" and add "cc_cubic_load=YES" to /boot/loader.conf net.inet.icmp.drop_redirect=1 net.inet.tcp.drop_synfin=1 net.inet.sctp.blackhole=2 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 # Note the blackhole options can sometimes # make debugging network issues more difficult. net.inet.tcp.icmp_may_rst=0 security.bsd.hardlink_check_gid=1 # These two options will break poudriere's security.bsd.hardlink_check_uid=1 # compiling privsep. security.bsd.see_other_gids=0 security.bsd.see_other_uids=0 security.bsd.stack_guard_page=1 security.bsd.unprivileged_proc_debug=0 security.bsd.unprivileged_read_msgbuf=0 ############################################################################### The following descriptions were taken from "sysctl -d" output with some minor grammar fixes. - kern.randompid: Random PID modulus (FreeBSD does not randomize process IDs by default) - kern.random.fortuna.minpoolsize: Minimum pool size necessary to cause a reseed - net.inet.icmp.drop_redirect: Ignore ICMP redirects - net.inet.ip.check_interface: Verify packet arrives on correct interface - net.inet.ip.process_options: Enable IP options processing ([LS]SRR, RR, TS) - net.inet.ip.random_id: Assign random ip_id values (FreeBSD does not randomize IP IDs by default) - net.inet.ip.redirect: Enable sending IP redirects - net.inet.sctp.blackhole: Enable SCTP blackholing (Side note: SCTP being enabled in the kernel is another horrible default. Long history of security problems. Highly recommend removing it.) - net.inet.tcp.blackhole: Do not send RST on segments to closed ports - net.inet.tcp.cc.algorithm: Default TCP congestion control algorithm (FreeBSD uses newreno by default, which is severely outdated and often results in poor upload speeds for LFNs.) - net.inet.tcp.drop_synfin: Drop TCP packets with SYN+FIN set - net.inet.tcp.icmp_may_rst: Certain ICMP unreachable messages may abort connections in SYN_SENT - net.inet.udp.blackhole: Do not send port unreachables for refused connects - security.bsd.hardlink_check_gid: Unprivileged processes cannot create hard links to files owned by other groups - security.bsd.hardlink_check_uid: Unprivileged processes cannot create hard links to files owned by other users - security.bsd.see_other_gids: Unprivileged processes may see subjects/objects with different real gid - security.bsd.see_other_uids: Unprivileged processes may see subjects/objects with different real uid - security.bsd.stack_guard_page: Insert stack guard page ahead of the growable segments (Also see: https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash) - security.bsd.unprivileged_proc_debug: Unprivileged processes may use process debugging facilities - security.bsd.unprivileged_read_msgbuf: Unprivileged processes may read the kernel message buffer ######################################################################### # Periodic # ######################################################################### Many useless things, some even potentially a security risk, will be running in the background by default. A lot of them are poorly documented or maybe not documented at all. If you configure your system to send email, expect some extremely long daily reports (with nothing useful in them) to be sent to root's inbox. I don't need my disks being thrashed every night because someone thought it was a good idea to enable every check under the sun. FreeBSD is very similar to Windows in that way. Have a look at the /etc/defaults/periodic.conf file. It shows which scripts from the base system are run by default when periodic is called from cron. In a standard configuration, all periodic scripts can be seen in either /etc/periodic (for base daemons) or /usr/local/etc/periodic (for ports). When you install a port or package, it may also add new periodic scripts and even enable them by default... something to be aware of. For reference, this is the /etc/periodic.conf that I use to disable much of the background activity. ############################################################################### daily_backup_aliases_enable="NO" daily_backup_pkg_enable="NO" daily_backup_pkgdb_enable="NO" daily_clean_preserve_enable="NO" daily_clean_rwho_enable="NO" daily_status_pkg_changes_enable="NO" daily_status_security_chkmounts_enable="NO" daily_status_security_chkportsum_enable="NO" daily_status_security_chksetuid_enable="NO" daily_status_security_enable="NO" daily_status_security_ipfdenied_enable="NO" daily_status_security_ipfwdenied_enable="NO" daily_status_security_neggrpperm_enable="NO" daily_status_security_pfdenied_enable="NO" daily_status_security_pkg_checksum_enable="NO" daily_status_security_pkgaudit_enable="NO" monthly_accounting_enable="NO" monthly_statistics_enable="NO" monthly_statistics_report_devices="NO" monthly_status_security_enable="NO" weekly_locate_enable="NO" weekly_noid_enable="NO" weekly_status_pkg_enable="NO" weekly_status_pkg_enable="NO" weekly_status_security_enable="NO" weekly_whatis_enable="NO" ############################################################################### That list may not be what everyone wants, and that's ok. Since your needs will dictate which scripts you want running, I'll only suggest disabling one in particular... ############################################################################### daily_status_security_pkgaudit_enable="NO" ############################################################################### I most certainly don't want pkg (running as root, remember) going out to the internet every night to fetch a list of vulnerable ports. Who thought this was safe? Being alerted to vulnerabilities in your installed packages is nice, but there's simply no need to be doing this operation as root. The dangerous combination of laziness and poor software design is quite prevalent here. ######################################################################### # SSL Library # ######################################################################### OpenSSL is included with the FreeBSD base system, and there are two main issues with that. First, some supported versions of FreeBSD included an unsupported version of OpenSSL, requiring the security team to backport all the fixes themselves. Second, OpenSSL itself has many problems you've probably heard about, like lack of code review and their unwillingness to remove support for arcane systems that no one has used in many years. You know... maybe OpenSSL and FreeBSD are a perfect fit in that regard. https://security.freebsd.org/advisories/FreeBSD-SA-01:51.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-02:33.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-03:02.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-03:06.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-03:18.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-04:05.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-05:21.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-06:19.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-06:23.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-07:08.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-09:02.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-09:08.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-09:15.ssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-10:10.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-12:01.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-13:03.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-14:03.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-14:06.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-14:09.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-14:10.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-14:14.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-14:18.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-14:23.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-15:01.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-15:06.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-15:10.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-15:12.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-15:26.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-16:11.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-16:12.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-16:17.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-16:26.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-16:27.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-16:35.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-17:02.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-17:11.openssl.asc https://security.freebsd.org/advisories/FreeBSD-SA-17:12.openssl.asc Similar to the NTP list, I would expect many more of these to come out. Also note that a lot of these advisories contain multiple vulnerabilities. FreeBSD releases have even been delayed due to OpenSSL-specific security bugs on more than one occasion. https://www.reddit.com/r/BSD/comments/54yntk And what about when FreeBSD leaves your version vulnerable for a month at a time or more? https://lists.freebsd.org/pipermail/freebsd-security/2017-November/009517.html We're dealing with highly insecure software, maintained by a largely-inactive "security team," and it's an obvious recipe for disaster. So how can we make things better? In FreeBSD, your SSL library choices essentially come down to these three: - Use OpenSSL in base, link all your ports against it, wait for it to be updated when security holes are found. This is made even worse by the fact that FreeBSD re-enabled insecure options that upstream disabled. https://svnweb.freebsd.org/base?view=revision&revision=296462 - Use (a newer version of) OpenSSL from ports, but all of the base system utilities will still be linked against the base one. At least you can easily turn off some insecure options this way. - Use an alternative SSL library from ports, but, again, all of the base system utilities will still be linked against the base one. My recommendation here is to use LibreSSL from ports and avoid base system utilities when interfacing with TLS. The relevant /etc/make.conf lines (or poudriere equivalent) to do this are: ############################################################################### DEFAULT_VERSIONS+=ssl=libressl ############################################################################### Switching to LibreSSL will cut down the number of vulnerabilities you have to deal with by a large margin, as well as the average severity of them. A somewhat comprehensive comparison can be seen here: https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities ######################################################################### # Swap # ######################################################################### I think swap should *always* be encrypted. FreeBSD developers disagree. It's surprising just how much private data in memory gets written to disk. Someone I know has run hexdump on his swap partition and found PGP private keys in plain view. Your SSH key might be password-protected on disk, but it could end up in swap sooner or later... with no password needed. Am I the only one who sees a problem here? It's been said that encrypted swap can't be the default in FreeBSD because kernel crash dumps would be unreadable. For the time being, if you need crash dumps written to your swap, don't do this part. For the rest of us, it's actually very simple to do. Here's an example /etc/fstab line for a standard swap partition: ############################################################################### # Device Mountpoint FStype Options Dump Pass# /dev/ada0p3 none swap sw 0 0 ############################################################################### Now here's the same thing with the swap automatically encrypted: ############################################################################### # Device Mountpoint FStype Options Dump Pass# /dev/ada0p3.eli none swap sw 0 0 ############################################################################### All you need to do is add ".eli" to the device name. A one-time key will be generated and destroyed when swap is unmounted, so the swap contents should be unrecoverable. If you had unencrypted swap previously, consider using dd to write random data over it before encrypting. ######################################################################### # Permissions # ######################################################################### Standard unix stuff. Run users with umask 077, chmod 700 home directories, don't let users read the firewall rules or other important config files. This prevents a lot of things from being leaked if a compromised process has read access to the filesystem. I think jails and "container culture" have made a lot of guys really lazy about this kind of thing, but I still do it. Many important files and directories are world-readable by default in FreeBSD. Just have a look around /etc and /root. ######################################################################### # rc.conf # ######################################################################### In addition to the items for what I've gone over already, I don't know why FreeBSD doesn't clear /tmp on startup, but that's expected behavior for me. Finally, if we're not going to be doing any remote logging, I'd prefer that syslogd doesn't open any sockets. These are the relevant lines in my /etc/rc.conf file: ############################################################################### sshd_enable="NO" ntpd_enable="NO" sendmail_enable="NO" sendmail_outbound_enable="NO" sendmail_submit_enable="NO" sendmail_msp_queue_enable="NO" pf_enable="YES" openssh_enable="YES" openntpd_enable="YES" openntpd_flags="-s" clear_tmp_enable="YES" syslogd_flags="-ss" ############################################################################### And now we come to the end. ######################################################################### # Closing # ######################################################################### By sharing this page, I hoped to start a discussion about changing some of the default settings in FreeBSD. I think many were decided on long ago and no one thinks about them anymore. Perhaps more important than that, though, is the mindset of many FreeBSD developers - one that blatantly disregards security in favor of performance and appeasing their enterprise consumers. This must change before anything else can improve. The resistance from the security team to phase out legacy options makes me wonder if they should be called The Backwards Compatibility Team instead. "The FreeBSD Security Officer's mission is to protect the FreeBSD user community by keeping the community informed of bugs, exploits, popular attacks, and other risks; by acting as a liaison on behalf of the FreeBSD Project with external organizations regarding sensitive, non-public security issues; and by promoting the distribution of information needed to safely run FreeBSD systems, such as system administration and programming tips." Taken from https://www.freebsd.org/security/charter.html In my view, the security team of today seems to be doing the exact opposite of a number of those tasks. I'd really like to see some things re-evaluated for the safety of their userbase. Fix the problems; don't ship poor defaults and expect the users to clean them up. That said, FreeBSD's history of security problems goes far beyond just poor default settings in the OS. There's a severe lack of transparency in the security team's disclosure policy too, which leaves their users vulnerable to attack for long periods of time. Many known vulnerabilities are left unpatched in FreeBSD for months on end. https://youtu.be/rRg2vuwF1hY?t=2741 It seems FreeBSD's own developers are realizing how much of a circus it is. https://lists.freebsd.org/pipermail/freebsd-arch/2018-March/018892.html https://lists.freebsd.org/pipermail/freebsd-arch/2018-March/018894.html Even if there are public exploits on news sites and social media, FreeBSD's security team often takes their sweet time fixing them, especially in the -RELEASE branch. Too often do I see security fixes merged into -CURRENT and simply left there. Sometimes you'll get lucky and it will be merged back to -STABLE, but it's increasingly rare for the main -RELEASE branch (the one most users run) to get all of the much-needed patches in a timely manner, if ever at all. That's curious to me, considering how few of their developers actually run the -CURRENT branch. Did a big compiler update leave a lot of ports broken? Yes, sometimes for over three months, but the port maintainers just delete the reports since they don't use it. https://lists.freebsd.org/pipermail/svn-src-stable-11/2018-March/006571.html https://lists.freebsd.org/pipermail/svn-src-stable-11/2018-March/006572.html The extra legwork of maintaining so many supported branches means that none of them ever get the developers' full attention, and you're bound to run into problems in one branch that were fixed (or never happened) in another. On a similar note, it's increasingly common for security-related commits to go in without any mention of security at all. No advisory either. Nothing. This problem is much worse in ports, where a simple "update to version xyz" commit log often hides substantial security fixes... which then don't get merged back to the quarterly branch... which is the default on new installs. Great. But maybe that's less of an issue when the security fixes never get committed in the first place. https://svnweb.freebsd.org/ports?view=revision&revision=470454 FreeBSD lacks any sort of exploit mitigation techniques, even basic ASLR. An experimental patch was posted in early 2016, but the author explains that it will be weak (or "non-aggressive") by default if it ever gets committed. https://www.freebsd.org/news/status/report-2016-04-2016-06.html Other basic protections like W^X and Position-Independent Executables are not planned as far as I can tell. FreeBSD is still stuck in the stone ages here. https://youtu.be/bT_k06Xg-BE?t=133 Network-facing services running on FreeBSD are particularly vulnerable to attack as a result of this. https://lists.freebsd.org/pipermail/freebsd-security/2018-February/009762.html https://lists.freebsd.org/pipermail/freebsd-security/2018-February/009763.html FreeBSD's malloc (jemalloc) is very forgiving of buggy/hostile code compared to something like otto malloc. FreeBSD's net installer fetches the *unsigned* OS files *as root* over *plaintext* protocols like FTP/HTTP. It took FreeBSD four years to switch their arc4random algorithm from RC4 to ChaCha20, even when multiple patches were presented to fix it. https://lists.freebsd.org/pipermail/freebsd-bugs/2013-October/054018.html https://svnweb.freebsd.org/base?view=revision&revision=317015 There's often very little review (or none at all) of the crypto code and security fixes in general. https://lists.freebsd.org/pipermail/freebsd-security/2018-January/009740.html This has even resulted in catastrophic failures like the RNG being broken for months without anyone noticing. https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054580.html Or the time when all high quality entropy sources were accidentally disabled. https://svnweb.freebsd.org/base?view=revision&revision=324394 Or the time when kernel code preventing shell injection was removed without any review or approval of the change. It was sponsored by Netflix though! https://lists.freebsd.org/pipermail/svn-src-head/2018-June/115473.html It seems that anyone with SVN access can commit whatever they want (or, more often, what their parent company wants) without any communication with other FreeBSD developers or any code review. This "commit-then-discuss" culture usually leads to long arguments on the mailing lists and glaring security problems, all of which could be prevented if some review had taken place. https://lists.freebsd.org/pipermail/svn-src-head/2018-June/115271.html https://lists.freebsd.org/pipermail/svn-src-head/2018-April/111838.html Remember that line from the beginning of this page? "FreeBSD takes security very seriously and its developers are constantly working on making the operating system as secure as possible." I think it's safe to say that's a big lie. The FreeBSD Foundation gets over a million dollars in donations every year, so you might be wondering why the project can't get any of this stuff right. Well, it seems they've got other plans for how to use your money... https://lists.freebsd.org/pipermail/freebsd-chat/2018-March/007181.html In conclusion, I can't recommend FreeBSD for any task where security matters. The OS is about as secure as a Linux box from the 1990s, and the developers are more interested in pushing identity politics and keeping corporate donors happy than making a good operating system. Thanks to bsdx, djm, and bdrewery for their technical review and input. ######################################################################### # Addendum # ######################################################################### Five months after this document was published, FreeBSD disabled DSA hostkey and SSHv1 server support in their bundled version of OpenSSH. This was done more than a year after upstream OpenSSH removed them. Five months after this document was published, FreeBSD introduced minimal privilege separation into their pkg tool. Though reverted just one day after being committed, pkg privsep was then revisited two months later and once again reverted in December. If you're keeping track of all the flip-flops, that means it's still going out to the internet as root. Ten months after this document was published, FreeBSD disabled the HPN patchset in their bundled version of OpenSSH. One year after this document was published, FreeBSD enabled some of the sysctl recommendations by default in their development branch's installer. It was reverted just one month later. Due to FreeBSD's release schedule, it wouldn't have reached the majority of their users for quite some time anyway. Users who upgrade between releases (rather than reinstalling) wouldn't have seen those options at all. When it was introduced, multiple developers on the mailing list were in favor of reverting the change. With a development community like that, it's not hard to see why little progress is ever made. Nearly two years after this document was published, FreeBSD disabled the HPN patchset in the ports version of OpenSSH. Removal of HPN from both base and ports appears to be due to build failures rather than security considerations. Nearly two years after this document was published, FreeBSD switched the poudriere tool's default build user from root to an unprivileged one, but left the distfile fetching operation (and others) running as root. Send me your feedback: https://twitter.com/blakkheim