Вы находитесь на странице: 1из 7

AIX Security Issues

The purpose of this paper is to give an explanation of some of the control features within the AIX operating system and how to ensure the customer is taking advantage of as many of these built in security features as possible. The security issues will be broken down by category. These categories are authentication, authorization, monitoring, handling denial of service attacks, and hardening the host. AIX is an open operating system from IBM that is based on a version of UNIX. As delivered it has no effective security, but provides the tools for the administrator to create a secure system. It is up to the administrator to establish initial security and maintain security through administrative actions. In its simplest form, authentication is a User ID (UID) and password. It allows the AIX operating system to confirm if the person trying to gain access to the system is actually who they say they are. This is based on a what a user knows (UID and password). AIX identifies a user by their UID number not their user name. The user name is the name given to the user that they use to log in as (John Smith). However, this username has nothing to do with the system authentication onto the AIX system. When a new user is added to the system, they receive a UID number. This number is then attached to the username created and is used for authentication onto the system. By default in AIX, this UID number is automatically assigned by the system when a user is added. This should be changed by the system administrator so that they have to manually assign this UID number to every new user. The reason for this is UID number management. The system administrator can assign every user in the purchasing department a 500 number, every user in the accounting department a 600 number, etc. This will reduce the risk of one UID number being assigned to more than one user because the managers of each department can periodically run a list of all their UIDs and ensure the same UID is not assigned to more than one user. This can also ensure each manager that they do not have an employee assigned to a UID number that is out of their range. This type of administration of UID numbers is required because there is no application control built into AIX that will prevent the system administrator from assigning the same UID number to more than one user. If this occurs, then the two people with the same UID number will have all their accesses assigned to them, along with all the accesses assigned to the other person. AIX allows the system administrator to deactivate any UID that does not have a password. This can be done through the pg /etc/passwd command and by verifying that the second field of each line is not a null. A time-out function can be implemented to automatically log out any UID that has been inactive in the system for a certain period of time. This can be accomplished by updating the /etc/profile file. AIX also allows the UID to be locked out of the system after a certain number of unsuccessful login attempts. The ability of any user to log on directly to the root UID should be disabled. If a user is able to log on to root directly, then there would be no evidence of who exactly logged on 1

and performed the activities that were performed. Therefore, disable this ability to log on directly to root using the SMIT command and setting the root UID login command as FALSE. Then give a certain person the ability to log on as the super user (SU) into the root UID and perform all the needed root activities. This shows accountability because in order to SU into root the user has to first log in with their own UID then SU into root. There is an SU log file (/var/adm/sulog) that logs which UID performed an SU into root and when. The following accounts on AIX are dangerous because they are common to all UNIX platforms and if not used should be locked. At the very least they need to have a password assigned to them and that password should not be known to anyone besides the system administrator and his/her backup. The accounts are guest, ftp, mail, bin, adm. Also, dormant accounts need to be disabled. Dormant accounts are not regularly used and not regularly examined for signs of attempted entry. Therefore, attacks could go unnoticed. A list of all dormant accounts for a certain period should be asked for and an explanation should be given for all accounts that are on that list. A user account can be disabled in AIX by placing an * in the password files in the /etc/security/passwd file. AIX has the capability to comply with the ITCS204 password restrictions. The system defaults for password restrictions can be setup by editing the /etc/security/user file. The actual passwords for the UIDs are stored in the /etc/security/passwd file and encrypted there using the crypy(3) algorithm. In AIX, no passwords should be stored in the /etc/passwd file. Putting the file in the /etc/security/passwd file ensures the passwords are encrypted and also provides another layer of defense against a hacker. For the hacker to crack the password file, they would have to have access to the /etc/security/passwd file, move that file to the /etc/passwd file, then run their crack. Now that we have discussed some of the ways that AIX and the system administrator can authenticate users on the AIX system, lets turn to how they provide authorization into the AIX system. Authorization involves the permissions that a user is given within the system and it is important to ensure that no user has been assigned higher privileges (permissions) than those approved by the system owner. AIX has many options that can help prevent excessive authorizations. In AIX, file permissions are used for authorization onto the AIX system. These file permissions can be set up into three separate areas. These areas are user, group, and others. These areas can further be broken down by type of access. The three types of accesses that can be assigned to each of these three areas are read, write, and execute. When a user creates a file, that user is labeled the owner of that file and they have the permissions assigned to the file specified in the user area. Users are not only assigned a UID, but they are also assigned to groups, based on their file access needs. Groups are identified through a Group ID (GID) and the groups permissions to certain files are specified in the group area. By default, there are no passwords for group. The security of these groups is dependent on the UID and user's password and the correct assignment of the group and GIDs to those users. The group can give another level of ownership to a file

and is used when several users need access to the same files. You can put these files into a group and grant individuals who need these files access to this group. Users are members of at least one group (default group is staff), but can be members of several groups. The users of the group have access (read, write, or execute based on what permissions were assigned to the group) to all files assigned to that group. The user's primary group is used for file ownership on creation. If Bob is a member of three groups (system, security, accountants) and creates a file while his primary group is set to accountants, then all members of the accountants group will have access to that file (based on file permissions for the group area). So when a user creates a file they have to beware which group is their primary group at the time of creating a file. Using the above example, if John is a member of accountant group and not system group, and Bob creates a file intended for the system group, but it was created accidentally under the accountants group because Bob forgot to change his primary group to system, then John will have unauthorized access to that file. The other area for permissions includes all users who did not create the file or are not members of the group that have access to that file. This includes a lot of users so access permissions in this area needs to be monitored closely. AIX allows the system administrator the option of a more granular level of authorization through access control lists (ACL). The AIX ACLs can provide a much more detailed level of access control than can be defined by file permissions (read, write, execute). For example, if Bob is a member of the accountants group and you want all accountants in that group to have read and write access to the file except Bob, then you put read and write permissions in the accountants group (including Bob at this point) and in the ACL you DENY Bob. ACLs also have a PERMIT function. If you only want Bob in the accountants group to have access to the file, you don't assign the accountant group access to it, but you do a PERMIT Bob. Most AIX systems give the security administrator (who should not have access to root or system administrator roles) the task of resetting passwords, sending out the initial password, adding users, adding groups and users to these groups, and policies. The security administrator should not be able to perform the above functions on all UIDs, especially the system administrators UID. If the security administrator has the capability to reset the system administrator's password, then they could reset it and thereby have access to the system as system administrator. This is a separation of duties (SOD) conflict. The security administrator duties and system administrator duties must be separated. To ensure proper SOD, the system administrator must assign the system administration UID (and any others they feel need to be) as an ADMIN user. This prevents the security team from being able to delete or change the UID or password. There are user role options in AIX systems versions 4.2.1 and higher. This allows non-root users to be assigned portions of root privileges. For example, you may assign just the manage passwords role to a certain person. If you assign all the roles of root to different people (remember SOD conflicts), then you may be able to eliminate the need to log in as

root. These people who are assigned these root roles must be a member of the security team and they can not have access to all of root. Be very careful of the roles "manage all users" and "manage all passwords". If given to someone, they would have the ability to change or delete the root ID and password and system administration ID and password. Noone should have that role. They could have "manage users" and manage passwords". When a user leaves you must lock the user account (UID, not the user name) then manage all their files. The system administrator should either delete or reassign all these files. When a user is removed from the system all that is removed is the user's description. All of the data that the user owned still exists in the files. However, because the user no longer exists on the system the files are deemed to be unowned. If the system administrator creates a new user with the same UID as the removed user, this new user would then own all of those files that have not been reassigned or deleted. This could affect confidentiality. To mitigate this the UIDs should be assigned based on department. This can make managing UID numbers a lot easier and stronger. The system /tmp directory should not be used by users to store their files in it. If allowed, users can fill up this directory and then the system could hang when it needs room in this directory. The system places files in this directory while running system programs, and/or events. The system administrator should check this directory regularly and delete those files that have not been accessed within a certain time period. No confidential information or data should be kept in this /tmp directory because it is readable to all users. Users should set up their own /tmp directory under their own file structure if they want to use a temp directory. All device special files (printers, mouse, cdrom, keyboards) must have accurate permissions assigned to them. Insecure permissions on device files allows direct access to hardware devices and their Kernel data structures. All device files must reside in the /dev directory. Any device files residing outside the /dev directory should be investigated to determine why it resides outside this directory. Monitoring security on the AIX server is as important as authentication and authorization. The following is a discussion of the monitoring and auditing tools available in AIX. The Trusted Computing Base (TCB), with the tcbck command, provides very useful tools for both security and system integrity. The TCB facilities can help detect or prevent accidental system changes and help protect you from playful users. TCB must be installed during the initial install. If it is not, then you must perform another initial install. The TCB is the set of programs and files that must be correct trusted if the rest of the system is to have security and integrity. This includes programs such as the AIX Kernel, the login programs, and the passwd programs. There are many commands to help ensure these are trusted. The most useful function of the TCB is the checking processes (syschk.cfg, tcbck, pwdchk, etc) associated with it. The syschk.cfg file and the tcbck command can work together to verify that attributes in various files are correct. The syschk.cfg file maintains a list of these attributes

(permissions, owner, checksum, links, etc) of certain files. Then the tcbck command checks that these same files still have the same attributes. Meaning that the attributes that make up the TCB were not changed since they were created. You should run the tcbck command periodically to verify the integrity of these attributes. AIX provides several other check commands that help increase the security of the system. These check commands (grpck, usrck, pwdck) are available for use by root or anyone in the security group. The grpck command verifies that all users listed as group members in a group are defined as users on the system, that the GID is unique in the system, and that the group name is correctly formed. This ensures that all people listed in this group are indeed a user on the system and that there are not two groups with the same GID. If the groups have the same GID, then people assigned to just one of those groups will have access to both groups. The usrck command verifies parameters of a UID. It also looks for duplicate UIDs. The pwdck command checks authorization stanzas in /etc/passwd and /etc/security/passwd. If anything is wrong between the two, the standard fix is to remove the stanza. This pwdck command does not check for specified password rules as defined. AIX comes with a lot of auditing features. Not all activities on the system can be audited, therefore, research must be done to determine what are the areas of greatest importance to audit. The following are some areas of great importance in AIX and should be audited to some extent: 1- Changes to the TCB (attempts to change the kernel, or critical databases) 2- User authentication (a hacker trying to authenticate himself as a user) 3- Configuration changes (changing the system INIT level) 4- Initialization of the system (installing new executable programs) 5- Data transfer (obtaining or granting privileges) 6- Access to data. (reading or modifying data to which the user has no access to) Once the determination is made on what information is to be audited, this information must be processed into a readable format. In AIX there are two ways to read audit information. They are STREAM (real time) and BIN (stored to a file for later review). In BIN mode, the audit records are written to a temporary file. After the file is filled, the data is processed by the auditbin daemon and the records are written to an audit trail for storage. This audit trail is stored in the /etc/security/audit/config file. Ensure that no one has access to change or delete this file, especially the people whose activities this file is auditing. In STREAM mode, the records are written to a buffer and can be read in realtime. This provides immediate threat monitoring capability. Use the auditstream command to provide immediate threat monitoring. There are features built into AIX that help prevent denial of service (DOS) attacks. A denial of service attack is when something or someone tries to use up all the system resources thereby rendering the system unavailable to users. Disk quotas is one way to prevent DOS attacks by limiting the amount of disk space that any one user can use. This will prevent the user from exceeding the allocated amount of

disk space. Without this restriction, a user can create a simple script to fill up a file system on disk. This could result in the system becoming unusable when the file system is full. There are three steps to setting up disk quotas: 1-Enable the file system to be protected for quotas (with the chfs command or edit the /etc/filesystems,then mount) 2-Set up the quota limits for a user (edquota -u user name) 3-Turn on quota monitoring for the system AIX also allows the system administrator to set limits against individuals usage of the system. This prevents a user from consuming large amounts of CPU time and possibly causing high paging activities thus slowing the system down. The limits that can be set include areas such as CPU usage time, file size, memory usage, data size, or time. This can be done by editing the /etc/security/limits file. Locking ports after a number of failed login attempts prevents a common DOS attack known as login swapping. Login swapping is when a large amounts of login requests are initiated that require the CPU to perform authentication and eventually slow a system down. This is a common DOS attack. There are ways a system administrator can make the AIX system more secure. AIX offers tools to help harden the host. Most UNIX operating systems (including AIX) are configured by default in a promiscuous manner. That means they are configured for easy communications with other systems. This means by default, many ports are active. It is important to close all the ports that are not needed or are not being used. The netstat command is a tool to discover which ports are available to enter the system. By removing the services and closing the ports that are are not used or required, you can make the host safer. In AIX there are certain services that are known to be problematic from a security standpoint and should be disabled. They are the tftp, finger,systat, netstat, uucp,exec, login, and shell services. These services can be disabled by editing the /etc/inetd.conf file and commenting out the services that are not required. The finger daemon (one that should be disabled as mentioned above) is the first command used by a hacker to try to break into the system. It shows users who are idle on the system. This gives the hacker information on whose account is not being used and gives them a target UID to break into. Since it is not being used, a successful break-in of the UID may go unnoticed because the user is not using it. This is why finger daemon should be disabled. The following are examples of passwordless services: R commands, X Windows, TFTP, and Anonymous FTP. These services were designed passwordless on purpose to make it easier for programmers to talk to each other. However, there is a danger with these services. No authentication exists between the client and the server. This means the server is reliant on the client machine being trusted (that no spoofing occurred). If you must use

these commands, do not use .rhosts or /etc/hosts.equiv files to automate their operations. These commands should stay manual commands. No important information should be displayed on the AIX logon screen. The operating system, the version or release number or host name should not be displayed. A welcome message should never appear on the login screen. A hacker could use the presence of that welcome message in court and say it said I was welcomed to the system. This has held up in court. A warning message about unauthorized access should display on this screen. This display can be changed in the /etc/security/login.cfg file. There are some TCP/IP commands that are not very secure when it comes to authentication (rcp, rlogin, rsh, and tftp). The securetcpip command disables less secure standard TCP/IP commands. It is recommended that the system administrator uses this securetcpip command on all systems in the network. Although AIX comes as an open system with hardly any security installed, AIX has a lot of security options built into it that require the system administrator to set up. These security options include authentication, authorization, monitoring, and hardening the host features. The system administrator must find the correct balance between security, risk and cost.

Вам также может понравиться