AIX Security Report

Generating audit security snapshots for your system will enable the system administrator to implement effective security control, so as to ensure proper management of the security of your AIX server. It also shows the standard security policies currently used. Before learning about what should be included in monthly security reports and audit reports, let's take a look at how to present them. Although only one security report is discussed here, remember that this report will be generated by a large number of AIX servers. Therefore, you must present the information in an accurate and pertinent manner, each section must have a clear title. You may decide to present the report using one machine one report (one box one report), or integrate all the reports into one report. I have used both methods before, but I prefer to generate large reports. You can consider using HTML to present the information, which contains some tags. Therefore, you can click different sections and find the information you are interested in. HTML can be embedded in an email or directly generated on a Web page. Obviously, the specific method depends on your own report standards.

When generating a report, you may decide to generate only the Report on the production server, instead of preparing the report on any development, R & D or acceptance test server. I think the security reports displayed to managers should only include production servers, because other servers are usually not as closed and conservative as production servers.

When merged into a report, you should assume that the server has adopted some related security tools. Some of the standard tools include:

SSH

TCP Wrapper

AIX Audit Service

Sudo

What is the report?

I think the report should focus on user-related production information, login attributes, and valid IBM Security recommendations. Before learning more about this, let's first look at the content that should be included in the General Security Report:

IBM Security recommendations

Password Policy reporting settings and expiration)

Report on setting user ID/group IDUID/GID) files instead of files generated by IBM)

The group members that comply with the application policy are correct.

Locked accounts of the system process owner, such as lpd and bin

Lock the account after a specified number of days for non-Logon activities

Any new or deleted users

Any new group or deleted Group

Delete or add a user that replaces the user (su) Permission

Permitted user group members

Allow su access to privileged accounts such as root users and application owners

Logon attribute, where admin is set to true

Status indicates whether to disable root access for remote logon activities

Licensed users can use File Transfer Protocol (FTP), Secure Shell (SSH), and Secure Copy Protocol (SCP) to access the AIX server.

Whether to disable rexec in/etc/ineted. conf

Report all. rhosts files found

Now, we will learn more about the items mentioned above.

Note:

IBM recommends that you be notified of the potential defects, patches, or solutions of a process or service under specific operating conditions by means of a detailed security vulnerability description sent by IBM via email. You need to determine whether this defect affects you and whether you want to solve the problem. These emails should be recorded in separate tables or databases, so that we can generate these suggested history records to provide detailed information, the time when the problem occurred, and what operations were taken, if yes ). Descriptions of these suggestions should be included in the report.

Password Policy

It is very important to have a good password policy and Password Expiration rules. The password policy you use in the production environment should be a strict standard. For example, for common support users, their passwords may expire after a period of time (for example, 35 days. However, for applications or batch users, this may cause some problems. No one wants the password to expire when running the batch processing program in the middle of the night, so these passwords may be set to never expire. However, all users should use the same rules to select a password, such as repeated characters and the minimum length of the password. When using the default value in/etc/security, you should check the default settings for the currently adopted standard policy. You will notice all inconsistencies. If these inconsistencies are known exceptions, an exclusion list should be used and provided along with the report. If you are using network authentication, such as Lightweight Directory Access Protocol (LDAP) or Kerberos, you should check the attributes of these extensions.

In the method demonstrated in Listing 1, you can compare and display the report of account attributes. Compare the template file containing the standard attribute policy with the default attribute in/etc/security/user on the remote AIX server, and you will find all the inconsistencies. Listing 1 also lists all exceptional users found during this check.

Listing 1. Account attributes

Standard attributes: Current attributes:

Admin = false

Login = true

Su = true

Daemon = true

Rlogin = true

Sugroups = ALL

Admgroups =

Ttys = ALL

Auth1 = auth1 = SYSTEM

Au22. = au22.

Umask = 022 umask = 022

Expires = 0

SYSTEM = "compat"

Pwdwarntime = 5 pwdwarntime = 5

Account_locked = false

Loginretries = 3 loginretries = 3

Histexpire = 26 histexpire = 26

Histsize = 15 histsize = 15

Minage = 1 minage = 1

Maxage = 5 maxage = 5

Maxexpired =-1 maxexpired =-1

Minalpha = 1 minalpha = 1

Minother = 1 minother = 1

Minlen = 8 minlen = 8

Mindiff = 2 mindiff = 2

Maxrepeats = 2 maxrepeats = 2

Excluded users for this host: ukpen01dd

User1, user2 ,..

Set-uID

All non-IBM set-uID programs should be reported by comparing them with previous running or log files, you can check whether a new set-uID or modified set-uID has changed. All displayed set-uID programs should be listed in the security report. You can consider using the fpm command in combination.

Group member relationship

Having a correct group membership relationship ensures that non-privileged users do not access privileged files in groups. A template should be created for all group application members. If there are any users in these groups that do not belong to these groups, report them.

Locked SYSTEM account

The owner of system process accounts, such as bin and lpd, should lock their accounts. These accounts should not be disclosed even if the login/rlogin attribute is false. The report should list all violations of the owner of these unlocked accounts.

Inactive Account

It is necessary to identify users who have not logged on to the AIX system for a long time and check whether they need an account. After a period of time, it is recommended that 40 days), should be locked rather than deleted) these accounts. The account can be unlocked when the user generates an incident process ticket and the Application Stack owner permits it. Users can be deleted after a long period of inactivity. However, you must be careful when performing this operation, because if the user is related to application support, they may be connected to the application through the GUI. Therefore, AIX cannot update the logon attribute of this user. In this case, you need to use other mechanisms for check or use the user exclusion list.

User and group Filling

Report information about any new or deleted users to display your management system by keeping the user group up-to-date. Any new user or group can create a change control request and record the event. Deleting a user may be completed by sending a request, or deleting the user based on the constantly updating list of resigned employees, or even deleting the user based on the dormant account. The maintenance process ensures that the system is not filled with inactive users.

Su and sudo

Search for su access and sugroup In the sudoers file. Privileged Access ensures that only authorized users can change user permissions. Usually, temporary su Access authorization is left, so the authorization becomes permanent. By reporting the su group, you can quickly determine which users should cancel the su access. You should at least Report su access to the following users: root User, application owner, and batch scheduling owner.

What is IBM DB2 on the host ukpen01dd? A typical entry of a member in the db2grp group. User Permissions can be converted to DB2 instance user db2inst1 without a password:

% Db2grp ukpen01dd = NOPASSWD:/usr/bin/su-db2inst1

Administrator Account

You should create a report that contains a list of all users whose admin is set to true in the account attributes. This usually includes system accounts. Some of these users are: root User, daemon, bin, sys, and lpd. However, you can delegate this permission to a specific user, so you should also report these users.

Disable rlogin for root users

I think all rlogin should be disabled for the root user. You shall only access the root user from the su/sudo process or through a direct SSH connection on the specified server. This method can effectively lock root access. The only logon access to the root user should be implemented through the system Console or the Hardware Management Console (HMC.

FTP/SCP access

You need to carefully consider whether to allow SCP/FTP access from a remote server, because you do not want to restrict users who need to transfer files. After sorting out the user list, you can use this list to fill in the user entries allowed in the/etc/ssh/sshd. conf file. In addition, do not forget the ftpaccess. ctl file. You can use this file to understand the user and FTP restrictions that allow FTP. You can also generate a list of users who disable FTP access. The contents are contained in/etc/ftpusers. In my opinion, only the root user should be allowed to access SCP, and only access from the specified first push is allowed.

Insecure commands

Check whether rexec is commented out in/etc/inetd. conf. I will not explain the security reasons for this, because all Linux? , UNIX? Or the AIX security documentation. I think the only reason why unsafe commands are still used today may be because of the introduction of Network Installation Management (NIM) and only temporary use of them should be allowed. You should also run a search command to identify all. rhosts files in the user's HOME directory. Unless otherwise required to use the. rhosts file in insecure connections for special reasons, no such content should be reported and a process should be implemented to move users to SCP.

Check the validity of passwords and group files

As part of the monthly report, you can use the maid and pwdck commands to confirm that your group and password files are correct, without any format issues or invalid users or groups.

Link all links

Run the Security Report script from a central server or push the script to every necessary remote host and then run it. In this way, if the script needs to be modified, you only need to modify it on a host.

When comparing users that are only allowed in a specific group, I think it is best to create a user template file and use it for comparison. This template file will be released from a central server before running the report, because you regularly update this central file every month to specify the group or sub-group to which the user or user belongs. The file format can be the same as that of/etc/group.

Groupname1: usera, userb ,..

Groupname2: usera, userb ,..

The subsequent process is much simpler. traverse the file, compare it with the existing group on the AIX server, and then report non-matched users.