HP-UX ServiceGuard - Design Considerations with NIS

PROBLEM
I am trying to share password and group information within my ServiceGuard cluster on HP-UX v 11.11 or v 11.23. What things should be considered in using NIS or NIS+ to do this?

SOLUTION
Here are some notes on how you can use Network Information Service (NIS) within your HP-UX v 11.11 or v 11.23 ServiceGuard Cluster, with a few conditions.

General restrictions on using NIS not limited to ServiceGuard:

NIS is not supported with HP-UX Trusted System. If when examining the /etc/passwd file find that ALL the passwords have been replaced by "*", then this indicates the system is trusted.

NIS is not supported if the ShadowPassword bundle has been implemented on HP-UX v 11.11 or v 11.23. If you examine the /etc/passwd file and find that ALL the passwords have been replaced by "+", then you have enabled Shadow Password. Note however, that NIS support for ShadowPassword is available with HP-UX v 11.31.

If you decide to use NIS, review the roles of the NIS client, the NIS Server, and of the NIS Master server, and the potential for single point of failure with the NIS Master Server.

Click here for more information on the roles of NIS client, Slave and Master Servers found in chapter 4 "Configuring and Administering NIS" in the "NFS Services Administrators Guide" manual at http://docs.hp.com/ .Look for the Manual on the main page.

Design considerations for NIS Server placement when using ServiceGuard:

The NIS Master server is a single point of failure since no password, nor other NIS database changes can be made if it is offline or unavailable. All database changes with NIS are made on the Master Server only, and propagated, or "pushed", to the Slave NIS Server(s), if any. Password changes are implemented by interaction between the passwd or yppasswd command on the NIS client and the rpc.yppasswdd daemon running on the NIS Master. If the NIS Master service is not available, these changes cannot be made.

The NIS database design does not lend itself well to implementing NIS Master and Slave servers within packages in a cluster. This is because the NIS database internally caches the hostname of the NIS Master in the database and also creates a ypservers map containing the names of the NIS Master and of all NIS Slave servers. This is not configurable.

Hosts in the cluster may be NIS slave servers in order to provide redundancy for NIS database lookups should the NIS Master be unavailable.

NIS Master server should also have be accessible on the private heartbeat LAN(s), if any are present. This is because Sun RPC assumes all networks are routable.

Click here to see the Chapter 4 of the "Managing ServiceGuard" manual at:

http://docs.hp.com/en/ha.html#ServiceGuard for an explanation.

NIS Client considerations:

All clients should use ypinit -c to create the list of NIS Servers to bind to, in preferential order. These hostnames MUST be in /etc/hosts, and include all active networks including Heartbeat networks. Unless the NIS Server is running as part of a ServiceGuard package (not recommended) you shouldn't need to specify any package IP hostnames. This step must be followed on all NIS clients, including those systems that are also acting as NIS servers.

For 11.11 nodes, you will most likely need to update the ypinit script since the ypinit -c functionality was released in a patch, and placed into /usr/newconfig/usr/sbin/ypinit. Save your /usr/sbin/ypinit script, and take note of any customizations you might have made to it, such as adding any new maps. Copy the ypinit script over from /usr/newconfig/usr/sbin into /usr/sbin and merge in those customizations, if any.

Systems acting as NIS slaves or as the NIS Master, should first try to bind to themselves. Systems in the cluster NOT acting as NIS Servers, should bind to any NIS Server systems in the cluster, if any.

All clients, and NIS Servers should generally use the /etc/nsswitch.files template for /etc/nsswitch.conf, with these considerations:

For password and group when using the "+" "-" entries to include or exclude users and netgroups, you should use:

passwd:   compat
group:    compat
netgroup: files nis

If not using the "+" "-" syntax in your /etc/passwd then you should use:

passwd:   files nis
group:    files nis
netgroup: files nis

Include "nis" for any other databases that are actually using NIS. Sometimes services are also managed by NIS, so you may want to add:

services:  files nis

Remember to use the "hosts" entry that is appropriate for your installation! We recommend looking at "files" first, before NIS or DNS. For example:

hosts:    files nis dns

What about using NIS+ or LDAP to share password or group databases?

The answer is that you could use either NIS, NIS+, or LDAP-UX. However, HP
does not recommend the use of NIS+ for several reasons, the most important
of which is that it has been discontinued in the present OS release (11.31)
and LDAP has replaced it.

Implementing ldap-ux is the suggested migration path.



HP-UX: support for shadow passwords with NIS

PROBLEM
With respect to Shadow Passwords with NIS in a heterogeneous NIS environment including:

HP-UX 11.11 NIS Master server
Sun NIS Slave server
NIS clients

the following document:

HP-UX Software Transition Kit  >  HP-UX 11i v1.6 critical impact

http://devrsrc1.external.hp.com/STK/impacts/i833.html

states that at some point, support for shadow passwords with NIS will be available.

When will this occur and with which release?

CONFIGURATION
Operating System - HP-UX
Version - 11.x
Subsystem - NIS (Network Information Service)

RESOLUTION
Here are a few observations regarding HP's NIS implementation:

1.  NIS is basically not secure with regards to the current security needs.

2.  Shadow Password for NIS is NOT supported on the current HP-UX versions - 11.0, 11.11 (also known as 11i version 1), 11.23 (11i version 2).  The software changes necessary to provide Shadow Password support with NIS on the current HP-UX versions would be considerable, and, at the time of this writing, it has been decided not to change the current versions.  Currently, plans are in place to provide Shadow Password for NIS with the next HP-UX version, that is, HP-UX 11.31, also known as 11i version 3.

3.  Some interoperability issues would remain in hybrid NIS environments such as NIS environments with other vendors' systems.

4.  HP's direction, as well as their competitors', is to move from NIS to LDAP.

5.  Regarding NIS+:  NIS+ (NIS Plus) addressed some security issues, but NIS+ has been discontinued by HP.  Other vendors recommend moving from NIS+ to LDAP.

At the time of this writing, plans are in place to provide Shadow password support for NIS in HP-UX version 11.31 to come, but LDAP-UX will remain HP's recommended, long-term solution.

NOTE:  HP provides NO guarantees of any kind regarding future support for Shadow passwords.

HP's recommended solution is to move from NIS to LDAP-UX.  The main reason is that LDAP is a more complete, secure, and standard solution, recommended by HP as well as by other major vendors.

LDAP-UX is the LDAP solution on HP-UX systems.  The HP LDAP-UX Integration bundle contains tools to migrate from NIS to LDAP as well as the NIS/LDAP Gateway product.  For more information, please refer to the HP Software Depot at:

http://software.hp.com/

Search for "LDAP-UX Integration" and obtain the following documents:

HP-UX Shadow Passwords
LDAP-UX Integration for HP-UX

Also refer to:

NIS/LDAP Gateway Administrator's Guide

available at:

http://docs.hp.com/en/J4269-90028/index.html



HP-UX NIS Client - Sun NIS Server with C2 Security: interoperability issues

PROBLEM
Here are three questions related to interoperability issues with respect to the following example configuration:

A.  NIS Server: Sun Solaris 9 + C2 secure activated (passwd.adjunct feature)

B.  NIS Clients:  HP-UX 11.11 systems

  1.  one r-commands client - remsh command

  2.  one r-commands server - remshd daemon

The questions are:

Q1.  Can an HP-UX system be used as an NIS Client of a Sun Solaris NIS Server that satisfies the Class C2 security criteria?

Q2.  What alternate solution can be advised?

Q3.  Why not use NISplus (NIS+) instead?

CONFIGURATION
Operating System - HP-UX
Version - 11.11
Subsystem - NIS

RESOLUTION
Please see the answers provided below each question:

Q1.  Can an HP-UX system be used as an NIS Client of a Sun Solaris NIS Server that satisfies the Class C2 security criteria?

A1.  There are several ways to implement C2 security.  The Sun-specific C2 implementation, that comprises the passwd.adjunct feature, is not supported on any HP-UX version.  At least one issue described in the following document may be encountered:

Doc_id:  4000097215A
Title:  remsh returns "Account is disabled"
available at:  http://www.itrc.hp.com/

Q2.  What alternate solution can be advised?

A2.  The main solution is to migrate from NIS to LDAP.  The LDAP solution on HP-UX is called LDAP-UX.

The HP LDAP-UX Integration bundle contains tools to migrate from NIS to LDAP as well as the NIS/LDAP Gateway product.  For more information, please go the HP Software Depot at:

http://software.hp.com/

and search for "LDAP-UX Integration".

Q3.  Why not use NISplus (NIS+) instead?

A3.  The NISPlus product has been discontinued.  NIS+ is replaced by LDAP-UX as well.

Here are the main reasons about why HP does not recommend to install and use NIS+ :

A few years ago, the Sun NIS+ (NIS Plus) product was intended to provide a more secured, enhanced NIS-like product.  However, it appears that NIS+ is no longer promoted; similarly, HP no longer provides NIS+ in HP-UX.

LDAP is an excellent replacement for NIS along with security features, but it implies the use of centralized user repositories.  Since most Unix market leaders, such as Sun, IBM, and HP, advise customers to migrate to LDAP, there is no plan to make HP-UX compliant with Sun's C2 implementation.  This means that, at the time of this writing, HP has no current plans to add support for the "passwd.adjunct" map because the industry is migrating from NIS to LDAP.

For NISplus / NIS+, please also refer to the LDAP-UX integration product.

The "NIS+ to LDAP Migration Guide" - available at http://docs.hp.com/ - describes the migration procedures used to migrate the NIS+ server to the LDAP directory server and to install LDAP-UX Client Services on HP-UX NIS+ clients.



HP-UX - Automount - 'couldn't bind to reserved port' and 'rpcbind:  t_bind t_errno = 23'

PROBLEM
The following behavior occurs on HP-UX Superdome systems with Enhanced AutoFS, such as AutoFS 2.3 for HP-UX 11.11, and NIS clients (NIS ONC 1.2) on HP-UX 11.11 or 11.23 systems.  On a Superdome (SD) partition that intensively operates with AutoFS automounts and with Name Resolution via NIS, the mount operations sometimes fail and log at least one of the following error messages:

o  in syslog.log:

   "automountd ... : mount ...: Couldn't bind to reserved port"

   "rpcbind: check_bound: t_bind: exit, t_errno = 23"

o  in automount.log:

   "getmount_alloc() failure"

CONFIGURATION
Operating System - HP-UX 11.11
Application - Enhanced AutoFS

RESOLUTION
There is a very intensive use of the UDP reserved ports done by NIS (NIS Client) for name resolution, as well as by the AutoFS automounter.  As a consequence, sometimes there are not enough UDP reserved ports left to service all the automount requests, thus the user may see the message:

   cannot mount /home/<user> directory

In the  "rpcbind: check_bound: t_bind: exit, t_errno = 23"  error message, "t_errno = 23" is an XTI/TLI error indicator which means that the address is already in use.  The transport provider cannot bind the specified address, hence the provider reports that the address is busy.

The root cause of this behavior is that when using NIS for name resolution, the system may run out of udp ports.  This is a scalability issue with NIS ONC 1.2 product limitation.  Reserved ports are kept open until the calling process exits.

Here are two solutions:

1.  Use DNS prior to NIS, i.e. change the /etc/nsswitch.conf file.  Be aware that it is VERY IMPORTANT to keep the DNS configuration as reliable and up to date as possible.  In many environments, this task is more difficult that with NIS.

2.  Perform an NIS to LDAP-UX migration.



HP-UX passwd command errors when nsswitch.conf contains winbind as a backend store

PROBLEM
On HP-UX 11.11, if the file /etc/nsswitch.conf contains a winbind entry in the passwd line, the HP-UX passwd(1) command may not work, and instead report an error message similar to the following:

     # passwd
     Supported configurations for passwd management are as follows:
     passwd: files
     passwd: files ldap
     passwd: files nis
     passwd: files nisplus
     passwd: compat
     passwd: compat AND
     passwd_compat: nisplus

This behavior can occur when attempting to change root's passwd or when entering a normal user password.

CONFIGURATION
Operating System - HP-UX
Version - 11.11
Application - CIFS Server A.02.xx

RESOLUTION
The behavior described above occurred because libpam_unix was checking for specific "registered" configurations for backends in nsswitch.conf; since winbind was not listed as one of these configurations, the passwd command, which goes through libpam_unix, would fail with the above error. This behavior was in fact also an issue for OTHER backend configurations such as that described in the SR referenced below.

The behavior described above is resolved by applying the following libpam vi patch:

[PHCO_33215/PACHRDME/English]
s700_800 11.11 libpam_unix cumulative patch

along with its dependency:

[PHNE_33971/PACHRDME/English]
s700_800 11.11 ONC/NFS General Release/Performance Patch

which contains a fix for the following SR (Service Request):

Doc_id:   [8606227681/STARS/English]   (CR# JAGad96745)
Title:  passwd command produces error when nsswitch.conf has files nis ldap

available at:  http://www.itrc.hp.com/

Note:
Apply these patches and any required dependencies.  These patches, as with any patch, may be superseded.  Please check for the latest patches at HP's IT Resource Center (ITRC) at the following web site:

http://www.itrc.hp.com/



Unix passwd may give errors when using winbind in nsswitch.conf

PROBLEM
On HP-UX 11.11, if the file /etc/nsswitch.conf contains a winbind entry in passwd line, the HP-UX command "passwd" may not work, and instead report an error message, whether you are changing root or a normal user password:

# passwd
Supported configurations for passwd management are as follows:
   passwd: files
   passwd: files ldap
   passwd: files nis
   passwd: files nisplus
   passwd: compat
   passwd: compat AND
   passwd_compat: nisplus

CONFIGURATION
CIFS Server A.02.XX running Winbind

RESOLUTION
The solution is to apply [PHCO_33215/PACHRDME/English] and it's dependency [PHNE_23502/PACHRDME/English], which contains a fix for the following JAG: JAGad96745.

Apparently when they 'relaxed' the nsswitch.conf checking by libpam_unix.1 to fix this problem, it also allowed libpam_unix to work with winbind.

Root Cause: libpam_unix was checking for specific 'registered' configurations for backends in nsswitch.conf; since winbind was not listed as one of these configurations, the passwd command, which goes through libpam_unix, would fail with the above error.  This behavior was in fact also a problem for OTHER backend configurations, such as that described in JAGad96745.  Fixing this behavior in libpam_unix vi patch [PHCO_33215/PACHRDME/English] resolves this issue.




How to configure PAM passwdqc password strength checking

PROBLEM
For security reasons I wish to enforce strong passwords. HP-UX trusted system does not offer all the password checks I am looking for.

I found the PAM_passwdqc product on the HP-UX 11i v1 and 11i v2 Internet Express offering:

HP-UX Internet Express A.06.00 Product Overview

  PAM_passwdqc

  PAM_passwdqc is a password strength checking module for PAM-aware password changing programs, such as passwd(1). PAM_passwdqc checks regular passwords, offers support for passphrases, and can provide randomly generated passwords.

It covers my requirements but is an open source product. I read the documentation but am still unsure how to add passwdqc to existing PAM modules on HP-UX 11.11 and 11.23.

RESOLUTION

As an Open Source security component the PAM passwdqc module is not covered under HP-UX support contracts. For documentation see:

passwdqc README

Below is an example of how passwdqc can be added to the existing PAM configuration file. Testing has been limited and the information is provided as is.

Install passwdqc

Download ixPAMpasswd from the software depot or install it from the Internet Express CD:

# swinstall -s /tmp/ixPAMpasswd_A.06.00-1.0.2.001_HP-UX_B.11.23_IA+PA.depot \* Verify the library

# ls /usr/lib/security/hpux64/pam_passwdqc.so.1
# ls /usr/lib/security/hpux32/pam_passwdqc.so.1

 Check the README

The README can be found in /opt/iexpress/pampasswd. Decide which options to use in your environment.

The openwall site states:

  On HP-UX 11, pam_passwdqc has to ask for the old password during the update
  phase. Use "ask_oldauthtok=update check_oldauthtok" with pam_passwdqc and
  "use_first_pass" with pam_unix.

Modify /etc/pam.conf

The README states:

  This module should be stacked before your usual password changing module (such as pam_unix or pam_pwdb) in the password management group (the "password" lines in /etc/pam.d/passwd or /etc/pam.conf).

This is an example of an HP-UX 11.23 system /etc/pam.conf including passwdqc.

# more /etc/pam.conf

#
# Password management
#
login    password required   pam_passwdqc.so.1 ask_oldauthtok=update
check_oldauthtok min=disabled,disabled,disabled,6,6 max=8 passphrase=0
similar=permit enforce=users
login    password required   libpam_hpsec.so.1
login    password required   libpam_unix.so.1 use_first_pass
passwd   password required   pam_passwdqc.so.1 ask_oldauthtok=update
check_oldauthtok min=disabled,disabled,disabled,6,6 max=8 passphrase=0
similar=permit enforce=users
passwd   password required   libpam_hpsec.so.1
passwd   password required   libpam_unix.so.1 use_first_pass
dtlogin  password required   libpam_hpsec.so.1
dtlogin  password required   libpam_unix.so.1
sshd     password required   pam_passwdqc.so.1 ask_oldauthtok=update
check_oldauthtok min=disabled,disabled,disabled,6,6 max=8 passphrase=0
similar=permit enforce=users
sshd     password required   libpam_hpsec.so.1
sshd     password required   libpam_unix.so.1 use_first_pass
OTHER    password required   libpam_unix.so.1

Note: The options after pam_passwdqc.so.1 are all on one single line.

Choose each service you wish to enable strong password checks for. The passwd service covers the passwd command. Adding the module to login and sshd causes them to check for passwords using passwdqc instead of the regular HP-UX checks when a user's password has expired and needs to be changed during login.

Use use_first_pass option for pam_unix:

use_first_pass
It compares the password in the password database with the user's initial password (entered when the user authenticated to the first authentication module in the stack). If the passwords do not match, or if no password has been entered, quit and do not prompt the user for a password.

The option does not apply to pam_hpsec.

The file would look very similar on HP-UX 11.11. The difference is that HP-UX 11.11 does not have a pam_hpsec. Some systems may not have sshd in the pam configuration either.

For further information regarding PAM, check the manual pages:
pam(3)
pam.conf(4)
pam_user.conf(4)
pam_unix(5)
pam_hpsec(5)

Test the PAM passwdqc module

# passwd user1

You can now choose the new password.

A valid password should be a mix of upper and lower case letters, digits, and other characters.  You can use a 6 character long password with characters from at least 3 of these 4 classes.  An upper case letter that begins the password and a digit that ends it do not count towards the number of character classes used.

Enter new password:
Re-type new password:
Changing password for user1
Passwd successfully changed

If a user's password has expired, login or ssh will prompt:

login: user1
Password:
Your password has expired. Choose a new one
Enter current password:

You can now choose the new password.

A valid password should be a mix of upper and lower case letters, digits, and other characters.  You can use a 6 character long password with characters from at least 3 of these 4 classes.  An upper case letter that begins the password and a digit that ends it do not count towards the number of character classes used.

Enter new password:

Back out PAM changes

If for any reason the passwdqc module has to be removed, copy your current /etc/pam.conf to another location and restore the original from: /usr/newconfig/etc/pam.conf
The effect on passwd, login etc is instant.

Disclaimer: While the above configuration has been tested with various scenarios, no extensive testing has been performed. Neither the passwdqc module nor the changes to pam.conf are supported by HP.  HP does support questions regarding the PAM framework.

Note: Some of this functionality is already available in the 11.23 HP supported PAM module pam_hpsec. The following options (defined in the security (4) manual page) can be used to configure password restrictions:

MIN_PASSWORD_LENGTH
PASSWORD_MIN_UPPER_CASE_CHARS
PASSWORD_MIN_LOWER_CASE_CHARS
PASSWORD_MIN_DIGIT_CHARS
PASSWORD_MIN_SPECIAL_CHARS

These values need to be configured in the file /etc/default/security. The default value for MIN_PASSWORD_LENGTH is 6 characters (does not apply to trusted systems) and the default for the other values is 0.

Additional security can be provided by installing the the HP Standard Mode Security Extensions software. This software is downloadable from HP's software depot (and is included in the May 2005 OE and later):

Software Depot

(search for "Standard Mode Security Extensions")

The web page that comes up when you click on the product shows information about the extra features available from this software.



HP-UX - winbindd accesses trusted domains even with 'allow trusted domains' set to 'no'

PROBLEM
With respect to the CIFS Server on an HP-UX 11.x system, winbindd still attempts to access trusted domains even when these two items are in place:

o  the smb.conf parameter "allow trusted domains" is set to "no"

o  winbind is used to resolve sids to uids/gids in the ADS security model

When these domains are unreachable, winbindd times out and causes problems with authenticating/accessing users in the actual domain that it SHOULD be using.

CONFIGURATION
Operating System - HP-UX
Version - 11.x
Subsystem - CIFS Server

RESOLUTION
At the time of this writing, winbindd does not currently respect the "allow trusted domains = no" smb.conf parameter.  At HP CIFS Server A.02.03 and below, this parameter is only implemented in the smbd daemon.

An enhancement request has been submitted to request that this functionality be added to the winbind daemon in a future release.



HP-UX - root account on Trusted System becomes disabled every few
minutes

PROBLEM
The root account on an HP-UX 11.x trusted system becomes disabled about every 5 minutes.  This is not a result of malicious activity.  PAM debugging was enabled according to the instructions in the following document:

doc_id:  UNISKBRC00011843
Title:   PAM Debugging
Available at HP's ITRC web site:  http://www.itrc.hp.com/

The only interesting entries found in /var/adm/syslog/debug.log were:

   syslog: unix pam_sm_authenticate(wbem root), flags = 0
   syslog: pam_authenticate: error Authentication failed

There seem to be several of these grouped together every 5 minutes or so.  Could this be causing the root account to get disabled?  If so, what is it, and how can I prevent it from disabling the root account?

CONFIGURATION
Operating System - HP-UX
Version - 11.x
Subsystem - Trusted System

RESOLUTION
Based on the fact that the root account is getting disabled every few minutes along with the fact that the PAM debug entry references wbem root, there is a strong likelihood that this is being caused by another system on the network that is running HP SIM (System Insight Manager).  For more information on HP SIM, see the following link:

http://h18013.www1.hp.com/products/servers/
management/hpsim/index.html

The system that is running SIM is trying unsuccessfully to access the trusted system, and as a result, is causing the root account to be disabled.  It is possible that at some time in the past, the SIM system had a legitimate reason to access this trusted system, but for whatever reason, can no longer do so (e.g. the root password on your trusted system has changed).

One way to find the system that is causing this behavior is to enable nettl(1M) tracing to look specifically at the port that is used by HP SIM.  See if there is a hint as to where the unsuccessful login originates.  In the following steps, assume a source system named Source_1, and a destination system named Dest_1:

1.  On the client (Dest_1), start nettl tracing:

# nettl -tn all -e all -tm 99999 -f /var/tmp/trace

2.  Let this run for about 5 minutes, or until the root account has been disabled.  For instance, in another window on system Dest_1, execute "/usr/lbin/getprpw root" until the string "lockout==non-zero" appears.

3.  Stop nettl tracing:

# nettl -tf -e all

4.  Create a filter file in /var/tmp containing the following:

filter ip_daddr Dest_1
filter tcp_dport wbem-https

   5.  Format the trace file:

    # netfmt -N -l -c /var/tmp/filter /var/tmp/trace.TRC000 > \
      /var/tmp/trace.fmt

6.  Edit the trace.fmt file; find a line that mentions system Dest_1 on it, for example:

============= IP Header (inbound -- [ICS]) =============
Source:  Source_1.newco.com(A) Dest:  Dest_1.newco.com(A)

If it is possible to establish that system Source_1.newco.com is sending requests to the local trusted system, Dest_1.newco.com, then the next step would be to attempt to find out who owns system Source_1 and whether HP SIM was configured to access the trusted system.

For best results with nettl(1M) and netfmt(1M), consider installing the most recent patches for those commands:

o  HP-UX 11.11:   [PHNE_30450/PACHRDME/English]

Title:  nettl(1M), netfmt(1M) and nettladm(1M) patch

o  HP-UX 11.23:   [PHNE_33283/PACHRDME/English]

Title:  nettl(1M), netfmt(1M) and nettladm(1M) patch

Note:
Please apply either of these patches along with any required dependencies.  Either of these patches, as with any patch, may be superseded.  Please check for the latest patches at HP's IT Resource Center (ITRC) at the following web site:

http://www.itrc.hp.com/



Can HP-UX be attacked by a virus?

PROBLEM
Can HP-UX be attacked by a virus? Is there anti-virus HP-UX software?

RESOLUTION
"Trojans" for UNIX, can exist and would very easy to script.  For example: a script that calls /sbin/rm -f /* executed by root will delete the files under / (exception would be /sbin and /sbin/rm and the shell because they are in use). While some people consider trojans a virus, they are not.

A virus has certain characteristics which would define them as a virus. First, a virus is usually memory resident. This means that the virus sits in memory and looks for keys to attack files. Usually the dos extension to the file name, for example .exe files and .com files. Next, a virus must be at least a nuisance, like writing "hacked by chinese" in the case of CodeRed.  It also causes an unwanted change to an attacked file. A program that sat in memory and wrote ficticous message to files would be a virus. A virus must also spread itself in one way or another.

Because the virus usually needs a trigger (like the .bat, .exe or some other executable) a UNIX virus is much more difficult to create. Since /usr/bin/rm is an executable not denoted by rm.exe, the virus would not be able to tell by name what is an executable to infect and spread, and what is not. /etc/hosts would look the same to a virus as /etc/ping. A virus would have to be huge to sit in memory and be able to stat all files, run magic, check bits, etc...to know how to spread.

Next, in UNIX the kernel is memory resident. When the system boots the kernel, it is read only. The kernel sits in memory until system shutdown. If a virus was to infect the kernel, it would not be effective until the system was rebooted with the bad kernel.  In Win/XXXX the kernel sits on a disk, and is constantly accessed.

The next problem with running a virus in UNIX is that the virus can only run at the access level of the user who executes the program. For example: if johndoe executes the program, the program can only affect johndoe's processes and files. Anything owned by root, and bettysue would be unaffected.  The virus could only do wide spread system damage if the super-user root executed the virus.  This severely limits the ability of a virus in UNIX. Windows NT and 2000 also have multi-leveled access for processes, but the implementation is very easy to bypass.

In SunOS and Linux, the virus scanning software that is available is NOT for UNIX/Linux protection, but Microsoft Windows protection. The software is made to scan data shared to and from Windows boxes.

The best defense in UNIX to the Virus threat is common sense, built in UNIX functionality, and basic security measures.

Based on this information, viruses do not pose a threat to a Unix system, where as anyone with root access does.  Limit or do not give out root access.