Computer Protection Program Berkeley Lab
Computer Protection Program at Berkeley Lab Security
Ernest Orlando Lawrence Berkeley National Laboratory
Emergencies | Site Index | Contact Us
CPP Home
Contacts
Policy Guidelines
Scan Information
System Procedures
Tools & Services
ALERTS
Recent CPP Actions
News & Articles
CPP Intranet
 
 
  PROCEDURES FOR SECURING SYSTEMS  
Solaris 7 – 9 Security Guidelines [1]  

 

Introduction

 

Over the years the out-of-the-box security configuration for Solaris releases has improved considerably from a security perspective. It is nevertheless necessary to make numerous changes to Solaris systems to harden them sufficiently to enable them to resist the kinds of attacks (external and internal) that they are most likely to face. Following the steps in these guidelines will bring Solaris 7 – 9 systems up to a baseline level of security.

 

Baseline Security Measures

 

These guidelines are intended to produce a level of security that represents a reasonable balance between security and functionality/usability in Solaris systems. These guidelines describe steps to be taken including: providing adequate physical security, securing accounts and groups, securing your host's file system, securing services that run on your host, configuring logging, patching your system, and other performing additional important actions.

 

A.     Host-based and Physical Security

 

1.  If possible, put your host in a physically secure area, i.e., a server room with restricted access (such as via a card reader or combination lock).

 

2.  Secure access to boot level by assigning a strong PROM password. To do this use the eeprom command to set the security mode to “command” and then set the password.

 

3.  Change the boot sequence so that the hard drive is first. You can do this by defining the boot-device parameter in eeprom.

 

4.   Use a screen saver that requires a password. Use “lock screen” on the OpenWindows menu, or click on the lock symbol on the CDE menu bar. Additionally, set the screen saver to activate automatically after a fixed period of inactivity in Properties (OpenWindows) or Settings (CDE).

 

5.   List only the ttys that are allowed to login as root in /etc/securetty.

 

 

B. Securing Accounts and Groups

 

1.   Disable unnecessary accounts by locking them and/or assigning an invalid shell. The following accounts should normally be locked and/or disabled:

 

adm

bin

daemon

listen

lp

nobody

nobody4

noaccess

nuucp

smtp or smmsp (in Solaris 8 and 9)

sys

uucp

 

You can lock an account named “user6” by changing the entry for this account in /etc/shadow to:

 

user6:*LK*
 
OR
 
user6:*NP*

 

OR you can disable this account by assigning a shell of /bin/false in /etc/passwd:

 

foo:*:536:40:Ben Foo:/home/foo:/bin/false

 

(Note that many Solaris system administrators prefer noshell (e.g, /sbin/noshell) to /bin/false for reasons described at http://www.fish.com/titan/TITAN_Solaris9.html, which is also the site from which you can download the noshell program.)

 

2.   If your host runs the ftp service, disallow ftp access via disabled user accounts. Do this by creating /etc/ftpusers and then adding all of the following accounts to this file:

 

adm

bin

daemon

listen

lp

nobody

noaccess

nobody4

nuucp

root

smtp

sys

uucp

 

3.   Allow root access to as few other users (ideally only two or three people) as possible. Only users who are assigned system administration responsibilities should be allowed root access.

 

4.  Create a very difficult-to-guess password for all accounts, but especially the root account. See http://www.lbl.gov/ITSD/Security/systems/passwords.html#choose for guidelines concerning how to create a good password. To change a password for an account, enter:

 

% passwd <loginname>

 

Ensure that only one account, root, has a UID of 0. (Note that in some instances the smtp or smmsp account will need to have a UID of 0, too.)  Check this by entering:

 

# awk –F: ’$3 == 0’ /etc/passwd

 

This will print out only the password file lines that have UID 0.

 

The UID field is the third field in each line. Note that in the following example more than one account with a UID of 0 exists, something that should be corrected by changing the UID for the admin account to something other than 0.

 

root:*:0:0:root:/:/bin/sh

kjs:*:159:33:Wanda Smith:/home/smith:/bin/csh

admin:*:0:0:alternate root user:/:/bin/sh

 

6.  To limit who can use the su command, create a “wheel-like” group:

 

   # chgrp root /usr/bin/su

   # chmod o-x /usr/bin/su

 

Allow only users with root access to be in the root group.

 

7.   Ensure that there is an x in the second field of every line in /etc/passwd to ensure that the /etc/shadow file will be used for all access to passwords.  Note that if you run pwconv on Solaris, this will put the x in the appropriate place for each entry in /etc/passwd and will also create /etc/shadow. You will need to run pwconv after every new account is created if you are using shadow passwords.

 

8.   Ensure that there are no logins in which a password does not need to be entered by verifying that the following entry is in /etc/default/login:

 

PASSREQ=YES

 

      If this entry does not exist, add it.

 

9.   Check for accounts that do not require passwords by entering:

 

   logins –p

 

Ensure in particular that if the following default accounts exist, they are passworded (or have logins disabled):

 

demos

guest

 

10.  To ensure that passwords will be at least eight characters long (and thus more difficult to crack) and that they will be changed every 180 days, set PASSLENGTH=8 and MAXWEEKS=26 in /etc/default/passwd.

 

11.  Delete all entries in /var/spool/cron/crontabs for all deleted and disabled accounts. 
 
12. Assign appropriate permissions to restrict access to /var/spool/cron to only those who have an appropriate business-related need. 
 

 

C. Securing the File System [2]

 

1.   Ensure that root owns all files that it uses, in particular, all binaries that it uses.

  

2.   To the maximum possible extent, avoid having any file and/or directory be world-writeable. Use the chmod command to change permissions accordingly.

 

3.   Inspect all system files and directories do not allow any unnecessary read, write and/or execute access to group owner and world.

 

4.   Remove the SUID and SGID bits from all executables for which having these bits set is not clearly justifiable from a business/operational standpoint. To find all SUID files enter:

 

# find / -user root -perm -4000 -print

 

To find all SGID files enter:

 

# find / -user root -perm -2000 –print

 

To unset the SUID bit for an executable, foo, enter:

 

# chmod u-s foo  OR  chmod 0XXX

 

To unset the SGID bit for a file, foo, enter:

 

# chmod g-s foo 

 

      OR 

 

# chmod 0XXX foo

 

5.   To prevent users other than the owner of files in a temporary directory (/tmp and /var/tmp) from modifying or deleting them without authorization, ensure that the sticky bit is set in each. To set the sticky bit in the /tmp directory, for example, enter:

 

# chmod 1777 /tmp 

 

        OR

 

# chmod o+t /tmp

 

D. Securing Services

 

1.   Disable every service that is not necessary for business/operational purposes. When you evaluate which services are necessary, pay particular attention to the following services, in which vulnerabilities are generally exploited more than in other services:

 

uucp

echo

discard

daytime

chargen

sprayd

walld

exec

talk

finger

telnet

comsat

cmsd (calendar manager daemon)

kcms_server

cachefsd (cache file system daemon)

dtspcd (desktop subprocess control daemon)

sadmind

tooltalk

snmpXdmid

bootp

tftp

ftp (unless your host must be an ftp server)

http (unless your host must be a web server)

every r utility (rusers,  rquotad, rsh, rlogin, and so on)

 

You can disable some unnecessary services by disabling the startup file (if it exists) for each service that is unnecessary. Go to /etc/rc2.d and /etc/rc3.d. and change the capital “S” in the name of the script to a lowercase “s” to disable each service. (Note: in some system administrators’ thinking “s” is too close to “S;” they thus use “d” instead of “s” to disable scripts that start services.)

 

You should NOT disable any of the following startup files:

 

S01MOUNTFSYS

S05RMTMPFILES

S20sysetup

S30sysid.net

S69inet

S71rpc

S71sysid.sys

S72inetsvc

S74autofs

S74syslog

S74xntpd

S75cron

S75savecore

S80PRESERVE

S88utmpd

S99audit

 

Additionally, comment out the names of any unnecessary services in /etc/inetd.conf. To be sure that changes are made, enter:

 

# /etc/telinit -q

 

And then reboot [3] by entering:

 

# init 6

 

2.   Ensure that each startup script runs with the proper umask by running the following script as root:

 

umask 022

echo “umask 022” > /etc/init.d/umask.sh [4]

chmod 544 /etc/init.d/umask.sh

for d in /etc/rc?.d

do

ln /etc/init.d/umask.sh $d/S00umask.sh

done

 

3.   Use ssh for remote logins in lieu of more dangerous services such as telnet, rlogin, rsh, and rcp. For information about configuring and using ssh visit http://www.lbl.gov/cyber/systems/ssh.html#unix. 

 

If possible, allow inbound connections via sshd, not inetd. To render inetd inoperable, comment out every line in /etc/inetd.conf Also, turn off by renaming S72inetsvc, which contradicts your information above about not renaming it.

 

4.   Use a TCP wrapper to limit inbound connections based on type of service and IP address and to provide additional log data concerning attempted connections to your host. In /etc/default/inetd change the default entry for the ENABLE_TCPWRAPPERS to YES, i.e.:

 

ENABLE_TCPWRAPPERS=YES

 

Create the following entry in /etc/hosts.deny:

 

ALL: ALL

 

Create entries in /etc/hosts.allow for all hosts allowed to have inbound access, e.g.:

 

ALL: LOCAL @<netgroupname>

 

OR

 

ALL: .lbl.gov EXCEPT secure1.lbl.gov

 

If you want tcpwrappers to deliver even higher levels of security, tcpwrap each individual service by making the appropriate entries in /etc/hosts.allow. You might, for example, tcpwrap sshd as follows:

 

sshd: .lbl.gov

 

To enable TCP wrapper logging (a potentially very valuable source of information, since attackers often forget to erase TCP wrapper log data) insert the following entry:

 

ENABLE_CONNECTION_LOGGING=YES

 

Finally, enter:

 

# /etc/telinit -q

 

5.   Secure NFS. NFS is one of the most useful services on Solaris, but, unfortunately, it is also one of the most dangerous (if not the most dangerous) services from a security perspective. If your Solaris machine is a workstation, you do not need export file systems; turn NFS off. Similarly, if you run a server, but do not need NFS, turn it off. Turn NFS off by entering:

 

# /etc/init.d/nfs.server stop

 

Now go to /etc/rc3.d and find the following file:

 

S15nfs.server

 

Change the capital “S” to a small “s” (or, as mentioned previously, a small “d”). 

 

Remove all entries in /etc/dfs/dfstab

 

If you need to run NFS, do not allow read-write mounts [5] unless there is a strong business/operational justification for doing so. Additionally, make all NFS-mountable volumes nosuid mountable [6] and specify the “secure” option (to run Secure NFS, which is somewhat more secure than conventional NFS). The following entry in /etc/dfs/dfstab would be appropriate:

 

/usr/bin   -ro –nosuid -secure -access=myhost.lbl.gov

 

File systems should not be exported with -anon=0.

 

After editing /etc/dfs/dfstab, ensure that changes take effect by entering:

 

# shareall

 

If you choose the “secure” option in your NFS server, you must also specify “secure” in the options field of /etc/vfstab in each client

 

<servername>:/usr/bin    nfs ro,secure 0 0

 

Finally, to enforce access checking, it is very important that you enable nfs requests from privileged ports. To do this, add the following entry in /etc/system:

 

set nfssrv:nfs_portmon = 1

 

6.   Secure NIS. NIS, like NFS, is extremely dangerous; do not run it unless there is strong business/operational justification for doing so. If it is necessary to run NIS, add a  /var/yp/securenets file to restrict the hosts that are allowed to contact your NIS daemons. The following is an example of some possible securenets entries for a host within the 128.3.9 subnet:

 

255.255.255.0         128.3.9.255 

host                  128.3.7.15 

host                  131.243.14.2

host                  131.243.223.116 

 

Afterwards you must stop and restart the ypserv and ypxfrd daemons

 

If possible, do not include root in the yppasswd file [7] . Instead, system administrators should, for the sake of security, access every host within an NIS domain via local root accounts.

 

Avoid doing unduly dangerous things such as placing user home directories on the NIS master. Additionally, do not run additional services such as Web services on the NIS master

 

7.   Secure anonymous ftp.

 

(Note: If possible, use vsftpd instead, because it is designed specifically for security and speed. You can download vsftpd from http://vsftpd.beasts.org).  You might mention that the Sun man page for ftpd tells how to securely setup ftpd)

 

Avoid putting the real password file in the anonymous ftp directory. Asterisk out password fields in ftp's /etc/passwd and /etc/group files

 

Put files available via anonymous ftp in an ftp home directory

 

Ensure that ftp directory is chrooted by entering:

 

# chroot /ftp

 

Allow only group access in ~ftp/etc/group       

 

Directory permissions should generally be 755. Avoid world-writeable directories except for anonymous FTP; in this case world-writeable directories are OK if they are not world-readable as well. Generally, incoming directories should be only writeable, whereas outgoing directories should be non-writeable.

 

etc,  bin and anonymous ftp root directory should not be owned by ftp (the recommended owner is root)

 

.netrc (which contains login and initialization information for use by ftp's auto-login process) should be readable only by owner (root)

 

Statically link all libraries used by anonymous ftp

 

Disable certain ftp services: chmod, mkdir, and mknod

 

In wu-ftpd, consider enabling the noretrieve option in the ftpaccess file (to prevent certain downloads)

 

8.   Secure sendmail [8] . If you do not have a policy exception in writing from the Lab Director to run a mail server, enter

 

# ps –elf | fgrep sendmail

 

to confirm that it is not running. If it is running, you can turn it off by entering:

 

# /etc/init.d/sendmail stop

 

Now go to /etc/rc2.d and find the following line:

 

S88sendmail

 

Change the capital “S” to a small “s.”

 

If you require incoming email support, you should upgrade to as new a version of sendmail as possible (8.12.X) or run postfix, a much more secure SMTP server. Postfix is available from http://www.postfix.org.

 

If you do not require incoming email support, but need to run sendmail on behalf of a mail client such as elm, remove the -bd flags in /etc/init.d/sendmail. Other machines will no longer be able to send mail to your host. Configure /etc/sendmail.cf as follows:

 

#Minimal client sendmail.cf

### Defined macros

# The name of the mail hub--insert appropriate hostname for your site

Drmailhost

# Define version

V8

#Whom errors should appear to be from

DnMailer-Daemon

# Formatting of the UNIX from line

D1From $g $d

#Separators

Do.:%@!

# From the sender’s address

Dq<$g>

# Spool directory

QQ/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 they are not used

Mlocal, P=/dev/null, F=rlsDFMmnuP, S=0, R=0, A=/dev/null

Mprog,  P=/dev/null, F=lsDFMeuP, S=0, R=0, A=/dev/null

###Rule sets -- whitespace between columns must be tabs!

S0

R@S+        S#error $: Missing user name

R$+         S#hub $@$R $:$1       forward to hub

 

S3

R$*<>S*     $n                 handle <> error parsing

R$*<S*>S*   $2                 basic RFC822 parsing

 

9.   Secure snmp. If you do not need snmp, use pkgrm to delete all of the following packages and then reboot:

 

SUNWmibii

SUNWsacom

SUNWadmi

SUNWsasnm

 

10. Secure xdm. Never enter xhost +   To prevent unauthenticated access through xdm, add xhost- in the following files in /var/X11/xdm:

   

xsession

Xsession-remote

Xsession.dt

 

To install a replacement to xhost that does not permit entering xhost +, perform the following steps:

 

cd /usr/X11/bin

mv xhost xhost.orig

 

Now create a script named “xhost” with owner/group root/root and a permission of 755:

 

#!/bin/sh

 

for i

do

    [ "$i" = "+" ] && { echo "xhost: + not permitted" 1>&2; exit 1 }

done

exec /usr/X11/bin/xhost.orig "$@"

 

Modify /usr/lib/X11/xdm/xdm-config to include:

 

DisplayManager*authorize:     on

 

To prevent any system from obtaining a login window, replace the initial two lines that start with a * in /var/X11/xdm/Xaccess with !*  To protect against having X connect to unauthorized hosts, remove any /etc/X* files.

 

Ensure that /usr/bin/X11/* is not world-writeable by entering:

 

# ls -al /usr/bin/X11

 

Confirm that no file in this directory has the write bit set for world.

 

Finally, reboot (or restart X-Windows).

 

11. Install rpcbind with libwrap enabled and then use the /etc/hosts.allow file to specify systems from which portmap and rpcbind allow RPC requests. Download the rpcbind software from http://www.eits.uga.edu/wsg/sun/security/wrapped_rpcbind.html. 

 

Note that installing patches may overwrite /etc/hosts.allow, so it is important to have a backup copy.

 

12.  Back up your system regularly.

 

13.  Insert the following entries in /etc/default/login:

 

# This permits root logins only on specified devices--commenting out altogether disables

# all remote root logons

CONSOLE=/dev/console 

# The time in seconds it takes for login to be disabled after LOGFAILURES or the

# MAXTRYS limit is reached

DISABLETIME=30 

# The number of bad logins before a login exit

MAXTRYS=3  

# This requires selection/entry of password at next login if there is none

PASSREQ=YES

SYSLOG=ALL

UMASK=077

 

E. Configuring Logging

 

1.   To obtain a sufficient amount of security-related log data, add the following lines [9] to /etc/syslog.conf:

 

*.warn                     @<loghost_address>

authpriv.*;auth.*         @<loghost_address>

 

2.     To conform to the Computer Protection Program’s requirement to send syslog data from Unix hosts to a central log repository, add the following lines to /etc/syslog.conf:

 

*.*          @syslog.lbl.gov

 

3.   Log failed login attempts by creating the /var/adm/loginlog file and then assigning the appropriate ownership and group ownership:

 

# touch /var/adm/loginlog

# chown root /var/adm/loginlog

# chgrp sys /var/adm/loginlog

 

4.   In Solaris 8 and 9 ensure that syslogd does not listen on udp port 514 by setting the –t flag in/etc/rc2.d/S74syslog:

 

# /usr/sbin/syslogd –t > /dev/msglog 2>&1

 

OR—in Solaris 9 you can prevent syslogd from listening by changing the LOG_FROM_REMOTE line in /etc/default/syslog as follows:

 

LOG_FROM_REMOTE = NO

 

5.   Set permissions for the log files that will keep everyone but the owner (root) from accessing them:

 

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

 

6.   To keep world from reading syslog and cron logs, set the permission for /var/spool/cron/crontabs/root to 700 (or possibly 740) by entering:

 

# chmod 700 /var/spool/cron/crontabs/root

 

7.   In Solaris 9 configure log files to be rotated daily, archiving old versions for 30 days by entering:

 

# /var/log/syslog –A 30d –p ld –z 1 –a ‘kill –HUP `cat \ /var/run/syslog.pid`’

# /var/adm/messages –A 30d –p ld –z 1 –a ‘kill –HUP `cat \ /var/run/syslog.pid`; \

# logger –t logadm Begin new logfile’

 

F. Patching Your System

 

Ensure that the latest patches are installed [10] . Current Solaris patch sets are available from the SRC or from http://sunsolve.sun.com. One of the easiest ways to install patches is to install the Solaris Patch Manager Tool, which is bundled with Solaris 9 and can be obtained for free for Solaris 7 and 8, go to http://www.sun.com/service/support/sw_only/patchmanager.html.

 

G. Other Measures

 

1.   Avoid creating trusted host files (~.rhosts and /etc/hosts.equiv) and using ssh agent for remote access to your host.

 

2.   Protect against stack smashing attacks and log any such attempts by inserting the following lines in /etc/system:

 

set noexec_user_stack=1

set noexec_user_stack_log=1

 

Now reboot your host by entering the command:

 

# init 6

 

3.   Prevent services that inetd executes from creating core files by running the following command as root in a startup script:

 

# ulimit –c 0

 

4.   Create /etc/init.d/nddconfig and link it to /etc/rc2.d/S70nddconfig by entering the following as root:

 

# touch /etc/init.d/nddconfig

# ln /etc/init.d/nddconfig /etc/rc2.d/S70nddconfig

 

5.   Set appropriate kernel parameters for /dev/ip by entering the following commands:

 

ndd -set /dev/ip ip_respond_to_echo_broadcast 0
ndd -set /dev/ip ip_forward_directed_broadcasts 0
ndd -set /dev/ip ip_respond_to_timestamp 0
ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
ndd -set /dev/ip ip_forward_src_routed 0
ndd -set /dev/ip ip_ignore_redirect 1

 

6.   Because the default port range allows easy access to RPC services even without rpcbind access, change the ephemeral port range. Use ndd as follows:

 

# /usr/sbin/ndd –set /dev/tcp tcp-smallest_anon_port \ <port_number> [11]

# /usr/sbin/ndd –set /dev/tcp tcp/largest_anon_port <port_number> [12]

 

7.   Ensure that strong (difficult-to-guess) TCP sequence numbers are generated by inserting the following entry in /etc/default/inetinit:

 

TCP_STRONG_ISS=2

 

8.   Disable IP forwarding by creating /etc/notrouter.

 

9.   To help prevent newly-created files that are world-writeable (and also group-writeable), set a default umask value of 022 by inserting the following entry in /etc/default/login:

 

umask 022

 

10.   Ensure the time is running correctly. You can add a root crontab entry to run rdate a minimum of once per day

 

rdate tic.lbl.gov  

 

OR   

 

rdate toc.lbl.gov

 

Alternatively, stop ntpd (in Solaris 7 and 8) and xntpd (in Solaris 9) by entering:

 

# /etc/init.d/ntpd stop

 

OR

 

# /etc/init.d/xntpd stop

 

Next specify time servers by adding a line specifying the IP address for each in /etc/inet/ntp.conf:  

 

server <IP_address> 

 

Now restart ntpd or xntpd by entering:

 

# /etc/init.d/ntpd start

 

OR

 

# /etc/init.d/xntpd start

 

11.   Run Tripwire (available from http://cerias.purdue.edu/tools/unix)or AIDE (available from http://www.sunfreeware.com) to check the integrity of critical files and directories.

 

12.   Backup your system as often as needed.

 

13.   Download and run the Center for Information Security’s Solaris security benchmark tool once a month from http://www.cisecurity.org/bench_solaris.html.

 

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

 

NOTICE TO USERS: Lawrence Berkeley National Laboratory operates this computer system under a contract with the U.S. Department of Energy. It is the property of the United States Government and is for authorized use only. The use of this system may be monitored for computer security purposes. Any unauthorized access to this system is prohibited and is subject to criminal and civil penalties under Federal Laws including but not limited to Public Laws 83-703 and 99-474. Each time you use this system (from here, from home, access, and copy files from a non-LBNL system), you consent to such interception, auditing, and related activity by authorized personnel; further, LBNL may detain, access, and copy files from a non-LBNL computer when there is reason to believe misuse has occurred. 

 

You can also use TCP wrappers to display a warning banner for each service your Solaris host offers. See:

http://www.lbl.gov/cyber/systems/install-banner.html#tcp. Note also that if your Solaris host runs an ftp server, you may also be able to display a warning banner by inserting the warning banner text in a line that begins with “banner=” in /etc/default/ftpd. See the man pages for your Solaris release as well as for your particular ftp server to find out more about this and other possibilities.

 

On-line Resources

 

http://csrc.nist.gov/pcig/CHECKLISTS/01-20-2004-DOT-SBCS-Solaris.doc

http://www.fish.com/titan/TITAN_Solaris9.html

http://www.sabernet.net/papers/Solaris.html

http://www.securitydocs.com/library/632

http://www.spitzner.net/armoring.html

http://sunsolve.sun.com/

http://www1.umn.edu/oit/security/guidelines.htm

http://www.vccs.edu/its/security/Security_Guidelines_for_Unix.htm



[1] These guidelines were written by Gene Schultz of Berkeley Lab’s Computer Protection Program. Jim Mellander, Don Varner, Jacquelin Scoggins, Susan James, Martin Boswell, and Dan Klinedinst, also of Berkeley Lab, provided a great deal of valuable advice and feedback.

[2] In a nutshell, applying the “least access” principle—giving each user only the level of access needed to perform job-related duties—is the major principle of file system security. 

[3] All things considered, rebooting is generally better from a security perspective because it verifies that services did not restart. Also, Solaris cluster patches are notorious for re-enabling services such as sendmail. Also remember, however, that rebooting is also potentially disruptive.

[4] The .sh extension is important; be sure to not omit it.

[5] /usr in particular should be read-only mountable. 

[6] Note, however, that nosuid is ineffective for / unless /dev and /devices are mounted separately. 

[7] If root in the yppasswds

[8] Re-inspect sendmail’s configuration after every patch set. Patches often reactive sendmail.

[9] Be sure to use tabs, not spaces, to separate the fields.

[10] Note that a reconfiguration boot (boot –r) following a patch install is necessary for kernel changes to take effect.

[11] A port number such as 48358 or 49152 or 50774—any high port number, but one in the well-known 3277X range, would be appropriate.

[12] A port number such as 61000 would be appropriate.

 

Top

 

Home | Contacts | Policy Guidelines | System Procedures | Tools & Services | ALERTS | News & Articles