# $Id: testnet-seceval-fbsd.txt,v 1.10 2002/05/26 04:14:01 tbaur Exp $
===========================================================================
Security HOW-TO, FreeBSD 4.x-STABLE
DALnet Security Evaluation
===========================================================================
Prepared by: Tim Baur
Based on: A basic guide to securing FreeBSD 4.x-STABLE
written by Marc Silver
==> Document Status: PUBLIC - release (v1.10)
The DALnet IRC Network
INSTRUCTIONS:
Review this document. I suggest you read it once (or twice if need be) in
its entirety, then go back and start making changes to your system. If,
while in the process of following this guideline, you run into questions,
please feel free to contact either testnet@dal.net or the person in charge
of doing the evaluation on your server. When you have completed these
changes to your server, send an email to testnet@dal.net, a meeting will
be scheduled with the staff member responsible for your evaluation.
===========================================================================
Table of Contents:
==> Overview
==> The Foundation for a secure system
-> File System Layout
==> Post Installation
-> System Secure Levels
-> Removal of the toor user
-> Shut down services that you dont need/want
-> syslogd
-> portmap
-> telnetd
-> sshd
-> inetd
-> ftpd
-> suid/sgid Binaries
-> Log in vain
-> Blackhole
-> Route Cache
-> Crontabs
-> Secure the console
-> Process accounting
-> IP Filtering
-> Mail aliases
-> DNS / DNS Resolver
-> Network Time Protocol
==> Kernel/sysctl changes
-> Disable bpf if you dont need it
-> Network Limits
-> kern.maxfiles
-> kern.ipc.somaxconn
-> net.inet.tcp.*space
-> net.inet.tcp.always_keepalive
-> Disable Ctrl-Alt-Del
-> Quota Support
==> Managing user accounts
-> User quotas
-> Home directory permissions
-> Hiding processes
-> Disabling procfs
-> login.conf(5)
==> Stay up to date
-> Keep your packages current
-> Keep your OS current
==> Be Vigilant
==> Other documents about FreeBSD Security
==> Thanks
Overview
========
The word security means different things to different people. While this
document covers various aspects and suggests things that can be done to
secure default installations of FreeBSD, it is is by no means an
authoritive guide to securing FreeBSD. It merely discusses a model that
DALnet requires be used on machines that are linked to the network and one
that we have had great success with.
For a broader look at security on FreeBSD and as a primer to this
document, I would suggest that everyone read the man page for security(7)
on their FreeBSD system.
The Foundation for a secure system
==================================
A system should be set up to be secure from the very beginning. There are
a number of things that can be done during the FreeBSD installation that
can save you serious headaches later. In my opinion, file system setup can
make a big difference in cases where you can (and must) assume that the
attacker already has a local login on the machine.
o File System Layout
The file system layout below may be used as a guideline for any
system. Obviously, disk layout can/will differ from machine to
machine based on the function of the machine but this should serve
as a basic guide.
You may adapt this to suit your own needs.
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ad0s1a 128990 31390 87282 26% /
/dev/ad0s1f 49583 27879 17738 61% /tmp
/dev/ad0s1d 12348393 2563101 8797421 23% /usr
/dev/ad0s1h 4065262 97983 3642059 3% /home
/dev/ad0s1g 2032623 6026 1863988 0% /var
procfs 4 4 0 100% /proc
Now, let's look at the output from the mount(8) command:
/dev/ad0s1a on / (ufs, local)
/dev/ad0s1f on /tmp (ufs, local, nodev, nosuid, soft-updates)
/dev/ad0s1d on /usr (ufs, local, soft-updates)
/dev/ad0s1h on /home (ufs, local, nosuid, with quotas, soft-updates)
/dev/ad0s1g on /var (ufs, local, soft-updates)
procfs on /proc (procfs, local)
Now, let's discuss why I've set things up this way.
The root partition (/) is a reasonable 128MB, (as recommended in the
tuning(7) man page) and is home to the kernel as well as KLD's and
various other fairly important directories which are linked directly
off it (/sbin is just one that comes to mind). With this in mind,
it's possible at a later stage to mount the root partition as
read-only by editing the flags for this partition in the fstab(5)
file.
Temporary files are stored in /tmp, and since this directory is
usually world writeable, it's important to not allow certain files to
be used from this directory. Using the fstab(5) file (also see
mount(8)) you should add the NOSUID and NODEV flags for /tmp which
disables suid programs and stops character or block special devices
on the filesystem. You may also want to add the NOEXEC flag for
/tmp, but this is severely restrictive and may begin to make things
difficult for your users. NOEXEC will also cause problems when you
'make installworld', since a fairly normal /tmp is required for this.
Enabling NOEXEC may also limit your ability to find an intruder.
It's important to note that you should symlink /usr/tmp and /var/tmp
to this /tmp partition, else you're still giving users a tmp
directory with no restrictions.
User specific directories are kept in /home and on this partition
it's a good idea to add the NOSUID flag, as well as adding QUOTA
support to limit the amount of disk space that your users may use.
Both /usr and /var are standard partitions with soft-updates enabled.
You may choose to also disable procfs. See 'Disabling procfs' for
more information.
This model can obviously be changed to suit your needs, and you can
be even more anal if you wish. This however, is intended to strike a
happy medium between security and usability.
Post Installation
=================
Once your FreeBSD system has been installed there are a number of things
that can be done to help harden the machine.
o System Secure Levels
Security levels are at the core of FreeBSD security. They are
extremely powerful and are essential in securing FreeBSD.
For most machines there is absolutely no reason to run in securelevel
-1, unless you wish to run X-Windows on the machine. You're not
running X-Windows, you're running an IRC server. You fail the security
evaluation if you are running in securelevel 0 or -1.
-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.
3 Network secure mode - same as highly secure mode, plus IP packet
filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and
dummynet(4) configuration cannot be adjusted.
DALnet recommends servers run in at least securelevel 1.
sysctl kern.securelevel=1
To make this change more permanent, add the following to
/etc/rc.conf:
kern_securelevel_enable="YES"
kern_securelevel="1"
o Removal of the toor user
By default, FreeBSD ships with an additional user that has a UID of 0.
This user is known as toor (root backwards), and is intended as a
backup user, so that if you mistakenly broke (for eg) root's shell, you
could log in using this user and fix things. The account is disabled
(passwordless) by default, and hence of no use UNLESS you change it's
password. You may either choose to set a password for it, or remove it.
DALnet suggests you remove this account.
It should be noted that the rmuser(8) command will not allow the
deletion of an account with a UID of 0, so you will need to use
vipw(8) to remove this account.
o Shut down services that you dont need/want
It's important to not have any non-essential services running on the
machine, or any services that you dont recognise. The best thing to
do is kill all the services running on your machine and then
explicitly enable those that you want running. This way you know for
sure what's running on your machine. You can tell what TCP ports are
open on your machine by using the netstat(1) command. eg:
secure-me (1) : netstat -na | grep LIST
tcp4 0 0 *.80 *.* LISTEN
tcp4 0 0 *.25 *.* LISTEN
tcp4 0 0 *.22 *.* LISTEN
This shows that ports TCP ports 22 (ssh), 25 (smtp), and 80 (http)
are listening on this machine and are bound to all IP's. If you have
a process listening and you're unsure of what process is keeping that
port open you may use sockstat(1) to list open sockets and provide
you with the relevant information.
Use rc.conf(5) to easily configure which services start up by
default, as well as local package init scripts which can be found in
/usr/local/etc/rc.d
Similarly you may wish to see if you have anything listening via UDP.
You can also get this information via netstat(1):
secure-me (2) : netstat -na | grep -i udp
udp4 0 0 *.514 *.*
Here, you see that syslogd is listening on port 514 (UDP).
I will now discuss some common services and what you can do to better
secure them.
- syslogd ::
syslogd will by default bind itself to UDP 514, but you can prevent
this from happening by adding a second '-s' flag to syslogd's
command line on startup. This prevents syslogd from using network
sockets and can be done by simply adding the following line to
/etc/rc.conf :
syslogd_flags="-ss"
See the syslogd(8) man page for more information.
- portmap ::
portmap is used for remote procedure calls and its most common
application in FreeBSD is for use with NFS. To disable portmap add
the following line in your /etc/rc.conf:
portmap_enable="NO"
- telnetd ::
This service should be avoided at all costs. While telnet is
useful, there is just no excuse to use it anymore. All data
transferred across a telnet session is transmitted in clear text
(including usernames and passwords). This should be disabled,
either by killing inetd(8) completely, or by removing the telnetd
line from /etc/inetd.conf. If you MUST run this service, then look
at using something like login.access(5) or ipfw(8) to limit where
connections to this service may come from.
FreeBSD comes standard with sshd(8), a drop-in replacement for
telnetd with far superior security built in.
- sshd ::
FreeBSD (since 4.1.1) now comes with OpenSSH as part of the base
system, and sshd(8) is a perfect drop in replacement for telnetd,
while remaining more secure by using encryption to protect your
session. The protocol also allows for stronger encryption with the
use of RSA/DSA keys.
The use of OpenSSH is required by DALnet. The most current upto date
version must be installed. Access to the SSH port must be firewalled.
It should be noted that the most current versions of OpenSSH now
use SSH protocol version 2, protocol version 1 should be disabled.
This can be done by making sure the following line exists in
/etc/ssh/sshd_config:
Protocol 2
This will tell the sshd that it should only allow incoming SSH2
connections - and it will not fallback to version 1. Please note
that you may need to restart the sshd in order for this change to
take effect.
Similarly, you should also make sure that all outbound SSH
connections are using SSH2 by default, and then failing back to
SSH1. This can be done by editing /etc/ssh/ssh_config
For more information on OpenSSH, and how to used it effectively,
please visit http://www.openssh.com/
- inetd ::
inetd is designed to listen for connections on certain sockets. It
is used for popular applications like telnetd(8), qpopper and
ftpd(8). Since you won't be running any inetd applications, disable
the daemon by adding the following line to /etc/rc.conf :
inetd_enable="NO"
ftpd ::
You should not be running ftpd either via inetd or standalone.
smtp ::
You should not be running an smtp server. Sendmail should be disabled
by adding the following line to /etc/rc.conf :
sendmail_enable="NO"
o suid/sgid Binaries
On an IRC server, you won't have a real need for suid/sgid bins. It is
highly suggested one of the things you might do is to "chmod 000"
binaries you will never ever find useful. Some examples would be
uustat, uucico or ppp and pppd. They are not needed. There is a utility
suidcontrol which will help you to set a system wide suid/sgid policy.
Those binaries you expect to use (like ping or traceroute) can have
their suid/sgid bit removed via "chmod a-s" or "chmod o-rwx" to allow
only users in the wheel group access. Run the following commands to
find suid/sgid binaries on your system:
# find / -perm -2000 -ls
# find / -perm -4000 -ls
NOTE: A list of suid/sgid binaries will be asked for during the
security evaluation.
o Log in vain
Even though you've now disabled many services, you should log
connection attempts to ports without listeners/daemons. To do this
simply add the following line to /etc/rc.conf:
log_in_vain="YES"
To change this without rebooting your server issue the following
commands:
sysctl net.inet.tcp.log_in_vain=1
sysctl net.inet.udp.log_in_vain=1
Now, failed connection attempts to ports without listeners will be
recorded to /var/log/messages.
o Blackhole
FreeBSD also allows you the option to blackhole any TCP/UDP traffic
that is bound for ports without daemons/listeners. Instead of
logging the connection like 'log in vain' does, it ignores the
packet, thereby creating a blackhole into which packets dissapear.
The man page for this feature also states that this could potentially
slow down DoS attacks aimed at your system. The Blackhole MIB can be
easily enabled by issuing the following commands:
sysctl net.inet.tcp.blackhole=2
sysctl net.inet.udp.blackhole=1
It should be noted that enabling blackhole for UDP will prevent
people from being able to traceroute(8) to your system. The TCP
value may also be increased to 2. For more information, please see
the blackhole(4) manpage.
To make these changes permanent, add the following lines to
/etc/sysctl.conf:
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
It should also be noted that this is NOT a replacement for ipfw/ipf.
o Route Cache
Spoofed packet attacks may also be used to overload the kernel route
cache. Refer to the net.inet.ip.rtexpire, rtminexpire, and rtmaxcache
sysctl parameters. A spoofed packet attack that uses a random source IP
will cause the kernel to generate a temporary cached route in the route
table, viewable with netstat -rna | fgrep W3. These routes typically
timeout in 1600 seconds or so. If the kernel detects that the cached
route table has gotten too big it will dynamically reduce the rtexpire
but will never decrease it to less than rtminexpire. There are two
problems:
1. The kernel does not react quickly enough when a lightly loaded
server is suddenly attacked.
2. The rtminexpire is not low enough for the kernel to survive a
sustained attack.
sysctl net.inet.ip.rtexpire=2
sysctl net.inet.ip.rtminexpire=2
To make these changes permanent, add the following lines to
/etc/sysctl.conf:
net.inet.ip.rtexpire=2
net.inet.ip.rtminexpire=2
Never set either parameter to zero (unless you want to crash the
machine). Setting both parameters to 2 seconds should be sufficient to
protect the route table from attack.
o Crontabs
Firstly, there are certain files which you may generally not want
users looking at. The crontab of the root user is a perfect example.
You can safely chmod /etc/crontab to 0640 so that only root and users
in the wheel group can see it. Your users do not need to know what
jobs are started by cron.
At the same time, you may not want to allow users to use crontab(1)
at all. You can easily stop them by creating /var/cron/deny and
adding a list of users to that file. Those users will then be told:
crontab: you (marcs) are not allowed to use this program
Similarly, you may also create a /var/cron/allow and only add users
that should be allowed to use crontab to that file. For more
information, please see the crontab(1) man page.
o Secure the console
Many people are concerned that a malicious user with physical access
could simply reboot into single user mode and change the root
password. While it's quite clear that if an attacker has physical
access to your machine, NOTHING you do can keep it safe, you can
prevent people from simply changing the root password in single user
mode by performing one simple step. This can be done by editing
/etc/ttys and changing the the word 'secure' on the 'console' line to
'insecure'. This will require you to enter the root password when
dropping into single user mode. Your line will then look like this:
console none unknown off insecure
You should also be aware that if you do this, and you somehow lose
the root password, you will have to use a fixit floppy to reset the
password, because dropping into single user mode will NOT allow you
to change the password.
o Process accounting
It's nice to know exactly what's happening on your machine and to
this end I would suggest enabling process accounting on any machine
that you run. This enables you to see what commands users are
executing, and it can also be useful when debugging certain problems.
It does add some slight overhead, but generally you shouldn't notice
degraded performance. To enable, merely execute the following
commands:
secure-me (1) : touch /var/account/acct
secure-me (2) : accton /var/account/acct
To make this change more permanent, add the following line to
/etc/rc.conf:
accounting_enable="YES"
Once accounting is enabled, you can then use the lastcomm(1) and
sa(8) commands to get meaningful statistics from the process
accounting database.
o IP Firewalling (packet filter)
There are two packages which can be used under FreeBSD. IP Filter and
IP Firewall. Both handle packet filtering: Nothing more, nothing less.
While it is beyond the scope of this document to outline how to fully
configure each application, you may wish to secure the machine further
as well as gain information on attack patterns on your machine using
IP Filter or IP Firewall. There will come a time when you'll want to
filter something on the machine as a quick fix to a more perm solution.
We'll try to provide a quick outline..
Once you decide which packet filter to use, support must be compiled
into your kernel. I usually compile support for IP Filter on most of my
machines, kernel config looks like this:
options IPFILTER #ipfilter support
options IPFILTER_LOG #ipfilter logging
For IP Firewall:
options IPFIREWALL #firewall
options IPFIREWALL_VERBOSE #firewall logging
options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity
Local packet filtering =may= not required, depending on the network
filtering. However, if nothing eles it should be compiled in, default
to accept.
Under IP Filter, I also suggest including the following in your default
configuration:
block in log all with frag
block in log proto tcp all with short
block in log all with ipopts
block in quick all with opt lsrr
block in quick all with opt ssrr
A similar config would also exist for IP Firewall. Each packet filter
can be enabled via /etc/rc.conf:
IP Filter:
ipfilter_enable="YES"
ipfilter_program="/sbin/ipf"
ipfilter_rules="/etc/ipf.conf"
ipfilter_flags=""
ipmon_enable="YES"
ipmon_program="/sbin/ipmon"
ipmon_flags="-D /var/log/ipflog"
IP Firewall:
firewall_enable="YES"
firewall_script="/etc/rc.firewall"
firewall_type="client"
firewall_quiet="NO"
firewall_logging="YES"
firewall_flags=""
NOTE: A review of the IP Filter or IP Firewall rulesets will be
requested.
o Mail aliases
It's important to make sure that you're being notified of anything
that's happening on your system. FreeBSD has many scripts that are
triggered on a daily/weekly/monthly basis (see the man page for
periodic(8) and take a look at /etc/periodic for more information)
that contain information about your system such as SUID program
changes, kernel messages and other useful information. For this
reason it is important to get these mails. The output of these
scripts are sent to the root account, but you may choose to send the
output to multiple addresses. To do this, edit /etc/mail/aliases and
add a line similar to this:
root: localuser, remoteuser@yourdomain.com
This means that not only is the local administrator getting a copy,
but you're also mailing the output to a (hopefully anyway) seperate
mail server where it is theoretically out of harms way.
PLEASE NOTE: The sendmail daemon does NOT have to be enabled for daily
runs to be delivered locally or remotely. There is no need for a local
smtp daemon on the IRC server.
o DNS / DNS Resolver
There have been cases of DoS/DDoS against DNS servers which are used by
the IRC servers. This causes the IRC daemon to be unable to resolve DNS
which also slows down client connections. While you are free to use the
resolver of your choice (with the assumption it is running current code
(this is =your= responsibility)), hosting a local resolver on the box
bound to 127.0.0.1 is strongly advised. There is some overhead
involved, mainly ram as the cache builds, but there are benefits.
This is an issue that can be addressed on a case to case basis durning
the security evaluation.
o Network Time Protocol
The use of ntpd is required on all DALnet servers. Each server must
have properly synched time. ntpd is an operating system daemon which
sets and maintains the system time-of-day in synchronism with Internet
standard time servers. Ordinarily, ntpd reads the ntp.conf(5)
configuration file at startup time in order to determine the
synchronization sources and operating modes.
In edition to running ntpd, you will also want to get the correct
time-of-day before starting ntpd. This is done by running ntpdate.
To enable ntpdate add the following line in your /etc/rc.conf:
ntpdate_enable="YES"
ntpdate_program="/usr/sbin/ntpdate"
ntpdate_flags="time.verio.net"
To enable ntpd add the following line in your /etc/rc.conf:
xntpd_enable="YES"
xntpd_program="/usr/sbin/ntpd"
xntpd_flags="-p /var/run/ntpd.pid"
An example of a minimum configuration, /etc/ntp.conf:
server 129.250.35.250 prefer # time.verio.net
server 143.232.55.13 # ntp.nasa.gov
peer 132.239.1.1 # ucsd.ucsd.edu
peer 18.72.0.3 # bitsy.mit.edu
peer 129.7.1.66 # tick.uh.edu
driftfile /etc/ntp.drift
Kernel changes
==============
o Disable bpf if you dont need it
One of the first things I do when I install a FreeBSD machine is
recompile the kernel. One of the options that I like to disable in
the kernel is the bpf device, since this would stop an attacker from
putting the network card of the machine into promiscious mode. This
is useful should the machine itself is compromised. Simply comment
out the following line in your kernel file:
#pseudo-device bpf #Berkeley packet filter
You may also want to add in the options for ipfw, ipfilter, and add
quota support at the same time.
o Network Limits
The NMBCLUSTERS kernel configuration option dictates the amount of
network mbufs available to the system. A heavily-trafficked server with
a low number of MBUFs will hinder FreeBSD's ability. Each cluster
represents approximately 2K of memory, so a value of 1024 represents 2
megabytes of kernel memory reserved for network buffers. A simple
calculation can be done to figure out how many are needed. If you have
a web server which maxes out at 1000 simultaneous connections, and each
connection eats a 16K receive and 16K send buffer, you need
approximately 32MB worth of network buffers to cover the irc server. A
good rule of thumb is to multiply by 2, so 32MBx2 = 64MB/2K = 32768.
options NMBCLUSTERS=81920
o kern.maxfiles
kern.maxfiles can be raised or lowered based upon your system
requirements. This variable indicates the maximum number of file
descriptors on your system. When the file descriptor table is full,
``file: table is full'' will show up repeatedly in the system message
buffer, which can be viewed with the dmesg command.
Each open file, socket, or fifo uses one file descriptor. A large-scale
production server may easily require many thousands of file
descriptors, depending on the kind and number of services running
concurrently. kern.maxfile's default value is dictated by the MAXUSERS
option in your kernel configuration file. kern.maxfiles grows
proportionally to the value of MAXUSERS. From this number, the kernel
is given most of its pre-defined limits.
maxusers 512
Example, if you wanted to hold 30,000 clients, you would compile
maxusers at 512, update NMBCLUSTERS and add the following into
/etc/sysctl.conf:
kern.maxfiles=32768
kern.maxfilesperproc=32768
o kern.ipc.somaxconn
The kern.ipc.somaxconn sysctl limits the size of the listen queue for
accepting new tcp connections. The default value of 128 is typically
too low for robust handling of new connections in a heavily loaded web
server environment. For such environments, we recommend increasing
this value to 1024 or higher. The service daemon may itself limit the
listen queue size (e.g. sendmail, apache) but will often have a
directive in its configuration file to adjust the queue size up.
Larger listen queues also do a better job of fending off denial of
service attacks.
kern.ipc.somaxconn=1024
o net.inet.tcp.*space
The net.inet.tcp.sendspace and net.inet.tcp.recvspace sysctls are of
particular interest if you are running network intensive applications.
This controls the amount of send and receive buffer space allowed for
any given TCP connection. The default is 16K. You can often improve
bandwidth utilization by increasing the default at the cost of eating
up more kernel memory for each connection. We do not recommend
increasing the defaults because you are serving thousands of
simultaneous connections. It is possible to quickly run the system out
of memory due to stalled connections building up. But if you need high
bandwidth over a fewer number of connections, especially if you have
gigabit ethernet, increasing these defaults can make a huge difference.
You can adjust the buffer size for incoming and outgoing data
separately.
We recommend the following:
net.inet.tcp.sendspace=8192
net.inet.tcp.recvspace=16384
In extreme cases you may have to turn on the net.inet.tcp.rfc1323
sysctl and increase the buffer size to values greater then 65535.
Generally this will not be required. Use at your own discretion.
net.inet.tcp.rfc1323=1
o net.inet.tcp.always_keepalive
We recommend that you turn on net.inet.tcp.always_keepalive. This
introduces a small amount of additional network bandwidth but
guarantees that dead tcp connections will eventually be recognized and
cleared. Dead tcp connections are a particular problem on systems
accessed by users operating over dialups, because users often
disconnect their modems without properly closing active connections.
net.inet.tcp.always_keepalive=1
o kern.ipc.maxsockets
We recommend you increase both kern.ipc.maxsockets and maxsockbuf.
This increases the number of sockets available and increases the socket
buffer size. On large client servers the default limits are to low and
you will run into problems.
kern.ipc.maxsockets=163840
kern.ipc.maxsockbuf=2097152
o Disable Ctrl-Alt-Del
You can stop users with physical access from using the Ctrl-Alt-Del
combination to reboot your machine. Simple add the following line to
your kernel to disable this:
options SC_DISABLE_REBOOT # disable reboot key sequence
You should be aware that all this will really prevent is users from
rebooting your machine. If you've also marked your console as
insecure it'll stop people from rebooting to change the root
password. That said, if someone has physical access and they want to
do something malicious, you're already in more serious trouble...
o Quota Support
In order to enable Quota support for your filesystems, you will need
to enable this option in your kernel. This can be done with the
following option:
options QUOTA #enable disk quotas
Managing user accounts
======================
o User quotas
By enforcing user quotas on certain filesystems you can limit the
damage that an attacker who wants to consume disk space can do.
Enforce quotas wherever possible to prevent users from filling your
disks. This also gives you the added advantage of being able to
manage your disk usage more effectively.
Quota's can only be used if you have compiled support for them in the
kernel. Once you've done this, you will need to add the following
lines in /etc/rc.conf:
enable_quotas="YES"
check_quotas="YES"
You may then use edquota(8), quotacheck(8), quotaon(8), quotaoff(8)
and repquota(8) to manage quota filesystems.
o Home directory permissions
You should be aware of what it is your users can see. Just as you
dont want users to be able to see what is in root's crontab you may
also not want them to view what is in root's directory. A quick
'chmod 0750 /root' will make sure that they can't see the contents
unless they're in the wheel group.
To that end, you may also want to restrict user home directories by
setting their permissions to 0700 by default. This way users will
have to explicitly change their directory permissions in order for
other users to view their directory contents.
o Hiding processes
You can also limit what processes a user can see when using the ps(1)
command. By default, FreeBSD will allow users to see all processes
on the system, including those that do not belong to them. You may
wish to only allow the user to see processes owned by them. To do
this, you may use the kern.ps_showallprocs sysctl variable. You can
change this while the system is running by issuing the following
command:
sysctl kern.ps_showallprocs=0
To make this change permanent, insert the following line into
/etc/sysctl.conf:
kern.ps_showallprocs=0
The root user is not affected by kern.ps_showallprocs and can always
see all processes.
While this method is effective for limiting what output ps(1) gives,
it will not stop an attacker from traversing /proc to find out what
processes are running. See 'Disabling procfs' for more information.
o Disabling procfs
procfs can be used to gather information on running processes. It is
required for the complete operation of programs such as ps(1), w(1)
and truss(1). Due to the amount of information that procfs may yield
many administrators feel that it is advantageous to disable this
filesystem.
This step is ENTIRELY voluntary. You do not need to disable this if
you do not want to.
To disable procfs, add the NOAUTO option to /etc/fstab for this
filesystem. You may then mount it manually if needed.
o login.conf(5)
FreeBSD allows you to add users to 'login classes', where you can
control (for example) how much CPU/memory each user can use. This
can be very effective in limiting local DoS attacks, whether
intentional or by accident. Since the use of login.conf would most
likely require a document of it's own, you are encouraged to read
the man page - login.conf(5) - for more information.
Stay up to date
===============
o Keep your packages current
When you're running daemons that are worldly visible and accessible
it's important to make sure (and it's common sense) that your
packages are always up to date. If you see a new version of a
package you have installed, then update it via the ports tree to make
sure that you've always got the latest version. It only takes a few
minutes in most cases, but it's worth the effort if you're saving the
machine from being compromised. It'll help to watch lists like
bugtraq for security advisories.
For more information on keeping your packages current, please see the
FreeBSD HandBook:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/
o Keep your OS current
Similarly, it's important to keep FreeBSD itself up to date. Keep
your source tree up to date, and 'make world' if/when new security
patches are made available. It'll help to watch lists like bugtraq
for security advisories.
For more information on keeping your OS current, please see the
FreeBSD HandBook:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/
You should also subscribe to the FreeBSD Security Advisories mailing
list. See:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html
for more information on subscribing.
Be Vigilant
===========
You should always be on the look out for strange behaviour as it is very
often the first sign that something is wrong. You should especially be on
the lookout for:
o A machine that has recently rebooted.
If your machine has rebooted (and you didn't do it) check to see if
anything serious has been changed. You should be especially watchful
of system securelevel's, since these will need to be changed for the
attacker to change things like the kernel, KLM's etc and afford an
opportunity to bypass system immutable and system append-only flags.
o Changes in SUID files.
The daily reports that get run contain information about any changes
in SUID files. Pay important attention to these.
o Changes in critical system files.
Watch out for changes in critical system files, like /kernel. When
you install FreeBSD, you should take MD5 values of these files and
store them somewhere safe (not on the machine). Compare these values
from time to time. If they dont match (for reasons you cant explain)
then investigate. You can use something like
/usr/ports/security/tripwire for this, though there are also other
alternatives.
Other documents about FreeBSD Security
======================================
o The following sites also contain information on securing FreeBSD:
- http://www.freebsd.org/security/
- http://www.freebsd.org/~jkb/howto.html
- http://www.subterrain.net/presentations
Thanks
======
I would like to extend a thanks to Marc Silver for
writting "A basic guide to securing FreeBSD 4.x-STABLE".
|