GeodSoft logo   GeodSoft

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

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/ as the configuration file and this has sendmail listening only to the localhost ( 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 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/ in OpenBSD 3.0. If mail is to be accepted from other hosts, in /etc/mail is set up to do that.

To change a 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. is used to create but was used to create /etc/mail/ Add a new line
"FEATURE(`accept_unresolvable_domains')dnl" before
"FEATURE(`msp')dnl" in or before
"FEATURE(`no_default_msa')" in Then do "make" or "make". Note the make filename matches the edited .mc file but ends in .cf. Copy the resulting .cf file to /etc/mail. Also rename to 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/`". The simpler "`cat /var/run/`" 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; 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,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:


The service names are the executable file names that end the lines in inetd.conf. In this example any computer on the class C,, network could make an FTP connection and those on the 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.

transparent spacer

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 (or 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 (or cgi-bin/ 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.


What's New
Email address

Copyright © 2000-2014, George Shaffer. Terms and Conditions of Use.