From: Subject: Solaris Network Hardening Date: Wed, 14 Nov 2001 08:36:43 +0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_001C_01C16CE7.7D23D4F0"; type="multipart/alternative" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C16CE7.7D23D4F0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: http://ist.uwaterloo.ca/ISTlogo.gif R0lGODlhYABfALMAAP///wAAAJ2dnYAGHPDm6F1dXSwsLNK3vKJJWkZGRv7+/saQmrNreIKCgpIq PeHM0CH5BAEAAAAALAAAAABgAF8AAAT+EMhJq7046827/2AojmRpnmiqrmzrvuZxbAoB3yAzT8ww MJPHAOHY4Y4SI2AxUCQHB6ZzCR0ikUKGDXCASoSL3rQHcAAzhMP2SmIOtorfhFnkaQcLjcMhZ48I CE0TCGcbBGsXe10Pfh0EOhMEPkonj10OD4iNFwd7A4wSCwdTKZKieJsbCAt7DqQuXT6gCpSpAAoO C4SaLWmgAEK/jWu4XpsMDo+8OIF5Eq9sTg5EdVcKrM22EmY+DNDMA8nI32wPZsJHgEXhBOTat3vL KQqBMgju2g9drDfF6O8UOmHDh4LAAoLvEARyoaAQQA7XaqFghfDhhUcM/oWQhMrih2v+PpyZIMDH oUcNgfZU9HBA40kLZm693KQPxQMG3jIcaMCTp4cHDwQIHSpgCwGiSJMOlXgCFx8EGQQEmBrAgKEC BqhqnbpD6tavXwtguKlFhBBaDqJuzaCgAditOw68nRtArIU4Q6BuDBcTg9epVi8oSECXatfCYO1W MCVFxIFV+P5WxVAAMdcklrcqrpAr3EoRAgyINpDgguTCcUUnUJ1V62rSohtgeLTA5QVR8kQQaE21 AFMNbqkGhkHkUwq5WmWPCA4YRycfuU4wn/rZwvThH/SJ3BDl8W8JAlav3iyhcu8S10HgDQdLK/by WsmDSA9ClLncJCS/B2B+qvwP9H3+cAAyxqygn3Xu4QeceyHQYdwGQoTEwYEVnNZAdRQECMIDCnHQ BU7fgcfgYl8ZUFQIGjriQx8aCKTGhCNW0N9WBhRwIgcpdoBbBz1MAqNwF/E2l4345OgCUAoCQKEF u2XWwDJGarMkk9PRZQAvUWpwyAtTXhQeYldWkGUG65g0G5IexmjITqu9pdwEXXJAEgNEbMDHitv5 peYHRwlJXYZ7yllSWijhtEBtPzZHwmBbCQAokCHgVBMLcYJAgGaPKupRpSDMWNoEY27CKYBqhtrI qB5MaaofqHag4ao2VdQqB55mOlkID2D4WJ6cbJUkW1u9CQCsc5hR3T4IKRBsCTP+BqDErIv15cEh tlFAWHzV3nWAnwG8QuwzW76A3FfKKcAabOi6KWagDzXr3zOZJbgupC8xiikAl8Z72byaspGkAs3a pWy8Bmi06iMotERIBwdcW5cE+SKWgADurLqPCXixku0EtAiwgwJKIZUrhEjJqU+BIxSxh5kzwbTi gyMUg0nLNGgn7QgMHEQzWxTgEmJ29+xMwS5BqBCLzjs35AMCvwoYThZCd/EIOytcQ09HNEuyBxMb R4r1zo/lnEwvOxiURyYPDbgGMk2TEMgPN6eCDB9tV4JHLHWrAAcUwfg7Dd1yuyJBOGz7MXUt7Rxx Mb5EN0LLBcgskLfXk18x9Q94lWNACyhaC91D4aV44sxjmePQOQtMAFCn0KEUiI1tq0MchRVUsMLy TBR98UNjSzROhC42aN2DDdeYUbotHwZiw4c4SfB5R9OYwnoH9CjifBNrDwBAH2KsMv20I+M7RB9S 9PUA0t//IUMkB6Gd/vvwxy///PTXz0EEADs= ------=_NextPart_000_001C_01C16CE7.7D23D4F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001F_01C16CE7.7D23D4F0" ------=_NextPart_001_001F_01C16CE7.7D23D4F0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Content-Location: http://ist.uwaterloo.ca/security/howto/2000-09-19/ Solaris Network Hardening <= NOFRAMES>=0A= =0A= Oops! Your browser doesn't support frames. Try starting at the=0A= Table of Contents.=0A= =0A= ------=_NextPart_001_001F_01C16CE7.7D23D4F0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Content-Location: http://ist.uwaterloo.ca/security/howto/2000-09-19/content.html Contents: Solaris Network Hardening
3D[IST]=20=20


Synopsis

Baseline
Issues
Hardening Kit

References
Credits

------=_NextPart_001_001F_01C16CE7.7D23D4F0-- ------=_NextPart_000_001C_01C16CE7.7D23D4F0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Content-Location: http://ist.uwaterloo.ca/security/howto/2000-09-19/baseline.html Solaris Network Hardening

Security Review: Solaris Network Hardening =
Information=20 Systems and Technology
University of Waterloo

Baseline -- What's there?

Before going anywhere you need to know what's on the system = and=20 better yet -- how to find that out. There are three tools we find = invaluable=20 -- netstat(1m) and rpcinfo(1m) as provided by the vendor = and=20 lsof(8) a public domain add on. All can be used to identify = network=20 services that your system offers to clients on the network. Services = that=20 might be exploited.=20

The netstat(1m) command

To determine the services = that your=20 system offers try this command:=20 
[2:20pm wally] netstat -a

UDP
   Local Address         Remote Address     State
-------------------- -------------------- -------
      *.sunrpc                              Idle
      *.*                                   Unbound
      *.32771                               Idle
      *.name                                Idle
 ...etc.
TCP
   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q  =
State
-------------------- -------------------- ----- ------ ----- ------ =
-------
      *.*                  *.*                0      0     0      0 IDLE
      *.sunrpc             *.*                0      0     0      0 =
LISTEN
      *.*                  *.*                0      0     0      0 IDLE
      *.ftp                *.*                0      0     0      0 =
LISTEN
 ...etc.
Active UNIX domain sockets
Address  Type          Vnode     Conn  Local Addr      Remote Addr
6169a3d0 stream-ord 6176fa40        0 /tmp/.X11-unix/X0               =20
 ...etc.
On a typical Solaris system you'll find = there's=20 lots going on. The display above is broken into three parts --=20 UDP services (User Datagram Protocol -- that's a = messaging=20 service built on IP), TCP services = (Transmission=20 Control Protocol -- that's a connection orientated service built on=20 IP) and Unix domain sockets. UDP and=20 TCP services are internet services available to the = world at=20 large. Unix Domain sockets are local "named pipe" services available = only to=20 processes on the same system. You should be concerned about all three = services=20 types (this is complicated further on Solaris8 which implements=20 IPv4 and the newer IPv6 -- you'll see=20 UDP and TCP on both).=20
Network services are either TCP or=20 UDP based. In the "netstat -a" output look for = TCP services in a "LISTEN" state and=20 UDP services in an "Idle" state to determine the = services=20 that your system offers to the world.

In the example above it should be apparent that there's a=20 TCP service with the "ftp" name (also port 21) = in a=20 "LISTEN" state -- it's waiting for a client to connect = and the=20 two processes will then start talking to one another. There's also a=20 UDP service at the "name" service (also port 42) = in an=20 "Idle" state -- it's waiting for clients to send it messages (to which = it will=20 respond). The mapping of service names -- like ftp, = name,=20 telnet, smtp, etc. -- to their corresponding number is = tabled in=20 the file /etc/services. The Internet Assigned Numbers Authority = (IANA)=20 manages the official names for various IP ports but = it's not=20 unusual for Unix systems to have incomplete data in = /etc/services.=20

The command "netstat -a" shows all active network = connections and=20 attempts to map IP numbers to host names and port = numbers to=20 service names -- where it cannot do the number to name mapping it will = show=20 the number instead. The command "netstat -an" will display = network=20 connections without any attempt to map numbers to names. You should = become=20 familiar with this tool; start by reading the manual page.=20

You may already know that it's the sendmail(1m) daemon = that's=20 providing the smtp service (on port 25); or you should know = that it's=20 the Apache web server you installed some time ago that's providing the = http service (on port 80). But in general, determining the = process that=20 stands behind a port (alternatively, the process that provides a = service) can=20 be difficult. You can rely on documents like this, or you can import a = tool to=20 help you. I am not aware of any vendor provided tools on Solaris that = will do=20 this for you.=20

The lsof(8) command

Lsof(8) is an excellent = tool (but=20 it's not part of the Solaris distribution) that you can use to = determine the=20 processes that provide network services. At this site you'll find=20 lsof(8) on most Unix systems. Here's how you can use it to find = the=20 network services you offer:=20 
[3:37pm wally] su
[3:37pm wally]# lsof -i | egrep 'COMMAND|LISTEN|Idle'
COMMAND     PID    USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
rpcbind     104    root    3u  inet 0xf5e9eec0      0t0  UDP *:sunrpc =
(Idle)
rpcbind     104    root    5u  inet 0xf5970138      0t0  UDP *:32771 =
(Idle)
rpcbind     104    root    6u  inet 0xf5970038      0t0  TCP *:sunrpc =
(LISTEN)
inetd       123    root    4u  inet 0xf59702b8      0t0  TCP *:ftp =
(LISTEN)
inetd       123    root    5u  inet 0xf59701b8      0t0  TCP *:shell =
(LISTEN)
inetd       123    root    6u  inet 0xf5970538      0t0  TCP *:dtspc =
(LISTEN)
inetd       123    root    7u  inet 0xf5e9e640      0t0  TCP *:ident =
(LISTEN)
syslogd     128    root    4u  inet 0xf5e9e7c0      0t0  UDP *:syslog =
(Idle)
dtlogin     203    root    6u  inet 0xf601dc48      0t0  UDP *:177 =
(Idle)
dtlogin     203    root    7u  inet 0xf601da48      0t0  TCP *:32771 =
(LISTEN)
sshd        270    root    3u  inet 0xf601d648      0t0  TCP *:22 =
(LISTEN)
Xsun       2357 reggers    7u  inet 0xf601da48      0t0  TCP *:32771 =
(LISTEN)
Xsun       2357 reggers    9u  inet 0xf62027d0      0t0  TCP *:6000 =
(LISTEN)
dtlogin    2358    root    7u  inet 0xf601da48      0t0  TCP *:32771 =
(LISTEN)
   ...etc.
Note that browsing all network connections = with=20 lsof(8) will usually require root user privileges. = Typically=20 lsof(8) is installed with only enough privileges to view = network=20 connections attached to your processes -- you aren't allowed to peek = at other=20 processes unless you are the root user.=20

You can use lsof(8) to determine the services you offer to = the=20 network -- look for TCP sockets in a = LISTEN=20 state and UDP sockets in an "Idle" state -- as well as = the=20 program that provides the service. The listing above even shows = the=20 process id -- the sshd program is running as process id 270 and = that's=20 the process offering a TCP service at port 22. Now we = have the=20 information we need:=20 

[4:16pm wally] ps -fp 270
     UID   PID  PPID  C    STIME TTY      TIME CMD
    root   270     1  0   Jun 19 ?        4:31 =
/software/ssh-1/servers/sshd
[4:17pm wally] man sshd

SSHD(8)                        SSH                        SSHD(8)

NAME
     sshd - secure shell daemon

SYNOPSIS
     sshd [-b bits] [-d ] [-f config_file] [-g login_grace_time]
     [-h host_key_file] [-i ] [-k key_gen_time] [-p port] [-q ]
     [-V version]
   ...etc.
Once you've determined the program behind the = service it's usually not very hard to figure out what's going on -- = read the=20 manual page for the program! With a little investigation we've found = out that=20 we offer a TCP service on port 22 with the sshd = program=20 -- the secure shell daemon that peers with the ssh(1) and = scp(1)=20 commands. That port is not listed in my /etc/services (it = should be,=20 the IANA has named it the "ssh" service). = Ssh=20 services are an important security enhanced replacement for a great = wack of=20 older less secure services -- telnet, rlogin, rsh and ftp!=20

Services provided by inetd(1m)

There's a couple of = wrinkles=20 you need to be aware of. First, note in the lsof(8) example = that it's=20 the inetd process that's listening for the ftp service = -- that's=20 a bit of a surprise, you'd think it would be the "ftp" daemon. The=20 inetd(1m) manual page will tell you how the inetd = process is=20 driven by a configuration file that lists services it should listen = for and=20 applications it should run when a connection is made. The application=20 inetd invokes when a connection is established to the = ftp=20 service is in fact the "ftp" daemon:=20 
[3:02pm wally] grep ftp /etc/inetd.conf
ftp     stream  tcp     nowait  root    /usr/sbin/in.ftpd       in.ftpd
Note in the lsof(8) example that other = processes stand on their own -- they're not run configured by = inetd. In=20 the example you'll see rpcbind, dtlogin and sshd=20 processes. Those are started at system boot time. You won't find them = listed=20 in the /etc/inetd.conf configuration file.=20

The second wrinkle you need to know about is Transport Layer = Interface=20 (TLI) services. These are better known (at least to me) = as=20 Remote Procedure Call (RPC) services. = RPC=20 services are typically layered on top of TCP or=20 UDP services. You will discover that inetd(1m) = is=20 usually configured to provide TCP, UDP = and=20 RPC services. Here's an example RPC = service=20 offered by inetd(1m):=20 

[3:30pm wally] grep 100221 =
/etc/inetd.conf
100221/1        tli     rpc/tcp wait root /usr/openwin/bin/kcms_server  =
kcms_server
That nasty thing about RPC = services=20 is their RPC program number (eg. 100221 in the=20 kcms_server example) have nothing to do with the=20 TCP/UDP port number where the service is found! = Many=20 RPC services are dynamically bound to whatever ports = are=20 available when the service is started. Services are registered with = the=20 rpcbind(1m) daemon and that daemon, if present, should always = be found=20 at TCP and UDP ports 111. Client=20 RPC applications have to contact the rpcbind(1m) = daemon=20 to locate the service they're after. Server RPC = applications=20 have to tell the rpcbind(1m) daemon where they are. The=20 rpcbind(1m) daemon is always found at port 111 so clients and = servers=20 can find it!=20

If netstat(1m) and lsof(8) show strange numbers that = don't=20 obviously map to services in /etc/inetd.conf you should start = looking=20 for a corresponding RPC service. Note that = lsof(8) may=20 show some RPC services provided by applications other = than=20 inetd -- the sunrpc service is provided by the = rpcbind=20 daemon which is started at boot time. Those are easy to figure out, = the ones=20 provided by inetd are a little harder.=20

The rpcinfo(1m) command

There's a adminstrator's tool = to=20 table all RPC services -- see rpcinfo(1m). The = tool=20 contacts the rpcbind(1m) daemon and gets a "directory" of=20 RPC services that have been registered there. In the = example=20 which follows I use it determine where all the RPC = services are=20 -- you'll find program 100221 (version 1) is at TCP = port 35651.=20 The RPC program numbered "100221" is implemented by the = kcms_server program found in /usr/openwin/bin and that = program=20 is provided to the client by inetd at TCP port = 35651.=20 
[3:26pm wally] rpcinfo -p
   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
    ...etc.
    100005    1   udp  32975  mountd
    100005    2   udp  32975  mountd
    100005    3   udp  32975  mountd
    100005    1   tcp  32787  mountd
    100005    2   tcp  32787  mountd
    100005    3   tcp  32787  mountd
    ...etc.
    100232   10   udp  65024  sadmind
    100002    2   udp  65026  rusersd
    100002    3   udp  65026  rusersd
    100002    2   tcp  35649  rusersd
    100002    3   tcp  35649  rusersd
    ...etc.
    100221    1   tcp  35651
    100235    1   tcp  35652
    100068    2   udp  65030
    100068    3   udp  65030
    ...etc.
RPC services will often have = well=20 known names (which are distinct from TCP and = UDP=20 service names) and these are tabled in /etc/rpc. In the=20 rpcinfo(1m) example above the RPC program = numbered=20 100005 is shown as the service called mountd -- the = /etc/rpc=20 table is used to map the RPC program numbers to=20 RPC service names. You will find several = RPC=20 services started from /etc/inetd.conf. They're tabled sometimes = by=20 number (eg. 100232) and sometimes by name (eg. rquotad). For example, = in my=20 inetd.conf I find:=20 
100232/10       tli     rpc/udp wait root =
/usr/sbin/sadmind     sadmind
rquotad/1       tli     rpc/datagram_v  wait root /usr/lib/nfs/rquotad  =
rquotad
Note that the RPC program = numbers=20 like 100005 doesn't have anything to do with the UDP = port=20 number 32975 and TCP port number 32787 that you found = in the=20 netstat(1m) and lsof(8) output -- you need to look at = the=20 RPC tables to discover that mapping.=20
It's important to know about RPC services. = The=20 netstat(1m) and lsof(8) tools will often show strange = service=20 numbers with no obvious mention of the number in = /etc/inetd.conf or=20 /etc/services. If you find one of these use = rpcinfo(1m) to=20 translate TCP/UPD port numbers to RPC = service=20 numbers/names which you probably will find in = /etc/inetd.conf.=20

Summary: Baseline -- What's there?

The first step in hardening the network connections on a Solaris = system (or=20 any other computer system for that matter) is to find out what = services you=20 offer and what they do. Then you can make a informed risk analysis and = impact=20 assessment. The above should have given you the tools to get started = so you=20 can determine what's there. Let's summarize:=20

  1. Use "netstat -a" to show all your network connections. = Look for=20 TCP connections in a "LISTEN" state = and=20 UDP connections in an "Idle" state -- those are the = network=20 services you offer to the Internet.=20

  2. Many of the services you discover will be found in=20 /etc/inetd.conf and are offered indirectly by = inetd(1m) -- for=20 all but RPC services it's easy to find the program = that=20 provides the service.=20

  3. Many services you discover are started at boot time and will not = be=20 found in /etc/inetd.conf. If the corresponding program that = provides=20 the service is not obvious to you use lsof(8) to find the = program=20 that offers the service.=20

  4. RPC services are found at strange port numbers = not listed=20 in /etc/inetd.conf or in /etc/services. Use the=20 rpcinfo(1m) command to determine the RPC = service=20 name/number that's registered at that port. Then you should be able = to find=20 the service by name or number in /etc/inetd.conf.=20

  5. RPC services not found in /etc/inetd.conf = will=20 typically correspond to services started at boot time. If the = corresponding=20 program that provides the service is not obvious to you use = lsof(8)=20 to find the program that offers the service.
The strategy = given here=20 should work on virtually any Unix system. The recommendations which = follow are=20 specific to Solaris but might be generalized to other Unix systems as = well.=20
Reg Quinton, Information Systems and Technology =
2000/09/19-2001/03/13=20
------=_NextPart_000_001C_01C16CE7.7D23D4F0--