Home arrow Security arrow Secure Your Server
Whitepaper - Secure Your FreeBSD Server PDF
Tuesday, 03 October 2006
If you want to have a good security of your FreeBSD server, follow all of the following steps.

This article is new and will be updated on regular basis. If other articles from Security section are more general, this is desired to be a step by step howto secure your server.

If we are missing something please write us at <info at freebsdonline dot com, with your corrections , we will be happy to add your ideas to this howto.

We asume that you've installed a FreeBSD server, cvsuped to last sources and recompiled the kernel and world (all sources).

Step 1. Secure your SSHd daemon
There are few things that must be done to have to secure your SSH services.

a) First of all you must permit SSH access to your machine only for users you need:
This is done by adding the following line in /etc/ssh/sshd_config: AllowUsers john bob
After that restart your ssh service:

# /etc/rc.d/sshd restart

You could also permit SSH login to wheel group, adding in /etc/ssh/sshd_config the line:
AllowGroups wheel

b) Run your SSH service on other port. By default SSHd is running on port 22, which makes it vulnerable to a lot of automated tools (brute force exploits).
 To acomplish this edit /etc/ssh/sshd_config, and add line 
Port 456 
Be carefull not to add a port that is already used for other service, otherwise won't work. Don't forget to restart the service after you've done modifications to config file but be aware that your shell will be disconnected, if you are doing it remotely and you will have to relogin to machine on the new port (456 for example).

c) Block multiple failed attempts to connect to ssh server. You can accomplish that by using an application available from ports.

d) Update SSH at regular timesFollow the security mailing list, and apply relevant security patches ASAP

e) If you login to your server via SSH only from known IPs, you could allow logins only from those IPs.

 >>disabling password-interactive logins in ssh, allowing only publickeys

f) Always run SSH protocol 2 (which is enabled by default in SSH daemon).

g) Email you every time somebody log in as root. Another idea would be to edit /root/.cshrc file and add a line to email you when somebody log in as root, ading the date and time too.

h) If you offer SSH access to your users, enforce them to use secure passwords.
Passwords must be long, must contain letters and numbers, small and big cases, mixed, and not contain dictionary words. 8 characters usually at least is considered safe for a password, with lower/uppercase mixed latter and with numbers. Also change password at regular times, because old accounts/passwords can be compromised.

>>,  there is some kind of PAM module that verifies the password's strength. you could give >>some info about this, and how to set it up

Step 2. Close services that you do not need
Disable inetd, also close all unneeded processes. Scan your server with nmap (nmap -P0 server_ip) to see
if you have open ports to check if you have running services you are not aware of. Services can be stopped by disable them from /etc/rc.conf, by removing executable of scripts that launch them from /usr/local/etc/rc.d (chmod -x /usr/local/etc/rc.d/script_name.sh), or for some of them by commenting them in file /etc/inetd.conf,
then restarting inetd service, or if is possible removing ined service (by adding to /etc/rc.conf the following line: ined_enable="NO"). 
>>step2 is ain't done from rc.conf, it's done from the packet filter of the choice.

Step 3. Secure your console
a) Secure your console so nobody could boot into single mode and change root password in order to break in.

Edit /etc/ttys, change line
console none                            unknown off secure
console none                            unknown off insecure

>>step3 is not a so good idea. on large systems, there are often no users in the system, just the root>>account and they are protected phyisically

b) Disable reboot of machine using Ctrl+Alt+Del (kernel must be recompiled)
edit your configuration kernel file, add the following option and compile/reinstall the kernel:

Step 4. Scan for open ports
To see if there are any open ports scan your server with a tool like nmap.
( /usr/ports/security/nmap). You will need to have ports open only for your needed services.
Do this process on regular basis.

Step 5. Setup server date and time and log advices
I had to put this in because I've discovered many people forget to proper set date and time on a server and if incidents are reported date and time is crucial, otherwise all logs will have recorded a bad date. Setup a ntp service to syncronize time from a ntp server. Also do not use log rotate if you have a small volume of log files. If you have big size log files, use log rotate but implement log rotating at regular basis (weekly or monthly for example), setup log rotation to not override last logs, backup old logs, and use a Log server.

Step 6. Protect from DOS/DDOS.
Some measures can be taken to add some level of protection to DOS attacks. Total protectin is almost impossible to achieve because when your server is flooded is already too late to do anything. You should contact your ISP. Also if you have multiple sources of attack is very hard to do something.

You will need to tune up some sysctl variable:
kern.ipc.somaxconn=32768    # to defend against SYN attacks

Increasing somaxconn variable SYN attacks to some level will have no effect (or low effect) on the availability of the server.

An attacker can use IP redirects to modify the routing table on your machine.

Step 7. Make a checksum for your files
If your machine will be compromised, it will be useful to check the sum of your files, to see if was not modified. You can install an application like tripwire (/usr/ports/security/tripwire-131) to build a MD5 sum of your every file.

Step 8. Monitor server activities and email you an automated report once a day with security status, using Logwatch Perl Script (http://www2.logwatch.org:81/). 

- don't use ftp services, instead use sftp to copy files

>>or step8 there is also gentoo's tenshi, and nagios, and cacti, and whatever

Step 9. Other security measures

msl = maximum segment life = maximum amount of time to wait for an ACK in reply to SYN-ACK or FIN-ACK, in miliseconds

This variable defines what will happend when your machine receive a TCP packet on a closed port. (1 - SYN packets are dropped, 2 - all packets are dropped).


This variable controls the maximum number of ICMP "Unreachable" and TCP RST to return at every second.

For the following NIC: dc, em, fxp, nge, rl, sis, turn on kernel DEVICE_POLLING option to reduce CPU time in processing inbound traffic.
After enabling in kernel config file and recompilling/installing the kernel the following sysctl variable must be configured.

>>and against SYN floods one can use pf's synproxy

>> security.bsd.see_other_uids=0


>>grep jail /etc/defaults/rc.conf, finetuning if these, devfsing of thse

>> neutering the base system for targeted systems (such as dedicted webservers), check the example make.conf for this

Step 10. Setup a statefull firewall
Using IPFW or PF you are able to setup a stateful firewall so only conections initiated from inside will pass the firewall when returning from outside.

Step 11. Use Jail whenever is possible (for Web Server or Mail server, or DNS Server)
Jail helps you separating a web server filesystem and access from real server, so when is a security breach, the attacker will not have access to server's os, only to jailed machine. Setting up a Jail server in some cases is tricky but it worth the effort.

Step 12. Use a DMZ for your Web Server
Regarding step 11, Jail is good when you need a web server to run on your server, but the best way is to use DMZ. DMZ stands for Demilitarized Zone, and is another machine (or machines) connected to the server, on other network card (an isolated from LAN connection), with IP's from other subnet than your LAN. This machine will not be visible from LAN. On this machine will be run a web server. If you want that web server to be visible when accessing IP of your main server, then you can do port forwarding port 80 (or the whatever port is running the web server) from main server to the ip and port of DMZ machine. 

Step 13. Check file permissions
Check setuid and setgid files on your server, to see if any unusual files are setup with that attributes. You can do that by issuing:

# find / -type f \ ( - perm 2000 -o perm -4000 \ ) -print

Step 14. Setup your kernel security level
There are 5 security levels for FreeBSD from -1 to 3. The Level can be changed using kern.securelevel sysctl variable.

>>more to add here

Step 15. Remove unused options from Kernel
Here are some options that can be removed from Kernel (unless you need them):
DEBUG - this is removed by default and shoud be left removed on a production server
IPv6, gif, faith - those must be enabled only if you need them
BPF - this is needed only if you have an IDS or tcpdump service on your server
KTRACE - this is used for debuging and unless you use it, it must be disabled
CD9660 - not needed on a secure server
MSDOSFS - not needed on a secure server
NFS - leave it only if you need it
USB - not needed on a server
UCONSOLE - not needed on a secure server

Step 16. Drop synfins
Configure your server to drop synfins. This is useful to hide from fingerprinting the OS, with tools like nmap. You must recompile kernel with option TCP_DROP_SYNFIN.
Then add in /etc/sysctl.conf:

Last Updated ( Saturday, 31 March 2007 )

Other BSD Systems





Best BSD firewall?