Bienvenue sur le site admin-sys

Suppression des services réseaux "inutiles" en Solaris 10

Jerome ROBERT — 2011-03-29T21:04:52Z

Un certain nombre de services réseaux peuvent être désactivés afin de renforcer la sécurité du système solaris 10

svcadm disable ftp
svcadm disable telnet
svcadm disable rlogin
svcadm disable svc :/network/shell:kshell
svcadm disable svc :/network/shell:default
svcadm disable finger
svcadm disable svc :/network/rpc/mdcomm:default
svcadm disable svc :/network/rpc/metamed:default
svcadm disable svc :/network/rpc/metamh:default
svcadm disable svc :/network/rpc/meta:default
svcadm disable svc :/network/stdiscover:default
svcadm disable svc :/network/stlisten:default
svcadm disable svc :/network/cde-spc:default
svcadm disable svc :/network/rpc/cde-ttdbserver:tcp
svcadm disable svc :/network/rpc/rstat:default
svcadm disable svc :/network/nfs/cbd:default
svcadm disable svc :/network/rpc/rusers:default
svcadm disable svc :/application/x11/xfs:default

JASS

Jerome ROBERT — 2009-04-22T15:27:51Z

Pour sÃ©curitÃ© votre systÃ¨me Solaris.

JASS est un ensemble de scripts qui permet de sÃ©curiser votre systÃ¨me
Solaris.

Il y a deux modes :

standalone
jumpstart

Le mode 'standalone' permet l'application des rÃ¨gles de sÃ©curitÃ©s sur un
systÃ¨me dÃ©jÃ installer.

Le mode 'jumstart' permet d'appliquer les rÃ¨gles de sÃ©curitÃ© lors de
l'installation du serveur.

Pour en savoir plus :

JumpStart Architecture and Security Scripts (JASS) toolkit :

http://www.sun.com/software/security/jass/

De la documentation pour sÃ©curiser votre SOLARIS prÃ©fÃ©rÃ©.

http://www.sun.com/software/security/blueprints/index.html

Securing a Solaris 8 Server : guide 2

Jerome ROBERT — 2009-04-22T15:22:59Z

guide2

Solaris Security Guide

This document provides a list of configuration changes which enhance the security of a Sun Solaris^TM (SunOS 5.X) system.

Auditing

Enable the Basic Security Module (BSM):
```
/etc/security/bsmconv
```

Configure the classes of events to log in /etc/security/audit_control:

 dir:/var/audit flags:lo,ad,pc,fc,fd,fm naflags:lo,ad # # lo - login/logout events # ad - administrative actions: mount, exportfs, etc. # pc - process operations: fork, exec, exit, etc. # fc - file creation # fd - file deletion # fm - change of object attributes: chown, flock, etc. #

Create /etc/security/newauditlog.sh:

 #!/sbin/sh # # newauditlog.sh - Start a new audit file and expire the old logs # AUDIT_EXPIRE=30 AUDIT_DIR="/var/audit" /usr/sbin/audit -n cd $AUDIT_DIR # in case it is a link /usr/bin/find . $AUDIT_DIR -type f -mtime +$AUDIT_EXPIRE \ -exec rm {} > /dev/null 2>&1 \;

Run the script nightly from cron:

 chmod 500 /etc/security/newauditlog.sh /usr/bin/crontab -e root 0 0 * * * /etc/security/newauditlog.sh

The audit files generated are not human readable. The praudit(1M) command can be used to convert audit data into several ASCII formats.

Boot Files

Disable all startup files for services that are not needed from /etc/rc2.d and /etc/rc3.d. Services may be disabled by changing the capital 'S' in the name of the script to a lowercase 's'. The following startup files should not be disabled:
```
 S01MOUNTFSYS S69inet S72inetsvc S74xntpd S80PRESERVE S05RMTMPFILES S71rpc S74autofs S75cron S88utmpd S20sysetup S71sysid.sys S74syslog S75savecore S99audit S30sysid.net 
```

In order to ensure that all of the startup scripts run with the proper umask, execute the following script:

 umask 022 # make sure umask.sh gets created with the proper mode echo "umask 022" > /etc/init.d/umask.sh chmod 544 /etc/init.d/umask.sh for d in /etc/rc?.d do ln /etc/init.d/umask.sh $d/S00umask.sh done

In order to log as much information as possible, add the following lines to your /etc/syslog.conf:
```
 mail.debug /var/log/syslog *.info;mail.none /var/adm/messages 
```
Note: Tabs must be used to separate the fields.
This will log mail entries to /var/log/syslog and everything else to /var/adm/messages.

Log failed login attempts by creating the /var/adm/loginlog file:

 touch /var/adm/loginlog chown root /var/adm/loginlog chgrp sys /var/adm/loginlog

Set the permissions on the log files as follows:

 chmod 600 /var/adm/messages /var/log/syslog /var/adm/loginlog

Configure syslogd to not listen on port 514/udp by specifiing the -t flag in /etc/rc2.d/S74syslog (Solaris >= 8):
```
 /usr/sbin/syslogd -t > /dev/msglog 2>&1 
```

Configure logs files to be rotated daily archiving old versions for 30 dain /etc/logadm.conf (Solaris >= 9):

 /var/log/syslog -A 30d -p 1d -z 1 -a 'kill -HUP cat /var/run/syslog.pid' /var/adm/messages -A 30d -p 1d -z 1 -a 'kill -HUP cat /var/run/syslog.pid; \ logger -t logadm Begin new logfile'

Enable hardware protection for buffer overflow exploits in /etc/system (sun4u, sun4d, and sun4m systems only).

 * Foil certain classes of bug exploits set noexec_user_stack = 1 * Log attempted exploits set noexec_user_stack_log = 1

Network Services

Because the /usr/lib/sendmail daemon is not running, you should add the following line to root's crontab file:
```
 0 * * * * /usr/lib/sendmail -q 
```

Replace /etc/mail/sendmail.cf with the following:

 # Minimal client sendmail.cf ### Defined macros # The name of the mail hub DRmailhost # Define version V8 # Whom errors should appear to be from DnMailer-Daemon # Formatting of the UNIX from line DlFrom $g $d # Separators Do.:%@!^=/[] # From of the sender's address Dq<$g> # Spool directory OQ/usr/spool/mqueue ### Mailer Delivery Agents # Mailer to forward mail to the hub machine Mhub, P=[IPC], S=0, R=0, F=mDFMuCX, A=IPC $h # Sendmail requires these, but are not used Mlocal, P=/bin/mail, F=rlsDFMmnuP, S=0, R=0, A=mail -d $u Mprog, P=/bin/sh, F=lsDFMeuP, S=0, R=0, A=sh -c $u ### Rule sets S0 R@$+ $#error $: Missing user name R$+ $#hub $@$R $:$1 forward to hub S3 R$*<>$* $n handle <> error address R$*<$*>$* $2 basic RFC822 parsing

This configuration should be sufficient for servers where no local mail delivery is required.

Create /etc/init.d/nddconfig and create a link to /etc/rc2.d/S70nddconfig.

 touch /etc/init.d/nddconfig ln /etc/init.d/nddconfig /etc/rc2.d/S70nddconfig chmod 544 /etc/init.d/nddconfig

Add the following lines to the /etc/init.d/nddconfig file:

 #!/bin/sh # # /etc/init.d/nddconfig # # Fix for broadcast ping bug /usr/sbin/ndd -set /dev/ip ip_respond_to_echo_broadcast 0 # Block directed broadcast packets /usr/sbin/ndd -set /dev/ip ip_forward_directed_broadcasts 0 # Prevent spoofing /usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1 /usr/sbin/ndd -set /dev/ip ip_ignore_redirect 1 # No IP forwarding /usr/sbin/ndd -set /dev/ip ip_forwarding 0 # Drop source routed packets /usr/sbin/ndd -set /dev/ip ip_forward_src_routed 0 # Shorten ARP expiration to one minute to minimize ARP spoofing/hijacking # [Source: Titan adjust-arp-timers module] /usr/sbin/ndd -set /dev/ip ip_ire_flush_interval 60000 /usr/sbin/ndd -set /dev/arp arp_cleanup_interval 60 # -- # # The following tweaks are from 'Tuning Solaris for FireWall-1' by # Rob Thomas (http://www.enteract.com/~robt # # Do not respond to queries for our netmask /usr/sbin/ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0 # # Do not issue redirects -- fix the routing table instead /usr/sbin/ndd -set /dev/ip ip_send_redirects 0 # # Increase our defense against SYN floods. # The "q" queue is the completed socket holding pen where sockets # remain until the application issues accept(). /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 1280 # The "q0" queue is the half-open socket queue. /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q0 10240 # # --

A sample nddconfig file can also be found on the Sun BluePrints site at http://www.sun.com/blueprints/tools/

Deny services executed by inetd(3) the ability to create core files and enable logging for all TCP services by editing the /etc/rc2.d/S72inetsvc:

 # Run inetd in "standalone" mode (-s flag) so it doesn't have # to submit to the will of SAF. Why did we ever let them change inetd? ulimit -c 0 /usr/sbin/inetd -s -t&

Configure RFC 1948 TCP sequence number generation in /etc/default/inetinit:
```
 TCP_STRONG_ISS=2 
```

Comment out or remove all unnecessary services in the /etc/inet/inetd.conf file including the following:

 shell login exec comsat talk uucp tftp finger sysstat netstat time echo discard daytime chargen rquotad sprayd walld rexd rpc.ttdbserverd ufsd printer dtspc rpc.cmsd

Create /etc/rc3.d/S79tmpfix so that upon boot the /tmp directory will always have the sticky bit set mode 1777.

 #!/bin/sh #ident "@(#)tmpfix 1.0 95/09/14" if [ -d /tmp ] then /usr/bin/chmod 1777 /tmp /usr/bin/chgrp sys /tmp /usr/bin/chown sys /tmp fi

[Source: Titan psfix module]

Access Controls

Disable network root logins by enabling the "CONSOLE" line in /etc/default/login.
Remove, lock, or comment out unnecessary accounts, including "sys", "uucp", "nuucp", and "listen". The cleanest way to shut them down is to put "NP" in the password field of the /etc/shadow file.
Require authentication for remote commands by commenting out the following line in /etc/pam.conf:
```
 #rlogin auth sufficient /usr/lib/security/pam_rhosts_auth.so.1 
```
and changing the rsh line to read:
```
 rsh auth required /usr/lib/security/pam_unix.so.1 
```
[Source: Titan pam-rhosts module]
Only add accounts for users who require access to the system. If using NIS, use the compat mode by editing the /etc/nsswitch.conf file:
```
 passwd: compat 
```
Add each user to the /etc/passwd file
```
 +nis_user:x::::/home_dir:/bin/sh 
```
and the /etc/shadow file
```
 +nis_user::10626:::::: 
```

Create an /etc/issue file to display the following warning banner:

 WARNING: To protect the system from unauthorized use and to ensure that the system is functioning properly, activities on this system are monitored and recorded and subject to audit. Use of this system is expressed consent to such monitoring and recording. Any unauthorized access or use of this Automated Information System is prohibited and could be subject to criminal and civil penalties.

Source: CIAC-2317 Windows NT Network Security: A Manager's Guide

Add the banner to the /etc/motd file:

 cp /etc/motd /etc/motd.orig cat /etc/issue /etc/motd.orig > /etc/motd

The Automated Security Enhancement Tool (ASET) checks the settings and contents of system files. Many of the setuid and setgid programs on Solaris are used only by root, or by the user or group-id to which they are set.
Run aset using the highest security level and review the report files that are generated in /usr/aset/reports.
```
 /usr/aset/aset -l high 
```
Use of the FixModes program available from the Sun BluePrints site at http://www.sun.com/blueprints/tools is recommended.
Create a master list of the remaining setuid/setgid programs on your system and check that the list remains static over time.
```
 /bin/find / -type f $ -perm -4000 -o -perm -2000 $ \ -exec ls -ldb {} \; 
```
Execution of the su(1M) command can be controlled by adding and configuring a wheel group such as that found on most BSD derived systems.
```
 /usr/sbin/groupadd -g 13 wheel /usr/bin/chgrp wheel /usr/bin/su /sbin/su.static /usr/bin/chmod 4550 /usr/bin/su /sbin/su.static 
```
The GID for the wheel group does not need to be 13, any valid GID can be used. You will need to edit /etc/group to add users to the wheel group.

Create an /etc/ftpusers file:

 cat /etc/passwd | cut -f1 -d: > /etc/ftpusers chown root /etc/ftpusers chmod 600 /etc/ftpusers

Remove any users that require ftp access from the /etc/ftpusers file.

Set the default umask so that it does not include world access. Add "umask 027" to the following files:
```
 /etc/.login /etc/profile /etc/skel/local.cshrc /etc/skel/local.login /etc/skel/local.profile 
```
Enable the "UMASK" line in the /etc/default/login file and set the value to 027

The files in /etc/cron.d control which users can use the cron(1M) and at(1) facilities.

Create an /etc/cron.d/cron.allow file:

 echo "root" > /etc/cron.d/cron.allow chown root /etc/cron.d/cron.allow chmod 600 /etc/cron.d/cron.allow

Create an /etc/cron.d/at.allow file:

 cp -p /etc/cron.d/cron.allow /etc/cron.d/at.allow

Create an /etc/cron.d/cron.deny file:

 cat /etc/passwd | cut -f1 -d: | grep -v root > /etc/cron.d/cron.deny chown root /etc/cron.d/cron.deny chmod 600 /etc/cron.d/cron.deny

Create an /etc/cron.d/at.deny file:

 cp -p /etc/cron.d/cron.deny /etc/cron.d/at.deny

If CDE is installed, replace the default CDE "Welcome" greeting. If the /etc/dt/config/C directory does not exist, create the directory structure and copy the default configuration file:
```
 mkdir -p /etc/dt/config/C chmod -R a+rX /etc/dt/config cp -p /usr/dt/config/C/Xresources /etc/dt/config/C 
```
Add the following lines to /etc/dt/config/C/Xresources:
```
 Dtlogin*greeting.labelString: %LocalHost% Dtlogin*greeting.persLabelString: login: %s 
```
If CDE is installed, disable XDMCP connection access by creating or replacing the /etc/dt/config/Xaccess file:
```
 # # Xaccess - disable all XDMCP connections # !* 
```
Set the permissions on /etc/dt/config/Xaccess to 444:
```
 chmod 444 /etc/dt/config/Xaccess 
```

Time Synchronization

Edit the /etc/inet/ntp.conf file:

 # # /etc/inet/ntp.client # # An example file that could be copied over to /etc/inet/ntp.conf; it # provides a configuration for an ntp server that uses three public sources # with an internal fallback (127.127.1.0). # # A simple NTP clilent would specify one or more network servers in your # organization: # # server ntp.example.com # # Public NTP Server list: http://www.eecis.udel.edu/~mills/ntp/clock1.htm # server 192.5.41.40 # tick.usno.navy.mil server 192.5.5.250 # clock.isc.org server 128.9.176.30 # timekeeper.isi.edu server 127.127.1.0 # internal clock fudge 127.127.1.0 stratum 10

Recommended Tools

FixModes

FixModes is a script that tries to make Solaris file modes more secure.

Sudo

Sudo (superuser do) allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments.

SunScreen

SunScreen is a host-based firewall product that is packaged with Solaris 8 and later. See also Securing Systems with Host-Based Firewalls

TCP Wrappers

With this package you can monitor and filter incoming requests for the SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other network services. TCP Wrappers is included in Solaris 9.

Secure Shell (ssh)

Ssh is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over unsecure channels. It is intended as a replacement for rlogin, rsh, and rcp.

Titan

Titan is a collection of programs, each of which either fixes or tightens one or more potential security problems with a particular aspect in the setup or configuration of a Unix system.

Logcheck

Logcheck is a perl script that monitors system logs for unusual activity.

Installing Solaris

This section describes the steps necessary to install Solaris with the smallest OS image possible.

Remove any network connections from the machine before installing the OS.
Boot the machine from the OS install CD-ROM
Answer the installation questions as they pertain to this instance. You will want to mark the machine as being networked and give the machine an IP address even though it is not connected to the network.
In the Solaris install program, select the Core SPARC cluster. Then select Customize. The following is a list of all the clusters that should be selected. For clusters that have subparts, select only the subparts listed, not the entire cluster.
AutoFS Automated Security Enhancement Tools Federated Naming System FrameBuffer Device Drivers Dumb frame buffer device drivers FTP Server, (Root) FTP Server, (Usr) GX (cg6) OS support files GX (cg6) device drivers Install and Patch Utilities Interprocess Communication Keyboard configuration tables Motif Runtime Kit Network Information System (NIS) Openwindows Version 3 Openwindows kernel modules X Window system window drivers PCMCIA Support Patch utilities Platform Support, OS Functionality (Usr) Portable layout services for Complex Text Layout support Programming tools and libraries Sun workshop bundled shared libm SPARCompilers bundled libc Static utilities Solaris desktop /usr/dt filesystem anchor Solaris Naming Enabler SunFastEthernet/FastWideSCSI-2 Adaptor Drivers SunSwift SBus Adaptor Drivers System Accounting System and Network Administration Terminal Information
Color Legend: | Solaris 2.6 & 7 | Solaris 2.6 | Solaris >=7 |

Be sure to install any device drivers specific to your hardware!

Solaris >=7: 64-bit package versions should also be selected if 64-bit support has been enabled.

If you need printer support, select the following:
Line Printer Support Tooltalk end user Tooltalk runtime
For remote Motif/X support, select the following:
Font Server Cluster X Window System common (not required) fonts X Window System optional fonts X Window System platform required fonts OpenWindows Version 3 ICE components X Window System platform software Tooltalk end user Tooltalk runtime XIL Runtime Environment
The following is required for FireWall-1:
Source compatibilty support Source Compatibilty, (Usr)
The Core SPARC cluster requires much less disk space than most types of Solaris installs. The following partition table is appropriate for machines loaded with the Core SPARC cluster:
```
 s0: / 250 megabytes s1: swap 1 gigabyte s2: overlap s3: 8 megabytes (for metadb) s4: /usr 500 megabytes s5: /var 2 gigabytes s6: /opt (rest of disk) 
```

The /var partition is large to accommodate extra logging and auditing information. You may wish to scale the swap space as appropriate for your hardware, but extra swap helps prevent "denial-of-service" attacks.

The Core SPARC cluster, even with the most recent patches, provides many services which are unnecessary.

Execute pkginfo. The results should match the following:

 % pkginfo system SUNWaccr System Accounting, (Root) system SUNWaccu System Accounting, (Usr) system SUNWadmap System administration applications system SUNWadmc System administration core libraries system SUNWadmfw System & Network Administration Framework system SUNWadmr System & Network Administration Root system SUNWast Automated Security Enhancement Tools system SUNWatfsr AutoFS, (Root) system SUNWatfsu AutoFS, (Usr) system SUNWcar Core Architecture, (Root) system SUNWcg6 GX (cg6) Device Driver system SUNWcsd Core Solaris Devices system SUNWcsr Core Solaris, (Root) system SUNWcsu Core Solaris, (Usr) CTL SUNWctpls Portable layout services for Complex Text Layout support system SUNWdfb Dumb Frame Buffer Device Drivers system SUNWdtcor Solaris Desktop /usr/dt filesystem anchor system SUNWesu Extended System Utilities system SUNWfns Federated Naming System system SUNWftpr FTP Server, (Root) system SUNWftpu FTP Server, (Usr) system SUNWhmd SunSwift SBus Adapter Drivers system SUNWipc Interprocess Communications system SUNWkey Keyboard configuration tables system SUNWkvm Core Architecture, (Kvm) system SUNWlibC SPARCompilers Bundled libC system SUNWlibms Sun WorkShop Bundled shared libm system SUNWmfrun Motif RunTime Kit system SUNWnisr Network Information System, (Root) system SUNWnisu Network Information System, (Usr) system SUNWos86u Platform Support, OS Functionality (Usr) system SUNWpcelx 3COM EtherLink III PCMCIA Ethernet Driver system SUNWpcmci PCMCIA Card Services, (Root) system SUNWpcmcu PCMCIA Card Services, (Usr) system SUNWpcmem PCMCIA memory card driver system SUNWpcser PCMCIA serial card driver system SUNWpsdpr PCMCIA ATA card driver system SUNWsolnm Solaris Naming Enabler system SUNWsutl Static Utilities system SUNWswmt Patch Utilities system SUNWswmt Install and Patch Utilities system SUNWter Terminal Information system SUNWxwdv X Windows System Window Drivers system SUNWxwmod OpenWindows kernel modules

Solaris >=7: 64-bit package versions will also be listed if 64-bit support has been enabled.

Use the pkgrm command to remove any non-essential packages that are not listed above.

Resources

Sun Recommended & Security Patches

Sun Security Bulletins

The Solaris Security FAQ

SANS Solaris Security: Step-by-Step

Solaris BSM Auditing

Tuning Solaris for FireWall-1 by Rob Thomas

jrr

Securing a Solaris 8 Server : guide 1

Jerome ROBERT — 2009-04-22T15:20:37Z

guide1

Version 1.4

Securing a Solaris 8 Server

This web page is a merging of the published security suggestions of several people. These people include Lance Spitzner, Keith Watson and Alex Noordergraaf, among others. It combines, and extends, their ideas using the paranoia I've learned through 22 years of working in the computer field. More information on the source papers can be found in the bibliography.

In addition, several people at the San Diego Supercomputer Center (SDSC) assisted me with this web page. That help included: a) Pointing me to additional reference papers, b) Helping with some of the more esoteric technical issues, and c) Proofreading to find glaring technical errors.

Finally, Stephanie Gates of The Scripps Research Institute (TSRI) was of enormous assistance in the final editing.

This web page was written specifically for the initial release of Solaris 8. Most of the functions performed here will also work on other versions of Solaris, but the exact procedure (file names and variables) may change. Additionally, many of the topics covered in this web page are applicable to other versions of UNIX, and to non-Server systems.

1. Introduction

I have 22 years experience in the computer field. Three of these were as a computer operator, and nineteen as a programmer. The last six years, I've also had to do hardware work. I guess that makes me a programmer with a screwdriver. Scary, isn't it?

I used to be employed by Cray, Inc. as a Customer Engineer for the San Diego Supercomputer Center (SDSC). Before that, I worked for the Atlantic Research Corporation (now a part of Computer Sciences Corporation) and Logicon (now a part of Northrop-Grumman).

I was first introduced to the concept of computer security in 1980, when I worked for the government as a computer operator. In 1983, I worked for Logicon developing a Multilevel Secure Operating System. In 1987, I worked for Atlantic Research Corporation developing a B1 secure DBMS command and data filtering system (TruData).

Since 1990, I've worked for Cray. The average Cray customer pays quite a bit for their computer, and they expect to get the full capabilities of what they bought. They do not expect to have it stolen by a resource thief. As part of my job, I've been asked, on occasion, to help ensure that the systems I worked on were appropriately secure.

2. History of this Web Page

I have several computers that the SDSC is kind enough to allow me to place directly on the Internet. One of the policies they have is that if a system is broken into, it will be confiscated for investigation. In order to keep this from occurring, I researched how to secure them. Since there were multiple systems (same operating system), I documented what I had done, so that I could do it again. Tom Perrine, SDSC's senior computer security expert, saw what I had done, and suggested that I give a presentation on it.

Instead of a presentation, I decided to create a paper. This web page is that paper.

3. Overview

The goal of this web page is to demonstrate how to secure a Solaris Server. This demonstration is based on actual experience, not just on theory.

Before going any further, I think I should describe what I mean when I say that a system needs to be secured, and why it needs to be done.

When we secure a server, we take measures to ensure that only those people with a legitimate reason to be on a computer, actually have access to it. We also make sure that those users that do have access to the computer, only have access to their information, and have the ability to allow, or restrict, such access for others.

We are interested in securing servers to keep one person's information from being improperly available to another. We also secure servers to ensure that the disk space, network bandwidth, and CPU resources are available for the intended users.

There are three general classes of people that we're securing the server against. The one thing that people in these classes all have in common is that they're criminals.

"Children" Playing

This class of person compromises more computers than any of the other classes discussed here. Often, it's just a game, to see who can break into the most computers. The most common forms this game takes are Denial Of Service (DOS) attacks, web page defacement, and general vandalism. Sometimes the participants are too young to know that what they're doing is unlawful, but not always.

Resource Thieves

These people want to use the server's resources without paying for it. This use includes using the computer to break into other computers, using it to store information, or using it to send large amounts of E-mail to people who would rather not see it.

Data Thieves

These people are looking for information. Sometimes, they're looking for specific information; other times, they're looking for anything that they find interesting. These people will often use the information they get for their own personal gain, which may include selling it to a competitor.

An extreme version of this type of person might modify the data on your server. This might be done to discredit a person or organization, or to cause incorrect/invalid results or conclusions.

These people are separate and distinct from the commonly found web page defacers and vandals, due to their motivation. The motivation of this group is usually either money or revenge. This motivation tends to create a determination that is not normally found in the other groups.

Here is a list of the various security philosophies whose implementation I discuss in this web page:

Defense in Depth

Defense in Depth is the single most useful concept that I cover here. When used with computer security, it means that you never depend on a single security measure (like a firewall) to keep your system secure. You assume that there's a hole in any security measure you put in place, and provide for it's being broken through.

The goal here is to either have enough security doors blocking the intruder that they give up, and move on, or they run into a door that they don't know how to get through. From the security standpoint, both of these can be considered a win, or at least a draw.

This concept should also be applied to the physical security of a server, and will be discussed in greater depth in the section on System Hardware Configuration.

Less is Better

Less is Better means that the less there is on a system, the more secure the system can be made. It refers to less software, fewer daemons, fewer users logging in, and fewer services being offered.

This concept is why large organizations have dedicated name servers, NFS servers, web servers, time servers, etc..

Strong Configuration Management

Strong configuration management is critical to properly securing a server in the long term. This measure is accomplished by the use of a properly configured change detection system (i.e. Tripwire), and/or a centralized configuration management system (i.e. cfengine). These two tools can be used independently, or together.

The purpose of an intrusion detection system is to inform a system administrator when a possible intrusion has occurred. This detection is often done by looking at the fingerprints of critical system files.

The purpose of a centralized configuration management system is to ensure that each system has the correct configuration at all times. The system should report when a discrepancy is found.

If you wish to run both of these tools, then the intrusion detection system should finish running prior to starting the centralized configuration management system, so that it can properly identify any changes that may have been made.

Hazard Awareness

A system administrator should always be aware of the hazards that come with operating a computer connected to the Internet, and protect against them. Usually, there are multiple ways to secure a service. The system administrator should be aware of the hazards that may arise because one or more of these actions is not performed. Making an informed decision to not close a particular security door is not necessarily bad; not monitoring it is.

Also, there are several security oriented E-mail lists, whose purpose is to keep administrators informed about current security issues. Among these are CERT, Bugtraq (from SecurityFocus) and SANS. URLs for these organizations may be found in the section on Sources of Tools.

Security Through Obscurity

This form of security is done by providing a minimal amount of information on the software configuration, software version, hardware configuration, or even the hardware vendor. Wherever it's possible to NOT provide information, don't provide it. In general, if someone has a legitimate need to know about what's on a system, they'll ask. The reasoning behind this is to never give the intruder a free ride. As an example, if you don't advertise that your web server has PHP, most intruders won't try the PHP exploits.

It should be noted that this security philosophy only serves to muddle the playing field. It is not sufficient, without the support of the other security philosophies described here. The Code Red worm is an example of why this security philosophy is inadequate. It didn't look or ask, it just hit.

Give a warning shot to the chest

This philosophy means that every feasible path into the system should get a warning message, and these messages should be plain, direct and to the point. Don't worry about being excessively polite. On the other hand, don't be excessively abusive.

These messages are not very useful against intrusion, but they may improve your legal position, if an intrusion occurs.

4. Network Topology

This web page is about securing a solaris server, not about creating a secure network infrastructure. It should be used as a rough guide, for the purposes of establishing the level of threat that a system faces.

For most people, the network topology that they use is already set. This section is to help them to understand the strengths and weaknesses of the topology they have to work with. The network administrator should be able to provide further assistance and clarification.

For the lucky few who are building a network from scratch, there's enough information here to give you a general idea of what you want to do, but probably not enough to actually do it. I suggest that you work with your network people, your ISP, a good vendor representative, or a reputable consultant, as this will greatly improve your chances of creating a functional network.

The O'Reilly book Building Internet Firewalls (1) has additional information on network topologies.

The general network topology that I've assumed in the rest of this web page, is a server with one or more network interfaces that are connected to the Internet, without any filters.

If your border router is performing packet level filtering, or if your server is behind a firewall, your server will be more secure from outside attacks. It will not be any more secure from inside attacks. Unfortunately, most disastrous intrusions occur due to inside attacks.

Several general network topologies are available. I have created diagrams of three network topologies that show, in general, how most networks are configured. Each of these will be briefly discussed.

Co-located Server

In this topology, you either own, or rent, a server and place it at an ISP. There is a direct connection from the ISP's router (or switch) to your system, usually over a 100 MegaBit connection. This topology places the highest possible security demands on your server, as it is fully and directly accessible from the Internet. The high speed of the connection will also allow large amounts of data to be transferred if an intrusion occurs.

Flat Network

In this topology, the router is not performing packet filtering. Typically, the decision to not filter packets would be made because the router doesn't have enough CPU power to perform packet filtering. The decision could also be made because the configuration management for the router tables would get too complex, or because a political decision has been made that no packet filtering will be performed. Often, the router will be a DSL or Cable modem. This topology is often used in a Small Office/Home Office (SOHO) network.

Many educational institutions also use this topology, even though they often use leased lines, with several MegaBits per second bandwidth, coupled with powerful routers and switches, and is an example of a political decision to use this topology.

With this topology, all systems on your network are fully and directly accessible from the Internet. The security demands on each system on your network are similar to those for a Co-located Server. The only improvement over the Co-located Server is that the bandwidth through which a compromised system can be exploited is usually lower. In most cases, this network topology is acceptable, only if there are a very small number of systems on your network.

Careful configuration of network routes can improve the security of this topology, but it's a complex task.

VPN connections are possible with this network configuration.

Medium Office Network

This network has the same topology as is shown for the SOHO Network. The primary difference (as far as security is concerned) is that with a Medium Office Network, packet level filtering is being performed in the Border Router. This network topology can be made almost as secure as the Partitioned Network topology. Usually, VLANs are being used in the switch(es), to simplify communications configuration.

The Mac and PC desktops are kept in separate subnets from the rest of the systems, as these systems send more broadcasts. Also, PC systems running Windows are more difficult to secure than UNIX systems.

The Authentication Server and the Internal File Server should both be connected to dedicated switch ports. Both systems should not have any direct communications with external systems.

Properly authenticated users (login and password) of the Dial-in Server should be allowed connections to external systems, in a manner similar to the internal desktop systems, and should receive the same degree of protection. File sharing should only be done to dial-in systems that are appropriately authorized (a separate issue from authentication). Optimally, only secured connections (ssh) to the internal systems should be allowed.

Partitioned Network

This network topology is capable of being very secure. Both the border router and the main router are performing packet filtering. If a firewall is not used, the Medium Office Network configuration can be used, as the second router provides little additional security.

The Firewall system should be capable of monitoring the state of the connection. This monitoring gives a high assurance that connections aren't being made to unprotected internal ports.

Some people feel that a Firewall system gives a false sense of security, and that it's better to not use them, and make sure that all the systems are properly secured. Other people feel that nothing can replace a properly configured Firewall. I fall between these two camps. I feel that a Firewall is useful in adding to the security of a network, but that it should not be relied upon to give complete security.

If additional protection of, and from, the Dial-in Server is desired, it could be connected to a port on the Firewall, thus providing additional protection for both the internal network, and the dial-up user. This may be useful if a user password becomes compromised.

If there exists a portion of the network, where there is external access to the switching and/or communication fabric, then that network should also be connected through the firewall. This lack of security is most often found with wireless networks.

If VPN is used in this configuration, it should be done in the border router. A connection request should not be allowed to enter the border router from the ISP, unless it's for one of the external servers, or for the Firewall. Also, no RPC or UDP requests should be accepted from the ISP, unless they're for one of the external servers that's supposed to receive them, or responses to DNS or NTP requests.

In theory, the capabilities of both the Border Router and the Main Router can be combined into a single router, but this complicates the configuration.

5. System Hardware Configuration

System Placement

The first thing to consider is the physical placement of the server. If you have a location with 24 hour staffing, and adequate power, cooling and connectivity, that's the ideal place to put a server. This would typically be a staffed computer room, or a security office.

If there is no available location that's staffed continuously, then a lockable room (or ventilated cabinet) should be used. Only a minimum number of people should have access to this space. There should be adequate power, cooling (may be difficult for a lockable ventilated cabinet), and network connectivity.

Disk Layout

Most of this subject has little bearing on security, but now is the proper time to consider it. I've searched for information on this topic, but found very little. Due to lack of information, I've assembled some background information, and a few suggestions, based on my experience.

This section does not cover file-system mount options, which does have an impact on security. Those options are covered later in this paper.

Disk Channels

Disks are connected to a computer over channels. The most commonly used types of channels are IDE, SCSI and Fiber Channel. If your server is performing disk intensive operations, then an attempt should be made to maximize the number of channels available.

Channel Contention

IDE Channels

IDE disks are relatively inexpensive, in comparison to SCSI or Fiber, because they are produced in much larger quantities, and because the electronics on the disk is simpler. The drawback is that IDE drives exhibit quite a bit of channel contention. If at all possible, use only one disk per IDE channel. If it's necessary to put a second disk on the channel, one of the disks should have relatively low I/O requirements. No more than two disks can be placed on an IDE channel.

SCSI Channels

SCSI disks usually have a faster access time than IDE disks, and a faster data transfer rate to/from the platter. With UNIX, the actual bus speed has little effect on I/O throughput, as long as it's greater than the platter data speed, because of the buffering that UNIX performs.

SCSI disks are usually priced between two and three times as high per GigaByte as IDE disks. Once the disk I/O requirements exceed what IDE can deliver, it becomes necessary to move to SCSI. SCSI disks have little channel contention, until the bus is saturated with data. With a limit of 15 disk drives (more if Logical Unit Numbers are used), it is not a difficult task to saturate a SCSI bus on a busy system.

Fiber Channels

Fibre channel disks (also spelled fiber) are normally built using the HDA (Head Disk Assembly), and most of the drive electronics of a SCSI drive. Only the physical interface, and a little bit of the microcode (the software that runs on the actual disk drive) needs to be changed. The primary advantage of Fibre disks over SCSI disks is the number of devices that can be put on a single channel (127 vs. 15). Another advantage is that the disks can be located farther from the system.

Fibre channel computer interfaces are available with either copper of optical connections. The copper interconnect cable is less expensive than the optical cable, but the optical interconnect cable is immune to electrical interference, and can be used on longer runs. In any case, the interface to the disk drive is always copper, with any necessary conversion being done in the chassis.

The pricing for Fibre disks is similar to the pricing for SCSI disks. The main reason for the price similarity is that the HDA for a given SCSI disk is normally also used in a Fibre disk, with different interface electronics.

Drive Contention

When there is activity on a single disk drive from multiple sources, this is called drive contention. Proper file-system layout can minimize this, but it usually requires a significant amount of knowledge about the I/O patterns of each file-system. The knowledge to lay out file-systems to minimize drive contention is usually gained from painful experience, and is difficult to put clearly into words.

File-system Layout

As part of the Solaris installation, you will be given a choice between a Custom and an Automatic (default) file-system layout. If you select Custom, you will be asked to enter the information about the file-system layout that you want. The following should be kept in mind when the file-system layout is entered.

It is necessary to have both a root and a swap partition. In fact, multiple swap partitions are supported, and, under some circumstances, might be appropriate. Additional information on the swap partition(s) is located near the end of this section.
It is possible to have a separate /usr file-system. On desktop workstations, this may be a good idea, but I don't suggest that it be done on a server. One of the problems is that the only way to check the /usr file-system is to boot from an external source (CDROM or Network).
I suggest that you establish a separate /var file-system. This is the file-system that is used to spool information to be processed, or that has been processed and is waiting to be returned to the user, and to store logs. It is also the file-system that is used by Solaris to store information on the packages and patches that have been installed. If you do not create a separate /var file-system, then an action that generates large amounts of data for the /var directory tree could easily fill the root file-system, causing the system to exhibit erratic behavior.
Additionally, if the system is a mail server, then it is often appropriate to have a separate /var/spool/mail file-system. The partition for this file-system should be made significantly larger that you expect will be needed. Other examples of the /var file-system needing to be further subdivided are /var/log on a log server, /var/adm on an accounting server, /var/spool/mqueue on an outgoing mail server, and /var/spool/lpd for a print server.
Many of the SUN optional packages, and third-party binary packages, are installed under the /opt directory tree. If you use many of these, it might be a good idea to have a separate /opt file-system. As with the /var file-system, the goal is to keep the root file-system from filling up. Again, the partition for this file-system should be made significantly larger that you expect will be needed.
Many of the freeware and source (i.e. GNU) packages are normally installed under the /usr/local directory tree. If there are more than just a few of these, I suggest that you have a separate /usr/local file-system. This will help to keep the /usr file-system (or the root file-system where there is no /usr file-system) from filling up. Again, the partition for this file-system should be made significantly larger that you expect will be needed.
The /tmp and /var/run directories are, by default, mounted on top of the swap partition (file-system type of tmpfs). This means that they use the same disk space as the swap partition. It is possible that this could cause a server to run out of swap space, or /tmp space (space in /var/run shouldn't be a problem). If either of these problems arises, or is expected to arise because of an expected heavy load on the /tmp file-system, then it is suggested that a separate partition be allocated for the /tmp file-system. Alternatively, it might be appropriate to allocate more space to the swap partition(s). Never allow the /tmp directory to be left in the root partition.
This is a tradeoff between speed (tmpfs is very fast, because it's heavily buffered in memory) and contention (is memory to be used for tmpfs or programs). This sort of decision often requires benchmarking to determine the best solution.

Swap

First, it should be noted that calling anything on a Solaris system swap is a misnomer. In reality, the swap partition is used for paging. The name is a carryover from the earlier days of UNIX, when paging wasn't supported, and entire programs had to be moved from memory to disk (swapped).

The swap space on a Solaris system functions as an extension of the memory on the system. Disk space that is used in this manner is referred to as virtual memory. When real memory (the RAM in a system) becomes full, the operating system will move portions of programs (called pages; usually 4096 bytes per page) onto virtual memory. The act of moving pages between real memory and virtual memory is called paging.

Keeping track of these virtual memory pages isn't significantly more complex then keeping track of real memory pages. The problem is that paging from virtual memory back into real memory can be a time consuming task.

When determining the amount of disk space to allocate for swap, you need to consider the maximum possible system memory usage. The sum of real memory and virtual memory (swap space) should be well in excess of the maximum possible system memory usage. This is primarily because applications have a tendency to grow, and users always seem to find something new to run on a system. Although it is theoretically possible to run a Solaris system with no swap space, only an expert should attempt to do so.

Also, when Solaris performs a crash dump, it places the dump into the swap area. As part of the reboot, this dump is read into the /var/crash directory (if dumps are enabled; they are by default). If there is not adequate space in swap to store the dump, then it will be lost. For this reason, it is advised that the swap space be at least as large as real memory. The operation of crash dumps can be altered with the dumpadm command.

Finally, the file-system type of tmpfs uses both real and virtual memory. This creates a very fast file-system, as much of the file-system structure resides in memory. Unfortunately, this file-system format is also transient in nature, as it is lost each time the system is rebooted. By default, the /tmp and /var/run file-systems are mounted as type tmpfs. There are several kernel tuning parameters that adjust the functionality of tmpfs. These are discussed in the Solaris Tunable Parameters Reference Manual (9).

Network Connectivity

When you install a system, you should have a good idea as to how much network connectivity the system will need. If the system is placed in a location where the network connections need to be run, it would be a good idea to make sure that the number of connections run to that location is at least twice the number needed. Allowing for growth will increase the amount of time until additional or replacement network connections need to be run.

Additionally, a server should never be connected to a hub. If possible, a server should receive a dedicated switch port to maximize the bandwidth actually available to the server.

6. Initial Installation

Before installing a Solaris server, disconnect all network interfaces to ensure that there are no intrusion attempts while the installation is occurring, before the system can be properly secured. To transfer data (patches, 3rd party packages and source) to the system being installed, use either CDROM, or tape (or any other non-networked, physically connected device).

Some of the newer SUN systems have neither a CDROM, nor an external SCSI connector. For these systems, you will need to perform the installation from the network. The best way to do this would be to use JumpStart on a fully isolated build network. Additionally, there are several papers on the SUN BluePrints website that cover the JumpStart procedure.

When installing Solaris for a server, it is normally not necessary to start with more than the CORE installation. The current Solaris installation is on two CDROMs. Unfortunately, the installation script isn't smart enough to request the second CDROM, unless Java is installed, and Java isn't part of the CORE installation. For this reason, any additional packages should be installed manually, at a later time. Fortunately, the entire CORE installation resides on the first CDROM.

Set minimum password length

In the /etc/default/passwd file, set the PASSLENGTH variable to 8. This will require that passwords be eight characters long. It should be noted that, with the default password methodology, any portion of the password beyond eight characters is ignored.

Set default password changing parameters

In the /etc/default/passwd file, set the MAXWEEKS variable to the maximum number of weeks that can pass, before a user must change their password. If MAXWEEKS is too short, users will have a tendency to cycle through a list of passwords. This value is normally not set to less than 13 (3 months).

Also, set the MINWEEKS variable to the minimum number of weeks that must pass before a user is allowed to change their password. The purpose of this variable is to lessen the likelyhood that a user will cycle through a password list, or change their password, then change it right back. For this reason, the MINWEEKS variable should not be set too small. On the other hand, if it is set too large, a user might not be able to change their own password, if it were to become compromised. I feel that a value between 2 and 4 is appropriate for this variable.

Finally, set the WARNWEEKS variable to the number of weeks that must pass since the last password change, before a user will receive password change warnings. This number should be slightly shorter than the value the MAXWEEKS variable was set to. If the difference between MAXWEEKS and WARNWEEKS is too small, users might return from a vacation, and find that they can't log in. I feel that the difference should be at least three weeks.

Add critical hosts

The critical hosts should be added to the /etc/hosts file. A critical host is one that is explicitly referenced in one of the other configuration files. Also, all the names for this host should be in the /etc/hosts file. This is done so that system critical issues do not need to have DNS or NIS functioning. Non-critical hosts can be retrieved through DNS.

If your network is small enough, and you don't need to log the host name of external hosts, or connect to external hosts by name, you might be able to use only the /etc/hosts file (preferable, if it can be done).

Add network names

Add the local networks to the /etc/networks file. Typically, you'd only be concerned about those networks you're directly connected to. This makes some of the netstat outputs easier to read and understand.

Configure DNS

Put the appropriate information into the /etc/resolv.conf file (only needed if you're running DNS).

Set hostname lookup

The /etc/nsswitch.conf file needs to be updated. The hosts line should have files as the first entry. Also, the networks line should have files as the only entry. Any references to NIS or NIS+ should be removed from the hosts line.

Update the login scripts

The files /etc/.login, /etc/cshrc and /etc/profile should be updated, as appropriate for your installation. These are the login script for the C-shell, and the startup scripts for the C-shell and the Bourne-shell, respectively.

Set available shells

The file /etc/shells should be updated to list all the commands that will be allowed to be used as shells by various system utilities. These utilities include ftp and sendmail.

Verify console settings

In the file /etc/default/login, ensure that the value for CONSOLE is set to /dev/console, allowing root logins only from the physical console. Solaris should make /dev/console the default, but it needs to be checked.

Use Journalling file systems

In the file /etc/vfstab, add the mount option logging on all mountable local file-systems. In case of a crash, use of a journalled file-system will minimize the corruption; very important for log files.

Install the patches

SUN comes out with a new recommended patch cluster about twice a month. In general, these should be installed as soon as possible after they come out. This is a task that never ends.

When performing the first patch install, the patches should come from a CDROM, or a tape because your network connection is still not connected; an important consideration, as Solaris (as delivered) is not well configured for security.

7. Minimizing Solaris

The CORE installation loads many packages that are not needed for a server to function. Among them are several X11 and OpenWindows packages. Alex Noordergraaf wrote a good paper on how to minimize Solaris (2).

Minimizing Solaris is a simple way of removing potential security issues. As an example, if a hacker knew of a security hole in a specific daemon that's not running, they might try to get it started. If it's not there, then they'd have to find another way in.

The most important thing to consider is that you don't want to remove any packages that are critical to your system. A great amount of care should be taken in removing driver packages. Also, you should have a good understanding of the needs of your application. If a package is needed by your application, it shouldn't be removed. When in doubt, leave it.

The drivers for some of the less frequently encountered hardware may not be include in the CORE installation. If you have hardware in your system that doesn't seem to work, please make sure that the package containing the driver has been installed.

As an example, I have a PC with Solaris 8 installed. The almost minimized package list is as follows (I didn't take the time to try to minimize further):

 NCRos86r	NCR Platform Support, OS Functionality (Root) SUNWadmr	System & Network Administration Root SUNWadp Adaptec 29xx/39/xx/78xx Family of SCSI HBA SUNWcar Core Architecture, (Root) SUNWcsd Core Solaris Devices SUNWcsl Core Solaris, (Shared Libs) SUNWcsr Core Solaris, (Root) SUNWcsu Core Solaris, (Usr) SUNWdfb Dumb Frame Buffer Device Drivers (deprecated) SUNWesu Extended System Utilities SUNWkey Keyboard configuration tables SUNWkvm Core Architecture, (Kvm) SUNWlibms	Sun WorkShop Bundled shared libm SUNWloc System Localization SUNWnamos	Northern America OS Support SUNWos86r	Platform Support, OS Functionality (Root) SUNWos86u	Platform Support, OS Functionality (Usr) SUNWpsdcr	Platform Support, Bus-independent Device Drivers (Root) SUNWpsdir	Platform Support, ISA Bus Device Drivers, (Root) SUNWrmodr	Realmode Modules, (Root) SUNWrmodu	Realmode Modules, (Usr) SUNWswmt	Install and Patch Utilities

I also have a SPARCstation LX with Solaris 8 installed. The almost minimized package list is as follows (again, I didn't take the time to minimize further):

 SUNWadmr	System & Network Administration Root SUNWcar Core Architecture, (Root) SUNWcg6 GX (cg6) Device Driver SUNWcsd Core Solaris Devices SUNWcsl Core Solaris, (Shared Libs) SUNWcsr Core Solaris, (Root) SUNWcsu Core Solaris, (Usr) SUNWdfb Dumb Frame Buffer Device Drivers SUNWesu Extended System Utilities SUNWkey Keyboard configuration tables SUNWkvm Core Architecture, (Kvm) SUNWlibms	Sun WorkShop Bundled shared libm SUNWloc System Localization SUNWnamos	Northern America OS Support SUNWrmodu	Realmode Modules, (Usr) SUNWswmt	Install and Patch Utilities

Install the minimum number of Solaris packages necessary to perform the required tasks. I added the following packages. Installation of other Solaris or third-party packages may require additional Solaris operating system packages to be installed.

On-line manual pages

 SUNWdoc Documentation Tools SUNWlibC	Sun Workshop Compilers Bundled libC SUNWman On-Line Manual Pages

Network Time Protocol

 SUNWntpr	NTP, (Root) SUNWntpu	NTP, (Usr)

GNU tools

 SUNWbash	GNU Bourne-Again shell (bash) SUNWgpch	The GNU Patch utility SUNWgzip	The GNU Zip (gzip) compression utility SUNWless	The GNU pager (less)

Various shells

 SUNWtcsh	Tenex C-shell (tcsh) SUNWzsh Z shell (zsh)

Needed to build many source packages

 SUNWarc Archive Libraries SUNWbtool	CCS tools bundled with SunOS SUNWhea SunOS Header Files SUNWsprot	Solaris Bundled tools SUNWtoo Programming Tools SUNWxcu4	XCU4 Utilities SUNWxcu4t	XCU4 make and sccs utilities

Needed to build Bind

 SUNWscpu	Source Compatibility, (Usr)

Needed to build SSH

 SUNWlibm	Sun WorkShop Bundled libm

Needed to build PostgresSQL

 SUNWipc Interprocess Communications SUNWlldap	LDAP Libraries

Misc. system maintenance stuff

 SUNWaccr	System Accounting, (Root) SUNWaccu	System Accounting, (Usr) SUNWadmc	System administration core libraries SUNWadmfw	System & Network Administration Framework SUNWspl Spell Checking Engine - Base Release (English) SUNWsutl	Static Utilities SUNWter Terminal Information

It should be noted that there are some decisions to be made here. If a package is needed, and the package is available as source (sendmail, NTP, perl, Apache and FTP being examples), it is necessary to decide whether to use the vendor package, or to build from source.

Building from source gives more flexibility in configuration, at the expense of greater system administration time and effort. Also, upgrades and security patches are usually available for source packages sooner.

8. Minimizing Network Services

The primary source for this information is a web page by Lance Spitzner (3).

Most network services are offered by inetd. The file inetd.conf lists the services that inetd is to offer, and what programs to execute when a connection is made to the service. If a line has a '#' as the first character, it will be treated as a comment, and any information that might be there about a service will be ignored.

Each service in the inetd.conf file should be individually analyzed to determine if it is necessary for the system to function properly. In most cases, the answer will be no. If a service is determined to be unnecessary, the line should be commented out, by inserting a '#' as the first character of the line. If you don't know what the service does, try to comment it out, and see is everything still works. NOTE: After the inetd.conf file is changed, the inetd program needs to be instructed to reread the file, by using the kill command to send it a SIGHUP (e.g. kill -1 (PID)).

Some of the services in the inetd.conf file are offered for both IPv4 and IPv6. These services may be identified by the protocol type of tcp6. If it is necessary to leave a service in for IPv4, but disable it for IPv6, the protocol should be changed from tcp6 to tcp. If the server is not running IPv6, then none of the services should be have a protocol of tcp6.

The most commonly used inetd services are telnet and FTP. If secure shell is used, these services can usually be disabled.

Among the least secure services offered by inetd are the R commands. These are rlogin, rexec, rcp and rsh. If at all possible, these services should be disabled in the inetd.conf file.

If the inetd.conf file gets to the point where all of the lines are commented out, then there is no longer any reason to run the inetd daemon. If this occurs, comment out the line that starts inetd, found in the /etc/rc2.d/S72inetsvc file (NOTE: number may not be 72; please check first with ls /etc/rc2.d/S*inetsvc).

Not all network services are offered by inetd. Sometimes, it is either necessary, or faster, to execute a daemon directly, and allow it to wait for connections. Here are the most common of those daemons:

Apache

Apache is an open-source web server, which is provided on the Solaris installation CDROMs. The version provided has only a minimal set of modules, which is not adequate for most web servers. If you are not running a web server, this software should not be installed.

There are modules available for Apache that enable almost any imaginable web functionality. In most cases, to use a module you will have to build Apache from source.

If you choose to run Apache, installed from source, I suggest that you install Apache from the Solaris installation CDROMs, save the startup scripts (/etc/rc2.d/*[Aa]pache*), and remove the package. These startup scripts should work well, as long as Apache is installed in the same location.

Automountd

The automountd daemon is used to automatically mount NFS file-systems when they are needed, and unmount them when they become unneeded. This helps to free up kernel resources, and keep the mount table small.

This might be useful on a desktop system, but I feel that it has no place on a server. When using NFS on a server (hopefully, this isn't too often), the delay for mounting a new file-system is not good, and could cause response problems.

Kerberos Authentication

Kerberos is a protocol for authenticating users. There are both advantages and disadvantages of using Kerberos, as compared to other readily available authentication protocols.

There exists a Kerberos daemon, which only needs to run on the Key Distribution Center (KDC). This daemon performs the tasks of saving user pass phrases, and distributing Kerberos Tickets. It also interfaces with remote Kerberos administration tools. Installation of a KDC, and configuration of Kerberos, is beyond the scope of this web page. For a description of how this is done, please either read the manual pages, or read the Addison-Wesley book Kerberos - A Network Authentication System (4).

Also, there are Kerberized clients (they use Kerberos tickets for authorization) listed in the inetd.conf file. These clients include ktelnet, kftp, krlogin, krlogin, krsh and krcp. Additionally, there exist other Kerberized clients for login, IMAP, POP, and many other authenticated access methods. When using Kerberos, these clients should not be commented out of the inetd.conf file (except, possibly, on the KDC).

LDAP

If it was necessary to install the LDAP package to get a third party package to build, it is normally a good idea to disable the LDAP daemon. To disable the LDAP daemon, enter the following command (NOTE: number may not be 71; please check first with ls /etc/rc2.d/S*ldap.client):

 mv /etc/rc2.d/S71ldap.client /etc/rc2.d/_S71ldap.client

LPD

The LPD (Line Printer Daemon) is only needed on a system that functions as a print server. Other systems should only have the printer queueing commands (lp, lpc, lpq, lpr and lprm). To disable LPD, remove the SUNWpsr package.

Also, there is a reference to in.lpd in the /etc/inetd.conf file. To disable LPD, this would also have to be disabled.

LPRng

LPRng is a third-party software package, covered by the GPL, that is sometimes used to replace the LPD system. It has several features that make it more useful then the LPD system, under certain circumstances.

When a default install is performed, several files are added to the /etc/rc2.d directory, for the purpose of starting the print daemon. If the system is not functioning as a print server, then the startup of the print daemon should be disabled.

To disable startup of the LPRng print daemon, enter the following commands (NOTE: numbers may not be 60 and 80; please check first with ls /etc/rc2.d/S*lprng):

 mv /etc/rc2.d/S60lprng /etc/rc2.d/_S60lprng mv /etc/rc2.d/S80lprng /etc/rc2.d/_S80lprng

NFS

If the server is on an unprotected network, or if there are users on the network that shouldn't see all the data in the server, then NFS should not be used. To disable NFS, enter the following commands (NOTE: numbers may not be 73 and 15; please check first with ls /etc/rc2.d/S*nfs.client and ls /etc/rc3.d/S*nfs.server):

 mv /etc/rc2.d/S73nfs.client /etc/rc2.d/_S73nfs.client mv /etc/rc3.d/S15nfs.server /etc/rc3.d/_S15nfs.server

NIS

SUN has created a powerful tool called NIS. This tool is very helpful for central configuration control of large groups of systems. Unfortunately, the design did not consider that passwords could be easily broken. Since DES encrypted passwords can no longer be considered to be secure, I strongly suggest that NIS not be used. To disable NIS, remove the SUNWnisu and SUNWnisr packages.

NIS+

As the name implies, this is a followon to NIS. It improves on the power, flexibility and security of NIS. If all (or almost all) of the UNIX systems on your network can use this protocol, it might be worthwhile using. Please note that the servers for NIS+ need to be carefully configured to be properly secure.

The O'Reilly book Managing NFS and NIS (5) has information on properly configuring servers and clients to use NIS+.

NTP

NTP is a package that can be used to synchronize the time on systems. Keeping times in sync is very useful, as it makes the log entries easier to interpret. It is also important when NFS is being used.

Routed

The routed daemon is used to determine where network traffic should go when it leaves a host. If there exists a /etc/defaultrouter file, then the IP address contained in that file would be used as the default route, and the routed daemon will not be started.

The routed daemon is not normally needed, unless a system has multiple network interfaces.

RPC

RPC is a service that allows remote (and local) programs to request that an action be performed. The rpcbind daemon allows remote users to determine what RPC services are being offered. This could allow a potential intruder to scan for hosts with a vulnerable service.

The rpcbind daemon is needed for NFS, NIS and parts of X11, among others. If you aren't running any of these, you may wish to try disabling RPC. To disable RPC, enter the following command (NOTE: number may not be 71; please check first with ls /etc/rc2.d/S*rpc):

 mv /etc/rc2.d/S71rpc /etc/rc2.d/_S71rpc

When disabling the rpcbind daemon, it is a good idea to make sure that the necessary network services function properly both before and after the change. NOTE: The system should be booted immediately prior to any such testing being done.

If you find that the rpcbind daemon is necessary for proper system functionality, it is possible to use TCP-Wrappers with rpcbind, to limit the hosts that can access the RPC information. For more information on this, please see the documentation that comes with the TCP-Wrappers package.

Sendmail

Most servers have an occasional need to send mail. Although it is not necessary to have sendmail running to send mail, it is often a good idea, as sendmail also scans the mail queues, trying to send out mail that was previously unsendable.

If the server doesn't need to receive mail (it's not one of the mail servers), then the -bd flag should be removed from the execution line. The file where this resides is /etc/rc2.d/S*sendmail. NOTE: With sendmail 8.12 and above, this change will cause locally initiated messages to not be deliverable.

An alternative to removing the -bd flag would be to not start the sendmail daemon, and to run sendmail -q from cron every hour.

If you're running the Solaris 8 sendmail, the configuration file /etc/default/sendmail can be used to disable the receipt of external mail. This file is not included in the initial Solaris 8 release, but it is in one of the update releases, and it is also in the latest patch cluster.

Reguardless of the state of the sendmail daemon on a system, it is critical that the configuration file (usually /etc/mail/sendmail.cf) be properly configured.

SSH

SSH is a secure replacement for telnet and FTP. SSH uses fully encrypted sessions, and allows forwarding of connections (i.e. X11 or FTP forwarding). SSH is discussed more in the section Install Necessary Third Party Packages.

SSH requires that a daemon be running to accept connections. Due to the computational overhead of computing a key pair at startup, this daemon should not be started from inetd.

Syslogd

The syslogd service serves as a way to combine log messages from several sources into a few centrally located log files. It also allows log messages to be sent to another system.

Although the socket that syslogd listens on is a potential security threat, the risks are more than offset by the ability to log information to another system in a timely manner. This ability may provide additional information, in the event of a compromise. For that reason, syslogd should always be used, and, whenever possible, it should be configured to send security related information to another system (i.e. a secured, dedicated log server).

It should be noted that the Solaris 8 syslogd deamon will create a UDP socket for use in sending log information to the remote host, and that the socket will be closed and reopened on a new port every few days. This could cause false positives on a network scan, and on some intrusion detection systems.

If the system will not be receiving messages from another system, then the syslogd daemon should be started with the -t flag. This will cause it to not listen on the UDP socket.

9. Remove the Solaris Installation Leftovers

Much of the information for this section came from a security benchmark by the Center for Internet Security (6).

When the Solaris installation is performed, a significant amount of unnecessary stuff is left behind, which should be cleaned up, to minimize the potential for unauthorized system access and DOS attacks.

Remove reconfiguration scripts.

Three configuration scripts are left behind. The purpose of these scripts is to allow simple reconfiguration, if necessary. The bad news is that these scripts can be triggered just by the creation of a file. Many exploits will allow the creation of such a file. As a result, when the system is rebooted the next time, the startup will be delayed, while the reconfiguration scripts run, and wait for input. Also, when they run, they may destroy some of the previously entered configuration information.

The following commands will keep the system installation configuration scripts from being run at boot time: (NOTE: numbers may not be 30, 71 and 72; please check first with ls /etc/rc2.d/S*sysid.net /etc/rc2.d/S*sysid.sys /etc/rc2.d/S*autoinstall):

 mv /etc/rc2.d/S30sysid.net /etc/rc2.d/_S30sysid.net mv /etc/rc2.d/S71sysid.sys /etc/rc2.d/_S71sysid.sys mv /etc/rc2.d/S72autoinstall /etc/rc2.d/_S72autoinstall

Remove unneeded accounts

Remove any unnecessary accounts from the system. Usually, this will include listen, nobody4, nuucp, smtp and uucp. The command to do this is passmgmt -d ACCOUNT.

If you are running Sendmail 8.12 or higher, do not remove the smmsp account.

Lock system accounts

Any non-root system accounts (UID < 100) should be locked, so that they can't be used as login accounts. The command to do this is passwd -l ACCOUNT. The login shell should also be changed on these accounts. The most secure login shell I know of is /dev/null, but some IDSs use a special shell to warn of intrusion attempts. The command to change the login shell is passwd -e ACCOUNT.

Set directories for NULL accounts

The accounts nobody, noaccess and nobody4 should have their login directories changed to /dev/null. The command to change the login directory is passmgmt -m -h /dev/null ACCOUNT. The login shell for these accounts should also be changed, as above.

Adjust /etc/inittab for system console

As distributed, the /etc/inittab file allows logins from both the console and the serial ports. This should be changed to allow logins on only one of these. If the keyboard is in use, then the serial ports should be disabled by commenting out the line containing /usr/lib/saf/sac. If a serial console is in use, then the keyboard should be disabled by commenting out the line containing /usr/lib/saf/ttymon.

Remove cachefs startup

In most servers, there is no need for the cachefs daemon. If this is the case, the startup script should be disabled. This can be done by the use of the following commands (NOTE: numbers may not be 73 and 93; please check first with ls /etc/rc2.d/S*cachefs.daemon and ls /etc/rc2.d/S*cacheos.finish):

 mv /etc/rc2.d/S73cachefs.daemon /etc/rc2.d/_S73cachefs.daemon mv /etc/rc2.d/S93cacheos.finish /etc/rc2.d/_S93cacheos.finish

Remove preservation of editor sessions

When the system is taken down (or crashes) and an editor (vi) session is active, the keystroke file is left behind. The startup script /etc/rc2.d/S80PRESERVE copies these keystroke files to the /usr/preserve directory, and sends E-mail to the users whose sessions were saved, informing them of the procedure to recover their sessions.

On most servers, there will be little editing, and this step in the startup procedure need not be done. The following commands will disable the saving of keystroke files during startup: (NOTE: number may not be 80; please check first with ls /etc/rc2.d/S*PRESERVE):

 mv /etc/rc2.d/S80PRESERVE /etc/rc2.d/_S80PRESERVE

10. Install Necessary Third Party Packages

Most servers need to have software installed on them that is not part of Solaris, many of which are available as precompiled packages. These can be found on various Internet sites. If you're not sure you can trust the site where you found the package, don't install it. On my Solaris 8 x86 system, the following precompiled packages were added:

 GNUbison GNU bison 1.28 i86pc Solaris 8 GNUgcc GNU gcc 2.95.2 i86pc Solaris 8 GNUgroff GNU groff 1.15 i86pc Solaris 8 GNUm4 GNU m4 1.4 i86pc Solaris 8 GNUmake GNU make 3.78.1 i86pc Solaris 8

On my SPARCstation LX, the same packages were added, but the descriptions were slightly different.

NOTE: The specific packages above are only examples. I installed them on my system, as I prefer to use source releases, whenever possible.

NOTE: Some people prefer to not build packages on the server, but to build them elsewhere, and transfer the installed files. If you have the ability to find every file installed by the package, and a spare system with the same architecture as your server, to do the builds on, this is probably a better idea.

In addition, there are many packages which are available in source form, but are not available precompiled for Solaris. There may also be packages that are available precompiled for Solaris, but with options set that aren't optimum for your installation. In these cases, you will have to locate and download the source package, and compile, test and install it.

When looking for a source package, it is useful to go to the origin site. This is because additional information on the package may be there. The actual package may be retrieved from mirror sites, if it's convenient, as long as the version number is current.

To make upgrades, and patch installation easier, I strongly suggest that you save the commands that you enter to build the packages. Some of these packages are quite complex to build. An example of this is the command sequence I used to build GAS:

 #! /bin/sh echo Building GAS if [ -d binutils-2.10.1 ] then rm -rf binutils-2.10.1 fi cp dist/src/binutils-2.10.1.tar.gz . gunzip binutils-2.10.1.tar.gz tar xf binutils-2.10.1.tar rm binutils-2.10.1.tar cd binutils-2.10.1 ./configure cd bfd make cd ../libiberty make cd ../gas make make install cd ../.. echo GAS Complete

There are several packages that, for security reasons, I suggest be installed on any system. These are:

LSOF

This package is very useful for tracking down possible problems in a system.

SSH

This package (from SSH Communications Security) can be used to replace both telnet and FTP (along with the remote commands: rlogin, rexec, rcp and rsh). It uses fully encrypted sessions. It also allows ports to be forwarded through it, allowing encrypted remote X11 access.

Another version is available from OpenSSH. There is an excellent paper out (12) that covers the installation of OpenSSH on a Solaris system.

SUDO

This package allows a system administrator to give limited super-user permissions to individual users.

TCP Wrappers

This package can be used to filter access to a system, based on the service being requested, and the client host.

Before building TCP Wrappers, change LOG_MAIL to LOG_AUTH, everywhere in the Makefile (it's in several places).

To allow extended option processing, the make command must contain the option STYLE=-DPROCESS_OPTIONS.

The minimum configuration only needs the /etc/hosts.allow file. The first line of the file should be ALL:localhost:ALLOW. The last line should be ALL:ALL:DENY. Placing the line ALL:ALL:DENY into the /etc/hosts.deny file can slightly increase your security.

11. Close the Doors

Many of the items in this section came from two papers by Alex Noordergraaf and Keith Watson (7 and 8), and a document from SUN (9). There is also information here from a web page by Lance Spitzner (3).

Add administrative group

Add the group wheel (or some similar name) to the /etc/group file, making sure that the GID is unique. This will be the group that can perform privileged functions.

Create Administrator Login

Create the login account for the primary administrator. This is not root, but the user that will log in, then su as necessary. Use the useradd command with the -d and -m options to do this. This user should be a member of the administrative group (wheel). Please remember to set a password immediately.

Check setuid files

Check for setuid files, and modify them, as appropriate. The command to check for these files is:

 find / -local -type f -perm -4000 -exec ls -ld {} \;

Some files must be left unchanged (/usr/bin/login, /usr/bin/passwd). Other files may have their group set to the administrative group (wheel), and have their modes changed to 4750 (/usr/sbin/ping, /usr/sbin/traceroute). Still others may be removed. NOTE: A server should be checked for setuid files after patches are updated, and after third-party packages (source or binary) are installed.

The setuid files found on my system, and the action performed, is as follows:

 /bin/su set administrative group /sbin/su.static set administrative group /usr/bin/at set administrative group (1) /usr/bin/atq set administrative group (1) /usr/bin/atrm set administrative group (1) /usr/bin/crontab set administrative group (1) /usr/bin/eject set administrative group /usr/bin/fdformat set administrative group /usr/bin/login leave alone /usr/bin/newgrp leave alone /usr/bin/passwd leave alone /usr/bin/pfexec set administrative group (1) /usr/bin/rcp set administrative group (1) /usr/bin/rdist set administrative group /usr/bin/rlogin set administrative group (1) /usr/bin/rsh set administrative group (1) /usr/bin/i86/ps leave alone (3) /usr/bin/i86/uptime leave alone (3) /usr/bin/i86/w leave alone (3) /usr/bin/su set administrative group /usr/bin/tip set administrative group (4) /usr/bin/yppasswd remove (2) /usr/lib/acct/accton set administrative group /usr/lib/fs/ufs/quota leave alone (4) /usr/lib/fs/ufs/ufsdump set 555 mode /usr/lib/fs/ufs/ufsrestore	set 555 mode /usr/lib/pt_chmod leave alone /usr/lib/sendmail leave alone /usr/lib/utmp_update leave alone /usr/local/bin/lpq leave alone /usr/local/bin/lprm leave alone /usr/local/bin/lpr leave alone /usr/local/bin/lpstat leave alone /usr/local/bin/ssh1 leave alone /usr/local/bin/ssh-signer2	leave alone /usr/local/sbin/lpc leave alone /usr/sbin/allocate leave alone (4) /usr/sbin/deallocate leave alone (4) /usr/sbin/list_devices leave alone (4) /usr/sbin/mkdevalloc leave alone (4) /usr/sbin/mkdevmaps leave alone (4) /usr/sbin/ping set administrative group /usr/sbin/sacadm set administrative group /usr/sbin/i86/whodo leave alone (3) /usr/sbin/traceroute set administrative group

Note 1: For these commands, it might be preferable to create another group (the privileged group), similar to the administrative group, but with more members. The members of the administrative group should also be members of this group.

Note 2: For some reason, SUN leaves this link to /bin/passwd around, even after all the NIS packages have been removed. If NIS isn't being used, this should be removed.

Note 3: These commands are architecture specific. The SPARC versions for a SPARCstation LX are:

 /usr/bin/sparcv7/ps /usr/bin/sparcv7/uptime /usr/bin/sparcv7/w /usr/sbin/sparcv7/whodo

Note 4: For these commands, it might be preferable to place them into a privileged group (see Note 1) and change their mode to 4750, or remove them.

Check setgid files

Check for setgid files, and modify them, as appropriate. The command to check for these files is:

 find / -local -type f -perm -2000 -exec ls -ld {} \;

NOTE: A server should be checked for setgid files after patches are updated, and after third-party packages (source or binary) are installed.

The setgid files found on my system, and the action performed, is as follows:

 /usr/bin/mail leave alone /usr/bin/mailx leave alone /usr/bin/netstat leave alone /usr/bin/passwd leave alone /usr/bin/write leave alone /usr/bin/yppasswd remove /usr/platform/i86pc/sbin/eeprom	set 2550 mode (1) /usr/sbin/i86/prtconf set 2550 mode (1) /usr/sbin/i86/swap set 2550 mode (1) /usr/sbin/i86/sysdef set 2550 mode (1) /usr/sbin/wall set 2550 mode /usr/xpg4/bin/i86/ipcs set 2550 mode (1)

Note 1: These commands are architecture specific. The SPARC versions for a SPARCstation LX are:

 /usr/platform/sun4m/sbin/eeprom /usr/sbin/sparcv7/prtconf /usr/sbin/sparcv7/swap /usr/sbin/sparcv7/sysdef /usr/xpg4/bin/sparcv7/ipcs

Check for world writable files and directories

Check for world writable files and directories, and modify them, as appropriate. The command to check for these files is:

 find / -local -perm -2 \! -type l -exec ls -ld {} \;

NOTE: A server should be checked for world writable files and directories after patches are updated, and after third-party packages (source or binary) are installed.

The world writable files and directories found on my system, and the action performed, is as follows:

 /var/sadm/install/.pkg.lock	set 644 mode /var/adm/spellhist leave alone, or remove /var/mail leave alone on mail server; otherwise remove /var/preserve remove /var/spool/pkg set 750 mode /var/tmp set 1755 mode /tmp set 1755 mode /tmp/.s.PGSQL.5432 leave alone (used by DBMS)

In addition to the above files, there were many device nodes (under /dev and /devices). These are either protected by the device driver, or not in need of protection (i.e. /dev/null).

Check permissions on /tmp and /var/tmp

The permissions on /tmp and /var/tmp should be set, both before and after the file-system mounts are performed. This can be done by entering the following commands:

 echo '#! /bin/sh' > /etc/rc2.d/S00setmodes echo '' >> /etc/rc2.d/S00setmodes echo 'chmod 1755 /tmp' >> /etc/rc2.d/S00setmodes echo 'chmod 1755 /var/tmp' >> /etc/rc2.d/S00setmodes chmod 744 /etc/rc2.d/S00setmodes ln /etc/rc2.d/S00setmodes S02setmodes

Set permissions on /etc/security

Change the mode of the /etc/security directory to 750.

Lock down remote commands

The files /etc/hosts.equiv, /.rhosts and /.netrc should be removed, touched and chmoded to 0. Doing so will lock out the remote commands for root. Some people suggest that these files be removed. I feel that it's easier for an intruder to create a file than it is for them to remove, then create a file.

Other people suggest that empty (mode=0, owner=root) directories be placed here. Using directories, instead of empty files, adds a minor improvement in security, but at an increase in potential confusion.

Disable rhost authentication

In the file /etc/pam.conf, comment out all lines that contain pam_rhosts_auth. If the remote commands (rlogin, rexec, rcp and rsh) have been left in the /etc/inetd.conf file, they will require passwords.

Disable dialup authentication

In the file /etc/pam.conf, comment out all lines that contain pam_dial_auth. If the system has modems connected, do not do this.

Lock down cron and at commands

The cron and at commands should be locked down, so that only those users who have a need of them will be allowed to. To lock these commands down, the /etc/cron.d/cron.allow and the /usr/lib/cron/at.allow files will need to be modified. The following commands will initialize these files for minimal usage:

 echo 'root' > /etc/cron.d/cron.allow echo '' > /usr/lib/cron/at.allow chmod 644 /etc/cron.d/cron.allow /usr/lib/cron/at.allow

If a user needs access to either the cron or at command, their login should be added to the appropriate file.

Enable cron logging

Enable cron logging of executed commands by adding the following line to the /etc/default/cron file.

 CRONLOG=YES

Disable execution of stack

Add the following two lines to the /etc/system file, to disallow execution of instructions in the stack. In 32-bit architectures, this should not be done if debuggers are to be used on the system, as they break debuggers. This is not usually a problem on servers. Also, on x86 architectures, these two lines don't do anything.

The reason for adding these settings is that many buffer overflow problems are related to execution of code on the stack. Although it is possible to exploit a buffer overflow with these settings, it is much more difficult.

 set noexec_user_stack=1 set noexec_user_stack_log=1

Ignore NFS requests from non-privileged ports

Add the following line to the /etc/system file to cause NFS to ignore requests originating on non-privileged ports (over 1024). This change should be made, even if NFS has been disabled.

 set nfssrv:nfs_portmon=1

Inhibit core dumps

Add the following line to the /etc/system file to keep core files from being generated.

 set sys:coredumpsize=0

System crash dumps

System crash dumps can be both good and bad. They can be bad, as they introduce the ability for an experienced Solaris person to extract passwords, or other critical information. On the other hand, they are very helpful for solving problems related to system crashes. If you have either the ability to perform a crash analysis, or a support contract that covers crash analysis, then I feel that the benefit outweighs the risk.

If you have neither the ability, nor a support contract that includes crash analysis, then you should disable copying of crash dumps into /var/crash. This may be done by entering the following commands (NOTE: number may not be 71; please check first with ls /etc/rc2.d/S*savecore):

 mv /etc/rc2.d/S75savecore /etc/rc2.d/_S75savecore

Set query port for Bind Version 8

In Bind version 8, it is possible to set the source port number for queries to remote systems. This should be set to port number 53, by placing the following line into the options section of /etc/named.conf, and restarting named. This simplifies firewall configuration, as allowing port 53 (UDP and TCP) through the firewall is all that's required for DNS to function properly.

 query-source address * port 53

Create ftpusers file

In Solaris, the /etc/ftpusers file is used to limit the users who have access to FTP. As a minimum, root, and all users that have login disabled, should be in this file. If FTP is not to be used on this system, the entire user population should be listed in this file.

Anonymous FTP

Anonymous FTP carries with it special hazards. When running Anonymous FTP, it is important to follow all of the directions included with the FTP package you use.

One additional hazard is that special attention should be paid to any directory in which anonymous users are allowed to have write permissions. If they are also allowed read or directory permissions, your system could easily be subverted for use as a server for unlawful or unwanted data. Although you would be unlikely to face criminal charges, you could easily find that your server is confiscated (at least temporarily) by law enforcement agencies.

Disable IP forwarding

To disable IP forwarding, you should touch the /etc/notrouter file. This file should exist, even if there is only one network interface on your system.

Use random IP sequence numbers

In the file /etc/default/inetinit, change the value of TCP_STRONG_ISS to 2 to generate random sequence numbers, instead of the default randomly incrementing sequence numbers. This change is made for the purpose of combating IP spoofing attacks.

Close off IP security holes

Add the following commands to the /etc/rc2.d/S69inet script (NOTE: number may not be 69; please check first with ls /etc/rc2.d/S*inet). Detailed information on what the individual changes mean can be found in the Solaris Tunable Parameters Reference Manual (9). These commands should be located immediately after the ISS generation is set:

 # Change LOTS of network parameters. This should help to secure # the system against some types of Denial Of Service attacks, and # intrusion attempts. It will also keep us from forwarding Denial # Of Service attacks to other networks. # Combat ARP DOS attacks by flushing entries faster. /usr/sbin/ndd -set /dev/arp arp_cleanup_interval 60000 /usr/sbin/ndd -set /dev/ip ip_ire_arp_interval 60000 # Combat ICMP DOS attacks by ignoring them. /usr/sbin/ndd -set /dev/ip ip_respond_to_echo_broadcast 0 /usr/sbin/ndd -set /dev/ip ip6_respond_to_echo_multicast 0 /usr/sbin/ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0 /usr/sbin/ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0 # Ignore redirect requests. These change routing tables. /usr/sbin/ndd -set /dev/ip ip_ignore_redirect 1 /usr/sbin/ndd -set /dev/ip ip6_ignore_redirect 1 # Don't send redirect requests. This is a router function. /usr/sbin/ndd -set /dev/ip ip_send_redirects 0 /usr/sbin/ndd -set /dev/ip ip6_send_redirects 0 # Don't respond to timestamp requests. This may break rdate # on some systems. /usr/sbin/ndd -set /dev/ip ip_respond_to_timestamp 0 # If a packet isn't for the interface it came in on, drop it. /usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1 /usr/sbin/ndd -set /dev/ip ip6_strict_dst_multihoming 1 # Don't forward broadcasts. /usr/sbin/ndd -set /dev/ip ip_forward_directed_broadcasts 0 # Don't forward source routed packets. /usr/sbin/ndd -set /dev/ip ip_forward_src_routed 0 /usr/sbin/ndd -set /dev/ip ip6_forward_src_routed 0 # Combat SYN flood attacks. /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q0 8192 # Combat connection exhaustion attacks. /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 1024 # Don't forward reverse source routed packets. /usr/sbin/ndd -set /dev/tcp tcp_rev_src_routes 0 # Combat IP DOS attacks by decreasing the rate at which errors # are sent. /usr/sbin/ndd -set /dev/ip ip_icmp_err_interval 1000 /usr/sbin/ndd -set /dev/ip ip_icmp_err_burst 5

There are also places in this script where ip6_ignore_redirect is set to 0. These lines should be commented out.

SUN also has a package called nddconfig that performs these functions. It is one of their BluePrint security tools. It performs most of the functions of the above, but it has been tested to work on all versions of Solaris from 2.5.1 to 8.

Disable Multicast

Multicast is used to send data to multiple locations, using only a single address. If the server doesn't use Multicast (most don't), it should be disabled. This can be done by commenting it out of the /etc/rc2.d/S72inetsvc file (NOTE: number may not be 72; please check first with ls /etc/rc2.d/S*inetsvc). It is near the end of the file, and well commented.

Set up accounting

The system accounting information is very useful for determining the extent of an intrusion. The information stored in the accounting records may indicate what actions were performed by the intruder, thus giving an idea as to the extent of the intrusion, and possibly the reason.

Also, The system accounting information may be useful in monitoring a system for intrusions. This information is used to determine changes in user behavior. As the number of systems being monitored increases, the usefulness of manual monitoring of this data decreases. This is due to the limited amount of time available to check the results.

If the monitoring of accounting data is automated, the usefulness of accounting data for intrusion detection remains high with more systems. To perform this properly would require a complex database system. It would also normally require several months of usage, before it could put out useful information.

As an example, if a user has been using 45MB of their 1GB quota, and their usage jumps to 950MB, then there has been a change that should be checked. This change could be due to a runaway program. It could also be due to an intrusion.

To run accounting, the SUNWaccr and SUNWaccu packages must be installed. Also, the following lines should be added to the crontab for the root user.

 # # The root crontab should be used to perform accounting data collection. # 0 * * * * /usr/lib/acct/ckpacct > /dev/null 2>&1 0 23 * * * /usr/lib/acct/dodisk / /var /usr/local > /dev/null 2>&1 59 23 * * * /usr/lib/acct/runacct > /dev/null 2>&1

The dodisk line should list all file-systems that you want to run disk accounting on. This should include all local file-systems that are normally mounted read/write.

Quotas

Quotas don't help to secure a system against intrusion, but can be used to limit the amount of data that an intruder can store on the system. On the other hand, poorly administered quotas could cause user data to receive lower security than is appropriate.

Quotas are a two-edged sword. Proper usage of quotas (along with user education) will tend to create a cooperative user community, which should tend to reduce the amount of time that a system administrator needs to spend on solving disk space issues. Also, if a user account is compromised, quotas can limit the amount of data that an intruder can store on the system.

On the other hand, by controlling quotas too tightly, and not considering the needs of the users it's possible to create a situation where the users ignore security to find a place to put their files. In extreme cases, this could become a security problem.

In general, normal users shouldn't be writing data in the root, /usr, /usr/local or /var (exclusive of /var/tmp) file-systems. The non-root usage of these file-systems should be static, and the root usage should change slowly, or not at all.

With respect to users, quotas are best used to remind users when it's time to clean up their files, and to keep runaway programs from filling an entire file-system. Currently, disk is so inexpensive that for the effort required to minimize space usage, it would have been cheaper to just buy more disk. Obviously, this philosophy has limits, but if users are often hitting their disk quotas, the system administrator might want to try to determine the root cause for the problem.

NTP

In the NTP configuration file, include the entry restrict default ignore after the servers and/or peers are set. After this, add specific permissions that you want hosts to have.

Enable logging

You should touch the log files /var/adm/loginlog, /var/adm/sulog, and /var/adm/tcpdlog. The daemons think that if the log file isn't there, then they shouldn't do logging.

Enable inetd logging

The inetd daemon posts listens, according to the /etc/inetd.conf file. When a connection occurs, inetd executes the appropriate command, and waits for another connection. By adding the -t option to the inetd invocation (in /etc/rc2.d/S72inetsvc), you can cause inetd to use the syslog daemon to log all connections. The daemon facility is used at the notice priority. This should be done, even if inetd is disabled in /etc/rc2.d/S72inetsvc.

Log FTP sessions

The in.ftpd daemon is executed by the inetd daemon when a connection is made to the TCP port 21 (if FTP is enabled in /etc/inetd.conf). By adding the -l option to the in.ftpd invocation (in /etc/inetd.conf), you can cause in.ftpd to log all sessions via the syslogd daemon. The daemon facility is used at the notice priority. This should be done, even if in.ftpd is disabled in /etc/inetd.conf.

Limit nscd caching

The nscd daemon is used by Solaris to cache frequently used data. This daemon's abilities have grown considerably, since it's inception as a Name Service Cache Daemon. These extra abilities can easily be disabled. It is not suggested that the nscd daemon be disabled, as that can cause severe problems.

A sample /etc/nscd.conf file, which minimizes the functionality of nscd, is as follows:

 logfile /var/adm/nscd.log enable-cache passwd no enable-cache group no positive-time-to-live hosts 3600 negative-time-to-live hosts 5 suggested-size hosts 211 keep-hot-count hosts 20 old-data-ok hosts no check-files hosts yes enable-cache exec_attr	no enable-cache prof_attr	no enable-cache user_attr	no

If your system has any instability with respect to host names and/or IP addresses, it is possible to substitute the following line for all the above lines containing hosts. This may slow down host name lookups, but it should fix the name translation problem.

 enable-cache hosts no

Set mount options

SUN suggests that the nosuid (no setUID) mount option be set on the /var file-system. I feel that this is probably a good idea.

SUN also suggests that the ro (read-only) mount option be set on the /usr file-system. This has good effects, but it requires that additional work be done prior to adding patches. In particular, it requires that the file-system be remounted read-write. This can be done with the /etc/mount -o remount,rw /usr. Unfortunately, the only way to return to read-only is to reboot the system. Since a reboot is often done after patches are installed, the inability to return to read-only could be only a minor nuisance.

They also suggest that whenever possible, other file-systems be mounted with either the ro option, the nosuid option, or, even better, both options. This may be quite difficult, politically.

The ro option might be useful on an archive file-system. The nosuid should always be used on NFS mounted file-systems, and may be appropriate for local file-systems containing users' home directories.

Vold

The vold daemon is used to automatically mount removable media (CDROM, Floppy, Optical, JAZ and ZIP). This simplifies the process of mounting removable media, but creates a potential security issue, if an unauthorized person gains access to the system. Also, this daemon, although potentially useful, is not normally necessary. My advice is to not use it. To disable vold, remove the SUNWvolg, SUNWvolr and SUNWvolu packages.

Also, the /etc/rmmount.conf file should be configured to mount file-systems with the -o nosuid flag set. This flag would be placed on the mount line for the file-system.

Set user file creation mask

In each of the files /etc/.login, /etc/cshrc and /etc/profile, there should be an invocation of the umask command. This invocation should be positioned immediately after the initial comments. The value passed to umask is an octal mask of the mode bits that are not set when a file is created. Acceptable values are 022, 026 (suggested) and 027. Each of these has advantages and disadvantages. Please read the umask manual page prior to selecting the value to be set.

Set FTP file creation mask

Add the following line at the end of the /etc/default/ftpd file. If there is another line for UMASK, it should be commented out. This line contains the default umask value that will be used by FTP when a file is created. The value shown here is for demonstration purposes only. The umask value chosen for the user file creation mask (above) should be used.

 UMASK=026

Set system startup file creation mask

The default umask during system startup should be changed from 000 (022 in Solaris 8) to 077. This change can be done by entering the following commands:

 echo '#! /bin/sh' > /etc/rc2.d/S00UMASK.sh echo '' >> /etc/rc2.d/S00UMASK.sh echo 'umask 077' >> /etc/rc2.d/S00UMASK.sh chmod 744 /etc/rc2.d/S00UMASK.sh

Set the PROM security mode

For SPARC systems, use the eeprom Solaris command, or the setenv OpenBoot command to set the security-mode variable to either command or full. It should be noted that on some systems, setting security-mode to full will disable auto-boot.

For a PC, the BIOS usually has a value that can be set to require a password prior to booting, or prior to entering BIOS. The procedures for this are different from system to system. Setting the BIOS to require a password prior to booting will disable autoreboot.

Set the PROM password

For SPARC systems, use the eeprom Solaris command, or the setenv OpenBoot command to set the security-password variable to the password you'd like to use. NOTE: If you forget this password, it is very difficult to reset, and will usually require a service call.

For a PC, the BIOS usually has a password that can be set. The procedures for this are different from system to system. NOTE: If you forget this password, you will have to reset all the BIOS parameters to factory default to clear the password, which will require setting a jumper on the motherboard.

Disable keyboard abort

For SPARC systems, you may want to disable the keyboard abort sequence (L1-A). If the system hangs, this will require a power cycle to initiate a reboot. If you want to do this, use the eeprom Solaris command, or the setenv OpenBoot command to set the keyboard_abort variable to disable. This may not be available in older systems.

12. Obscure the Tracks

The goal for this step is to locate the source of messages that a potential intruder can receive, and do whatever can be done, to make them as generic as possible. Remember, any message your computer sends may be used against it.

Apache

After the ServerType line, there should be a line that says ServerTokens Prod. This change will remove the Apache version number and the list of available modules from responses.

Bind (version 8)

In the options section, add the line version "DNS";. This string (DNS) will be given out as the server description.

FTP

This information is covered in the Post the Warnings section.

Sendmail

In the .mc file that is used to generate the sendmail.cf file, set the confSMTP_LOGIN_MSG variable to be $j Sendmail; $b. This change will remove the sendmail version number from responses.

If you are using the default SUN sendmail, then the configuration file (usually /etc/mail/sendmail.cf) should be modified, setting the variable SmtpGreetingMessage to $j Sendmail; $b.

Telnet

This information is covered in the Post the Warnings section.

SSH

When using the -v flag of ssh, I know of no way to disable the version number exchange, short of modifying the code.

13. Post the Warnings

This section describes how to post warnings so that they will be seen by users. I strongly suggest that the exact wording of these messages be checked by your legal department.

/etc/default/telnetd

Add the following line at the end of this file. If there is another line for BANNER, it should be commented out. This line contains a message that will be displayed when a telnet connection occurs. This should be done, even if telnet is disabled.

 BANNER="\r\nWARNING: Authorized use only. Usage may be monitored.\r\n\r\n"

/etc/default/ftpd

Add the following line at the end of this file. If there is another line for BANNER, it should be commented out. This line contains a message that will be displayed when a FTP connection occurs. This should be done, even if FTP is disabled.

 BANNER="\r\nWARNING: Authorized use only. Usage may be monitored.\r\n\r\n"

/etc/motd

Place the following message (or a similar one) into this file. It contains a message that will be printed after a successful login.

 This is a private computer facility. Access for any reason must be specifically authorized by the owner. Unless you are so authorized, your continued access and any other use may expose you to criminal and/or civil proceedings. Usage may be monitored.

/etc/issue

Place the following message (or a similar one) into this file. It contains a message that will be printed during the login process.

 This is a private computer facility. Access for any reason must be specifically authorized by the owner. Unless you are so authorized, your continued access and any other use may expose you to criminal and/or civil proceedings. Usage may be monitored.

NOTE: The users may see both the /etc/motd and the /etc/issue messages when they login.

Boot PROM

The SPARC Boot PROM can store a warning message, to be displayed at boot time. This message is stored in the oem-banner environment variable, which should be set as follows:

 This system property of ABCD Corp

Please remember to replace the company name (ABCD Corp) with the name of your company.

14. Perform System Backups

System backups of servers should be done on a regular basis. The backups of the system file systems should be done to non-networked media that can be read after performing only a CORE install, or even better, from the boot CDROM. Networked backup usually requires that much more than the CORE install be done to perform a restore, and therefore may not be appropriate for the system file-systems (i.e. root, /usr and /var).

Additionally, if an intrusion occurs, there is no guarantee that you will be able to identify all the files that have been modified. For that reason, the suggested resolution is to either reinstall from scratch, or to rebuild from backups that you know to be from prior to the intrusion.

15. Watch for Changes

Install a package to inform you about changes to configuration files, and other critical files (executables and shells). There are several packages available to do this.

ASET: ASET is a SUN package for Solaris (SUNWast). It's fairly good, but the SUN security experts recommend against using it. The reason for this was not obvious from the message. Based on this, I wouldn't use it.
Axe Handle: This is a set of scripts that I created. Their purpose is to look for the results of a successful intrusion. This tool examines files and network status. These scripts are available for use under the GNU Public License.
COPS: This tool was developed at Purdue University. It primarily searches for new security problems in a system, but is also useful in securing a system initially.
Tripwire: Tripwire is the most frequently used intrusion detection tool. It is available in both commercial and freeware versions.

For those with a bit less paranoia (or a bit more scripting / programming skill), a simple set of scripts could be constructed to perform similar functions. I have done this, and found that it only takes a few hours to create a rather flexible, and powerful, tool. The advantage provided is that you will know exactly how it works.

Now, it is time to reconnect your system to the network. All reasonable security measures have been put in place, along with the appropriate monitoring tools.

16. Sources of Tools

Here are some tools that you may find useful in securing your Solaris server. In general, I don't like to use tools to perform this function. The reason is that I like to know what changes were made, so that they can be monitored. Most tools hide the details of their actions, so that you don't know what was changed, and can't monitor the changed files, to determine if an intrusion has occurred.

fix-modes

Fix-modes was created by Casper Dik to adjust the permissions of several files and directories in Solaris, for the purpose of improving security. It is available from ftp://ftp.wins.uva.nl/pub/solaris/fix-modes.tar.gz.

It is also available from SUN, under http://www.sun.com/blueprints/tools.

JASS Toolkit

The JASS toolkit was developed by SUN to simplify building secured Solaris systems. It is available from http://www.sun.com/blueprints/tools. There exists good documentation for the current release (0.3) of this toolkit. The best of the documents is the Internals document (11). This document provides fair detail as to what the toolkit actually does.

If you choose to use the JASS toolkit, please be aware that it will be necessary to verify that the changes you made previously are still in place after JASS runs.

Titan

The Titan toolkit was created by Brad Powell to fix or tighten potential security holes in UNIX (Solaris, Linux and FreeBSD). It is available from http://www.fish.com/titan.

Here is a short list of web sites that you may find useful.

sunsolve.Sun.COM/pub-cgi/show.pl?target=home - SUN Recommended & Security Patches
web.mit.edu/kerberos/www - Kerberos home page
www.auscert.org.au - Australian Computer Emergency Response Team
www.cert.org - CERT Coordination Center
www.cisecurity.com - The Center for Internet Security
www.fish.com - Dan Farmer's web site with lots of computer security related stuff
www.ibiblio.org/pub/solaris/sparc - Solaris Package Archive (SUNSite)
www.infrastructures.org/cfengine - Cfengine
www.rootprompt.org - Root Prompt -- Nothing but Unix
www.sabernet.net/papers/Solaris.html - Solaris Security Guide
www.sans.org - SANS Institute
www.securityfocus.com - SecurityFocus
www.solarisguide.com - SolarisGuide.com
www.sun.com/bigadmin - Sun Large System Administration
www.sun.com/blueprints - SUN Blueprints
www.sun.com/security/blueprints - SUN Security Blueprints
www.sun.com/security/jass - Additional information on the SUN JASS toolkit
www.sunfreeware.com - Sunfreeware

Bibliography

1. Building Internet Firewalls by Elizabeth D. Zwicky, Simon Cooper and D. Brent Chapman (ISBN 1-56592-871-7).
2. Minimization for Security: A Simple, Reproducible and Secure Application Installation Methodology by Alex Noordergraaf.
3. Armoring Solaris and Armoring Solaris: 2 by Lance Spitzner.
4. Kerberos - A Network Authentication System by Brian Tung (ISBN 0-201-37924-4).
5. Managing NFS and NIS by Hal Stern, Mike Eisler and Ricardo Labiago (ISBN 1-56592-510-6).
6. Center for Internet Security Solaris Security Benchmark
7. Solaris Operating Environment Security by Alex Noordergraaf and Keith Watson.
8. Solaris Operating Environment Network Settings for Security by Alex Noordergraaf and Keith Watson.
9. Solaris Tunable Parameters Reference Manual
10. Solaris Security by Peter H. Gregory (ISBN 0-13-096053-5).
11. The Solaris Toolkit - Internals by Alex Noordergraaf and Glenn Brunette.
12. Building and Deploying OpenSSH for the Solaris Operating Environment by Jason Reid and Keith Watson.

To contact ACCS:

P.O. Box 948316
La Jolla, CA 92037-8316
Phone: (858) 689-ACCS
Email: sales@accs.com

If you have comments or suggestions, please E-mail webmaster@accs.com

Bienvenue sur le site admin-sys

Suppression des services réseaux "inutiles" en Solaris 10

JASS

Securing a Solaris 8 Server : guide 2

Securing a Solaris 8 Server : guide 1

Securing a Solaris 8 Server

Table of Contents:

1. Introduction

2. History of this Web Page

3. Overview

4. Network Topology

5. System Hardware Configuration

System Placement

Disk Layout

Disk Channels

Channel Contention

IDE Channels

SCSI Channels

Fiber Channels

Drive Contention

File-system Layout

Swap

Network Connectivity

6. Initial Installation

7. Minimizing Solaris

8. Minimizing Network Services

9. Remove the Solaris Installation Leftovers

10. Install Necessary Third Party Packages

11. Close the Doors

12. Obscure the Tracks

13. Post the Warnings

14. Perform System Backups

15. Watch for Changes

16. Sources of Tools

Bibliography