The ability to produce an audit security snapshot of your system enables the system administrator to produce the effectiveness of your security controls to ensure that security is managed properly on your AIX servers. It also demonstrates the standard security policy that you are currently adopting. Before looking at what should be included in a monthly security and audit reports, let us see how it can be presented. Though I am discussing a security report, remember that the report will be generated from numerous AIX server, and therefore, keep the information presentation sharp and to the point with clearly headed sections. You might decide to have a one box one report approach or you might decide to have all the reports combined into one report. The choice is yours. I have done both the methods, however, I prefer the one big report approach. Think of presenting this information in the HTML format, with tags, so you can click on different sections and go straight to the information that you are interested in. The HTML can be embedded into an email or generated straight to a web page. The choice (without any doubt) will be decided by your own reporting standards.
While producing a report, you might well decide to report only on production servers and exclude any development, research and development, or acceptance testing servers. I believe that a security report that will be shown to your management should only include production servers, as the other servers are generally not as closed and baton downed as a production one.
When putting together a report, you should assume that the servers have the relevant security utilities already operating. Some of the standard tools may be:
- TCP wrappers
- AIX Audit service
What items to report?
I believe that the report should be aimed at producing information about user and login attributes and active IBM security advisories. Before getting into the details, let us first look at the related items that should be included in a general security report:
- IBM security advisories
- Report on password policy (setting and aging)
- Report on set user ID/group ID (UID/GID) files (non-IBM produced ones)
- Correct group membership as per your application policy
- Locked accounts for system process owners, such as: lpd, bin
- Locked accounts after a specified number of days of non-login activity
- Any new or removed user
- Any new or removed groups
- Users who have had substitute user (su) privileges removed or added
- Allowed group membership of users
- Allowed su access to privileged accounts, such as root and application owners
- Login attributes where admin is set to true
- Status indicating if root access is disabled for remote login activities
- Allowed users are able to use File Transfer Protocol (FTP), Secure Shell (SSH), and Secure Copy Protocol (SCP) to access the AIX server
- Report if rexec is disabled in /etc/ineted.conf
- Report on any .rhosts files found
Let us now take a closer look at the points stated above.
The IBM advisories covers vulnerabilities that are sent out by IBM in a detailed email to notify you about the possible compromises of a process or service discovered in certain operating conditions, a fix, or a solution. It is up to you to decide whether the compromise affects you and if you want to resolve it. These emails should be logged in a spread sheet or a database, so that a history of these advisories (providing details about when it came out and what action you took, if any) can be produced. A note of the advisory should be placed in the report.
Having a good password policy, by this I mean password aging and password rules, is paramount. The password policy you use in production should be of a firm standard. One may have two types of password policies. For example, for ordinary support users, perhaps their password should expire after a certain number of days, for example, 35 days. However, for application or batch owners, this can cause issues. No one wants a password to expire during the middle of the night, when an overnight batch is running, so these could be set to never age. However, the rules in choosing a password, such as repeatable characters and minimum length of the password should be the same for all the users. Using the defaults in /etc/security, you should run a check on the defaults stanza against the standard policy that you currently adopt, and you should note any discrepancies can then be seen. If there are known exceptions, then an exclude list should be used and produced with the report. If you are using network authentication, such as Lightweight Directory Access Protocol (LDAP) or Kerberos, then interrogate those extended attributes as well.
Listing 1 demonstrates the method in which a report on the account attributes can be compared and displayed. A template file containing the standard policy of attributes is compared against the default attributes stanza in /etc/security/user on the remote AIX server. Any discrepancies would be seen straight away. Any user who is excluded from this check is also listed.
Listing 1. Account attributes
Standard attributes: Current attributes: admin = admin = false login = true login = true su = true su = true daemon = true daemon = true rlogin = true rlogin = true sugroups = sugroups = ALL admgroups = admgroups = ttys = ttys = ALL auth1 = auth1 = SYSTEM auth2 = auth2 = NONE umask = 022 umask = 022 expires = expires = 0 SYSTEM = SYSTEM = "compat" pwdwarntime = 5 pwdwarntime = 5 account_locked = false 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,..
What user set-uIDs I have
All non-IBM set-uID programs should be reported, so that you will know historically if any new or amended ones have been changed, by comparing it to a previous run or log file. All bespoke set-uID programs should be listed in a security report. You can consider using the fpm command in conjunction with this.
Having the correct group membership ensures that unprivileged users do not have the group access to privileged files. A template that is used against all the group application members should be created. If there are users who should not be in these groups, then this needs to be reported.
Locking system accounts
System process account owners, such as bin, lpd, and so on should have their accounts locked. There really is no reason why these accounts should be left open, even if the login/rlogin attributes are false. The report should list any violations of theses process account holders who have their accounts unlocked.
It is necessary to find users who do not log in to the AIX server for a given long period of time, and check whether they would need an account. After so many days (I suggest 40 days as a good starter), the account should be locked (not removed). It can then be unlocked through an incident process ticket raised by that user, along with an authority given by the application stake holder. After a slightly longer inactive period, the user can be removed. However, one has to be careful here, because if the user is involved in application support, they may well connect to the application through a GUI. Thus, AIX will not be able to update the user’s login attributes, and in such cases, some other mechanism is required to check on this, or perhaps use a users’ exclude list.
User and group population
Reporting about any new or removed user or groups demonstrates the way you are administering your system, by keeping the user base population up to date. Any new user or group may arise through a change control request and thus this event is logged. The removal of users most probably through a request or from an employee leavers list that is circulated or perhaps even from dormant accounts. The process of user maintenance is one way to ensure that your system is not clogged up with inactive users.
su and sudo
Check your sudoers file for su access and sugroups, privileged access ensures that only entitled users have the ability to switch user entitlements. It is often the case that a temporary grant of su access is left and thus becomes permanently. By reporting on the su groups, you can quickly determine the users for whom the su access should be revoked. You should at the least report on su access to the following users: root, application owners, batch scheduler owners.
A typical entry for members of the IBM DB2® group (db2grp) with the ability to switch user entitlements without a password to the DB2 instance user db2inst1 is shown below on host ukpen01dd:
%db2grp ukpen01dd = NOPASSWD:/usr/bin/su - db2inst1
Look for admin accounts
You should create a report providing the list of all the users who have admin set to true on their account attributes. Typically this would include the system accounts. Some of these users are: root, daemon, bin, sys, and lpd. However, having stated that, you might delegate this authorization to certain users, and they should also be reported.
No rlogin for root
In my opinion, root should be disabled from any rlogin. You should only be able to access root either from an su/sudo process or through a direct SSH connection from a designated server. This approach pretty much locks the root access down. The only direct login access for root should be through the system console or Hardware Management Console (HMC).
Allowing SCP/FTP access from remote servers needs to be carefully thought about, as you do not want to restrict a user working on an issue that might require them to transfer files. After a user list has been compiled, you can use this list to populate the allowed users’ entry in the /etc/ssh/sshd.conf file. Also, do not forget the ftpaccess.ctl file for FTP allowed users and FTP restrictions. One could also produce the list for users who are forbidden FTP access, and these details would be contained in /etc/ftpusers. I am of the opinion that user root should be allowed only SCP access and that too only from a designated (rollout) server.
A check should also be made to identify if rexec is not commented out in /etc/inetd.conf, I will not state the security reasons for this as they are well explained in any Linux®, UNIX®, or AIX security documentation. The only reason I can see why these should be used nowadays is for perhaps Network Installation Management (NIM) rollouts, and that should only be allowed on a temporary basis. A find command should also be run to identify any .rhosts files in the users’ HOME directories. Unless there is a special reason for a .rhosts file to be used in an insecured connection, these should be reported, and a process must be implemented to get the user moved to SCP.
Check the validity of your password and group files
You can use the
pwdck commands as part of the monthly reporting to demonstrate that your group and password files are correct and have no format issues or invalid users or groups.
Thoughts on putting it together
The security reporting script would be run from a central rollout server, or better still push the script out to each desired remote host then run it. This way if the script needs amending, it only has to be amended on one host.
When dealing with the issue of comparing users who are only allowed in certain groups, I find it best to create a template file of users and use that to compare. This template file would get rolled from a central rollout server before the report is run. The reason for this is, you will be updating this central file periodically throughout the month to specify the user and the group or subgroup to which the user should belong to. The format of the file can be in the same format as /etc/group.
groupname1: usera,userb,.. groupname2: usera,userb,..
It is then a fairly straight forward process to read through this file to compare against the existing groups on the AIX server in question and report users who do not have a match.
Producing a monthly security report allows the system administrator to view the current security policies that are used on all your AIX servers. These can then be easily viewed for any security policy-related discrepancies that you have. The reports should also be presented to the IT security officer for review and storing.
- Subscribe to IBM AIX security advisory email list.
- IBM AIX security
- Read Password expiry and Controlling su access with sugroups.
Get products and technologies
- Try out IBM software for free. Download a trial version, log in to an online trial, work with a product in a sandbox environment, or access it through the cloud. Choose from over 100 IBM product trials.
- Follow developerWorks on Twitter.
- Participate in developerWorks blogs and get involved in the developerWorks community.
- Get involved in the My developerWorks community.
- Participate in the AIX and UNIX® forums:
Dig deeper into AIX and Unix on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.