- Goal
- Background Information
- Securing Sun Fire Domains
- Verifying Domain Hardening
- Related Resources
Like this article? We recommend
Like this article? We recommend
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 *.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 3000b987cb8 stream-ord 3000b989c98 00000000 /var/spool/prngd/pool
After hardening, the daemons left running are as follows:
[sun15-a/] uname -a
SunOS sun15-a 5.8 Generic_108528-11 sun4u sparc SUNW,Sun-Fire-15000
[sun15-a/] ps -ef
UID PID PPID C STIME TTY TIME CMD
root 0 0 0 19:26:36 ? 0:02 sched
root 1 0 0 19:26:36 ? 0:00 /etc/init -
root 2 0 0 19:26:36 ? 0:00 pageout
root 3 0 0 19:26:36 ? 0:00 fsflush
root 394 1 0 19:27:05 ? 0:00 /usr/lib/saf/sac -t 300
root 286 1 0 19:26:55 ? 0:00 /usr/lib/utmpd
root 246 1 0 19:26:53 ? 0:00 /usr/platform/SUNW,Sun-Fire-15000/lib/sckmd
root 11 1 0 19:26:38 ? 0:00 /platform/SUNW,Sun-Fire-15000/lib/cvcd
root 59 1 0 19:26:45 ? 0:00 /usr/lib/sysevent/syseventd
root 61 1 0 19:26:45 ? 0:00 /usr/lib/sysevent/syseventconfd
root 68 1 0 19:26:47 ? 0:00 devfsadmd
root 279 1 0 19:26:55 ? 0:00 /usr/sbin/nscd
root 254 1 0 19:26:53 ? 0:00 /usr/sbin/inetd -s -t
root 262 1 0 19:26:53 ? 0:00 /usr/sbin/syslogd -t
root 265 1 0 19:26:54 ? 0:00 /usr/sbin/cron
root 397 394 0 19:27:05 ? 0:00 /usr/lib/saf/ttymon
root 305 1 0 19:26:56 ? 0:00 /usr/lib/efcode/sparcv9/efdaemon
root 325 1 0 19:26:58 ? 0:00 /opt/OBSDssh/sbin/prngd --cmdfile /etc
/prngd.conf --seedfile /etc/prngd-seed /v
root 378 1 0 19:27:04 ? 0:00 /opt/OBSDssh/sbin/sshd
root 407 1 0 19:27:56 ? 0:00 /usr/lib/sendmail -q15m
root 631 1 0 19:28:34 ? 0:00 /usr/lib/dcs
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, visit 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 V. 2.54BETA22 ( http://www.insecure.org/nmap/ ) Interesting ports on xc4p02-b11.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.001.073.042. 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.001.073.042. 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 traversing the I1 or MAN internal network.