Solaris Server Hardening Security Tips I

1-

Hardening The Operating Systems:

By default, Solaris includes many useful services. However, most of these services are not required for a firewalled gateway and pose potential security risks. The /etc/inetd.conf file specifies services the /usr/sbin/inetd daemon will activate. None of the services in this file is essential to the running for FireWall-1.

• Disable all unnecessary network services and daemons to harden the Solaris operating system.
• Comment all unneeded service entries in the /etc/inetd.conf file (almost everything)
• Disable Netstat, Systat, TFTP, and Finger Services
• Disable the rshd, rlogind, and rexecd daemons
• Disable NFS by renaming /etc/rc3.d/S15nfs to /etc/rc3.d/s15nfs
• Kill and disable dtlogin by running /etc/init.d/dtlogin stop, then rename /etc/rc2.d/S99dtlogin to /etc/rc2.d/s99dtlogin
• Shutdown Router Discovery (IRDP) by renaming /usr/sbin/in.rdisc to in.rdisc_old
• Create the text file /etc/default.router with the IP address of default gateway. This will stop RIP broadcasts.
• Kill -HUP the inetd daemon

Confirm the services are commented out, by using the following command:

#grep -v "^#" /etc/inetd.conf

In the /etc/rc2.d and /etc/rc3.d directories, there are scripts launched at boot by the init process. Several of these are not needed. To prevent a script from starting during boot, replace the uppercase "S" with a lowercase "s"

Scripts that my be disabled in the /etc/rc2.d directory

S73nfs.client - used for NFS mounting a system. A firewall should never mount another file system.
S74autofs - used for automounting, a firewall should never mount another file system.
S80lp - used for printing, your firewall should never need to print.
S88sendmail - listens for incoming email. Your system can still send mail (such as alerts) with this disabled.
S71rpc - portmapper daemon, a highly insecure service (required if you are running CDE).
S99dtlogin - CDE daemon, starts CDE by default

Scripts that my be disabled in the /etc/rc3.d directory

S15nfs.server - used to share file systems, a bad idea for firewalls.
S76snmpdx - snmp daemon

Example: Disabling scripts in the /etc/rc2.d directory

#cd /etc/rc2.d
#mv S37nfs.client s37nfs.client
#mv S74autofs s74autofs
#mv S801p s801p
#mv S88sendmail s88sendmail
#mv S71rprc s71rprc
#mv S99dtlogin s99dtlogin
#mv S15nfs.server s15nfs.server

Hardening The Operating Systems (Continued):

Running any GUI (CDE or OpenWindows) is not a good idea. You can disable CDE, the default GUI in Solaris 2.6, with the S99dtlogin startup script (replace the capital S with a small s). To get an idea of how many ports and services CDE requires, type the following command when it is running.

ps -aef | wc - l

Once you are done with the installation and have turned off S99dtlogin and S71rpc (required to run CDE), type the command again and compare how the numbers of services have decreased. The fewer services running, the smaller target the box is. For those of you who installed the Core installation, this is not an issue, as the GUI is not installed.

Disabling Syslog Server:

It is not a good idea for a Firewall to be a syslog server. Logs should be redirected to another syslog server. In Solaris 8, edit script/etc/rc2.d/S74syslog to start syslogd with the "-t" option. This will cause local listening service to be disabled for the syslog daemon and prevent listening on port 514, allowing local logging only.

Testing the Boot Files:

Test all boot files changes by rebooting, using dmesg or examining/var/adm/messages, and checking for extraneous processes in ps -elfoutput.

Disabling IP Forwarding in the Kernel:

IP forwarding is enabled during the init process, in /etc/rc2.d/S69inet. If the system detects more then 2 interfaces (including the loopback) ip forwarding will be enabled by default. Your system is now a gateway.

It is recommended that IP Forwarding be disabled in the kernel. In this way, IP Forwarding will be never be enabled unless VPN-1/FireWall-1 is working, no matter which of the above options you have chosen.

This section specifies how to enable and disable IP Forwarding on the following platforms: Solaris 2.x

Solaris 2.x (source routed packets)

To turn off IP Forwarding and source routed packets, edit/etc/rc2.d/S69inet and change:
to:

ndd -set /dev/ip ip_forwarding 1
ndd -set /dev/ip ip_forwarding 0
ndd -set /dev/ip ip_forward_src_routed 0

Solaris 2.5 or Later

You can have a system with 2 or more interfaces and not forward packets if you want. This is done one of two ways. First, by touching the file /etc/notrouter. During the init process, /etc/rc2.d/S69inet will look for this file. If it finds it, it turns off ip forwarding by executing the following command.

ndd -set /dev/ip ip_forwarding 0

Additional Security Protection:

1. First we will create the wheel group. The wheel group is a group of select individuals that can execute powerful commands, such as /usr/bin/su. By limiting the people that can access these commands, you enhance the system security. To create the group, vi the file /etc/group, create the group wheel, and add the system admins to the group. Then identify critical system binaries, such as /usr/bin/su. Change the group ownership to wheel, and the permissions to owner and group executable only (be sure to maintain the suid or guid bit for specific binaries). For /usr/bin/su, the commands would be:

/usr/bin/chgrp wheel /usr/bin/su
/usr/bin/chmod 4750 /usr/bin/su

* Note: (Don't forget, for su there is actually another binary in /sbin. For 2.6, this is called /sbin/su.static This is the same thing as /usr/bin/su, however the libaries are statically linked, hence the larger file size. Don't forget to change this file also ). 

2. Second, we will lock down the files .rhosts, .netrc, and /etc/hosts.equiv. The r commands use these files to access systems. To lock them down, touch the files, then change the permissions to zero, locking them down. This way no one can create or alter the files. For example,

/usr/bin/touch /.rhosts /.netrc /etc/hosts.equiv
/usr/bin/chmod 0 /.rhosts /.netrc /etc/hosts.equiv

3. Also, we want to set the TCP initial sequence number generation parameters. By truly randomizing the initial sequence number of all TCP connections, we protect the system against session hijacking and ip spoofing. This is done by setting TCP_STRONG_ISS=2 in the file/etc/default/inetinit. By default, the system installs with a setting of 1, which is not as secure. This is an example of setting the TCP initial sequence number generation parameters in the file /etc/default/inetinit

# @(#)inetinit.dfl 1.2 97/05/08
#
# TCP_STRONG_ISS sets the TCP initial sequence number generation parameters.
# Set TCP_STRONG_ISS to be:
# 0 = Old-fashioned sequential initial sequence number generation.
# 1 = Improved sequential generation, with random variance in increment.
# 2 = RFC 1948 sequence number generation, unique-per-connection-ID.
#
TCP_STRONG_ISS=2

To protect against possible buffer overflow (or stack smashing) attacks, add the following to lines to /etc/system.

set noexec_user_stack=1
set noexec_user_stack_log=1

4. Next, we make some modifications to the IP module. Add these commands to one of your start up scripts. For detailed information on ndd and tuning ip modules for security, check out Network 

Settings for Security.

### Set kernel parameters for /dev/ip
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
ndd -set /dev/ip ip_forward_directed_broadcasts 0
ndd -set /dev/ip ip_respond_to_timestamp 0
ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
ndd -set /dev/ip ip_forward_src_routed 0
ndd -set /dev/ip ip_ignore_redirect 1

5. Last thing I like to do is eliminate as many suid root binaries as possible. suid root binaries pose a high risk, as vulnerable versions can be used to gain root. Since this is a dedicated system with few accounts, most of the suid binaries can be disabled or removed. To find all suid root binaries, run the following command on your system.

find / -type f -perm -4000 -exec ls -lL {} \; | tee -a /var/tmp/suid.txt

Once you have identified all of the suid root binaries, you can remove most of them by changing the permissions to '555', or deleting the binaries entirely. For example, I eliminated the suid bit on the following binaries from a Core installation of Solaris 2.7.

# NOTE: You want to delete '/usr/bin/yppasswd', as it is hard linked
# to '/usr/bin/passwd'.
#
-r-sr-xr-x 1 root bin 15260 Oct 6 1998 /usr/lib/fs/ufs/quota
-r-sr-sr-x 1 root tty 174392 Aug 14 03:32 /usr/lib/fs/ufs/ufsdump
-r-sr-xr-x 1 root bin 869168 Aug 14 03:32 /usr/lib/fs/ufs/ufsrestore
---s--x--x 1 root bin 4316 Oct 6 1998 /usr/lib/pt_chmod
-r-sr-xr-x 1 root bin 8576 Oct 6 1998 /usr/lib/utmp_update
-r-sr-xr-x 1 root sys 27628 Oct 6 1998 /usr/bin/sparcv7/ps
-r-sr-xr-x 2 root bin 11528 Oct 6 1998 /usr/bin/sparcv7/uptime
-r-sr-xr-x 2 root bin 11528 Oct 6 1998 /usr/bin/sparcv7/w
-rwsr-xr-x 1 root sys 35916 Oct 6 1998 /usr/bin/at
-rwsr-xr-x 1 root sys 13996 Oct 6 1998 /usr/bin/atq
-rwsr-xr-x 1 root sys 12704 Oct 6 1998 /usr/bin/atrm
-r-sr-xr-x 1 root bin 14352 Oct 6 1998 /usr/bin/eject
-r-sr-xr-x 1 root bin 28776 Oct 6 1998 /usr/bin/fdformat
-r-sr-xr-x 1 root bin 29292 Oct 6 1998 /usr/bin/login
-rwsr-xr-x 1 root sys 7736 Oct 6 1998 /usr/bin/newgrp
-r-sr-xr-x 1 root bin 21368 Oct 6 1998 /usr/bin/rcp
-r-sr-xr-x 1 root bin 56280 Oct 6 1998 /usr/bin/rdist
-r-sr-xr-x 1 root bin 16772 Oct 6 1998 /usr/bin/rlogin
-r-sr-xr-x 1 root bin 9332 Oct 6 1998 /usr/bin/rsh
-rws--x--x 1 uucp bin 56240 Aug 14 03:34 /usr/bin/tip
-r-sr-sr-x 2 root sys 99824 Sep 9 1999 /usr/bin/yppasswd
-r-sr-xr-x 1 root bin 12948 Oct 6 1998 /usr/sbin/sparcv7/whodo
-rwsr-xr-x 3 root bin 17536 Aug 14 03:34 /usr/sbin/allocate
-rwsr-xr-x 1 root bin 10000 Aug 14 03:34 /usr/sbin/mkdevalloc
-rwsr-xr-x 1 root bin 10336 Aug 14 03:34 /usr/sbin/mkdevmaps
-r-sr-xr-x 1 root bin 20404 Oct 6 1998 /usr/sbin/ping
-rwsr-xr-x 1 root sys 23000 Aug 14 03:32 /usr/sbin/sacadm
-r-sr-xr-x 1 root bin 22056 Oct 6 1998 /usr/sbin/traceroute
-rwsr-xr-x 3 root bin 17536 Aug 14 03:34 /usr/sbin/deallocate
-rwsr-xr-x 3 root bin 17536 Aug 14 03:34 /usr/sbin/list_devices

Solaris Environment Settings for Security:

Strict Destination Multihoming

Strict destination multihoming prevents packet spoofing on nonforwarding multihomed systems. A Solaris system with IP forwarding disabled and strict destination multihoming enabled will ignore packets sent to an interface from which it did not arrive. This prevents attackers from creating packets destined for networks only connected to a multihomed server that does not forward packets. The system is aware of which interface on which a packet arrives. If a packet appears to be from a
network attached to another interface, the packet is dropped.

This feature can be enabled on the Solaris Operating Environment. It is disabled by default. Use the following ndd command to enable it:

# ndd -set /dev/ip ip_strict_dst_multihoming 1

Forwarding Directed Broadcasts

A directed broadcast is a unicast datagram from a system on a remote network addressed all systems on another network. Once the datagram reaches the router connected to the intended network, the datagram is forwarded to all systems as a
data-link layer broadcast.

Directed broadcasts can be problematic due to the amount of network traffic generated by broadcasts and the ability to send a packet to all systems on a network. An attacker may take advantage of forwarded directed broadcasts to attack and
probe systems. CERT Advisory CA-98.01 describes a denial of service attack called the "smurf" attack after its exploit program. It involves forged ICMP echo request packets sent to broadcast addresses. The source address in the forged packet is set to a target. The result is that the target and intermediate routing machine which forwards the directed broadcasts suffered from network congestion. One recommended action is to disable directed broadcast forwarding at all routers.
Attackers may also send directed broadcasts to probe the network and determine which systems have exploitable vulnerabilities.

A Solaris system with IP forwarding enabled forwards directed broadcasts by default. You can disable it using the following ndd command:

# ndd -set /dev/ip ip_forward_directed_broadcasts 0

Forwarding Source Routed Packets

A source routed packet contains a specific path that datagram should follow to its final destination. Normally, routing decisions are handled by routers. They maintain information on available routes and dynamically update them as new route
information is received. Source routed packets bypass routing decisions made by routers to define their own path to the final destination.

There is not much need for source routing in most networks. Properly configured routers make better decisions about routing. Source routed packets may be an indication of nefarious activity on the network. An attacker may attempt to use
source routed packets to bypass specific routers or internal firewalls or try to avoid a known network intrusion detection system by routing packets around it. Source routed packets are rare. Silently dropping them should affect few if any applications.

A Solaris system with IP forwarding enabled forwards source routed packets by default. It can be disabled with this ndd command:

# ndd -set /dev/ip ip_forward_src_routed 0

Solaris Environment Settings for Security (Continued):

Echo Request Broadcast

An echo request is a common network diagnostic created with the ping command. Echo requests can be sent to broadcast addresses. All systems configured to respond to broadcasted echo requests will send an echo reply. That can be a large number of packets. Even more devastating is the ability to increase the payload size of the
packet. The receiving system will return all of the data contained in the payload. Extremely large payloads will be fragmented across several packets, thus further increasing network traffic. Disable responding to echo request broadcasts with this
ndd command:

# ndd -set /dev/ip ip_respond_to_echo_broadcast 0

ICMP - Redirect Errors

Redirect Errors are used by a router to inform a host sending data to use a different router. Both routers involved in the redirection must be connected to the same subnet. The sending host will then install a new host routing entry in the routing
table for the destination host. Unlike ARP entries, these will not time out and be deleted. Most systems check the redirect message for errors and potential problems prior to modifying the routing table.

Receiving Redirect Errors

An attacker may forge redirect errors to hosts to install bogus routes. This may create a denial of service attack since the different router may not be a router at all. There are some rules governing valid redirect errors, all of which can be spoofed
easily. There are several attack tools do this. Use this ndd command to ignore ICMP redirect errors:

# ndd -set /dev/ip ip_ignore_redirect 1

Sending Redirect Errors

Only routers need to redirect errors, never hosts or even multihomed systems. Disable the sending of redirect errors with this ndd command:

# ndd -set /dev/ip ip_send_redirects 0

IP Spoofing Attacks Prevention

Solaris 2.6

There are several settings available on Solaris systems: the predictable method (0), an improved method with random increment value (1), and the RFC 1948 method (2). The default method for all revisions of Solaris is 1.

Solaris 2.6 and 7 releases have and 7 releases should be modified to use method 2.

To do this, edit the /etc/default/inetinit file and change the following line:

TCP_STRONG_ISS=1
to
TCP_STRONG_ISS=2 

Driver Installation for Quad (qfe) Interface:

1. Check the /etc/driver_aliases file for the line required by the adapter.

# grep 'pci_pci "pci1011,25"' /etc/driver_aliases

If this line already exists in the driver_aliases file, you can proceed with the adapter installation, which is described in the next section. Otherwise, you will need to add this line to the file before installing the adapter.

2. Using a text editor, add the following line to the end of the/etc/driver_aliases file.

pci_pci "pci1011,25"

Once you have added this line to the file, you can safely install the adapter.

Verifying the Installation

After you have installed the Sun Quad FastEthernet PCI adapter, but beforeyou boot your system, perform the following tasks to verify the installation. Refer to the Solaris 2.x Handbook for SMCC Peripherals manual or your Solaris documentation for the detailed instructions.

1. Power on the system, and when the banner appears, press the Stop-A keys to interrupt the boot process and to get to the ok prompt.
2. Use the show-devs command to list the system devices.

You should see lines in the list of devices, similar to the example below, specific to the Sun Quad FastEthernet PCI adapter:

ok show-devs
...
/pci@1f,2000/pci@2/SUNW,qfe@0,1
/pci@1f,2000/pci@2/SUNW,qfe@1,1
/pci@1f,2000/pci@2/SUNW,qfe@2,1
/pci@1f,2000/pci@2/SUNW,qfe@3,1
...

The SUNW,qfe@x,1 entries identify the adapter's four Ethernet devices.

Local-Mac-Address Property:

Each of the network interfaces of the Sun Quad FastEthernet PCI adapter have a MAC (Media Access Control) address, which represents the 48-bit ethernet address for that channel. The OpenBoot firmware reports this MAC address via the local-mac-address property in the device nodes corresponding to the network interfaces.

A system is not obligated to use this assigned MAC address if it has a system-wide MAC address. In such cases, the system-wide MAC address applies to all network interfaces on the system.

The device driver, or any other adapter utility, can use the network device's MAC address (local-mac-address) while configuring it. In the Solaris 2.6 operating system (and later Solaris revisions), you will be able to use a channel's MAC address when booting over the network.

The mac-address property of the network device specifies the network address (system-wide or local-mac-address) used for booting the system. To start using the MAC addresses assigned to the network interfaces of the Sun Quad FastEthernet PCI adapter, set the NVRAM configuration variablelocal-mac-address? to true

ok setenv local-mac-address? true

Configuring the Hostname File(s):

After installing the Sun Quad FastEthernet driver software, you must create ahostname.qfe<num> file for the adapter's Ethernet interfaces. You must also create both an IP address and a host name for its Ethernet interfaces in the/etc/hosts file.

1. At the command line, use the grep command to search the/etc/path_to_inst file for qfe devices.

# grep qfe /etc/path_to_inst
"/pci@1f,2000/pci@2/SUNW,qfe@0,1" 4 "qfe"
"/pci@1f,2000/pci@2/SUNW,qfe@1,1" 5 "qfe"
"/pci@1f,2000/pci@2/SUNW,qfe@2,1" 6 "qfe"
"/pci@1f,2000/pci@2/SUNW,qfe@3,1" 7 "qfe"

In the example above, the four SUNW,qfe@x,1 instances are from a Sun Quad FastEthernet PCI adapter installed in slot 2. For clarity, the instance numbers are bold.

2. Create an /etc/hostname.qfe<num> file, where <num> corresponds to the instance number of each interface you plan to use.

If you wanted to use all of the adapter's interfaces in Step 1's example, you would need to create four files:

Filename Instance Number Adapter Ethernet Channel (See Figure 1-2)

Filename	Instance Number	Adapter Ethernet Channel (See figure 2)
/etc/hostname.qfe0	0	0
/etc/hostname.qfe0	1	1
/etc/hostname.qfe0	2	2
/etc/hostname.qfe0	3	3

• Do not create /etc/hostname.qfe<num> files for Sun Quad FastEthernet PCI adapter channels you plan to leave unused.
• The /etc/hostname.qfe<num> file must contain the hostname for the appropriate network interface.
• The host name should have an IP address and should be entered in the/etc/hosts file.
• The host name should be different from any other host name of any other interface, for example: /etc/hostname.hme0 and/etc/hostname.qfe2 cannot share the same host name.

Using the instance examples in Step 1, the following example shows the four/etc/hostname.qfe<num> files required for a system called fw01 that has a Sun Quad FastEthernet PCI adapter (fw01-qfe0, fw01-qfe1, fw01-qfe2, and fw01-qfe3).

# cat /etc/hostname.hme0
fw01
# cat /etc/hostname.qfe0
fw01-qfe0
# cat /etc/hostname.qfe1
fw01-qfe1
# cat /etc/hostname.qfe2
fw01-qfe2
# cat /etc/hostname.qfe3
fw01-qfe3

3. Create an appropriate entry in the /etc/hosts file for each active qfechannel.

Using the example in Step 1, you will have:

# cat /etc/hosts
#
# Internet host table
#
# Note - 10.2.2.5 Subnet Mask 255.255.255.248
#
127.0.0.1 localhost
10.2.3.2 fw01 loghost
209.27.3.252 fw01-qfe0
172.20.1.252 fw01-qfe1
192.168.1.252 fw01-qfe2
192.168.10.252 fw01-qfe3
10.2.3.1 fwmngt

4. Reboot your system.

Hostname.* File:

The file /etc/hostname.* is critical, this is what causes the device to be plumbed. During the boot process, the /etc/rcS.d/network.sh file reads all the /etc/hostname.* files and plumbs the devices. Once plumbed, the devices are configured by reading the /etc/hosts and the /etc/netmasksfile. By reading these two files, the device is configured for the proper IP and netmask, and brought to an up state. Lets take the device hme0 as an example. During the boot process, /etc/rcS.d/network.sh looks for any/etc/hostname.* files. It finds /etc/hostname.hme0, which contains the following entry.

Fw01

/etc/rcS.d/rootusr.sh looks in /etc/hosts and resolves the namefw01 with an IP address of 10.2.2.5. The device hme0 is now assigned this IP address. The script then looks at /etc/netmasks to find the netmask for that IP address. With this information, the startup script brings up interface hme0 with an IP address of 10.2.2.5 and a netmask of 255.255.255.248. It may seem redundant having the script review the netmask of a class C address. However, do not forget that, starting with 2.6, Solaris supports both classless routing and VLSM (Variable Length Subnet Masks).

Specifying Netmasks:

To define the netmasks of your network, you use the file /etc/netmasks. This file is read during the bootup process, defining the makeup of your networks. Here is an example of a /etc/netmasks file.

#
# The netmasks file associates Internet Protocol (IP) address
# masks with IP network numbers.
#
# network-number netmask
#
# The term network-number refers to a number obtained from the Internet Network
# Information Center. Currently this number is restricted to being a class
# A, B, or C network number. In the future we should be able to support
# arbitrary network numbers per the Classless Internet Domain Routing
# guidelines.
#
# Both the network-number and the netmasks are specified in
# "decimal dot" notation, e.g:
#
#
#
10.2.3.2 255.255.255.0
209.27.3.252 255.255.255.0
172.20.1.252 255.255.255.0
192.168.1.252 255.255.255.0
192.168.10.252 255.255.255.0

Network Interface(s) Configuration:

When using a quad (qfe) network interface card, set the MAC addresses of different interfaces to different values using ifconfig. By default, all four interfaces of the quad card are assigned the same MAC address. This change yields significant improvement in network traffic throughput

Force all LAN network interfaces to maximum speed and full duplex, when applicable. Disable the auto-negotiation feature.

The procedure for checking and setting link parameters of qfe interfaces is the same as for hme with the additional consideration of the interface "instance". For a single four port qfe card, the instances are 0-3: qfe0,qfe1,qfe2,qfe3.

An additional qfe card would have interfaces qfe[4-7]

Checking the current running speed(s)

	Choose the interface instance:
	# ndd -set /dev/qfe instance 0
	This selects the first instance, qfe0. Note that the default instance is 0.
	Check the status, speed & mode
	# ndd -get /dev/qfe link_status 1 = up 0 = down
	# ndd -get /dev/qfe link_speed 1 = 100Mb 0 = 10Mb
	# ndd -get /dev/qfe link_mode 1 = Full Duplex (FDX) 0 = Half Duplex (HDX)

To check another instance, repeat the "ndd -set /dev/qfe instance N, where N is the instance id, and re-run the "ndd -get..." commands above.

Configuring via /etc/system

This will set all qfe interfaces to 100 full-duplex. Select only one value set to 1, as appropriate for your system.

	Forcing 100Mb Full Duplex (FDX) Note: all line MUST be used.
	ndd -set /dev/qfe instance 0 ndd -set /dev/qfe adv_100fdx_cap 1 ndd -set /dev/qfe adv_100hdx_cap 0 ndd -set /dev/qfe adv_10fdx_cap 0 ndd -set /dev/qfe adv_10hdx_cap 0 ndd -set /dev/qfe adv_autoneg_cap 0

Configuring individual interfaces via ndd commands

This script is usually installed as /etc/rc3.d/S99qfe.

#!/bin/sh
# /etc/rc3.d/S99qfe to set port modes
# set the speed as defined
# for all the ports on QFE cards 0 and 1 (0-7)
# and for hme ports 0 and 1

n100H=""
n100F="0 1 2 3"
n10F=""
n10H=""
HMEF="0 1"

for nic in $n100F
do
ndd -set /dev/qfe instance ${nic}
ndd -set /dev/qfe adv_100fdx_cap 1
ndd -set /dev/qfe adv_100hdx_cap 0
ndd -set /dev/qfe adv_10fdx_cap 0
ndd -set /dev/qfe adv_10hdx_cap 0
ndd -set /dev/qfe adv_autoneg_cap 0
done

for nic in $n100H
do
ndd -set /dev/qfe instance ${nic}
ndd -set /dev/qfe adv_100fdx_cap 0
ndd -set /dev/qfe adv_100hdx_cap 1
ndd -set /dev/qfe adv_10fdx_cap 0
ndd -set /dev/qfe adv_10hdx_cap 0
ndd -set /dev/qfe adv_autoneg_cap 0
done

(continued)

for nic in $n10F
do
ndd -set /dev/qfe instance ${nic}
ndd -set /dev/qfe adv_100fdx_cap 0
ndd -set /dev/qfe adv_100hdx_cap 0
ndd -set /dev/qfe adv_10fdx_cap 1
ndd -set /dev/qfe adv_10hdx_cap 0
ndd -set /dev/qfe adv_autoneg_cap 0
done

for nic in $n10H
do
ndd -set /dev/qfe instance ${nic}
ndd -set /dev/qfe adv_100fdx_cap 0
ndd -set /dev/qfe adv_100hdx_cap 0
ndd -set /dev/qfe adv_10fdx_cap 0
ndd -set /dev/qfe adv_10hdx_cap 1
ndd -set /dev/qfe adv_autoneg_cap 0
done

for nic in $HMEF
do
ndd -set /dev/hme instance ${nic}
ndd -set /dev/hme adv_100fdx_cap 1
ndd -set /dev/hme adv_100hdx_cap 0
ndd -set /dev/hme adv_10fdx_cap 0
ndd -set /dev/hme adv_10hdx_cap 0
ndd -set /dev/hme adv_autoneg_cap 0
done

Bringing up the Network Interface(s):

The first step in bringing up an interface is "plumbing" the interface. By plumbing, we are implementing the TCP/IP stack. We will use the above interface, hme0, as an example. Lets say we had just physically added this network interface card and rebooted, now what? First, we plumb the device with the plumb command.

ifconfig hme0 plumb

This sets up the streams needed for TCP/IP to use the device. However, the stack has not been configured as you can see below.

hme0: flags=842<BROADCAST,RUNNING,MULTICAST>

    mtu 1500
    inet 0.0.0.0 netmask 0
    ether 8:0:20:9c:6b:2d

The next step is to configure the TCP/IP stack. We configure the stack by adding the IP address, netmask, and then telling the device it is up. All this can be down in one command, as seen below.

Fw01 #ifconfig hme0 10.2.2.5 netmask 255.255.255.248 up

This single command configures the entire device. Notice the up command, which initializes the interface. The interface can be in one of two states, up or down. When an interface is down, the system does not attempt to transmit messages through that interface. A down interface will still show with the ifconfig command, however it will not have the word "up" on the first line.

Adding Static Route:

The route statement for the static NAT configuration needs to be put in the Solaris start up files. Typically routing commands are put in/etc/rc2.d/S69inet.

Edit this file and add the appropriate route command:

route add <static_external_ip> <static_internal_ip>

This would be a host route for configurations where the static_internal_ip is on the same network as the VPN-1/FireWall-1 Module machine. It is also possible, if the host is on a different network, to use the route command to specify a network route, like this:

route add <static_external_ip> mask <netmask> <gateway IP>

Where gateway_ip is the IP address of the next hop router in the path to the network in which the static NAT host is located.

Troubleshooting Network Interface(s):

ifconfig -a will show you which interfaces are currently installed and active. Remember, just because you added the physical network interface card does NOT mean it is active. If you do an ifconfig before you have configured the device, the interface will not show up. Once configured however, the typical output of the ifconfig -a command would look like this:

lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
    inet 127.0.0.1 netmask ff000000
hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500

    inet 192.168.1.132 netmask ffffff00 broadcast 192.168.1.255
    ether 8:0:20:9c:6b:2d

Here we see two interfaces, lo0 and hme0. lo0 is the standard loopback interface found on all systems. hme0 is a 10/100 Mbps interface. All hme interfaces are 10/100 Mbps, all le interfaces are 10 Mbps, all qe interface are quad 10 Mbps, and qfe interfaces are quad 10/100 Mbps. There are three lines of information about the interface. The first line is about the TCP/IP stack. For the interface hme0, we see the system is up, running both broadcast and multicast, with a mtu (maximum transfer unit) of 1500 bytes, standard for an Ethernet LAN. Notrailers is a flag no longer used, but kept for backwards compatibility reasons.

The second line is about the IP addressing. Here we see the IP address, netmask in hexadecimal format, and the broadcast address. The third line is the MAC address. Unlike most interfaces, Sun Microsystems? interfaces derive the MAC addressing from the NVRAM, not the interface itself. Thus, all the interfaces on a single SPARC system will have the same MAC address. This does not cause a problem in routing, since most NICs are always on a different network. Note, you must be root to see the MAC address with the ifconfig command, any other user will only see the first two lines of information.
Once you have mastered the tricks to modifying your interfaces, troubleshooting should be easier. Several things I always look for when troubleshooting an interface. First, when working with an unfamiliar machine, often you do not know how many physical interfaces are on the machine. A quick way to tell is use dmesg, this will give you information on the physical hardware. Look for le0, qfe0, hme0, or qe0. These are the names assigned to the physical devices.

If an interface is not responding to the network, check to be sure it is the correct IP address and netmask. The ifconfig command is a quick and temporary way to change IP and netmask information for troubleshooting purposes. Mtu (maximum transfer unit) is another possibility. Some systems may have problems communicating due to fragmented packets. Changing the mtu size may solve that problem. You'll notice that you did not have to set the mtu size in the examples above, these are set to defaults automatically, such as 1500 for Ethernet interfaces.

If that fails, try bringing the face down, then reinitializing it with the up command. If nothing else works, unplumb the device, then plumb it again. Basically, this reinstalls the TCP/IP stack.

Performance Tuning:

Performance tuning a VPN-1/FW-1 Server is an important step during, and after an installation. Capacity planning is important before the installation.

Here are some good guidelines to follow:

• Only install the minimum software required on the Firewall Module
• Avoid using the install scripts. Instead use pkgadd to install the modules that are required
• Tune the performance of the TCP/IP stack on the Operating System
• Tweak the memory allocation parameters

Tunning the TCP parameters:

1) Tuning the TCP high-water parameters for maximum throughput. The default values are set to 8192.

ndd -set /dev/tcp tcp_xmit_hiwat 65535 ndd -set /dev/tcp tcp_recv_hiwat 65535

2) Tuning the TCP Slow Start and TCP queue sizes affects performances.

	In /etc/system:
	set tcp:tcp_conn_hash_size = 16384 ndd -set /dev/tcp tcp_slow_start_initial 2 (Default = 1) ndd -set /dev/tcp tcp_conn_req_max_q 1024 (Default = 128) ndd -set /dev/tcp tcp_conn_req_max_q0 4096 (Default = 1024) ndd -set /dev/tcp tcp_close_wait_interval 60000 (Default = 240000)

Example:

	vi /etc/system
	set tcp:tcp_conn_hash_size = 16384 ndd -set /dev/tcp tcp_slow_start_initial 2 ndd -set /dev/tcp tcp_conn_req_max_q 1024 ndd -set /dev/tcp tcp_conn_req_max_q0 4096 ndd -set /dev/tcp tcp_close_wait_interval 60000

Increasing the open file descriptors:

Increasing the number of open file descriptors is especially relevant for busy security servers. This can be added into the /etc/system file:

set rlim_fd_max = 16384 (Default = 1024)
(Minimum recommended)

This parameter is a hard limit on file description that a single process might have open. This modification should be at least twice thetcp_conn_req_max_q0 parameters.

The rlim_fd_cur is the soft limit on the file descriptors. The soft limit (rlim_fd_cur) is initially allocated to a user process. More file descriptors can be provided to this process, as needed, up to the hard limit (rlim_fd_max).

To view the current hard and soft limits on the file descriptors, use the following commands:

ulimit -Sn ulimit -Hn

Soft limit (rlim_fd_cur) Hard limit (rlim_fd_max)

To verify the tcp_conn_req_max_q0 parameter, type in the following command:

ndd /dev/tcp tcp_conn_req_max_q0

Tweaking the memory allocation parameters:

By default, VPN-1/FW-1 allocates 3MB of memory for the kernel. Every simple connection (not authenticated or encrypted) requires about 70 bytes of memory, Encrypted (IKE) traffic requires 3 Kb per encrypted tunnel. Based of these values, it is possible to estimate the amount of memory VPN-1/FW-1 will require to support the given number of concurrent connections.

A general guideline it is a good idea to allocate 16 MB of memory for a busy firewall:

On Solaris, edit the /etc/system file and add the following set parameter:

Set fw:fwhmem = 0x1000000

Installing Check Point SVN Foundation:

Check Point SVN Foundation

For a new installation, install the NG FP1 package.
For upgrading an existing 4.0/4.1 installation, install the NG FP1 package.
For upgrading an existing NG installation, install the NG FP1 patch.

Solaris

Patch
1) Download cpshared_NG_FP1_0352_1_solaris_patch.tgz to a temporary directory and extract
the files.

2) Run the patchadd command, giving the CPSVNSP500001-01 directory as an argument:

Package
3) Download cpshared_NG_FP1_0352_1_solaris_package.tgz to a temporary directory and extract
the files.

4) Run the pkgadd command, giving the CPshrd-50 directory as an argument:

patchadd CPSVNSP500001-01
pkgadd -d . CPshrd-50

Installing Check Point Firewall-1 NG:

Solaris

Patch
1) Download fw1_NG_FP1_51129_2_solaris_patch.tgz to a temporary directory and extract the
files.

2) Run the patchadd command, giving the CPFWSP500001-01 directory as an argument:

Package

Installing FW-1 NG

1) Download fw1_NG_FP1_51129_2_solaris_package.tgz to a temporary directory and extract the
files.

2) Run the pkgadd command, giving the CPfw1-50 directory as an argument:

patchadd CPFWSP500001-01
pkgadd -d . CPfw1-50

Please make sure you reboot the Firewall Module after the packages have been added.

Installation of <CPfw1-50> was successful.

# reboot
syncing file systems... done
rebooting...
Resetting ...

The system is coming up. Please wait.
checking ufs filesystems
/dev/rdsk/c0t0d0s3: is clean.
/dev/rdsk/c0t0d0s4: is clean.
/dev/rdsk/c0t0d0s6: is clean.
/dev/rdsk/c0t0d0s7: is clean.
Starting IPv4 routing daemon.
Setting default IPv4 interface for multicast: add net 224.0/4: gateway fw01
cprid started...
Product fw-1 is not configured.
The system is ready.

Configuring Check Point Firewall-1 NG:

# cpconfig

Welcome to Check Point Configuration Program
=================================================
Please read the following license agreement.
Hit 'ENTER' to continue...

Do you accept all the terms of this license agreement (y/n) ? y

Which Module would you like to install ?
-------------------------------------------
(1) VPN-1 & FireWall-1 Enterprise Primary Management and Enforcement Module
(2) VPN-1 & FireWall-1 Enforcement Module
(3) VPN-1 & FireWall-1 Enterprise Primary Management
(4) VPN-1 & FireWall-1 Enterprise Secondary Management
(5) VPN-1 & FireWall-1 Enterprise Log Server

Enter your selection (1-5/a) [1]: 2

**************** VPN-1 & FireWall-1 kernel module installation ****************
installing VPN-1 & FireWall-1 kernel module...
FW-1: driver installed
VPN-1: driver installed
Done.
**************** Interface Configuration ****************
Scanning for unknown interfaces...
Would you like to install the High Availability product ? (y/n) [y] ?
IP forwarding disabled
Hardening OS Security: IP forwarding will be disabled during boot.
Generating default filter
Default Filter installed
Hardening OS Security: Default filter will be applied during boot.
This program will guide you through several steps where you
will define your VPN-1 & FireWall-1 configuration.
At any later time, you can reconfigure these parameters by
running cpconfig

Configuring Licenses...
=======================
Host Expiration Features

Do you want to add licenses (y/n) [n] ? y_ _n

Configuring Groups...
=====================
VPN-1 & FireWall-1 access and execution permissions
-------------------------------------------
Usually, a VPN-1 & FireWall-1 module is given group permission
for access and execution.
You may now name such a group or instruct the installation
procedure to give no group permissions to the VPN-1 & FireWall-1 module.
In the latter case, only the Super-User will
be able to access and execute the VPN-1 & FireWall-1 module.

Please specify group name [<RET> for no group permissions]:

No group permissions will be granted. Is this ok (y/n) [y] ? y

Setting Group Permissions... Done.

Adding Local Licenses to Check Point Firewall-1 NG:

Adding Licenses using the Local Licensing Model

# cpconfig
This program will let you re-configure
your VPN-1 & FireWall-1 configuration.

Configuration Options:
----------------------
(1) Licenses
(2) SNMP Extension
(3) Groups
(4) PKCS#11 Token
(5) Secure Internal Communication
(6) Disable Check Point High Availability/State Synchronization
(7) Automatic start of Check Point Products
(8) Exit

Enter your choice (1-8) :1

Configuring Licenses...
=======================
Host Expiration Features

Do you want to [A]dd or [D]elete a license. ('q' to quit): a

Do you want to add licenses [M]anually or [F]etch from file: f

Please enter the file name: CPLicenseFile.lic

Adding Local Licenses to Check Point Firewall-1 NG:

Adding Licenses using the Local Licensing Model

# cpconfig
This program will let you re-configure
your VPN-1 & FireWall-1 configuration.

Configuration Options:
----------------------
(1) Licenses
(2) SNMP Extension
(3) Groups
(4) PKCS#11 Token
(5) Secure Internal Communication
(6) Disable Check Point High Availability/State Synchronization
(7) Automatic start of Check Point Products
(8) Exit

Enter your choice (1-8) :1

Configuring Licenses...
=======================
Host Expiration Features

Do you want to [A]dd or [D]elete a license. ('q' to quit): a

Do you want to add licenses [M]anually or [F]etch from file: f

Please enter the file name: CPLicenseFile.lic

Adding Hostname Entry for Management Console and FW-1

On the management console, add the hostname for the firewall in the hosts file:

Hosts File Path Location on Windows 2000:

EDIT (Drive Letter:)\WINNT\SYSTEM32\DRIVERS\ETC\HOSTS

# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

127.0.0.1 localhost
10.2.3.2 fw01

On the Firewall Module, make sure that the hosts file contacts the Management Console

# cat /etc/hosts
#
# Internet host table
#
# Note - 10.2.2.5 Subnet Mask 255.255.255.248
#
127.0.0.1 localhost
10.2.3.2 fw01 loghost
209.27.3.252 fw01-qfe0
172.20.1.252 fw01-qfe1
192.168.1.252 fw01-qfe2
192.168.10.253 fw01-qfe3
10.2.3.1 fwmngt

2. Initial OS installation

Connect the serial console, switch on, halt to the OK prompt by sending a Stop-A (~#, ~%b, or F5 depending on whether you use tip, cu or a vt100 terminal), then start the installation procedure -
"boot cdrom - install".

Install the minimum end user bundle (or even better the core packages), set hostname, terminal, IP parameters, timezone, etc. Don't enable naming services like NIS or NFS. Don't enable power management. Don't mount any remote file systems (NFS).

Choose manual disk partitioning: Keep /usr and /opt separate from root, so that they can be later mounted read-only (see below). Consider a separate, large /var filesystem for syslog/web/news/proxy servers. Servers containing lots of data (web, ftp) should use a separate disk for their data.
If you don't wish to mount partitions read-only, then put the whole boot disk under root.
Suggestion for a 2GB disk: 200MB / (+var), 200MB swap,  600MB /usr and 1GB on /opt.
Suggestion for a 1GB disk: 300MB / (+var+opt), 200MB swap,  500MB /usr.

Set a strong password (7 or 8 chars with numbers, letters and punctuation) for root, and reboot. 

No man pages are installed with the user bundle, so install some while the the Solaris CD is still mounted:

cd /cdrom/cdrom0/s0/Solaris_2.7/Product;
pkgadd -d . SUNWman SUNWdtmaz SUNWdtma SUNWjvman SUNWpmowm SUNWolman SUNWolman SUNWtltkm SUNWxwman SUNWxwpmn

Update indices, so that "man -k keyword" will allow searching of relevant man pages:

/usr/lib/makewhatis /usr/man; /usr/lib/makewhatis /usr/openwin/man;
/usr/lib/makewhatis /usr/local/man

Install the recommended & security patches from Sun. Typically a separate CD "Maintenance Release" is provided with a patch bundle. Reboot and logon again as root. The list of patches installed can be listed with showrev -p .

---

3. Stripping/configuring OS: 1st pass

Disk mounting: To reduce the risk of trojan horses and unauthorised modifications, in /etc/vfstab, mount / with options "remount,nosuid", /var with "nosuid", /tmp with "size=100m,nosuid" (allow /tmp to only use 100MB of swap space and disallow execution of SUID programs).

The commands listed below assume you use the C-Shell. If you use the C-Shell, the following will make editing easier and enable history functions:
  csh;
  setenv TERM vt100; setenv VISUAL vi; setenv EDITOR vi;
  set filec; set history=40; alias h history; alias ls 'ls -aF \!*';

Shutdown the network interface during this phase, just in case (the interface name depends on the architecture e.g. hme0 or le0):

ifconfig le0 down

Disable NFS :

rm /etc/rc2.d/{S73nfs.client,K28nfs.server} /etc/rc3.d/S15nfs.server /etc/dfs/dfstab

Disable Sendmail daemon. Although sendmail is not running as a daemon, the binary is still present and email can be sent from (but not received by) the host. The only host that needs to receive email, the mail gateway, should use smap or an equivalent to minimise sendmail risks.

rm /etc/rc2.d/S88sendmail
And add a root cron entry to process the mail queue hourly:
0 * * * * /usr/lib/sendmail -q

Disable more services (automounter, power mgt., serial protocols, caching fs, etc.):

rm /etc/rc2.d/{S74autofs,S30sysid.net,S71sysid.sys,S72autoinstall} /etc/auto_*;
rm /etc/rc2.d/{S93cacheos.finish,S73cachefs.daemon,S80PRESERVE};
rm /etc/rc2.d/{S85power,K07dmi};
rm /etc/rc3.d/S77dmi;
If you have server/developer packages:
rm /etc/rc2.d/{S47asppp,S89bdconfig,S70uucp}

Disable RPC: This is highly desirable, but will break some programs like CDE or Disksuite. If you don't disable RPC, then a packet filter that blocks it is an absolute must.

rm /etc/rc2.d/S71rpc

Disable printing (unless there's a local printer attached):

rm /etc/rc2.d/{S80lp,S80spc}

Consider disabling the naming Services Caching Daemon: I've had problems with nscd (& Soalris 2.5) and don't like daemons running that I don't trust. It might offer performance advantages however, and some applications such as Netscape webproxy V3.5 needs it.

mv /etc/rc2.d/S76nscd /etc/rc2.d/.S76nscd

Disable CDE: unless you insisted on a graphical console?

rm /etc/rc2.d/S99dtlogin

Consider disabling NTP - Network Time Protocol. (NTP is accurate but complex, uses bandwidth and is an additional security worry. I prefer to use rdate to one central host, which then uses NTP to get accurate time). See also theadditional notes below. To disable it:

mv /etc/rc2.d/S74xntpd /etc/rc2.d/.S74xntpd

Disable SNMP, unless you do really need to use HP Openview or whatever. I prefer simple ping/traceroute scripts. If SNMP is switched on, only allow read (not write) access and change the community string.

rm /etc/rc2.d/K07snmpdx /etc/rc3.d/S76snmpdx

Inetinit: Disable ip forwarding, source routing (if there is more than one network interface), and avoid echo broadcasts.  Add a few lines to the end of /etc/init.d/inetinit:

## hardening
ndd -set /dev/ip ip_forward_directed_broadcasts 0
ndd -set /dev/ip ip_forward_src_routed 0
ndd -set /dev/ip ip_forwarding 0
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
ndd -set /dev/ip ip_strict_dst_multihoming 1

And in /etc/default/inetinit, prevent TCP sequence prediction (IP spoofing) attacks, by generating initial sequence numbers as suggested in RFC 1948.

TCP_STRONG_ISS=2
This change can be edited automatically with:
mv /etc/default/inetinit /etc/default/inetinit.orig;
sed 's/TCP_STRONG_ISS=1/TCP_STRONG_ISS=2/' /etc/default/inetinit.orig \
> /etc/default/inetinit; chgrp sys /etc/default/inetinit;

Prevent some buffer-overflow attacks by adding the following lines to /etc/system. This protects against forms of attack where the code to be executed lives on the stack. The OS won't allow the code to be executed, but it requires hardware support (it's only effective on sun4u/sun4d/sun4m systems).

* Hardening
set noexec_user_stack=1
set noexec_user_stack_log=1

Use default routes: add the IP address of the router to /etc/defaultrouter, or create a startup file in /etc/rc2.d/S99static_routes using the "route" command. To disable dynamic routing:
        touch /etc/notrouter
        mv /usr/sbin/in.routed /usr/sbin/.in.routed

/etc/init.d/inetsvc:
- Disable multicasting by commenting the lines around "route add 224.0.0.0." (it's about 14 lines, make sure you get all the ones in brackets).
- Enable logging of all INETD connections: Add add "-t" to the inetd startup line at the bottom, it should read:  /usr/sbin/inetd -s -t . Even better: disable inetd (see below)

Configure /etc/hosts with a list of critical machines (which you don't want resolved via DNS).

/etc/inetd.conf:

• Disable everything.
• If you don't use SSH, you might need ftp/telnet. RPC programs like Disksuite will insist on having a few entries enabled, but as noted previously we want to avoid RPC.
• If you really want to use inetd services, then use them with the FWTK netacl or tcp wrappers to allow a minimal IP address based access control and decent logging.
• To list the actived inetd entries, and make sure that the correct lines
  are disabled, try this:
  egrep -v '^#' /etc/inetd.conf
• Tell inetd to re-read the configuration file:
  kill -1 `pgrep inetd`

Reboot.

---

4. Connect to test network

The system has now gone through a first hardening phase and should be still working! Connect it to a secure, isolated network where standard tools/software can be downloaded. Boot and login on the console as root. Check for error messages on the console during boot, fix if necessary.

Tools are typically copied down with ftp. Avoid using the root account on the target server and change the password to a temporary one during the downloads, change back afterwards.
Once SSH has been installed, use it, rather than ftp for downloads.

---

5. Installing tools & sysadmin software

At this stage standard tools/utilities are going to be installed, the most important being SSH. These tools should already have been compiled and tested extensively on another machine. They are typically transferred as tar files, by CD or FTP. 

• Install SSH for login access. Configure the ssh daemon (/etc/sshd_config) so that access is restricted to named hosts with known public keys (/etc/ssh_known_hosts) and rhosts authentication is disabled. Use .shosts rather than .rhosts, if remote admin is needed.
  If telnetd/ftpd was still enabled, disable it in /etc/inetd.conf, once you have tested SSH.
• Environment:

/.cshrc /.profile: set aliases, variables (such as VISUAL, EDITOR and PATH don't include "."). Set umask to 077, or 027.

DNS client (avoid if not needed): add domain name & DNS servers to /etc/resolv.conf. Add a DNS entry for "hosts" in /etc/nsswitch.conf.

Email: If hosts are not supposed to send email outside the subnet, don't configure the mailhost alias. Delete /usr/lib/sendmail if you don't need any kind of email.
Otherwise edit /etc/mail/aliases (at least point root to a real address), set mailhost in /etc/hosts and in /etc/mail/sendmail.cf set the following to ensure all outgoing email is channeled over mailhost:
   Dj$w.YOURDOMAIN.COM.
   DSmailhost
   DRmailhost
   DHmailhost
   O FallbackMXhost=mailhost
Add a hostname.YOURDOMAIN.COM alias for this machine in /etc/hosts.
Send a test email to check the config:
   mailx -v -s test_email root </dev/null

• Install other necessary tools: gzip, traceroute and maybe top (without SUID) or lsof.
• Perl 5, for scripting - install & create a link to /bin/perl.
• Install security scripts in /secure, for example those used below: rotate_cron, rotate_log, wtrim.pl, rdistd. Protect /secure:
     chmod -R 700 /secure; chown -R root /secure

---

6. Stripping/configuring OS: 2nd pass

More OS patches: The Patch CD above won't be quite up to date. Get the Patchdiag tool from Sunsolve along with and update patchdiag.xref and run it to see what recommended and security patches are needed, then download & install the missing ones.

Configure logging:

Enable SU logging to console in /etc/default/su.

Enable logging of failed attempts to login:
touch /var/adm/loginlog; chmod 600 /var/adm/loginlog; chgrp sys /var/adm/loginlog

Syslog logging: Split up log analysis according to the example syslog.conf which enables more logging than the default and splits up services into separate logfiles. Designate one machine as the loghost (in /etc/hosts) or log locally.

Syslog "loghost"

Give the loghost a whopping great disk for logs.
Create empty logs & set permissions:
   cd /var/log; touch daemonlog authlog kernlog userlog maillog lprlog cronlog newslog locallog alertlog;
   chmod 600 daemonlog authlog kernlog userlog maillog lprlog cronlog newslog locallog alertlog;
   kill -1 `pgrep syslogd`

Use rotate_log to prune & compress logs, add the root cron entries:
## Prune syslog logs weekly, keeping the last 6 months or so:
55 23 * * 6 /secure/rotate_log -n 40 alertlog
55 23 * * 6 /secure/rotate_log -n 40 authlog
55 23 * * 6 /secure/rotate_log -n 20 cronlog
55 23 * * 6 /secure/rotate_log -n 40 daemonlog
55 23 * * 6 /secure/rotate_log -n 40 kernlog
55 23 * * 6 /secure/rotate_log -n 40 locallog
55 23 * * 6 /secure/rotate_log -n 20 newslog
55 23 * * 6 /secure/rotate_log -n 40 userlog
55 23 * * 6 /secure/rotate_log -n 10 lprlog
55 23 * * 6 /secure/rotate_log -n 20 maillog

Disable the Solaris log pruning (& other) lines in the root cron, since you're doing it yourself:

#10 3 * * 0,4 /etc/cron.d/logchecker
#10 3 * * 0 /usr/lib/newsyslog
#15 3 * * 0 /usr/lib/fs/nfs/nfsfind
#1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
#30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean

Pruning of login & other logs:

## Empty login/logout records at year end
0 0 31 12 * /secure/wtrim.pl wtmp 20
0 0 31 12 * /secure/wtrim.pl wtmpx 20
# Solaris 2.x logs:
0 4 * * 6 /secure/rotate_log -L /var/adm -n 30 loginlog
0 4 * * 6 /secure/rotate_log -L /var/adm -n 30 sulog
0 4 * * 6 /secure/rotate_log -L /var/adm -n 2 vold.log
0 4 * * 6 /secure/rotate_cron

Crons

Remove unnecessary crons:
rm /var/spool/cron/crontabs/{lp,sys,adm}
Don't delete the adm cron if you want sar performance collection or accounting .

Root cron entries:

Set date once a day with a reliable source using rdate (you may prefer NTP, it's more accurate, but complex, uses bandwidth and is an additional security worry):

## Synchronise the time:
0 * * * * /usr/bin/rdate YOURTIMEHOST  >/dev/null 2>&1

File permissions: tighten basic permissions, and restrict certain tools to root or disable:

chmod 0500 /usr/sbin/snoop /usr/sbin/devinfo
chmod o-r /var/spool/cron/crontabs/*
chmod 000 /bin/rdist
chmod o-rx /etc/security
chmod og-rwx /var/adm/vold.log
chmod u-s /usr/lib/sendmail        #Not for mailgateways or multi-user hosts
chmod 400 /.shosts /etc/sshd_config /etc/ssh_known_hosts

Then download, compile and run Casper Dik's script ftp://ftp.fwi.uva.nl/pub/solaris/fix-modes.tar.gz for improving file and directory permissions (runs on Solaris 2.2-2.7).

Documentation:

Document configuration changes in a text file such as /etc/mods, update after each change, with date, author, files affected, description.
cat > /etc/mods <<EOF
29.11.99  sb  New install of Solaris2.7 & tools according to hardening guidelines
EOF

Set login banners to warn users about unauthorised access (you'll need this if you want to prosecute intruders). For Telnet and SSH, use /etc/issue (for pre-login) /etc/motd (for post-login), containing, for example:

ATTENTION: You have logged onto a secured XXXX Corporation server.
Access by non YYYY administrators is forbidden.
For info contact YYYY@XXX.com

Reboot, login via SSH.

Now, ps -e should show a small process list:
   PID TTY TIME CMD
   0 ? 0:00 sched
   1 ? 0:00 init
   2 ? 0:00 pageout
   3 ? 0:09 fsflush
   156 ? 0:00 ttymon
   152 ? 0:00 sac
   447 ? 0:06 sshd
   88 ? 0:00 inetd
   98 ? 0:00 cron
   136 ? 0:00 utmpd
   605 ? 0:00 syslogd
   175 console 0:00 ttymon
   469 pts/1 0:00 csh
   466 ? 0:01 sshd
   625 pts/1 0:00 ps

and netstat -a should show a minimum of network connections (e.g. only SSH).

UDP
Local Address Remote Address State
-------------------- -------------------- -------
*.syslog Idle
*.* Unbound

TCP
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
-------------------- -------------------- ----- ------ ----- ------ -------
*.* *.* 0 0 0 0 IDLE
*.22 *.* 0 0 0 0 LISTEN
*.* *.* 0 0 0 0 IDLE

---

7. Create Tripwire image, backup, test

• Test - Do SSH and the standard tools work? Check log entries, check console messages. Does the system behave as expected?
• When all is working fine, freeze /usr and if possible /opt:

Mount /usr and /opt read-only (in /etc/vfstab with "ro" option). This reduces the risk of trojan horses and unauthorised modifications.
Mount other partitions nosuid (SUID programs cannot assume other identities).
Reboot.
Run the mount command to check that filesystems options are effective.

• If CD-ROMS are not needed for production, disable the volume manager (one less daemon, one less security worry). It can always be re-enabled if needed later:
      mv /etc/rc2.d/S92volmgt /etc/rc2.d/.S92volmgt
• At this stage install tripwire (or some other filechecker that uses secure hashing algorithms), initialise it's database and run regular checks to monitor for changes. If possible keep the tripwire master database on another machine or write-once media. Even better, copy tripwire & it's database and run it remotely at regular intervals using SSH. This makes it difficult for an attacker to know that tripwire is being used to check the system. See the sample script for running tripwire, trip_host.sh.
• Backup the system to two tapes, one offsite.

---

8. Install, test, harden applications

Consider installing applications on a separate partition or /opt. If /opt is used, it will have to be mounted read-write during installation and testing, and switched back to read-only afterwards.

Depending on the function of the server, applications such as ftpd, BIND, proxies, etc. are installed at this point. Web servers and firewall engines in particular, are complex and require careful configuration. The following is a general checklist that servers/applications should conform to:

·         Is the umask set restrictively (e.g. 022) by or before the application starts?

·         Does it run as a non root user with minimum privileges? Is it's password "blocked" and shell set to a dummy value such as /bin/false? If the password is really needed, is it set to min 8 chars with numbers, letters and punctuation?

·         If it runs as root, to bind to a low port, does it immediately fork to a non privileged user to minimise risks?

·         Are file permissions set so that only the application user can read/write files are there are no world read/writeable files?

·         Does the application write log permissions securely? Does it write passwords in the install log (don't laugh - it's common!).

A few tips for well known services

1. FTP server (ftpd):

·         If you use Washington University wu-ftpd (for it's better logging, access control and other features), be wary. It has a history of bugs (e.g. see CERT advisories CA-93:06, CA-94:07, CA-95:16 and Auscert AA-97.03 and AA-1999.02). Use at least V2.6.0 or later.

·         Configure /etc/ftpusers to list system accounts, so they cannot not be used for ftp e.g. disable use of ftp by root, add "root" to /etc/ftpusers.
One way of doing this for all system accounts on your fresh new system is:
  awk -F: '{print $1}' /etc/passwd > /etc/ftpusers

·         FTP can be selectively enabled per user via /etc/ftpusers or by using the following trick: For users who shouldn't have ftp access to this machine, give their accounts a non-standard shell (such as bash or tcsh) and don't enter this new shell into /etc/shells. FTP access will be denied. Conversely, if a non-standard shell is required, it must appear in /etc/shells for FTP to work correctly.

·         Enable logging: adding the "-l" option in /etc/inetd.conf (the additional -d option adds debug output).

·         FTP can be restricted on an IP address or hostname basis with the tcp wrappers.

·         For anonymous ftp, be VERY careful. A chroot environment is a MUST. See the in.ftpd man page which includes a script. Avoid allowing uploads. If uploads are necessary, don't allow downloads of uploaded files, hide uploaded file names and don't allow them to be overwritten (otherwise you may end up as an illegal software repository).

·         For normal "user ftp", chroot is also recommended.

·         Put the ftp data area on a separate disk partition and mount it nosuid.

2. DNS servers:

·         Use the latest BIND (Berkeley Internet Name Server) rather than Sun's named. BIND has more features, is easier to debug (with dig) and is updated quickly when security problems are found.  See www.isc.org/products/BIND

·         Use 8.2.2-P5 or later (which includes security fixes).

·         Create a "dns" user and group and start with "/usr/local/sbin/named -u dns", so that BIND will fork and change identity to the dns user (rather than the all powerful root). Give the dns user read access to BIND configuration files (they should belong to root however).

·         Restrict zone transfers to the IP address of secondaries (in /etc/named.conf).

·         Consider installing BIND in a chrooted environment.

·         A great tool for testing active domains is www.uniplus.ch/direct/testtool/dnstest.html

·         Troubleshooting:

o    Use nslookup or dig to check server results.

o    Client: Check /etc/nsswitch.conf and /etc/resolv.conf if you're having DNS client side problems. Start nslookup with the "-d2" option to get buckets of debugging info. Try killing the nscd daemon.

o    Server: Use spaces and not tabs in Sun's old /etc/named.boot (bind uses named.conf). Start named with the debug option "-d" and read the console & logs. Typically logs are found in the syslog "daemon" section.

o    See www.ebsinc.com/solaris/dns.html

o    To get statistics from the name server, do the following
     kill -ABRT `cat /etc/named.pid`
This puts the statistics into the file /usr/tmp/named.stats.

o    Send a HUP signal to named, to reread the config file after changes.
    kill -HUP `cat /etc/named.pid`

3. A good article on general chroot environments, also called "padded cells" can be read at Sunworldwww.sunworld.com/swol-01-1999/swol-01-security.html

4. HTTP servers:

·         If content doesn't change often, store it on CD-ROM, it simplifies change control and provides greater resilience to the hackers favourite of "site defacing". The HTTPD server will cache pages, ensuring that access speed does not depend on CD-ROM speed.

·         Separate "simple read-only" content servers from E-commerce servers.

·         Check out the CIAC Bulletin J-042 which describes best practices for Internet web servers.

·         Setup for a simple Apache 1.3.6 server:

o    Download (e.g. from sunfreeware.com) and install as root in /usr/local/apache. Create "apache" user & group with blocked password.

o    httpd.conf non-default changes: Set port, switch off server signatures, set ServerAdmin, ServerName, set User & Group=apache.

o    File permissions -  by default everything will belong to bin, which is fine. Remove world access, give minimum rights to apache group:
chgrp -R apache /usr/local/apache;  chmod -R o-rwx /usr/local/apache;

Preparing to go live

You probably won't need CR-ROMs or floppies anymore, so disable the volume manager:
    mv /etc/rc2.d/S92volmgt /etc/rc2.d/.S92volmgt
If you do need to mount a CD in the future, start vold manually & check for new devices:
    drvconfig; disks; vold &; volcheck; df -k

Consider installing a script to check that important daemons are running. Install monitor_processes.pl and add a root cron entry:
## Check that important processes are running during office hours:
## [If you run 7x24, modify accordingly]
0,30 8-19 * * 1-5 /secure/monitor_processes.pl inetd sshd httpd

If partitions such as /opt or /usr had to be mounted read-write during the application install/testing, mount them read-only now.

Reinitialise tripwire (or equivalent integrity checker).

Backup the system to two tapes, one offsite.

Run a network scan on the system, to ensure that only expected services are visible. A commercial tool such asISS or a free one like Nessus, nmap or Satan should do the job. Print out the results and archive.

If possible, have additional people do the final testing, just in case something was forgotten.

Test in detail - What works? What is forbidden? Check console/log entries. Does the system behave as expected? Watch the logs very frequently during the first few days of production.

---

9. Install on live network, test

Test in detail. Check log entries. Does the system behave as expected?

Have applications been tested in detail, by different people with different points of view, from different access points on the network?

---

10. Regular maintenance

The following activities should take place hourly, daily, weekly or monthly, depending on how critical the system is:

• Check the status of patches with Sun's Patchdiag, update as needed. Be very wary of kernel patches (test on a non-production machine).
• Check all logs for errors and unusual activity: syslog (/var/adm/messages or /var/log/*log, depending on syslog.conf), /var/cron/log, last, /var/adm/sulog, /var/adm/loginlog, application/server logs.
• Write scripts to report if critical daemons die, or if important systems cannot be pinged.
• Run tripwire (or equivalent integrity checker).
• Be regularly informed of new vulnerabilities and security issues, either by subscribing directly to CERT, CIAC and the vendor security lists (Sun, Microsoft, etc.) and/or, subscribing to SecurityPortal's weekly letter or the SANSmonthly letter.