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 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 group’s 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 administrator’s 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 real-time.
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.
No comments:
Post a Comment