FreeBSD Security How-To
FreeBSD Security How-To
Table Of Content
Introduction
Networking - overview
inetd - overview
SSH - Secure Shell
Networking part II - details
telnetd - telnet daemon
ftpd - ftp daemon
fingerd - finger daemon
IP firewalling with ipfw
log_in_vain
Filesystem
Kernel Securelevels and file flags
System logging
Miscellaneous tips
LKM
Portmap
Sendmail
Ports and Packages
Filesystem quota
Crontab
bpf - Berkely packet filter
CVS, CVSup, etc.
SSH (again)
Related URLs
Thanks
FreeBSD Security How-To Introduction
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 audit. 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 How-To will go
over some steps which will help you increase overall security of your machine.
Will you mention tripwire, tcp wrappers, crack, cops, other tools?
No I will not (except for SSH). This is FreeBSD specific How-To. There is a lot
of information for non-OS specific tools already out there. I would like to
concentrate on BSD only at this time. I will however provide links to the pages
which talk about other, non-BSD specific security tools.
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 eMail the maintainer:
jkb@best.com
While this How-To is FreeBSD specific most of the material covered here will
also apply to other Unix OSes (especially OpenBSD and NetBSD).
Is this How-To available in other languages?
As far as I know it has been translated to Russian:
http://www.freebsd.org.ru/security.html
and Chinese:
http://water.ite.ntnu.edu.tw/doc/cfbhow2.txt
TODO:
Cover /etc/login.conf and login classes.
Talk about running X windows.
Convert this to .html - Done! Yay!
Talk about locking down /etc/rc* and friends for securelevel - mentioned many
times by Robert Watson on freebsd-security
Incorporate 3.0 additions such as ipf, etc.
Networking
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 pico with with -w
option:
-w Disable word wrap (thus allow editing of long
lines).
-w is very useful when editing files suuch as /etc/inetd.conf You can also use ee
- it comes with FreeBSD and is actuallyy 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, what user to run
them as and etc. 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
inetd_enable="YES"
to
inetd_enable="NO"
Now 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 hardware to support that. Or else someone can also
cause DoS and crash your computer by opening 1024 telnet connections at one
time. Hence, in the file /etc/rc.conf the line right below
inetd_enable="YES"
should be changed from:
inetd_flags=""
to:
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.
SSH - Secure Shell
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 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
http://fox.doc.ic.ac.uk/~ci2/ssh/
http://www.zip.com.au/~roca/ttssh.html
http://bmrc.berkeley.edu/people/chaffee/winntutil.html
http://public.srce.hr/~cigaly/ssh
SecureCRT from http://www.vandyke.com
Networking part II (details)
telnetd
So you have decided to use inetd. Fine. Let us look at the options inside of
/etc/inetd.conf which can make services a little more secure and informative.
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. It should
also be noted that there are some utilites which can tell you the OS by just
"fingerprinting" the running TCP/IP stack of that OS. 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
By turning off telnetd your users (and you) will be forced to use a more secure
alternative such as SSH. 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
system.
ftpd
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
configuration file.
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:
ftp.* /var/log/ftpd
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
fingerd
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
/etc/syslog.conf file:
daemon.notice /var/log/fingerd
% 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.
IP firewalling with ipfw
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
options IPFIREWALL_DEFAULT_TO_ACCEPT #just what it say
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.
********** WARNING ************
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
options IPFIREWALL_DEFAULT_TO_ACCEPT
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 for 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
temporarally.
*****************************
One should take a closer look at /etc/rc.firewall for possible examples and
basic firewall setup. Go here for FreeBSD ipfw config page.
log_in_vain
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
I would like to point out that only tcp packets which have only SYN set as flag
will be logged. This might not be enough in some cases. Apply this patch to be
able to see all tcp packets.
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 to find out what ports
you have open. I recommend nmap. 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`
Filesystem
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(8) 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. 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,nosuid 2 2
/dev/sd0s1i /tmp ufs rw,nosuid 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 only root
user 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 do:
# 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 will 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. There is a utility suidcontrol (currently
in beta) which will help you to set a system wide suid/sgid policy.
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.
Kernel Securelevels and file flags
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 description 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 give 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=N
where N is 0, 1 or 2.
You will also have problems upgrading your system via "make world" or 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 10616799 Jun 30 01:27 /kernel
That "schg" is what will prevent you from installing a new kernel:
nfr# id
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem)
nfr# sysctl kern.securelevel
kern.securelevel: 2
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 2048800 Jul 19 20:38 init
# ls -lo /bin | grep schg
-r-sr-xr-x 1 root bin schg 1925512 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 appropriate securelevel)
# 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:
http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html
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)
System logging via syslog
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. To make sure that syslogd is running on your system,
do:
% 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 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 very easy - much easier then TCP. One thing you can do is to tell your
syslog daemon NOT to listen to syslog messages from other systems by running
your syslog daemon in secure mode. To do so, add "-s" switch in your
/etc/rc.conf file.
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:
Jul 21 10:52:35 nfr syslogd: discarded 1 unwanted packets in secure mode
Jul 21 10:52:35 nfr syslogd: discarded 2 unwanted packets in secure mode
Jul 21 10:52:35 nfr syslogd: discarded 4 unwanted packets in secure mode
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
whichever 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 add to the /etc/syslog.conf the following line:
auth.*,authpriv.* /var/log/authlog
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 instead is
started from crontab ever so often:
% 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 probably (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:
http://www.core-sdi.com/Core-SDI/english/slogging/ssyslog.html
Another is nsyslog (new syslog) from the people who brought you ipfilter and
can be found 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 such analizer is called logcheck and is available from
http://www.psionic.com/abacus/abacus_logcheck.html
Another similar package is called logsurfer and you can download it from
http://www.cert.dfn.de/eng/team/wl/logsurf/
Miscellaneous hints and tips
LKM
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 configuration file:
options NO_LKM
Portmap
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).
with
portmap_enable="NO" # Run the portmapper service (or NO).
Sendmail
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 change:
sendmail_enable="YES" # Run the sendmail daemon (or NO).
to
sendmail_enable="NO" # Run the sendmail daemon (or NO).
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.
Filesystem quota
If you are running a "shell" 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 /etc/rc.conf from:
check_quotas="NO" # Check quotas (or NO).
to
check_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
Crontab
If you are using /etc/crontab to run jobs which can give someone extra
information about your system, make sure to:
# chmod 640 /etc/crontab
BPF
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.
Updating OS via 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. By doing this you will know that you are
running up-to-date OS. For more info see:
http://www.freebsd.org/handbook/handbook277.html#592. Don't forget to read
ERRATA file for your release.
A very good documentation on how to "make world" after you got the latest source
can be found at:
http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html
SSH
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. SSH is
also simply a must if you manage a server an via un-trusted networks (such as
colocated server at an ISP, etc).
Related URLs:
FreeBSD Hardening Project: http://www.watson.org/fbsd-hardening/
FreeBSD ipfw Configuration Page: http://www.metronet.com/~pgilley/freebsd/ipfw
FreeBSD Security advisories: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/
FreeBSD Security web page: http://www.freebsd.org/security/security.html
Security tools in FreeBSD: http://www.samag.com/archive/0705/feature.shtml
Thanks!
I would like to thank the cast of many for help with this work. Your comments,
support and feedback made it possible. Special thanks to Chris Peiffer for
english grammar and spelling edits.
freebsd-questions@FreeBSD.ORG
Copyright © 1995-1998 FreeBSD Inc. All rights reserved.
$Date$
(
geocities.com/hackermuda)