For a updated version of this FAQ, Please goto the original authors page at:
# This HOW-TO is maintained by Jan Koum (firstname.lastname@example.org)
# Please mail me any additions, comments, suggestions, etc.
# $Id: secure_howto,v 1.13 1998/09/13 10:01:26 jkb Exp jkb $
FreeBSD SECURITY HOW-TO
o FreeBSD Security HOW-TO Introduction
o Is there really a need for this HOW-TO?
FreeBSD is a very secure operating system. Since source code is freely
available, the OS is constantly going through the review and inspection.
While FreeBSD comes very secure OOB (Out-Of-Box), there are many features
that can make it more secure for those of you who are "paranoid". This
HowTo will go over some steps which will help you increase overall
security of your machine.
o Will you cover tripwire, TCP wrappers, crack, cops, Satan, other tools?
No I will not (except for SSH). This is FreeBSD specific HowTo. There is
a lot of information for non-OS specific tools already out there. I would
alike to concentrate on BSD only at this time.
o Who should read this HOW-TO?
Anyone who wants to learn more about ways to make their system more secure.
This HOW-TO will cover some very basic steps and some very complex steps. If
you have any questions or would like to contribute, please E-Mail the
While this HOW-TO is FreeBSD specific most of the material covered here will
also apply to other Unix OSes (especially OpenBSD and NetBSD).
o Is this HowTo available in other languages?
As far as I know it has been translated to Russian:
Cover /etc/login.conf and login classes.
Talk about running X windows.
Convert this to .html
o inetd (Inet Daemon)
Networking plays a very important role in overall system security.
FreeBSD is based on 4.4BSD which comes with built in networking and
actually has one of the most solid and fast TCP/IP stacks around. This
stack provides support for protocols such as telnet, ftp, talk, rsh, and etc.
Main configuration file for many of these services is located in /etc and
is named inetd.conf - to edit this file type "vi /etc/inetd.conf" (I will
use vi as in editor in these examples. You should however use an editor
you are most comfortable with - if you want an easy way out try pico).
If you are going to use pico, start with with -w option:
-w Disable word wrap (thus allow editing of long
This is very useful when editing files such as /etc/inetd.conf
You can also use ee - it comes with FreeBSD and is actually set as an
editor of choice by default for root, but "echo $EDITOR" to check.
When you open the file in editor you will see plain ascii text which
tells inetd which services to run, as what user and etc. (man 5 inetd.conf).
Since this file is the main file which starts all the network services it
is very important to configure it properly. To turn off a service you would
place a "#" in front of the line. In general, placing a "#" before a line in
any unix configuration file disables that line. A basic rule of thumb is to
turn off the services which you unfamiliar with. If you don't know what it
is or what it does, don't run it then. Ideally you would not run inetd at all.
One example is if you are doing web serving only. Then you would run ssh and
httpd only and NOTHING ELSE. More info on ssh follows below. If you decide
not to run any of the daemons in the inetd.con file, then you can simply turn
off inetd. To do that, edit /etc/rc.conf file and change
nobody will be able to telnet, rlogin or ftp into your computer.
If you will be running inetd, consider using tcp wrappers. You can find
more information at ftp://ftp.win.tue.nl/pub/security/index.html#software
If you do decide to leave inetd running, then make sure to enable logging
and to increase the number of times a service can be invoked in one minute.
(The default is 256, I recommend 1024 - adjust it yourself as you see fit).
If you are connecting with a slow link (a modem for example), this will
not matter, but if you have a fast connection this "feature" can be used
to create a DoS (Denial of Service) attack. Someone can create a simple
shell script to invoke more then 256 connections to your computer which
will cause your inetd service to shut down. On the other hand, if you want
to support 1024 simultaneous connection to your box make sure you have it
configured to support that. Or else someone can also cause DoS and crash your
computer. Hence, the line right below
should be changed from:
inetd_flags="-l -R 1024"
this will turn on logging (-l switch) and increase maximum connection number
to 1024 from the default 256. You will also need to change your syslog.conf
file in /etc directory, but we will talk about syslogd later.
I mentioned above that in some cases you will not need to run inetd at all.
For example, if you are running a web, news or nfs only server, there
is no need to have another services running on the machine. "How do I
control my machine?" one might ask? This is where SSH comes in. You can login
into the machine remotely using SSH (Secure Shell). Secure Shell was designed
as a replacement for rsh, rlogin and other Berkeley r* commands, but people
quickly realized how useful SSH is and started using it instead of such
applications as telnet and ftp. SSH has many features, but it is mostly
used for encrypting connection to prevent clear text passwords and the rest
of the data traveling on in the clear on the wire. If you use telnet,
your connection can be spied on. (If you think that S/Key is the solution
there still exists the problems of data insertion and connection hijacking.)
I hope by now you have been convinced to turn off inetd completely and
install SSH instead. If you don't think you can live without services
provided by inetd then at least enable logging and increase maximum allowed
connections per minute (see above).
One can download SSH from ftp://ftp.funet.fi/pub/unix/security/login/ssh
If you want an easy way out:
# cd /usr/ports/security/ssh
# make install
If you will have your users connect to you from non-Unix machines, some of the
places to get Windows SSH clients are
SecureCRT from http://www.vandyke.com
o Inetd (part II)
So you have decided still to use inetd. Let us look at the options inside
of inetd.conf which can make services a little more secure.
Every attacker at first will gather information about the network or the
system he/she is about to attack. One of the things you can do to prevent
this is to add "-h" switch to the telnet daemon:
telnet stream tcp nowait root /usr/libexec/telnetd telnetd -h
from the telnetd man page:
-h Disable the printing of host-specific information before login
has been completed.
While there are many other ways for someone to gather system information,
one step here and another step there will overall produce a good result.
If you don't want to run telnet daemon at all, then simply add "#" in the
very beginning of the line:
#telnet stream tcp nowait root /usr/libexec/telnetd telnetd
One of the quite extreme measures you can take is to refuse someone a
telnet session if their IP does not resolve into a hostname. To do that,
simply add "-U" switch to the telnet daemon:
telnet stream tcp nowait root /usr/libexec/telnetd telnetd -h -U
This will do very little, however, to increase the overall security of your
Now let's look at ftpd. FreeBSD has the ftp daemon configured to do some
logging. You can see that because ftpd is started with "-l" switch from
inetd.conf. However, you also need to configure your syslogd (syslog daemon)
to provide support for the log generated by ftp daemon (ftpd).
From the man page:
-l Each successful and failed ftp(1) session is logged using syslog
with a facility of LOG_FTP. If this option is specified twice,
the retrieve (get), store (put), append, delete, make directory,
remove directory and rename operations and their filename argu-
ments are also logged. Note: LOG_FTP messages are not displayed
by syslogd(8) by default, and may have to be enabled in syslogd(8)'s
Let's enable ftpd logging in the syslog daemon's configuration file. This file
is /etc/syslog.conf (also `man 5 syslog.conf`). Add the following line to
the configuration file:
don't forget to issue the command "touch /var/log/ftpd" since syslogd can't
write to a file which isn't created first. Don't forget to add the file
to which you will log ftp activity into /etc/newsyslog.conf to make sure
it is rotated properly. See below for newsyslog(8) information.
If you want to add more information about your ftp daemon (ftpd) to the log
files, just add second "-l" to the ftp line in /etc/inetd.conf:
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l -l
If you want to make sure your users are using scp (Secure Copy, which is
part of SSH suite), but still want to allow anonymous ftp access, start
your ftp daemon with "-A" switch:
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l -A
You can then also edit /etc/ftpwelcome to say that ftpd will only allow
incoming anonymous connections and that existing users should use scp
instead of ftpd. If you do enable anonymous ftpd, then you can use -S
option to log anonymous ftp transfers:
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -A -S
Finger service comes configured as "secure" by default: it does not
allow queries without a user name. This is a good thing (tm). Yet,
some people are paranoid and would like not to run finger service
at all. In that case, again, comment it out by placing "#" at the
beginning of the line. If you would like to continue running finger
service, enable logging by adding "-l" switch:
finger stream tcp nowait nobody /usr/libexec/fingerd fingerd -s -l
Logs from fingerd will go into /var/log/messages by default. If you want to
have finger daemon log to a specific file, add the following line to your
/* !fingerd anyone? */
$ man 5 syslog.conf
You really should not have anything other then ftp, telnet and finger
daemons enabled in your /etc/inetd.conf file. I usually disable talk and
and comsat as well as other services I personally have no need for. As I
mentioned before: if you don't know what the service does or think you don't
need it, disable it. Some man pages which you might find useful relating
to the networking configuration are: inetd, ftpd, telnetd, fingerd, syslogd,
comsat, talkd, rshd, rlogind, and inetd.conf. Make sure to look at the
"SEE ALSO" section of the man page for related information.
o ipfw (IP FireWall)
IP Firewall does packet filtering: Nothing more, nothing less. However,
you should consider compiling support for ipfw into your kernel. I usually
compile support for ipfw on most of my machines, HOWEVER, on most my kernel
config looks like this:
options IPFIREWALL #finger the net
options IPFIREWALL_VERBOSE #log the net
first line includes basic IP Firewall support. Second line configures ipfw
to be able to log accepted or rejected packets. Third line is very
important. It does exactly what it says: accept any connections and packets
from anywhere by default. If you don't do this, ifpw will deny everything
by default. I like to have ipfw built into the kernel just in case, but I
don't like to deny everything by default on my personal workstation or for
example a shell server.
********** NOTE ************
DO NO USE THIS OPTION UNLESS YOU KNOW WHAT YOU ARE DOING!!!
This is not the correct approach to firewall configurations. Everything
should be denied by default. DO NOT add
if you are building a secure system or production firewall. Make
sure everything is denied by default first and then add rules to allow
connections/packets on a case by case bases. See /etc/rc.firewall more info.
AGAIN: Do not use this options unless you just like to have ipfw built into
the kernel to deny occasional DoS attacks or block certain ports/network
One should take a closer look at /etc/rc.firewall for possible examples
and basic firewall setup. See URL at the bottom for FreeBSD ipfw config
You can also change some useful kernel variables through sysctl command:
# sysctl -w net.inet.tcp.log_in_vain=1
# sysctl -w net.inet.udp.log_in_vain=1
This will provide you with logging of attempted connections to your box
to the port which does not have a server running to it. For example,
if you do not have DNS server on your computer and someone would try
to use your computer as DNS you would see a message such as:
Connection attempt to UDP yourIP:53 from otherIP:X
(where X is some high port #)
This will be seen with "dmesg" command. dmesg displays the system's
kernel message buffer. However, this buffer only can store limited
amount of information and hence this also gets logged to the messages
file in /var/log directory:
# tail -1 /var/log/messages
Jun 12 19:36:03 ugh /kernel: Connection attempt to UDP yourIP:53 from otherIP:X
o Final notes
Now you should in theory have your machine a little more secure than when
you just installed it. A few things you can do now to verify that everything
you did above worked are:
$ netstat -na | grep LISTEN
this will tell you which ports have services waiting for a connection. The
less you have, the better :) Also, run different port scanners (strobe, nmap)
to find out what ports you have open.
And also make sure syslog is actually logging everything you want it to:
# cd /var/log
# tail -10 fingerd ftpd messages
If you don't see anything in your logs, make sure that you have restarted
both inetd and syslogd processes:
# kill -HUP `cat /var/run/syslog.pid` `cat /var/run/inetd.pid`
Since Unix considers everything a file, it is very important to properly
protect your filesystem. This process starts before installing the OS
itself: you need to calculate and design your partition layout. There are
a few main reasons for doing so. One is that you can mount different
filesystems with different options (some examples below). Another is that
if you want to export a filesystem, you will have a more granular control.
If you are coming to FreeBSD from the Linux world you will notice that
while Linux puts everything under one root partition "/", FreeBSD by default
gives "/", "/usr" and "/var". This makes it easy to use programs like
dump also. But there are security advantages as well. One of the things I
usually do is try to separate partitions where users will be able to write
so that they can be mounted "nosuid". From the mount man page:
nosuid Do not allow set-user-identifier or set-group-identifier
bits to take effect. Note: this option is worthless if a
public available suid or sgid wrapper like suidperl is
installed on your system.
Hence you would have one partition for user directories: /home or /usr/home
Then you could also create separate partition for /var/tmp and then
point your /tmp to it:
# rm -rf /tmp
# ln -s /var/tmp /tmp
For example, you then could have something like:
# cat /etc/fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/sd0s1b none swap sw 0 0
/dev/sd0s1a / ufs rw 1 1
/dev/sd0s1g /usr ufs rw 2 2
/dev/sd0s1h /usr/home ufs rw,nosuid 2 2
/dev/sd0s1f /var ufs rw 2 2
/dev/sd0s1e /var/tmp ufs rw,nosuid 2 2
proc /proc procfs rw 0 0
At this point you need to make sure all the directories where users can
write are either mounted "-nosuid" or have been chmod'ed in such way that
not anyone can write to them. By default FreeBSD will have only one you
should be concerned with: /var/spool/uucppublic
You can either mount your "/var" filesystem "-nosuid" or just issue
# chmod o-w /var/spool/uucppublic
If you want to find all your writable directories, issue:
# find / -perm -0777 -type d -ls
As the man page points out, having an suid/sgid wrapper will make mounting
your other filesystems nosuid useless. Find out what files are installed
on your system as suid or guid. To do that use find(1):
# find / -perm -2000 -ls
# find / -perm -4000 -ls
Also, you can simply not use the "-ls" switch to get a more compact output
One of the things you might do is to "chmod 000" binaries you will never
ever find useful. Some examples would be uustat, uucico (even getting uid
of uucp is not good) if you never touch uucp. Or ppp and pppd if you never
will do anything PPP related on the system. If you will never do ANY printing
you can safely chmod to 000 lpr, lprq, lprm. Maybe one day someone will
implement a simple shell script which based on a series of questions will
chmod your system for you.
At this point you might be asking what can stop an attacker from simply
unmounting and then mounting the filesystem without "-nosuid" flag?
Well, nothing, unless you change securelevel.
BSD kernel has a notion of securelevel. While some argue that it is not
as perfect as it could be, it will do the job most of the time to stop
your average "script kiddiez". Securelevel is simply the level with which
your kernel runs - each level implementing different protections and checks.
This is taken from the init(8) man page:
The kernel runs with four different levels of security. Any superuser
process can raise the security level, but only init can lower it. The
security levels are:
-1 Permanently insecure mode - always run the system in level 0 mode.
0 Insecure mode - immutable and append-only flags may be turned off.
All devices may be read or written subject to their permissions.
1 Secure mode - the system immutable and system append-only flags may
not be turned off; disks for mounted filesystems, /dev/mem, and
/dev/kmem may not be opened for writing.
2 Highly secure mode - same as secure mode, plus disks may not be
opened for writing (except by mount(2)) whether mounted or not.
This level precludes tampering with filesystems by unmounting them,
but also inhibits running newfs(8) while the system is multi-user.
If the security level is initially -1, then init leaves it unchanged.
Otherwise, init arranges to run the system in level 0 mode while single
user and in level 1 mode while multiuser. If level 2 mode is desired
while running multiuser, it can be set while single user, e.g., in the
startup script /etc/rc, using sysctl(8).
For example, if all your system does is web serving, you can safely set
your securelevel to 2. However, if you are running an X server, setting
your securelevel to 1 or higher will cause you problems because X server
needs to open /dev/mem and /dev/kmem for writing, and securelevel of 1
prevents doing so. One way around this is to set your securelevel after
you start your X server, but IMHO if you are running X server you already
have other security issues to worry about then kernel securelevel.
To find out what your current securelevel is:
# sysctl kern.securelevel To raise your securelevel:
# sysctl -w kern.securelevel=X
where X is 0, 1 or 2.
You will also have problems upgrading your system with "make world" and
when rebuilding the kernel if you are running with securelevel of 1 or
higher. This is because by default "make install" will install your kernel
with the system immutable flag:
# ls -lo /kernel
-r-xr-xr-x 1 root wheel schg 1061679 Jun 30 01:27 /kernel
That "schg" is what will prevent you from installing a new kernel:
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem)
nfr# sysctl kern.securelevel
nfr# rm -rf /kernel
rm: /kernel: Operation not permitted
nfr# mv /kernel /tmp/
mv: rename /kernel to /tmp//kernel: Operation not permitted
If you are running in securelevel of 1 or 2, this flag may not be turned off:
# chflags noschg /kernel
chflags: /kernel: Operation not permitted
It should be noted however that file /boot.config can be used to change
kernel used at system boot-up. To prevent this, one should:
# touch /boot.config
# chflags schg /boot.config
By default you will also have some binaries installed with schg flag set
on your system:
# ls -lo /sbin | grep schg
-r-x------ 1 bin bin schg 204800 Jul 19 20:38 init
# ls -lo /bin | grep schg
-r-sr-xr-x 1 root bin schg 192512 Jul 19 20:36 rcp
But back to locking down your system. Since we are talking about system
immutable flags, one might consider running chflags schg on the whole
/sbin and /bin tree. This will make it harder for someone to backdoor
your system with a "rootkit" (considering that you are also running with
# chflags schg /bin/*
# chflags schg /sbin/*
Since /sbin can be moved out of the way and new /sbin can be created,
it also makes sence to chflags both /sbin and /bin if you did the above:
# chflags schg /bin ; chflags schg /sbin
Doing a lot of changes to file flags is bound to and will in turn cause
problems with "make world".
It is best to do "make world" in single user mode anyway. For more
information on "make world" and reasons why see:
At this point you should have your system reasonably locked down with
very few services running, filesystems mounted the way they should
and with appropriate kernel securelevel.
Man pages related to the above topics: init(8), chflags(1), sysctl(8)
Logging is very important. It might provide you with clues that you are
under attack, that attempts to break in have been made or that your
system has been broken into. Standard Unix logging is done through syslog
daemon, syslogd(8). This daemon is started upon boot up from /etc/rc
and then keeps on running until you shut down your system.
$ ps -axu | grep syslogd
Syslog daemon reads configuration from /etc/syslog.conf file when it starts.
This file is very important as it tells syslog what to log and where.
You will probably want to read man pages for both syslogd and syslog.conf:
$ man syslogd ; man 5 syslog.conf
Since Unix is designed around networking, syslog daemon can and will
by default accept syslog datagrams from other systems. It in turn can itself
send datagrams to other computers on the network also. And of course it
can log everything locally - which is the default. Since syslog daemon
uses UDP - datagrams can be forged. One thing you can do is to tell your
syslog daemon NOT to listen to syslog daemon from other systems by running
your syslog daemon in secure mode. To do so, add "-s" switch in your
If you need your system to accept syslog datagrams from another devices
(such as your router, our your web server), use "-a" switch to allow
specific hosts, domains or subnets.
Next time you reboot your system, syslogd will be running with "-s" switch
and when someone will send datagrams to your syslogd over the network you
will see the following in your logs:
If you don't want to reboot your system, simply kill -9 your syslog daemon
and start it as root with "-s" switch.
This is all nice and fine if all the attacks against your system fail and
your syslog files are left uncompromised. But what if you actually were
broken into and an attacker erased your /var/log directory? There are many
ways to prevent this. One way is to set up a machine on your network which
will do syslog logging for your whole network and NOTHING else. It will have
no ports open except for UDP port 514 (syslogd). This way you can have all
of your systems (routers, firewalls, server, workstation) send critical (or
whatever you chose) information to this one machine. This can be an
old 486 computer with a lot of disk space. Make sure to give correct options
to the "-a" switch if you dedicate a system for syslogd. You can also connect
an old line printer to your system and have syslog send certain information
to the printer (failed logins, etc). If it is on the paper, it will be very
hard for an attacker to erase the logs (unless she is works in the same
place). Other options includes sending all your syslogd messages to another
computer connected with a serial (cuaaN) or parallel (lpN) port cable.
Everyone will have different needs as to what they want to log. However,
one thing I usually do is to add to the syslog.conf file the following line:
FreeBSD comes with something called newsyslog. This program will rotate
your logs for you so they don't grow big or take all your hard drive.
The configuration file is /etc/newsyslog.conf - please take a look at the
man page for more information:
% man newsyslog
Unlike syslogd, newsyslog is not always running on your system, but is rather
started from crontab:
% grep newsyslog /etc/crontab
0 * * * * root /usr/sbin/newsyslog
You should modify /etc/newsyslog.conf to your needs. I usually change the
default mode of 664 for some files to 640 - the reason is that there is no
reasons for users to read your logs. You should also (as root) do the following
# cd /var/log
# chmod g-w,o-r * ; chmod a+r wtmp
This will prevent your users from reading the log files, unless they are in
the appropriate group (such as wheel or something else). You should probably
make all your log files owned by group wheel -- this purely for convenience:
if you are in group wheel, most likely you can su(1) to root and read log
files anyway - this way you just don't have to su(1) one extra time.
You will also have to add "root.wheel" to your /etc/newsyslog.conf file:
/var/log/maillog root.wheel 640 7 100 * Z
/var/log/authlog root.wheel 640 7 100 * Z
/var/log/messages root.wheel 640 7 100 * Z
This will rotate files when they reach size of 100K, gzip them, rotate
old files, chmod to 640 and chown to root.wheel - exactly what we want.
There are a also a few alternatives to the standard Unix syslog:
One is ssyslog (secure syslog) from CORE SDI and is located at:
Another is nsyslog (new syslog) from the people who brought you ipfilter
and is located at: http://cheops.anu.edu.au/~avalon/nsyslog.html
To go with any of the above (standard syslog, ssyslog or nsyslog) one
should probably also take a look at some utilities which will analyze
log files for you, saving you the trouble of running grep yourself.
One is called logcheck and is available from
Another similar package is called logsurfer and you can download
it from http://www.cert.dfn.de/eng/team/wl/logsurf/
o Misc. hints and tips
One might want to disable use of LKM's on a production system. Why? See:
Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 09
To disable LKMs, add the following line to your kernel:
to your kernel configuration file.
By default FreeBSD comes with portmapper enabled. If you don't have a need
for it: disable it. You will not have a need for portmap daemon if you are not
using any programs which require RPC. To disable the portmap, edit
/etc/rc.conf and replace:
portmap_enable="YES" # Run the portmapper service (or NO).
portmap_enable="NO" # Run the portmapper service (or NO).
By default FreeBSD ships with sendmail enabled. In the past sendmail was
known for weak security. Lately people working on sendmail did a great job
in cleaning up the code, but due to the size of sendmail's source it is
no an easy thing to do. In other words: turn off sendmail also if you don't
need it. If you do need to use sendmail, check with http://www.sendmail.org
for patches and different hacks. Also, if you are running sendmail 8.8 please
make sure that spammers can not use your system to relay spam.
See http://www.sendmail.org/antispam.html for more information on anti-spam.
To turn off sendmail in FreeBSD simply edit /etc/rc.conf (yes, again) and
sendmail_enable="YES" # Run the sendmail daemon (or NO).
sendmail_enable="NO" # Run the sendmail daemon (or NO).
o Ports and Packages
It is best not to use ports or packages when building a secure system.
You don't really know which ports or packages will install suid-root
binaries on your system -- and you don't want more then what you have
already, trust me. Even though you can give different switches to the
pkg_add command (such as "-v" or "-n"), it is best to download the software
in source code form and compile it yourself.
o Filesystem quota
If you are running a "shell" type server, you might want to consider using
quotas on the user filesystem (such as /usr/home for example). This can
protect you from Denial of Service attack (accidental or not) of a random
user filling up the whole filesystem. To enable quotas, modify the line in
check_quotas="NO" # Check quotas (or NO).
tocheck_quotas="YES" # Check quotas (or NO).
Please also take a look at the following man pages for more information
and examples of how to use quotas: quotaon, edquota, repquota, quota
Make sure to add "userquota" to your /etc/fstab: man 5 fstab
If you are using /etc/crontab to run jobs which can give someone extra
information about your system, make sure to "chomd 640 /etc/crontab"
BPF stands for berkeley packet filter and is required to be in the kernel
if you want to perform network sniffing. Programs such as tcpdump or NFR
use BPF all the time. However, program which sniff the network from BSD
systems also use BPF. If someone does manage to get root on your system,
having BPF in the kernel will make sniffing of your network much easier for
them. Don't compile BPF into the kernel if you won't have a need for it. By
default FreeBSD's kernel does not support BPF.
o CVSup, CVS, etc.
If you installed your system from a CD-Rom, chances are that by the time the
code was frozen to the time you got your CD in the mail, some bugs were
discovered. Most likely (or so we all hope), they were not security bugs.
Yet, I would recommend upgrading your system to the latest -current (or
-stable: whichever one you follow) source. Doing this you will know that
you are running up-to-date OS. For more info see:
A very good documentation on how to "make world" after you got the latest
source can be found at:
I can't stress enough how important it is to use SSH instead of telnet, ftp,
rlogin, rsh, etc. For people who are on slow speed lines (dial-up, 56K frame)
ssh has -C option: [man page quote]
-C Requests compression of all data (including stdin,
stdout, stderr, and data for forwarded X11 and
TCP/IP connections). The compression algorithm is
the same used by gzip, and the "level" can be con-
trolled by the CompressionLevel option (see below).
Compression is desirable on modem lines and other
slow connections, but will only slow down things on
fast networks. The default value can be set on a
host-by-host basis in the configuration files; see
the Compress option below.
This will "make your ssh connection faster" :) In other words, just use SSH.
Please, PLEASE use ssh. If you won't, then no security will help you.
o Related URLs:
FreeBSD Hardening Project:
FreeBSD ipfw Configuration Page:
FreeBSD Security advisories:
FreeBSD Security web page:
Security tools in FreeBSD:
I would like to thank the cast of many for help with this work-in-progress.
Your comments, support and feedback made it possible.
Special thanks to Chris Peiffer for english grammar and spelling editing.