Hardening OpenBSD Internet Servers
Removing Unneeded Services
Bugs in services are one of the prime methods of gaining access
to remote systems. OpenBSD is better about this than other systems.
Still, any unused but active service represents a potential threat
and should be disabled. Some possibly unneed services and how
to turn them off is discussed on this page. Using TCP Wrapers
to control access to older services, which may be needed
for compatibility, is also discussed.
Portmap, RPC and NFS
The most interesting configuration choice in the default OpenBSD
install is portmap and some of the related RPC services. portmap
is on by default and the comment is that it's "almost always
needed". Though the RPC, yp and NFS services are very widely
used in LAN environments they are among the more insecure
services and widely regarded as having no appropriate role on an
Internet server. All will be disabled. This involves changes in
three /etc files. In /etc/inetd.conf you'll want to comment out the
two lines that begin and end as follows:
rstatd/1-3 . . . /usr/libexec/rpc.rstatd rpc.rstatd
rusersd/1-3 . . . /usr/libexec/rpc.rusersd rpc.rusersd
After these services are disabled and probably most important,
change the portmap=YES to portmap=NO in /etc/rc.conf. Disregard
the "almost always needed" comment. Portmap should not be
running on a machine that is acting as a firewall or public
Internet server such as a web, FTP, or SMTP server. It probably
shouldn't be running on any machine directly connected to the
Internet, i.e. in a DMZ or perimeter network. It surely should
never be exposed to direct Internet access. If portmap must run
on a machine directly connected to the Internet, it's one of the
services that you should be particularly careful about when
configuring your firewall to be sure there is no public access to
this service.
In addition, I chose to comment out the lines from /etc/rc
relating to the rpc daemons which begin after the echo.
I commented each of the three "if" statements and all the
following lines until the matching "fi":
echo -n 'starting rpc daemons:'
# $portmap is imported from /etc/rc.conf;
# if $portmap == YES, the portmapper is started.
#if [ X"${portmap}" = X"YES" ]; then
#if [ -d /var/yp/binding ]; then
#if [ X${nfs_server} = X"YES" -a -s /etc/exports -a \
Functionally this is not necessary as portmap and nfs_server are
set to or changed to NO in /etc/rc.conf. This goes back to
defense in depth. Later, all the related executables, will be
removed from the system (as well as turning off kernel support).
Services should be disabled in the configuration files before the
executables are removed from the system.
In 2.8 and latter, the nfs_client no longer appears in rc or rc.conf.
A comment on nfs_server in rc.conf, says to see sysctl.conf for
client configuration.
Commenting Versus Deleting Configuration Lines
I could have just deleted the lines from /etc/rc but turning them
into comments documents what I've done. NFS is no longer just
one of several services that is set to NO in /etc/rc.conf; it's a
service I really don't want to run on this system. Retaining
these lines but commented out serves as a reminder why the
executables are missing.
Removing the lines entirely would make it harder for anyone to
put them back. However, for years I've been following the advice
in the O'Reilly
Essential
System Administration book and preserve a copy of the
original version of modified system configuration files in a
.dist file. For example /etc/rc was copied or moved to
/etc/rc.dist before any changes were made. This makes it easier
for me or an intruder to put the original settings back but the
security related changes I make to systems are not at the expense
of my understanding what those changes are. Security is about
trade-offs and understanding what I've done and why is as
important as making it hard for an intruder to change those
things.
Having a copy of the original system configuration files can be very
useful when the time comes to upgrage or replace a system with one
using an upgraded OS. Being able to run diff on the old and new
standard files as well as compare your customized configuration to
the original files they were derived from, makes it much easier to
determine the best approach to merging changes you've made and wish
to keep with changes that came with the upgrade OS.
I don't expect these files to be changed without being
automatically informed. In addition to the "daily insecurity"
report provided by default on OpenBSD systems, my systems have
automated remote file change and process tracking as described in
Homegrown Intrusion Detection
that are likely to pick up such changes.
/etc/rc is the primary OpenBSD startup file. This file is largely
designed so that it does not need to be modified but picks up
configuration settings from /etc/rc.conf. Most services can be
turned on or off with simple flag setting changes in rc.conf. I
commented out the NFS, rpc and sendmail sections from /etc/rc.
Otherwise, I've generally left the rc sections intact that are turned
off with simple rc.conf setting changes. Perhaps in the future,
I'll be more aggressive in commenting out sections of /etc/rc for
unneeded services that have been turned of in rc.conf.
Other Services
Prior to OpenBSD 3.0, I always disabled sendmail as a daemon by
changing the sendmail_flags to NO in /etc/rc.conf and also
commenting out the /etc/rc lines that started sendmail. Now there
is a change that requires sendmail to run as a daemon. I find this
odd and annoying but it seems to be fact and apparently a Sendmail
version issue, not an OpenBSD issue. There were serveral
references to this in misc@openbsd.org.
The primary reason for not running sendmail as a daemon is to not
expose a public SMTP port (25). As long as the default install is
used, this will not happen (and this was also true on
default installs in versions prior to 3.0). The default install
starts sendmail using /etc/mail/localhost.cf as the configuration
file and this has sendmail listening only to the localhost
(127.0.0.1.) IP address and not any outside addresses. The command
"ps ax" shows "sendmail: accepting connections (sendmail)" but this
can be ignored. This bothered me for two reasons. The first was the
"connections" which are not remote and second because the line had
so little to do with the command that stated sendmail. I learned
from misc@openbsd.org that any executable can change its ps output
appearance; see "man 3 setproctitle". If the ps output ends with
parentheses around the command name, the program has altered its
command line appearance.
In addition to running as a daemon, the Sendmail included with
OpenBSD 3.0 is much more insistent about doing DNS lookups. If
Sendmail cannot properly resolve the current machine's IP address to
a hostname that matches one provided in the system setup, e-mail
won't be delivered and /var/log/maillog will fill with errors. Todd
C. Miller provided the fix which involves a changes to the sendmail
configuration files. By default this is now /etc/mail/localhost.cf
in OpenBSD 3.0. If mail is to be accepted from other hosts,
submit.cf in /etc/mail is set up to do that.
To change a sendmail.cf file in /etc/mail, cd to
/usr/share/sendmail/cf and edit the .cm file in that directory that
matches the one in /etc/mail. submit.cm is used to create submit.cf
but openbsd-localhost.cm was used to create /etc/mail/localhost.cf.
Add a new line
"FEATURE(`accept_unresolvable_domains')dnl" before
"FEATURE(`msp')dnl" in sumbit.cm or before
"FEATURE(`no_default_msa')" in openbsd-localhost.cm. Then do "make
submit.cf" or "make openbsd-localhost.cf". Note the make filename
matches the edited .mc file but ends in .cf. Copy the resulting .cf
file to /etc/mail. Also rename openbsd-localhost.cf to localhost.cf
when copying.
The former change may be sufficient if a DNS server is available but
the local IP address does not reslove properly. If no DNS server is
available, such as on a bridging firewall, an additional change
must be made. /etc/mail/service.switch must be created and contain
a single line consisting of "hosts files". With an updated
configuration in /etc/mail, restart the system if Sendmail is not
running or restart sendmail if it is running. You can use ps to get
sendmail's process id and "kill -HUP pid" or "kill -HUP `sed
1q /var/run/sendmail.pid`". The simpler "`cat
/var/run/sendmail.pid`" will produce several error messages because
sendmail's .pid file contains the process ID and the command line
that started sendmail.
On web servers, httpd_flags is changed from NO to YES in
/etc/rc.conf. If you are using OpenBSD for any kind of public
server, you will need to find the appropriate settings in rc.conf
and enable them.
Ntpd was the only service that I consistently added to all my
computers up to about 2005. By then most computers were coming
with time synchronization software installed. Today nearly every
computer sold has time syncrhonization software installed and
enabled by default. Inaccurate computer times are unusual
today on fairly new computers.
/etc/inetd.conf controls the services that inetd starts when it
gets a request for services that do not run full time but only
when a request is received. Besides the two RPC related services
discussed above, in 2.7 the time, daytime, finger, ident, ntalk
and comsat services were disabled by commenting out the six lines
that began with these words. Time and daytime were disabled as
simply not necessary; ntpd is the only time related service that
I believe is needed.
Starting with OpenBSD 2.8, finger and ntalk have been turned off
by default. Finger provides information useful to crackers. There
are "safe" versions of finger and there are simple ways to have
finger requests give out constant company contact information.
These all seem more trouble than they are worth as the legitimate
uses of finger have been supplanted by the web. Ntalk is a
little used and insecure chat type protocol.
Ident is another service that gives out information that is
useful to crackers. Ident is used in conjunction with some mail
services so if you are running a mail server you may want to
understand this service better before making a decision on
keeping it or not. If the machine receives mail and has
interactive users, comsat should be left at the default.
Comsat is not needed if no mail server is running or the mail
server is being used purely as a relay server and there are no
interactive users receiving mail on the system.
I've now replaced telnet and FTP with SSH on most systems. At
least on my firewalls, I've been able to disable all the services
traditionally started by inetd. As a result, while I've left
/etc/inetd.conf in place (all lines are now comments), I've
updated /etc/rc.conf so the inetd line is now "inetd=NO #
almost always needed" and inetd doesn't run. The result is that
only two network services are left running: sshd and ntpd. sshd
allows remote administrative control and ntpd ensures correct
computer time so log file entries will be accurate; both run only
on internal non routable IP address. Most of OpenBSD's sshd's
options are correct but I think one default, "PermitRootLogin yes"
should always be changed to no. I don't understand this default;
most other systems I've seen have this defaulted to the more
secure no. Additionally, on machines with multiple network
cards, the ListenAddress option would be appropriate where ssh
connections should not be allowed on all network interfaces. The
specifics are discussed on my
sshd servers page. I don't
think it is necessary to use client keys with ssh but if you wish
to use them and find what goes where confusing, I think my page
on ssh clients has clear
step by step instructions.
Network Scanners
A useful tool for system and network administrators is
Nmap, a Free security Scanner.
Nmap may be available as an OpenBSD package. If
you use nmap on your own network, it can quickly reveal potential
vulnerabilities. If you are the system or network administrator
you should understand the function of every port reported as open
by nmap or similar tools. If you don't, you should investigate
and learn what each open port is for. I don't believe a person with
a title like system administrator of a network server deserves that
title unless he or she can describe the function of every service
that computer make available to the external world.
You should close every open port not needed for the machine to
perform it's intended functions, i.e. disable the service that is
listening on that port. Alternatively if the service serves some
local use only, it might be configured not to "listen" on an external
interface. It might listen on 127.0.0.1; if it's a TCP server,
it might be wrapped in TCP Wrappers and have no entries in the
hosts allow file.
If you are planning to use a firewall on the computer in question,
you could leave all the services at their default settings. Typically
a firewall will be configured to block all incoming packets that are
not recognized as a response to something the local computer previously
sent out. Then specific ports would be opend to allow the services the
machine was created for. If it's a web server, normally port 80 would
need to be open to incoming traffic. If it's a mail server and uses
SMTP normally port 25 needs to be open. Secure mail connections and
other mail protocols use different ports. If employees are too log in
remotely, in 2013 that would normally be with SSH on port 22. The easy
way is to allow all incoming connections and count on user passwords
or cryptographic key pairs which are more convenient for the user, and
arguably slightly more secure. Web servers can not know where their next
visitor may come from, and often allow connections from all IP addresses.
With SSH it's very easy to identify the pool users as each must have a
valid user account on the machine they are to log into.
Often this would include a block of IP
addresses for a nearby network or in some setups, other computers on
the same network segment. There might be several remote locations that
required other blocks of IP addresses. Users working from home should
be allowed a single IP address which would need to be changed when their
DNS setup changed. GUIs and other software can be tunnelled securely
through SSH.
Besides an external port scanner, netstat can be used to gather port
information. With an -a it gathers all network connections and open
ports. With an -l it lists listening (open) ports. This is an internal view
and may look like your computer is wide open. If, as already discussed
a local firewall will be in place, the large output from netstat can be
ignored. Only ports deliberately opened should be exposed. An external
port scanner gives a much better picture of what is visible and accessible.
Nmap is also used by many crackers as a first step in mapping out
networks for vulnerabilities that may be exploited. You need to be
very careful in the use of this tool and similar tools. Most ISP's
prohibit the use of tools like this; unauthorized probing of networks
belonging to others could get your account canceled. Bill Machrone
wrote a column in the October 19, 2000 issue of PC Magazine titled "TOS
Your Cookies on Terms of Service" agreements formerly at
http://www.zdnet.com/zdnn/stories/comment/0,5859,2641793,00.html but
now apparently off-line. Unauthorized use in a business environment
could get you fired. Be sure you have the appropriate
authority before scanning any computer, even one you think you are
responsible for.
Some users of port scanners have a false sense of security because
most uses are not reported. Many, probably the large majority of
networks connected to the Internet do not identify these scans but
some do. These probes are in the logs of most scanned computers; if
they are recognized depends on the tools available and the dedication
of the staff responsible for analyzing the logs.
Script analysis of firewall logs can quickly reveal
port scans and network intrusion detection systems are
specifically designed to identify these and other potential
intruder activity. My tiny LAN averages several scans a day. I
don't have the time to follow up on most of these but I do know
about them. Generally those who are aware of the scans are also
those who are best protected from them. Persistent or intense
scans of properly defended networks increase the chances a
documented report to the originating ISP, but even a single
limited scan of the wrong network could result in such a report.
Telnet, FTP and TCP Wrappers
Perhaps ironically, depending on the server, I've enabled
services in /etc/inetd.conf that are turned off in OpenBSD by
default and that are widely regarded as insecure. Specifically
ftpd servers have been enabled on some systems for compatibility
with Windows systems. I also used to use telnet but have been
able to replace that with SSH. Use of telnet or non anonymous FTP
should be limited exclusively to systems that don't fully support
SSH and only behind a firewall. Telnet and ftp are not
sufficiently secure to allow incoming logins across the Internet
to real user accounts. They should be replaced by SSH to the
extent possible. TCP Wrappers allows control of which sytems can
access these services but can't hide the plaintext passwords used
by these services.
The telnetd and ftpd servers were not simply turned
on by uncommenting the lines in /etc/inetd.conf (the "standard"
way of enabling these services). The changes follow:
#ftp stream tcp nowait root /usr/libexec/ftpd ftpd -US
ftp stream tcp nowait root /usr/libexec/tcpd ftpd -US
#telnet stream tcp nowait root /usr/libexec/telnetd telnetd -k
telnet stream tcp nowait root /usr/libexec/tcpd telnetd -kh
Notice that the servers in /usr/libexec have both been replaced by
tcpd. This is the TCP Wrappers program. It allows
controls to be wrapped around standard TCP services to provide
security that is otherwise not available. Primarily it can be
used to control source IP addresses from which connections are
accepted.
Also note the addition of the "h" at the end of the telnet line.
This causes telnetd to surpress the pre login banner which
displays the operating system, architecture, hostname and
terminal before displaying the "login:" prompt. See below
for more on login banners.
TCP Wrappers controls are implemented in the /etc/hosts.allow and
/etc/hosts.deny files. The simplest and safest way to implement
it is to have a one line hosts.deny file that consists solely of
ALL: ALL. This blocks connections to all services from all
sources. Specific connections that are to be allowed are then
put into the hosts.allow file. The SSH server, sshd, also uses
the hosts allow and deny files even though it is not started by
inetd, so if you set up TCP Wrappers as discussed here, allowed
ssh connections
must be enabled in hosts.allow, or SSH won't work.
A simple sample file might consist of:
ftpd: 192.168.27.0/255.255.255.0
telnetd: 192.168.27.13/255.255.255.255
telnetd: 192.168.27.22/255.255.255.255
sshd: 10.20.30.0/255.255.255.0
The service names are the executable file names that end the
lines in inetd.conf. In this example any computer on the class
C, 192.168.27.0, network could make an FTP connection and those
on the 10.20.30.0 network an SSH connection to the computer using TCP
wrappers and SSH. Only two specific hosts are allowed to make a
telnet connection to this machine. Access to all other services,
that are protected by tcpd in inetd.conf are denied. This is not
a realistic example because of the presence of both sshd and
telnetd but the relationship between SSH and the hosts.allow and
hosts.deny files is very poorly documnetd and can cause much
confusion if you happen to use both SSH and TCP Wrappers. Use
'man 5 hosts_access' or 'man hosts.allow' to view the
documentation on the format of and options in hosts.allow and
hosts.deny.
Top of Page -
Site Map
Copyright © 2000 - 2014 by George Shaffer. This material may be
distributed only subject to the terms and conditions set forth in
http://GeodSoft.com/terms.htm
(or http://GeodSoft.com/cgi-bin/terms.pl).
These terms are subject to change. Distribution is subject to
the current terms, or at the choice of the distributor, those
in an earlier, digitally signed electronic copy of
http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the
time of the distribution. Distribution of substantively modified
versions of GeodSoft content is prohibited without the explicit written
permission of George Shaffer. Distribution of the work or derivatives
of the work, in whole or in part, for commercial purposes is prohibited
unless prior written permission is obtained from George Shaffer.
Distribution in accordance with these terms, for unrestricted and
uncompensated public access, non profit, or internal company use is
allowed.
|