- Introduction
In todays company, the fast pace of business puts the speedy deployment of
technology resources in the critical path. Staff often work late hours and
overtime to keep with the stride of evolving business needs and requirements.
However, rapid deployment often involves cutting corners. Sometimes, these
corners are in planning. Other times, these corners are design.
The most commonly overlooked and compromised portion of an implementation in
rapid deployment is security. All too often, servers are racked, operating
system loaded, and recommended patch clusters installed within a few hours.
Shortly thereafter vendors arrive with application software, or database
administrators install their respective software and populate their databases.
After the installation of the application software, the server is tested, and
placed into production.
Yet while the systems may have been patched, what's to prevent exposure to newly
developed bugs after the system has been placed into a production status? What
insurance is there that a system will be less exposed when maintenance and
patching is done only during the next scheduled outage window, or when approved
by change management?
This document outlines the creation a of Diamond in the Rough, a server hardened
to network intruders attempting to gain access through service exploits, both
known and unknown. This document is not intended to detail the hardening of a
system for local users, nor is it intended to provide the final say in what
services should and should not be permitted on production systems. In this text
we will examine services that run by default, and discuss both the benefits and
drawbacks of disabling these services. As shutting down every service isn't
always possible, approaching systems with a regimented security paradigm and
justification of business needs will help determine exactly what is needed in
your environment. It is impossible to create one model that applies to all
systems. The purpose of each system varies as widely as people and
personalities. In essence, the goal is to mine the raw stone. You, the jeweler,
polish and cut the stone into a fine piece, deciding how you want it to look.
A Fresh Perspective
While this document applies to both newly installed systems and current
production systems, we'll make use of a fresh installation of Solaris 8. While
many production environments are using earlier releases, most of the topics
discussed within this document apply to all systems. With the release of the
Ultra-Sparc III processors, Solaris 8 will very soon become standard release in
all shops, thus this rationale.
There are as many approaches in installation as there are opinions of what
should be installed. The approach used for educational purposes is a full
install plus OEM support. This tends to be the best selection of methodologies
since it's often easier to remove what is not needed. After installation, the
Recommended Patch Cluster is pulled down and installed.
Now that there is a system in place, let's look at creating an inventory.
Inventory of Needs
Creating an inventory of needs should always be the first step in creating a
security model for your servers. Creating an inventory provides organization,
standardization, and a means of seeing things and their relationships within
your organization. There are several needs that should not be taken for
granted, and several things that should be weighed in risk to benefit terms.
The first step in the approach of this inventory is a raw, objective inventory
from the technical perspective. With the plethora of free tools on the
internet, we'll make use of Fyodors Nmap security scanner. This program allows
for several different types of remote port scans, and is one of the most
versatile in existence currently. A description of nmap can be found in the
tools database of Securityfocus.com, or downloaded from insecure.org.
Nmap is also available for Windows NT from Eeye Digital Security. This tool is
indexed in the Securityfocus.com tools database here, and can be downloaded by
visiting the homepage for NmapNT at Eeye Digital Security.
Creating a raw inventory
Following the download and installation of nmap for our respective platform,
it's time to take inventory. We first make use of system tools to get our
inventory of services. To do this, we need a login to the machine running
Solaris.
netstat
After logging into the machine, the first tool we want to use is netstat.
Output from netstat looks like the following (note: the IPv6 statistics have
been trimmed, as their configuration is controlled by the IPv4 configuration):
$ netstat -a
UDP: IPv4
Local Address Remote Address State
-------------------- -------------------- -------
*.route Idle
*.* Unbound
*.sunrpc Idle
*.* Unbound
*.32771 Idle
*.name Idle
*.biff Idle
*.talk Idle
*.time Idle
*.echo Idle
*.discard Idle
*.daytime Idle
*.chargen Idle
*.* Unbound
*.32772 Idle
*.32773 Idle
*.32774 Idle
*.32775 Idle
*.lockd Idle
*.32776 Idle
*.32777 Idle
*.32778 Idle
*.32779 Idle
*.syslog Idle
*.* Unbound
*.32784 Idle
*.32785 Idle
*.32786 Idle
*.177 Idle
*.161 Idle
*.32790 Idle
*.32791 Idle
*.32789 Idle
*.* Unbound
*.6500 Idle
*.* Unbound
|----- IPv6 udp output snipped -----|
TCP: IPv4
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
-------------------- -------------------- ----- ------ ----- ------ -------
*.* *.* 0 0 24576 0 IDLE
*.sunrpc *.* 0 0 24576 0 LISTEN
*.* *.* 0 0 24576 0 IDLE
*.ftp *.* 0 0 24576 0 LISTEN
*.telnet *.* 0 0 24576 0 LISTEN
*.shell *.* 0 0 24576 0 LISTEN
*.shell *.* 0 0 24576 0 LISTEN
*.login *.* 0 0 24576 0 LISTEN
*.exec *.* 0 0 24576 0 LISTEN
*.exec *.* 0 0 24576 0 LISTEN
*.uucp *.* 0 0 24576 0 LISTEN
*.finger *.* 0 0 24576 0 LISTEN
*.time *.* 0 0 24576 0 LISTEN
*.echo *.* 0 0 24576 0 LISTEN
*.discard *.* 0 0 24576 0 LISTEN
*.daytime *.* 0 0 24576 0 LISTEN
*.chargen *.* 0 0 24576 0 LISTEN
*.32772 *.* 0 0 24576 0 LISTEN
*.32771 *.* 0 0 24576 0 LISTEN
*.lockd *.* 0 0 24576 0 LISTEN
*.32773 *.* 0 0 24576 0 LISTEN
*.32774 *.* 0 0 24576 0 LISTEN
*.fs *.* 0 0 24576 0 LISTEN
*.32775 *.* 0 0 24576 0 LISTEN
*.printer *.* 0 0 24576 0 LISTEN
*.dtspc *.* 0 0 24576 0 LISTEN
*.5987 *.* 0 0 24576 0 LISTEN
*.32776 *.* 0 0 24576 0 LISTEN
*.32777 *.* 0 0 24576 0 LISTEN
*.32778 *.* 0 0 24576 0 LISTEN
*.* *.* 0 0 24576 0 IDLE
thebes.telnet 192.168.1.3.33050 8760 0 24820 0 ESTABLISHED
*.smtp *.* 0 0 24576 0 LISTEN
*.* *.* 0 0 24576 0 IDLE
|----- IPv6 tcp output snipped -----|
The -a argument gives us the state of all sockets on the system. The two key
areas of interest are the Local Address column, and the State column.
The Local Address column tells us the name or port number of the service.
The State column tells us what function the service is performing in its
respective port.
As can be observed from this verbose output, Solaris 8 starts a number of
services by default. This information should be gathered, and a few copies
printed for system management logs (in the case of a production machine) and our
purpose, which is security model design.
rpcinfo
The output of netstat gives plenty of information to work with. One problem
commonly encountered is that all services aren't mapped to names, or do not run
on dedicated ports. This is the case with rpc services, and getting information
about what services are running can prove to be tedious without information
directly from the port mapper.
To make an inventory of rpc services easier, we make use of a tool called
rpcinfo. This tool queries the rpc port mapping daemon to return names to
numbers. This step can, to our fortune, be performed either on the local
machine, or from a remote machine capable of running the rpcinfo program. The
following output is the rpc information retrieved from the host thebes from a
remote host:
$ rpcinfo -p thebes
program vers proto port service
100000 4 tcp 111 rpcbind
100000 3 tcp 111 rpcbind
100000 2 tcp 111 rpcbind
100000 4 udp 111 rpcbind
100000 3 udp 111 rpcbind
100000 2 udp 111 rpcbind
100232 10 udp 32772 sadmind
100011 1 udp 32773 rquotad
100002 2 udp 32775 rusersd
100002 3 udp 32775 rusersd
100021 1 udp 4045 nlockmgr
100024 1 udp 32774 status
100021 2 udp 4045 nlockmgr
100021 3 udp 4045 nlockmgr
100021 4 udp 4045 nlockmgr
100024 1 tcp 32771 status
100002 2 tcp 32772 rusersd
100002 3 tcp 32772 rusersd
100012 1 udp 32776 sprayd
100021 1 tcp 4045 nlockmgr
100008 1 udp 32777 walld
100021 2 tcp 4045 nlockmgr
100021 3 tcp 4045 nlockmgr
100021 4 tcp 4045 nlockmgr
100001 2 udp 32778 rstatd
100001 3 udp 32778 rstatd
100001 4 udp 32778 rstatd
100083 1 tcp 32773
100221 1 tcp 32774
100235 1 tcp 32775
100133 1 udp 32774
100133 1 tcp 32771
100068 2 udp 32779
100068 3 udp 32779
100068 4 udp 32779
100068 5 udp 32779
300598 1 udp 32784
300598 1 tcp 32776
805306368 1 udp 32784
805306368 1 tcp 32776
100249 1 udp 32785
100249 1 tcp 32777
rpcinfo makes an rpc protocol version 2 request to the host, when specified with
the -p flag. Our focus in this information is the program number column, the
proto (or protocol) column, the port number, and finally, the service. The
abstract from this information is the port and program running, what protocol is
being used, and the program number if the program isn't mapped to a name.
nmap
As we've gathered information about the system through both netstat and rpcinfo,
scanning the system remotely may at first seem like overkill. In the case of a
system that has been freshly installed, patched, and not allowed to sit on any
network idle, this thought can be justified.
However, in the case of a production system, or a system that has been left to
sit without adequate hardening, this is in fact an essential step. As is the
case with most systems that are compromised, most intruders make an effort to
cover their tracks and keep access to the system for as long of a period as
possible. Covering ones tracks often involves installing a package of programs
called a rootkit.
The purpose of the rootkit is simple; hide all traces of the intruder and
anything the intruder has done to the system. Most rootkits contain
replacements for the standard system binaries, such as netstat, ls, df, and ps.
More advanced rootkits contain kernel modules which when loaded, can make an
intruder entirely invisible.
To combat this, we remotely scan the system. This is done by using nmap to
discover what's listening on our systems, and recording a log file of the scan.
Scanning both TCP listening ports and UDP listening ports should provide a full
list of listening ports on the system.
Our scan should look like the following:
doomgate# nmap -sS -sU -sR -O -oN thebes thebes
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on thebes.mrhal.com (192.168.1.2):
(The 3049 ports scanned but not shown below are in state: closed)
Port State Service (RPC)
7/tcp open echo
9/tcp open discard
13/tcp open daytime
19/tcp open chargen
21/tcp open ftp
23/tcp open telnet
25/tcp open smtp
37/tcp open time
42/udp open nameserver
79/tcp open finger
111/tcp open sunrpc (rpcbind V2-4)
161/udp open snmp
177/udp open xdmcp
512/tcp open exec
513/tcp open login
514/tcp open shell
515/tcp open printer
517/udp open talk
520/udp open route
540/tcp open uucp
4045/tcp open lockd (nlockmgr V1-4)
6112/tcp open dtspc
7100/tcp open font-service
32771/tcp open sometimes-rpc5
32772/tcp open sometimes-rpc7
32773/tcp open sometimes-rpc9
32774/tcp open sometimes-rpc11
32775/tcp open sometimes-rpc13
32776/tcp open sometimes-rpc15 (dmispd V1)
32777/tcp open sometimes-rpc17 (snmpXdmid V1)
32778/tcp open sometimes-rpc19
32779/udp open sometimes-rpc22 (cmsd V2-5)
32786/udp open sometimes-rpc26
TCP Sequence Prediction: Class=random positive increments
Difficulty=36566 (Worthy challenge)
Remote operating system guess: Sun Solaris 8 early access beta through actual release
Nmap run completed -- 1 IP address (1 host up) scanned in 262 seconds
When passed the sS argument, nmap will conduct a syn scan for open TCP ports. The
sU argument scans for open UDP ports. The sR argument scans specifically for RPC
services on both TCP and UDP ports. With the O argument, nmap conducts packet
analysis in an attempt to guess the operating system of the machine being scanned.
And finally the oN argument records a log file. nmap supports many other options
as well, although for our purposes these will suffice.
The focus here is on the Port column, the State column, and the Service
column. The Port column gives us the type of port number on which the service
is running and the TCP/IP protocol which it uses to communicate. The State
column tells us the status of the port. The Service column maps the port number
to a name.
Conclusion
With the gathering of the information provided by netstat, rpcinfo, and nmap,
we've built ourselves a raw inventory of the services being provided by a
Solaris 8 system. We've discussed how to use the tools, what options used with
the tools are most useful for our purposes, and shown typical output from a
stock install of Solaris 8.
In our next article, we'll look at taking an inventory of business needs, making
decisions based on service necessity, and locking down unnecessary services.
