This is a very simple and easy to follow guide on securely administer your FreeBSD server. That said I am not a security expert although I’ve gained some knowledge as time goes by. Not pretending to be the definitive guide this article is an introduction on how to secure FreeBSD in which I will tackle some simple but fundamental aspects. Security is a complex issue but it also depends on your needs and usually on the trade off’s between usability, simplicity, security and manageability.
In this guide we will cover the minimal basics which in turn can be very deep and insightful topics on their own right. I will talk about user behaviour, network, operating system and applications running on top.
If you find the articles in Adminbyaccident.com useful to you, please consider making a donation.
Use this link to get $200 credit at DigitalOcean and support Adminbyaccident.com costs.
Get $100 credit for free at Vultr using this link and support Adminbyaccident.com costs.
Mind Vultr supports FreeBSD on their VPS offer.
User behaviour.
A user can be considered someone interacting with your server in some way. You are, as an administrator, a user too. Let’s imagine a common scenario nowadays for your server. A web server. Or your cluster of servers since you are operating a very successful website in needs of an horizontal and vertical approach too. Your visitors, users, anyone in the need to interact with your server can potentially have some kind of malware on their device which will surely try to mess with your service. That is something you will have to worry about but this falls, in my view, on the application layer. You have an obligation, as a user, and as administrator as well, to have a sane behaviour.
What kind of behaviour? Well, simple things that will head your attitude, your decisions, your approach to security, to sanity and good manners. A common problem we are facing today is the number of passwords and pins we have to remember in our daily life. A password manager is a useful tool since people is reusing passwords all the time and that is very unsecure. Second factor authentication came in help to solve this issue. As the security researcher and technical officer at Telefónica, Chema Alonso, points out at every given opportunity, a robust security system must comply with three different requirements. It must be composed by one thing you know, such as a password. It must be something you have, such as a token or a device such as a smart phone or smart card, objects you may easily carry on with you. And thirdly something you are, something from your anatomy you can work with, so you can think of face recognition systems or finger prints.
Is all of that really necessary to secure your FreeBSD server or any other server you may be using? Well, it depends on your needs, the regulations you have to comply with and the usability and complexity of the measures you need to implement to achieve that goal. Is second factor authentication really necessary to log in to your server? That is a question you have to answer yourself. Is that a corporate web service where you can get all the data from your customers? My answer would be you’d better have that measure in place if not a third factor as well. However if you just happen to have a website or a blog where you write your thoughts and ideas it may not be necessary for you.
At least you should think on how you use the services you depend on and the way you connect to your servers. Using any service that is not using TLS to encrypt your username and password when you log in to, let’s say your email, should be avoided. Passwords you received by email should be changed immediately. And of course you must type different passwords with enough strength to be as random characters as possible at the same time you remember them. Given the number of passwords one has to produce and remember, a password manager is not only mandatory but even more necessary. This kind of utility allows you to have one long difficult to guess password to access all the other passwords you may have stored and it also encrypts them. Without the main key you can’t access the rest of the keys. If you combine that with a second factor this way of storing passwords becomes much more strong.
A second measure is completely removing the use of passwords when you login to your system through, let’s say ssh. Instead of using them you must use ssh keys. As I explain in this article ssh keys are simple to use and they give you the strength you may need to keep your FreeBSD system secure when you log in. Needless to say avoiding root logins is a must, however this is the default behaviour in FreeBSD. So if you are a Linux user it is quite easy that is not the case and you can remotely access your system using the root account. Don’t panic since you can easily modify this.
Enabling a second factor authentication for your logins is interesting too in order to secure FreeBSD. You can get some general insights of this by reading this article about PAM or pluggable authentication modules in FreeBSD. However if you want to get into enabling this capability in your system you can read several online guides on Google’s Authenticator. You can enable TFA (two factor authentication) using Yubikeys as well. This option is interesting for those who want more security since your smartphone can be compromised or you may lose it or even worst, be stolen.
For a multi user environment where dozens of users log in your servers to operate things or interact with, you can also set a policy on password. This policy may include password expiration, rotation, complexity and its enforcement. Cracklib can be an interesting tool just for this.
All in all this chapter can be summarized as: use a password manager for your accounts, use SSH keys to login in your systems and enable two factor authentication if you need more security (aka you are not the only one login there and many users are). Plus enable that two factor authentication around your services since if any part of your work tools is compromised, the whole environment is not one hundred per cent trustful.
Network.
At the network level security can be very complex. Since this is only an introductory guide on how to secure FreeBSD server and I am not an expert whatsoever, take what you read here with a grain of salt.
One of the firsts tasks I do when I set up a new box is enabling the firewall. As I explain on this simple article the firewall usually comes down (disabled) on every operating system since nowadays almost every time we connect to the internet a firewall is sitting between us and the rest of the world. Phone carriers and ISP’s are usually the ones providing these devices and if the company you are dealing with has some sense of security these devices are correctly configured for “home” use. FreeBSD is no exception and after the install you have to enable the firewall but with this OS you can choose from three options. IPFW, PF and IPFilter. Which one is the best for you will take some time, reading, testing and overall getting knowledge on how a network works, the services you need to run and your personal view will influence on that decision too.
Before you enable the firewall make sure you are able to log in the system, be it because you are sitting in front of it and you can interact with the system with a keyboard, be it because you have set some simple rules so can you log in through port 22 using openSSH for example. If you want to set up a simple firewall and the services you need to run are SSH connections, HTTP/HTTPS connections for your web server you can follow this article I wrote some time ago.
The basic idea here is simple. Unwanted traffic must stay out of your server. The firewall is a great tool that comes handy for that to happen. But there are more tools that complement the use of a firewall. Fail2ban is a useful tool that works great in tandem with your firewall. You can set a policy that will ban ip’s after a previously defined failed login attempts for the period of time you decide. That said you can use another tool instead of Fail2ban such as SSHGuard. Both tools work against port knockers which are always trying to find open ports and trying connections. Sometimes attackers do also perform dictionary attacks where they read passwords stored on files (from previous breaches) using tools as hydra but also using botnets.
There is a third option you can use. If you happen to have a successful in popularity web server you may also need an external service in order to avoid unwanted connections. DDOS atacks are a real thing and with the advent of IoT devices the world will get a bit noisier in this sense. VPN service providers are one option if you happen to travel around and you need to connect to your servers from places you do not have any control over the network, although you can set your own.
Operating system.
Another simple yet effective measure to secure your FreeBSD server. You can use sudo when you login to your system with a regular user in case you need root privileges for certain tasks. For a minimal installation you can check this guide of mine but you can get more information on the internet. But if you want to dig deep on this topic there is an excellent book written by Michael W. Lucas called “Sudo Mastery”. That said, the OpenBSD guys (the paranoid security guys on BSD camp) have simplified the idea of sudo and built a new one called doas. Choose your poison.
Scanning for viruses and rootkits is another measure to apply to secure your FreeBSD server. A very common virus scanner in the open source world is the Clamav antivirus. There is an extension to use it on your email server as well so this is a very good tool for you. In this article I explain the very basics of it. As for rootkits there is one interesting tool among others called rkhunter. However rkhunter does not only scan for rootkits but checks several other things as well such as: hidden malicious files, compares hashes, looks for wrong file permissions for binaries and looks for suspicious strings in the kernel. Ain’t it great?
In hand now and as a complementary tool comes in an intrusion detections system. There are many out there but two known ones are OSSEC and Tripwire. Broadly speaking both systems keep track of critical files of the system and the applications to take care of. If any changes are applied or new files appear the system will warn the administrators or users for that specific. In one sentence these systems maintain and guard the integrity of the system. However one of the differences is OSSEC does log analysis while the free open source implementation of Tripwire does not. This said OSSEC is mainly thought to operate in Linux environments and some defaults have to be changed since the paths in FreeBSD are a bit different because it roots from the old UNIX’s unlike the GNU/Linux ones.
Last but not least operating system maintenance is a very basic but necessary and mandatory task for any system administrator. To secure FreeBSD regular updates are a must. Mind this operating system allows you to play with updates in ways other mainstream OS’s don’t. Because of ZFS and beadm any FreeBSD administrator can update the system without fear of losing any data if the update breaks or works unexpectedly. Boot environments sit on top of ZFS and beadm helps you in managing that. You can read more about this feature by reading this article I wrote.
Applications.
The scope here is immense, huge, vast, take your word for “bigger than big”. My particular use case is WordPress but many of the things will apply on any CMS around, be it Drupal, be it Magnolia.
First things first. Log in. Yet again. The same way you had to be cautious with the way you connected to your server, the same principles apply when you do it with your application. However things might change. Using TLS connections as default is something you have to manually set on WordPress. And again, if you happen to administer a big website with a decent amount of traffic and users, two factor authentication is mandatory as well. This can be achieved by using some extensions such as Google Authenticator (previously seen, although the link here is specific to WordPress) and Wordfence plugin in case you use WordPress.
Plus you may apply some sane settings on your application installs such as user names not being obvious or public. Mind a user and a password is a combination that unlocks access. If your user name to any application is your name, people already have fifty per cent of the information required to access.
For WordPress and many other CMS’s there exists a plethora of plugins and addons to install and enforce security. For example Wordfence and BulletProofSecurity are two plugins that perform and provide a noticeable security improvement on any WordPress install. For example BPS writes rules to your .htaccess file (provided you use the Apache web server) in order to harden the access to the files in your application as it were a firewall. It scans for malware and logs failed logins in a way that it even creates white and black lists. Wordfence does also implement these features but it also provides some functionality similar to OSSEC or Tripwire by keeping track to the specific WordPress core files. If any unidentified or unwanted files appear of changes are made on critical files for the application Wordfence can block them but if it’s not able to it warns the administrator of a possible intrusion.
And the final and for some the definitive tool to secure FreeBSD, provided this is a web server. Modsecurity. It basically a web application firewall. It initially started as a module loadable for the Apache web server but you can nowadays install it on NGINX, Microsoft IIS or standalone. It basically scans your http and https connections and apply rules for them. Those rules are constantly improved and published so it’s a good idea you to maintain track of them and update your mod_security install. The Core Rule Set protects your application from SQL injection, cross site scripting, local file inclusion, php code injection, http protocol violations and much more.
In conclusion security is not an easy thing nor a unique receipt that works for everybody on every situation. The variables to have in mind are endless and use cases are so different there is no true hardcore guide. That said I hope this article gives you a minimal insight on the topic and helps you to secure FreeBSD.
If you find the articles in Adminbyaccident.com useful to you, please consider making a donation.
Use this link to get $200 credit at DigitalOcean and support Adminbyaccident.com costs.
Get $100 credit for free at Vultr using this link and support Adminbyaccident.com costs.
Mind Vultr supports FreeBSD on their VPS offer.