CXL
©2008 CXL - UScan
|
|
CXL ©2008 CXL - UScan
|
| Report for | Demo |
| Company | |
| Business Unit | |
| Location | |
| System | . |
| Report name | c:\tbxnew-works\reports\myrepu.html |
| Report date | 24-Feb-2008 |
| RISKS |  Low risk |
 Medium risk |
 High risk |
RESULTS | Correct or low impact |
Medium impact |
Major problem |
| 1 | UPWDS | User Passwords |
 |
| Risk |
| Passwords are the main access control mechanism employed to prevent unauthorised access to you system. Users with short, easy to guess or non-existent passwords all make your system vulnerable to attack. |
| 1.1 | DUPPWD | Duplicate names in password file |
|
|
Risk |
| If the PASSWORD file has been manually edited, it is possible that someone could have created a duplicate user. This will confuse the operating system and administrators and should be rectified. |
| Actions |
| Delete the duplicate users so that each user is unique. |
| Results |
Name Number |
| 1.2 | NOPWD | Users without passwords |
|
|
Risk |
| There is a high risk of unauthorised access to your system from accounts which do not require a password. A user without a password has nothing in the second field of the password file. If a shadow password file is being used however, this field in the shadow file will be blank and the ordinary password file will contain a o or and !. Anyone knowing (or guessing) these user-IDs can log on without a password and access your system. |
| Actions |
| Ensure that every user MUST have a valid password. Enforce password ageing if available. |
| Results |
The following users do NOT have a password: |
| 1.3 | DISPWD | Disabled accounts |
|
|
Risk |
| These users cannot access your system since their password is disabled. If the user does a remote login to another machine which is classed as a trusted host, they will not be required to enter a password and will simply be logged in. |
| Actions |
| Delete these accounts if no longer required or Set the login shell to a non-existent filename. Set the home directory to a non-existent directory. Do NOT delete any system accounts such as root,bin,sys,uucp,nobody or daemon. |
| Results |
The following users have a disabled password: |
| 1.4 | BADFIELD | Incorrect number of fields |
|
|
Risk |
| Password files consist of 7 fields: user-ID : password : UID : GID : text field : home directory : shell Fields are separated by colons. If the wrong number of fields are in the file, the system will become confused (e.g. the GID could be read as the UID). |
| Actions |
| Examine the password file and ensure that every user has the correct number of fields in each user record. |
| Results |
The following users have the wrong number of fields: |
| 1.5 | UNMATCH | Unmatched password file entries |
|
|
Risk |
| If a shadow password file is being used every entry in the normal password file should have an equivalent entry in the shadow file and visa versa. The password field in the normal password file should be + o or ! and the encrypted password field (e.g. Fg1k92H/YfqtW) should be found in the shadow password file. Reliance on the encrypted password field may not be possible and unauthorised access could be gained. |
| Actions |
| Examine all entries which are unmatched and delete those which are no longer required. |
| Results |
These users do NOT have entries in the shadow password file although they |
| 1.6 | PWDLIFE | Password lifetimes |
|
|
Risk |
| On some versions of Unix, password lifetime information is included in the password file or shadow file, at the end of the encrypted password. In others it will be found in a configuration file which is not examined by UScan. A comma followed by some characters provide information about the maximum and minimum password lifetimes. If this information is available in your files, it will be shown below. The max. lifetime means the user must change his password every x weeks. The min. lifetime means the user must keep the new one for y weeks. Long maximum lifetimes increase the risk of passwords becoming widely known. Short minimum lifetimes (change intervals) mean that a user can change the password back to his original one very quickly. |
| Actions |
| Implement a minimum/maximum password lifetime for each user. |
| Results |
The max. password lifetime policy states 90 days. |
| 1.7 | ACCTINFO | Account information |
|
|
Risk |
| Some shadow password files contain user information such as how long the account may be used for and the life of the password. The columns below are: o PWD LAST CHANGED The date when the password was last changed. o MIN DAYS The minimum number of days before a user can change a password (to prevent immediately returning to old password) o MAX DAYS The maximum days that a password is valid for. o WARN DAYS Number of days warning that a password needs changing. o INACT DAYS Number of days of inactivity allowed for that user. o A/C EXPIRES The absolute days when the account cannot be used. Passwords which are not changed for long periods can become widely known resulting in unauthorised access. |
| Actions |
| Compare the figures below with your company standard and highlight any which fall below. Make all users conform to the standard. |
| Results |
Pwd last Min Max Warn Inact Account |
| 2 | UUIDS | User UIDs |
|
| Risk |
| On Unix systems, the User Identification (UID) is used to define the user to the operating system. The username is not actually used - only by the account owner when signing-on. Normally, the system manager will give every user a different UID and it is this number which is used to determine the user's privileges. |
| 2.1 | ZEROUID | UID=0 |
|
|
Risk |
| On many Unix systems users with UID=0 are SUPERUSERs. Usually this user is called ROOT but any other users with a UID of 0 will have the same high privileges. Anyone with a UID of 0 runs without any security checks being performed and the user will have full access to the whole system. A super user can do the following: o Read, modify or delete any file on the system o Run any program including compilers o Add, change or delete users' accounts o Become any other user on the system o Access any working device o Shut down the computer |
| Actions |
| Ensure that every user shown below really should have these privileges. Change the UID of any user who does not need these facilities. |
| Results |
The following users have a UID=0: |
| 2.2 | NOUID | No UID |
|
|
Risk |
| This is an odd situation. The system needs a UID to recognise a user since it does not use their user-ID. Thus a user without a UID cannot sign on and does not really exist. |
| Actions |
| Delete these users or give them a valid, non-zero UID. Do NOT delete any system accounts such as root,bin,sys,uucp,nobody or daemon. |
| Results |
The following users do NOT have a UID: |
| 2.3 | BADUID | Invalid UIDs |
|
|
Risk |
| A valid UID is one which is an integer in the range 0 to 65535. Most systems will only recognise UIDs in this range and thus any shown below have something wrong with them. UIDs are essential for the operating system to recognise the user (not the user-ID). An unrecognised user may be treated in an unpredictable way by the system. |
| Actions |
| Find out why these users have invalid UIDs. Change them to correct values. |
| Results |
The following users have an invalid UID: |
| 2.4 | DUPUID | Duplicate UIDs in the password file |
|
|
Risk |
| Users with duplicate UIDs are treated by the system as being the same person since the system only recognises UIDs, not user-IDs. This is going to cause confusion especially if the accounts have different permissions. Users will be treated with the same privileges and access to the system. |
| Actions |
| Ensure that every user has a unique and valid numeric UID. |
| Results |
The following duplicate UIDs are used: |
| 3 | UGIDS | User GIDs |
|
| Risk |
| Every user belongs to one or more groups. Groups are used to collect together users with similar jobs or access to the system. Like users, each group is given a unique number called a GID which the system recognises to extend the users access to files and directories. |
| 3.1 | ZEROGID | Users with GID=0 |
|
|
Risk |
| The group with a GID of zero is often referred to as the 'system' or 'wheel' group. On many Unix systems only users in this group are able to use the su command. Thus only these users can become super users. Users in this group could become super users with full access to the system. The ROOT account will normally be found in this group and is not a problem. |
| Actions |
| Review any users shown below and ensure that you are happy for them to possibly become super users. |
| Results |
The following 'primary' users have a GID=0: |
| 3.2 | NOGID | Users with no GID |
|
|
Risk |
| This is an odd situation. The system needs a GID to recognise a user's GROUP. |
| Actions |
| Delete these users or give them a valid, non-zero GID. Do NOT delete any system accounts such as root,bin,sys,uucp,nobody or daemon. |
| Results |
The following users do NOT have a GID: |
| 3.3 | BADGID | Users with an invalid GID |
|
|
Risk |
| The users listed below have invalid GIDs. This is dangerous if the GID translates into a number (e.g. kl0 maybe taken as GID=0). Users in these groups could become super users with full access to the system. |
| Actions |
| Change to a legal numeric value. |
| Results |
The following users have an invalid GID: |
| 3.4 | DUPGID | Duplicate GIDs in the password file |
|
|
Risk |
| These users share GIDs. This is not a problem but you should be aware that these users are likely to have the same access profiles to the same files and programs. Users in these groups could gain unintended access to parts of the system. |
| Actions |
| Review users in each group and ensure that they should be grouped in the way they are. |
| Results |
The following GIDs are shared: |
| 3.5 | EXSTGID | Non-existent GIDs |
|
|
Risk |
| These users have GIDs of groups which do not exist in the group file. Essentially users do not belong to an initial group. |
| Actions |
| Reassign these users to valid groups or delete them. Do NOT delete any system accounts such as root,bin,sys,uucp,nobody or daemon. |
| Results |
User GID |
| 4 | UHDIRS. | User Home dirs. |
|
| Risk |
| When a user successfully logs onto a system, they are placed in their home directory. This directory may contain their own start-up programs or menus and is used to configure their start-up. |
| 4.1 | NOHDIR | No home directory |
|
|
Risk |
| On some systems, not having a home directory may prevent a user from logging on to the system and they will be returned to the login prompt. On other systems the user will be placed in the ROOT directory with the message 'Changing directory to /'. Initial programs or menus may not be activated when the user logs on. |
| Actions |
| Ensure that every user has a valid home directory. This may be used as a means of disabling the account in which case it would be better to delete the user all together. Do NOT delete any system accounts such as root,bin,sys,uucp,nobody or daemon. |
| Results |
The following users do NOT have a home directory set: |
| 4.2 | INVHDIR | Invalid home directory |
|
|
Risk |
| On some systems, not having a valid home directory may prevent a user from logging on to the system and they will be returned to the login prompt. On other systems the user will be placed in the ROOT directory with the message 'Changing directory to /'. Initial programs or menus may not be activated when the user logs on. |
| Actions |
| Ensure that every user has a valid home directory. This may be used as a means of disabling the account in which case it would be better to delete the user all together. Do NOT delete any system accounts such as root,bin,sys,uucp,nobody or daemon. |
| Results |
|
| 4.3 | SHAREHDIR | Shared home directory |
|
|
Risk |
| These users share home directories and are thus likely to have similar access profiles. Ensure that you are satisfied with these groupings of users. A change made to one user could impact several others. |
| Actions |
| Review the users sharing each home directory. |
| Results |
The following home directories are shared: |
| 4.4 | STKYHDIR | Home directory NOT sticky |
|
|
Risk |
| If a directory is flagged as sticky, files in the directory can only be removed, renamed or unlinked by: o the file owner o the directory owner o the super user. Other users could modify or delete the data files or programs in the user's home directory. |
| Actions |
| Ensure that all home directories have this set. |
| Results |
|
| 4.5 | WRITEHDIR | Writeable home directory |
|
|
Risk |
| If a user's home directory is world or even group writeable, other people can modify the files. This is an easy way of for a hacker to gain the password of a user by inserting a password capturing program into the user's home directory, for example masquerading as the ls command. |
| Actions |
| Remove the write permission from the directory. Suggested permissions are: owner:rwx group:r-x world:--- (e.g. drwxr-x---) Use chmod a-w HomeDirName or chmod 750 HomeDirName |
| Results |
|
| 4.6 | SUSHDIR | Home directory contains suspicious files |
|
|
Risk |
| Users should not have 'system' files in their home directories. If they are able to replace the 'real system' files with their own modified files, they could severely disrupt the system. They may be developing a new 'ls' command which corrupts files instead of listing directories. |
| Actions |
| Examine these files and discover what they are and what they do. Ask the user why they are there and then remove them. |
| Results |
User bxxxx /bin/shadow |
| 5 | USHELLS | User Shells |
|
| Risk |
| Shells are a means of providing the user with an operating system language which lets them perform a number of tasks easily. Common shells are sh, ksh, and csh. |
| 5.1 | NOSHELL | No shell shown |
|
|
Risk |
| Every user should have a shell defined. This file should exist, be valid, and ideally should be a compiled program. o A binary (compiled) file only needs EXECUTE permission. o A script file will need READ permission. o The shell should not have the SUID/SGID bit set. On some systems, the user cannot login if they do not have a shell. On other systems, the account will be admitted onto the system using the default shell which is usually the Bourne shell. The message produced will be: Using /bin/sh |
| Actions |
| Ensure that every user has a shell defined. This file should be a compiled program and should not have SUID/SGID set. |
| Results |
The following users do NOT have a shell set: |
| 5.2 | INVSHELL | Invalid shells |
|
|
Risk |
| Every user should have a shell defined. This file should exist, be valid, and ideally should be a compiled program. o A binary (compiled) file only needs EXECUTE permission. o A script file will need READ permission. o The shell should not have the SUID/SGID bit set. On some systems, the user cannot login if they do not have a shell. On other systems, the account will be admitted onto the system using the default shell which is usually the Bourne shell. Some of these could still be valid if they are symbolic links to real files. |
| Actions |
| Ensure that every user has a shell defined. If this file has been chosen to prevent the user from logging in, then decide whether this user still needs to be registered on the system. Delete them completely from the password file if they are no longer required. Do NOT delete any system accounts such as root,bin,sys,uucp,nobody or daemon. This file should be a compiled program and should not have SUID/SGID set. |
| Results |
User Shell |
| 5.3 | SHARESHELL | Shared shells |
|
|
Risk |
| These users share shells. If one user changes a file he will have an impact on the other users which may have undesirable consequences. |
| Actions |
| Provide each user with an individual shell which can only be amended by them (or ROOT). |
| Results |
The following shell files are shared: |
| 5.4 | SUIDSHELL | Shells which are SUID/SGID |
|
|
Risk |
| A shell with SUID/SGID set could give the user the ability to execute privileged commands. |
| Actions |
| Find out and justify the need for the SUID/SGID bit setting. Remove this bit from the permissions. |
| Results |
User Permission Shell |
| 5.5 | WRITESHELL | Shells which are writeable |
|
|
Risk |
| Where a binary file is being used the correct permissions are - --x --x --x With a script file, READ permission is also required. This means that other users can read and copy the file. A copy of a shell could be modified to cause serious user/system problems. |
| Actions |
| Make sure the shells are binary files and have the permissions shown above. |
| Results |
User Permission Shell |
| 6 | GRPS | Groups |
|
| Risk |
| Every user belongs to one or more groups. Groups are used to collect together users with similar jobs or access to the system. |
| 6.1 | DUPGRPNAME | Duplicate group names |
|
|
Risk |
| This could confuse the system and there is possibly something wrong if these exist. Problems will arise when you add or remove names from a group. |
| Actions |
| Rename duplicate groups correctly. Only leave the correct one. |
| Results |
Group Number |
| 6.2 | PWDGROUP | Password protected |
|
|
Risk |
| Groups rarely need passwords as the security is handled by the user-ID. |
| Actions |
| Remove the passwords and replace with a '*'. |
| Results |
The following groups have a password: |
| 6.3 | BADFIELDS | Improper number of fields |
|
|
Risk |
| The group file should contain records whose fields are separated by three colons. If not, unpredictable results will occur depending on which is the missing field. |
| Actions |
| Fix these group records and ensure that there are only four fields. |
| Results |
The following groups have the wrong number of fields: |
| 6.4 | NOUSERGRP | No users |
|
|
Risk |
| The following groups do not have any VALID users in them. If these groups do not contain any users, why do they exist. |
| Actions |
| Delete any unused and therefore unnecessary groups. Reassign group ownership of files and directories to groups populated with the appropriate users. |
| Results |
The following groups do not have any valid users: |
| 6.5 | BADUSER | Non-existent users |
|
|
Risk |
| The following groups have non-existent users i.e. they do not exist in the password file. |
| Actions |
| Examine the GROUP file and remove those users who are not present in the PASSWORD file. |
| Results |
The following users in these groups do not exist in the password file: |
| 6.6 | DUPUSER | Duplicate users |
|
|
Risk |
| A user is listed more than once in a group. If a user is deleted, they may still keep their privileges. |
| Actions |
| Remove the duplicates, leaving only one user in the list. |
| Results |
The following users are duplicated in the group file: |
| 6.7 | USRSGRP | Users in each group |
|
|
Risk |
| This is a simple list of users in each group. It is possible that users have been assigned to the wrong group. |
| Actions |
| Examine each group and ensure that the members of that group are all valid and appropriate for the functions performed by the group. |
| Results |
|
| 7 | GRPGIDS | Group GIDs |
|
| Risk |
| Every user belongs to one or more groups. Groups are used to collect together users with similar jobs or access to the system. Like users, each group is given a unique number called a GID which the system recognises to extend the users access to files and directories. |
| 7.1 | ZEROGID | GID=0 |
|
|
Risk |
| On many Unix systems only users within these groups are able to use the SU (Set UID) command. Thus only these users can become super users. |
| Actions |
| Review any groups shown below and ensure that you are happy for the users to possibly become super users. |
| Results |
The following groups have a GID of 0: |
| 7.2 | NOGID | No GID |
|
|
Risk |
| Groups without a GID will severely confuse the system. |
| Actions |
| Every group should have a unique group number which is reflected in the user profiles. |
| Results |
The following groups do NOT have a GID: |
| 7.3 | BADGID | Invalid GIDs |