* 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 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, 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
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 1061679 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 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 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-wo
rld.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:
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-wo
rld.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: 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).
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 (c) 1995-1998 FreeBSD Inc.
Vova
