Home > Articles

  • Print
  • + Share This
Like this article? We recommend

Verifying Domain Hardening

After you complete the hardening process for each domain, reboot the domain and test the configuration by having the domain perform the tasks it should be capable of. At a minimum, make sure that each of the services provided by a hardened domain are running and functioning properly.

Check any additional software installed on the domain to validate that it is functioning properly. Ideally, use existing quality assurance or acceptance testing and scripts to verify that hardened domain is working properly and that the hardening process has not adversely affected any required features.

For our sample configuration, the modifications reduced the TCP and UDP services listening from 93 to 4. Similarly, the registered RPC services went from 149 to 0. These results represents a significant improvement in the security of the Solaris OE on each domain.

After we hardened each domain, installed appropriate versions of Secure Shell, and the rebooted the system, the only network services that are available in our sample configuration are as follows:

# netstat -a
UDP: IPv4
  Local Address     Remote Address   State
---------------------------------------------------
   *.*                  Unbound

TCP: IPv4
Local Address Remote Address Swind Send-Q Rwind Recv-Q   State
---------------------------------------------------------------- 
*.*        *.*     0  0   24576  0  IDLE
*.cvc_hostd    *.*     0  0   24576  0  LISTEN
*.sun-dr      *.*     0  0   24576  0  LISTEN
*.32772      *.*     0  0   24576  0  LISTEN
localhost.smtp   *.*     0  0   49152  0  LISTEN
*.22        *.*     0  0   24576  0  LISTEN

TCP: IPv6
Local Address Remote Address Swind Send-Q Rwind Recv-Q State If 
----------------------------------------------------------------
*.*        *.*     0   0  24576  0  IDLE
*.cvc_hostd    *.*     0   0  24576  0 LISTEN
*.sun-dr      *.*     0   0  24576  0 LISTEN
*.22        *.*     0   0  24576  0 LISTEN

Active UNIX domain sockets
Address Type     Vnode   Conn Local Addr   Remote Addr

After hardening, the daemons left running are as follows:

[sun15-a/] uname -a
SunOS 5.9 Generic_112233-03 sun4u sparc SUNW,Sun-Fire-15000
[sun15-a/] ps -ef
   UID  PID PPID C  STIME TTY   TIME CMD
root   0   0 0  Dec 06 ? 0:02 sched
root   1   0 0  Dec 06 ? 0:00 /etc/init -
root   2   0 0  Dec 06 ? 0:00 pageout
root   3   0 0  Dec 06 ? 7:09 fsflush
root 1158   1 0  Dec 06 ? 0:00 /usr/lib/saf/sac -t 300
root  219   1 0  Dec 06 ? 0:00 /usr/lib/utmpd
root  63   1 0  Dec 06 ? 0:00 devfsadmd
root  11   1 0  Dec 06 ? 0:00 /platform/SUNW,Sun-Fire-15000/lib/cvcd
root  54   1 0  Dec 06 ? 0:00 /usr/lib/sysevent/syseventd
root  60   1 0  Dec 06 ? 0:02 /usr/lib/picl/picld
root  115   1 0  Dec 06 ? 0:00 /usr/platform/SUNW,Sun-Fire-15000/lib/sckmd
root  151   1 0  Dec 06 ? 0:00 /usr/sbin/inetd -s
root  252   1 0  Dec 06 ? 0:00 /usr/lib/efcode/sparcv9/efdaemon
root  187   1 0  Dec 06 ? 0:00 /usr/sbin/syslogd
root  190   1 0  Dec 06 ? 0:00 /usr/sbin/cron
root  238   1 0  Dec 06 ? 0:00 /usr/lib/sendmail -bd -q15m
smmsp 6045   1 0  08:55:45 ? 0:00 /usr/lib/sendmail -Ac -q15m
root 1163   1 0  Dec 06 ? 0:00 /usr/lib/ssh/sshd

We perform an additional check to validate the services available on the domain using nmap, as follows:

# ./nmap -p 1-65535 -sS -sU 10.0.0.200

Using the popular freeware network scanner nmap command, this port scan is performed from a system external to the Sun Fire 12K or 15K frame. For more information about the nmap command, refer to http://www.insecure.org/nmap.

Our scan verified that only the following network services are available from outside the frame of the Sun Fire 15K domain:

Starting nmap 3.27 ( http://www.insecure.org/nmap/ ) at 2003-10-10 19:42 EST)
Interesting ports on sun15-a.blueprints.Sun.COM (10.0.0.200):
Port    State    Service
22/tcp   open    ssh 
442/tcp  filtered  cvc_hostd        
665/tcp  filtered  sun-dr 

Nmap run completed -- 1 IP address (1 host up) scanned in 3 seconds

The scan generated the following syslog error messages:

Sep 20 08:04:26 sun15-a ip: [ID 993989 kern.error] ip_fanout_tcp_listen: Policy Failure for the incoming packet (not secure); Source 129.148.181.252, Destination 010.000.000.020.

Sep 20 08:04:27 sun15-a last message repeated 1 time

Sep 20 08:04:28 sun15-a sshd[357]: [ID 800047 auth.error] error: setsockopt SO_KEEPALIVE: Invalid argument

Sep 20 08:04:29 sun15-a ip: [ID 993989 kern.error] ip_fanout_tcp_listen: Policy Failure for the incoming packet (not secure); Source 129.148.181.252, Destination 010.000.000.020.

Sep 20 08:04:30 sun15-a last message repeated 1 time

These error messages were generated by the IPsec authentication mechanism on the domain when scanned by nmap. Error messages are produced because the nmap IP packets did not conform to the IPsec security policies used to protect those ports. IPsec is used to authenticate all Sun Fire system traffic accepted by Sun Fire daemons and traffic that should traverse the I1 or MAN internal network.

  • + Share This
  • 🔖 Save To Your Account