CXL
©2009 CXL - UScan
|
|
CXL ©2009 CXL - UScan
|
| Report for | |
| Company | |
| Business Unit | |
| Location | |
| System | . |
| Report name | reports\myrepu.html |
| Report date | 12-Oct-2009 |
| RISKS |  low risk |
 medium risk |
 high risk |
RESULTS | correct |
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 L 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 |
|
|
risk |
| Groups with invalid or non-numeric GIDs can give strange results and produce unpredictable permissions. |
| Actions |
| Change the GID to a valid number. |
| results |
The following groups have an invalid GID: |
| 7.4 | DUPGID | Duplicate GIDs |
|
|
risk |
| Groups with different names but the same GID will confuse the system. |
| Actions |
| Ensure that each group has a unique GID and name or else move users and files into a single group. |
| results |
|
| 8 | FILES | Files |
|
| Risk |
| Files may contain data or be executable programs. When they are created, they will have an owner and a group. A number of privileges determine whether they can be written to, read or executed and by whom. |
| 8.1 | UKNOWNR | Files - Unknown owners |
|
|
risk |
| The following users own files but do not have records in the PASSWORD file i.e. the owner no longer exists. |
| Actions |
| Examine these files and either remove them and their files or assign them to new owners. |
| results |
The following files have unknown owners: |
| 8.2 | UKNGRPS | Files - Unknown groups |
|
|
risk |
| The following groups own files but do not have records in the GROUP file i.e. the group no longer exists. |
| Actions |
| Examine these files and either remove them and their files or assign them new group ownership. |
| results |
The following files are owned by unknown groups: |
| 8.3 | WLDWRITE | Files - WORLD writeable |
|
|
risk |
| Anyone can modify or delete these files. This can be a security problem if the file can be used to gain root access (e.g. the password file). The following points should also be noted: o If a file does not have 'read' rights it can still have data appended to the end or it can be deleted and replaced. o If a file has read rights the contents can be modified. o With execute rights, a compiled program can be run but shell scripts require read rights. o To write to a file a user does not need write access to the directory. o A user must have 'execute' permission on the directory to do anything to the files. o Files in directories which are sticky have NOT been shown since it is assumed that these can only be renamed or removed by the owner of the file, the owner of the directory or the super user. |
| Actions |
| Remove world write from these files unless it is actually needed. Use chmod a-w |
| results |
Attribute File |
| 8.4 | WLDEXEC | Files - WORLD executable |
|
|
risk |
| Anyone can run the files here which are world executable. Many of them are system commands designed to be used by everyone. (e.g. ls) The following points should also be noted: o With execute rights, a compiled program can be run but shell scripts require read rights. o To write to a file a user does not need write access to the directory. o A user must have execute permission on the directory to do anything to the files. o In order to examine only the more important files, we have ignored files in directories whose path contains the word /bin/ or /sbin/. |
| Actions |
| Examine the list of files and ensure that it is intended that everyone can run them. Remove world execute from these files unless it is actually needed. |
| results |
Attribute File |
| 8.5 | GRPWRIT | Files - GROUP writeable |
|
|
risk |
| Any member of this file's group can modify or delete these files. This can be a security problem if the file can be used to gain root access. (e.g. the password file). The following points should also be noted: o If a file does not have read rights it can still have data appended to the end or it can be deleted and replaced. o If a file has read rights the contents can be modified. o With execute rights, a compiled program can be run but shell scripts require read rights. o To write to a file a user does not need write access to the directory. o A user must have execute permission on the directory to do anything to the files. o Files in directories which are sticky have NOT been shown since it is assumed that these can only be renamed or removed by the owner of the file, the owner of the directory or the super user. |
| Actions |
| Remove group write access from these files unless it is actually needed. |
| results |
Attribute Group file |
| 8.6 | GRPEXEC | Files - GROUP executable |
|
|
risk |
| Any member of this file's group can run the files here which are group executable. The following points should also be noted: o With execute rights, a compiled program can be run but shell scripts require read rights. o To write to a file a user does not need write access to the directory. o A user must have execute permission on the directory to do anything to the files. o Many of them are system commands designed to be used by everyone. (e.g. ls) In order to examine only the more important files, we have ignored files in directories whose path contains the word /bin/ or /sbin/. |
| Actions |
| Examine the list of files and ensure that it is intended that members of the group can run them. Remove group execute access from these files unless it is actually needed. |
| results |
Attribute Group file |
| 8.7 | BADPRIV | Files - Uneven privileges |
|
|
risk |
| These file permissions have: o GROUP higher than OWNER or o WORLD higher than GROUP or o WORLD higher than OWNER. This makes nonsense of the permissions set on these files. |
| Actions |
| The file permissions should be adjusted accordingly. |
| results |
Problem Attribute File |
| 8.8 | SUID | Files - SUID |
|
|
risk |
| When applied to an executable file, the person who executes this program will do so under the UID of the OWNER - in many instances this will be ROOT. It is a standard hacking technique to SUID some common commands (e.g. \bin\time) to allow root access with an ordinary account. |
| Actions |
| Ask the owner of the files to justify the need for SUID and ensure that you are happy for these files to be SUID. |
| results |
Attribute File |
| 8.9 | SGID | Files - SGID |
|
|
risk |
| If an executable file has the SGID bit set then when someone executes the file, his group will temporarily change to that of the file's group. In some instances this will cause problems if the group has special privileges. |
| Actions |
| Ask the owner of the files to justify the need for SGID and ensure that you are happy for these files to be SGID. |
| results |
Attribute File |
| 8.10 | STICKY | Files - Sticky |
|
|
risk |
| If the sticky bit is set on a program file it will not be removed from memory after it has finished executing. This makes it useful if the program is run often. Improved memory management has made this unnecessary but very useful when applied to directories. |
| Actions |
| None. |
| results |
Attribute File |
| 8.11 | SUID+WW | Files - SUID/SGID and WORLD executable/writeable |
|
|
risk |
| This test has been included to assist you in finding the most high risk files i.e. those which are SUID or SGID and are world WRITEABLE/EXECUTABLE. Anyone with access to these files will be able to execute (programs) under the UID of the owner. |
| Actions |
| Ask the owner of the files to justify the need for these high privileges. |
| results |
Attribute File |
| 8.12 | HOSTINFO | Files likely to contain host information |
|
|
risk |
| These files are likely to contain information about other computers and users which can connect to the system being reviewed. If someone breaks into just one of these systems it is possible for them to gain access to all the others in which there is a host.equiv file. Similarly, the .rhosts file will show external systems and users who can login to a local account without a password. DO NOT TRUST ANY SYSTEM WHICH YOU DO NOT CONTROL ACCESS TO. Note: Some of the files listed below may be executable programs rather than data files and will therefore be likely to be needed by the system. |
| Actions |
| Try to avoid using these files unless absolutely necessary. Obtain a printout of each of these files or use the CAT command. Then: o Examine the names of the other systems which can connect to this computer and ensure that they are permitted and actually needed. o Examine any .rhosts files and check that the users contained in them are authorised to access this system Ensure that the files are not writeable. |
| results |
Attribute File |
| 8.13 | SUWW | Startup files which are world writeable |
|
|
risk |
| The following files are likely to be the start-up files of users. Where they are script files, they will be run soon after the user has logged in. Anyone who can write to these files can insert malicious commands which will then be executed by the legitimate user. |
| Actions |
| Ensure that these files are owned by the system administrator (NOT the user). Ensure they are not writeable by other people. |
| results |
Attribute File |
| 9 | DIRS | Directories |
|
| Risk |
| Directories are used to group files together. When they are created, they will have an owner and a group. A number of privileges determine whether they can be written to or read and by whom. |
| 9.1 | UNKOWN | Dir - Unknown owners |
|
|
risk |
| The following users own directories but they are not present in the PASSWORD file i.e. the owner no longer exists. |
| Actions |
| Examine these directories and either remove them and their files or assign them new owners. |
| results |
Owner Directory |
| 9.2 | UNKGRP | Dir - Unknown groups |
|
|
risk |
| The following groups own directories but do not have records in the GROUP file i.e. the group no longer exists. |
| Actions |
| Examine these directories and either remove them and their files or assign them new group ownership. |
| results |
Group Directory |
| 9.3 | WRLDWRT | Dir - WORLD writeable |
|
|
risk |
| A user must also have 'execute' rights in order to cd to that directory or any directory underneath it. A user must also have 'read' rights to list files but can run programs if they know the file name. Sub-directories, in directories which are sticky, have NOT been shown since it is assumed that these can only be renamed or removed by the owner of the file, the owner of the directory or the super user. Anyone can delete these directories and any files or subdirectories in them. |
| Actions |
| Remove world write from these directories unless it is actually needed. Use chmod a-w |
| results |
Attribute Directory |
| 9.4 | WRLDEXE | Dir - WORLD executable |
|
|
risk |
| Directories which are 'executable' can be accessed by everyone. If users also have write permission on the directory they can delete files from here. If users do NOT have read access they can only delete files which they know to exist; they cannot list the directory. Directories which need to be protected should not have this permission. Unauthorised access to data. |
| Actions |
| Ensure that most directories do not have this permission. Where they do, ensure that this access is actually intended. |
| results |
Attribute Directory |
| 9.5 | GRPWRT | Dir - GROUP writeable |
|
|
risk |
| Any member of the group can delete these directories and any files or subdirectories in them. A user must also have 'execute' rights in order to cd to that directory or any directory underneath it. A user must also have 'read' rights to list files but can run programs if they know the file name. Sub-directories, in directories which are sticky, have NOT been shown since it is assumed that these can only be renamed or removed by the owner of the file, the owner of the directory or the super user. Unauthorised access to data. |
| Actions |
| Remove group write access from these directories unless it is actually needed. |
| results |
Attribute Directory |
| 9.6 | GRPEXE | Dir - GROUP executable |
|
|
risk |
| Directories which are 'executable' can be accessed by members of the group. If everyone in the group also has write permission on the directory they can delete files from here. If everyone does NOT have read access they can only delete files which they know to exist; they cannot list the directory. Directories which need to be protected should not have this permission. Unauthorised modification and deletion of data. |
| Actions |
| Ensure that most directories do not have this permission. Where they do, ensure that this access is actually intended. |
| results |
Attribute Directory |
| 9.7 | BADPRIV | Dir - Uneven privileges |
|
|
risk |
| Permissions must logically be in the correct order i.e. Group permissions should be lower than OWNER permissions and WORLD permissions should be lower than GROUP permissions. These directory permissions have: GROUP higher than OWNER or WORLD higher than GROUP or WORLD higher than OWNER. This makes nonsense of the permissions set on these directories. |
| Actions |
| These directory permissions should be adjusted accordingly. |
| results |
Problem Attribute Directory |
| 9.8 | SGID | Dir - SGID |
|
|
risk |
| On some versions of Unix, the SGID bit on a directory determines the way the system handles groups, either: With the SGID bit set, files created inside the directory have the same group as the directory. With the SGID bit NOT set, files in these directories have the same group as the primary group of the user. or With the SGID bit set or NOT set, files created in these directories have the same group as the primary group of the user. |
| Actions |
| None. |
| results |
Attribute Directory --------------------- |
| 9.9 | NSTICKY | Dir - Not Sticky |
|
|
risk |
| These directories do not have the sticky bit set. In many versions of Unix only the file owner, the directory owner and the super user can rename or remove files in these directories. Unauthorised modification of data. |
| Actions |
| This is a useful feature which should be employed whenever possible. |
| results |
Attribute Directory -------------------- |
| 10 | FTP | FTP |
|
| Risk |
| The File Transfer Protocol (FTP) is a standard means of moving files from one system to another |
| 10.1 | FTPOWNBIN | Anonymous FTP bin directory has wrong owner |
|
|
risk |
| Anonymous FTP allows people on the network who do not have an account on the computer, to deposit files in or retrieve files from the anonymous FTP account's pub directory. The anonymous FTP account's bin and etc directories contain files and commands needed to support anonymous FTP. |
| Actions |
| The owner of these directories should be the root account. |
| results |
The /ftp/bin/ directory was not found in file directory listing. |
| 10.2 | FTPOWNETC | Anonymous FTP etc directory has wrong owner |
|
|
risk |
| Anonymous FTP allows people on the network who do not have an account on the system to deposit files in or retrieve files from the anonymous FTP account's pub directory. |
| Actions |
| The anonymous FTP account's bin and etc directories contain files and commands needed to support anonymous FTP. The owner of these directories should be the root account. |
| results |
The /ftp/etc/ directory was not found in file directory listing. |
| 10.3 | FTPHDIROWN | Anonymous FTP home directory has wrong owner |
|
|
risk |
| Anonymous FTP allows people on the network who do not have an account on the system to deposit files in or retrieve files from the anonymous FTP account's pub directory. The anonymous FTP account's home directory should be owned by the root account to prevent users being able to write to or modify its content. |
| Actions |
| Change the ownership of the anonymous FTP account's home directory to root using the command 'chown root 'DIRECTORY-NAME''. |
| results |
The user 'ftp'was found in the password file. |
| 11 | /ETC | /etc |
|
| Risk |
| The /etc directory is one of the most important directories on a Unix system since it contains many of the computer's security files such as the password file. |
| 11.1 | ETCWW | Directories under /etc has world write access |
|
|
risk |
| The directory /etc and its sub-directories normally contain files that are executed by the root account during system start-up and are critical for the running of the system. |
| Actions |
| Permitting world write access to a directory allows all users on the system to modify the files it contains. |
| results |
Directories under the /etc directory are not world writable. |
| 11.2 | ETCPWD | File /etc/default/passwd has insecure permissions |
|
|
risk |
| If the file /etc/default/passwd exists, can it be only written too by its owner. |
| Actions |
| Check the ownership and permissions of this file and its parent directories (i.e. /etc /etc/default). If necessary, use the chmod command to change permissions such that only root can write to the file. |
| results |
The files /etc/passwd and /etc/default/passwd were examined. |
| 11.3 | ETCPROF | File /etc/profile has insecure permissions |
|
|
risk |
| /etc/profile allows the system administrator to perform services for the entire user community. Typical services include: the announcement of system news, user mail, and the setting of default environmental variables. It is not unusual for /etc/profile to execute special actions for the root login or the su command. |
| Actions |
| Ensure that the file /etc/profile can only be written to by root. |
| results |
The Profile file not found. |
| 12 | LOG FILES | Log files |
|
| Risk |
| Log files are used to record key events on the system such as the use of SU and failed logins etc It is important to ensure that they cannot be amended by users. |
| 12.1 | LOGLOGEX | The login log file does not exist |
|
|
risk |
| If the login log file does not exist then failed attempts to log in, such as those caused by a hacker repeatedly attempting to guess passwords, will not be logged. |
| Actions |
| Create the login log file, ensuring it is owned by username root and group sys, and that it has read and write permissions granted solely to its owner. The login log file should exist and should be regularly monitored for such behaviour. Also, this file should not be a symbolic link, especially if the file linked to is not on the same partition as the link, as this could lead to login events being written to the wrong file or worse still discarded. Also, ensure that the file is not a symbolic link. |
| results |
Login files found: |
| 12.2 | LOGLOGOWN | Login log not correctly owned |
|
|
risk |
| If the login log file exists, is it owned by username root and group root or sys. |
| Actions |
| Ensure that the login log file is owned by username root and group root or sys, and that only the owner has read and write permissions. |
| results |
Login files found: |
| 14 | AIX | AIX |
|
| Risk |
| AIX is a proprietary operating system from IBM. The structure of the password file is different to most other Unix versions and it has thus got its own section. |
| 15 | NIS | NIS |
|
| Risk |
| NIS is a distributed system which enables other computers to share password files, group files and many other files over a network. |
| 15.1 | NISUSED | Is NIS being used. |
|
|
risk |
| This section reports on whether NIS is being used for the control of user-IDs. We have found a + sign in the password or group file which indicates that NIS is being used. When obtaining user or group information, the Unix system will first look in the password file and if the user-ID is not present it will refer to the master password file on the NIS server. |
| Actions |
| As part of your review, it is important that you examine this master system. Ensure that the line in the password file is +: and not +::0:0::: In the second instance, if the + were accidentally replaced with just a single character such a 'p' then typing in this character at login time would allow a user to connect without a password and be connected as a super-user. |
| results |
| NIS is not being used on this system. |