Basic AIX Security Strategies and Best Practices
Jaqui Lynch covers some of the basics of locking down your LPARs
In this article we will cover some of the basics of locking down your LPARs. This isn’t done by default, but it’s fairly easy to do. It ranges from default permissions and umasks, good usernames and passwords, logging, patching, and removing insecure daemons to integration with LDAP or active directory (AD).
Usernames and PasswordsThis is one of the most basic protections. In order to have longer usernames and passwords, you need to make a system change. Changing the username length is almost always required if you want to integrate with LDAP or AD (active directory) and it requires a reboot.
Below is the command to increase the maximum username length to 36:
chdev -l sys0 -a max_logname=36 Then you check it as follows: # lsattr -El sys0 | grep max_log max_logname 36 Maximum login name length at boot time TrueThe above change requires a reboot of the LPAR.
In order to have longer passwords, you need to use the chsec command. The version below causes the system to use ssha256 (up to 255 characters) for passwords. The next time local users change their password they will get a much longer, more secure password.
chsec -f /etc/security/login.cfg -s usw "pwd_algorithm=ssha256"Then you can use getconf to check the setting
getconf PASS_MAX 255Finally, I normally set the system up to automatically create home directories—this is important in an LDAP or AD environment.
chsec -f /etc/security/login.cfg -s usw -a mkhomeatlogin=true tail /etc/security/login.cfg pwd_algorithm = ssha256 mkhomeatlogin = true
LoggingLogging is a critical part of any system-protection strategy. Without logs, it’s impossible to know what’s been happening on the system. The syslog daemon (syslogd) starts by default on AIX, but the log configuration file isn’t set up to actually log everything. The first step is to correctly set up /etc/syslog.conf. It’s best to set up a separate file system for logs (e.g., /usr/local/logs) rather than use the default of /var/spool. If /var fills up, the system will crash; if your separate file system fills up, it will just stop logging. Although file systems should be monitored, it’s still wise to store logs in their own file system to protect against
large logs bringing down the system. Logs can be written to a file, sent to the console, logged to a central host across the network (be wary of this as the traffic
can be substantial), e-mailed to an administrator or sent to all logged-in users or any combination thereof. The most commonly used method is writing to a file in a file system. Once the file system is set up, code a /etc/syslog.conf file. Here’s an example file that writes to a local filesystem. It keeps the logs to no more than 2MB, then rotates and compresses them, keeping the last 10 logs. I do this on all LPARs and VIO servers.
# mail.debug /usr/local/logs/mailog rotate size 2m files 10 compress *.emerg /usr/local/logs/syslog rotate size 2m files 10 compress *.alert /usr/local/logs/syslog rotate size 2m files 10 compress *.crit /usr/local/logs/syslog rotate size 2m files 10 compress *.err /usr/local/logs/syslog rotate size 2m files 10 compress auth.notice /usr/local/logs/infolog rotate size 2m files 10 compress *.info /usr/local/logs/messages rotate size 2m files 10 compressGo into /usr/local/logs and create each of the files above using touch.
Now you can stop (stopsrc -s syslogd) and start (startsrc -s syslogd) the logging daemon.
Insecure DaemonsThe /etc/inetd.conf is over 120 lines long—some items are commented out but most are not. Many of the protocols listed in there have known security holes. One of the first things I do after setting up an lpar is to secure those protocols. I take a copy of /etc/inetd.conf to /etc/inetd.conf-orig and then delete everything in /etc/inetd.conf except the items I want to keep. I then do a “refresh -s inetd.” I do this on all my LPARs and my VIO servers. Typically, my inetd.conf looks like this:
#ftp stream tcp6 nowait root /usr/sbin/ftpd ftpd #telnet stream tcp6 nowait root /usr/sbin/telnetd telnetd -a #xmquery dgram udp6 wait root /usr/bin/xmtopas #dtspcd stream tcp nowait root /usr/dt/bin/dtspcd /usr/dt/bin/dtspcdYou will notice it’s only four lines and everything is commented out. On a NIM server you will see tftp and bootp uncommented. Occasionally when you do maintenance it uncomments or adds back in services. When the file is only 4 lines you can see immediately that it did that. I don’t use ftp and telnet because they are insecure and I have ssh and sftp instead. If you have to use telnet or ftp then you can uncomment them, but remember they send passwords, etc in clear text.
I would also recommend looking at /etc/rc.tcpip to see if snmp, sendmail and other daemons are starting. If you need snmp or sendmail to run then they should be properly configured to keep hackers from taking advantage of default exploits.
Time SynchronizationIn a previous life I used to do a lot of security investigations. When issues involve multiple systems it’s a nightmare trying to follow the trails when the timestamps do not match. A simple fix for this is to implement NTP (network time protocol). Most companies have an NTP server set up on their AD servers, but you can always point to the atomic clocks if necessary. You should set up ntp on your LPARs and your VIO servers.
PatchingAt a minimum make sure you are running a fully supported version of the OS (VIO, AIX, IBM i, Linux). You can check this using the FLRT (fix level recommendation tool). It’s important to keep your patching up to date to proactively solve problems. In the AIX/VIO world there are two different kinds of patching. The first is fix packs (technology levels and service packs) and the second is efixes or ifixes (emergency or interim fixes). Fix packs are installed using install and efixes/ifixes are installed using emgr.
Technology levels and service packs are found at Fix Central. You should check here regularly for updates to your LPARs, VIO servers, server and I/O firmware and HMCs. Additionally, there are products installed, even at the latest service pack, that need updating—typically this includes Java, openssh and openssl. Java patches are downloaded at Fix Central. openssh and openssl are downloaded at the Web Applications site.
I try to get a full patching window every six months unless it’s an emergency. You can use the FLRT and FLRTVC tools to determine what patching needs to occur. Typically, I update the HMC first, then the server firmware, then the I/O firmware and VIO servers and finally the LPARs. However, you should look at the readme/description files for every update to make sure IBM does not have prerequisites that must be followed. This is particularly important with the HMC and server firmware interaction. There are also some requirements with POWER9 and adapter firmware because of the new trusted boot settings.
FLRTVC (efixes and ifixes)Fix Level Recommendation Tool Vulnerability Checker (FLRTVC) comes in two flavors—the first is a script that you can run on the system that uses data from a file (apar.csv) to compare installed filesets and interim fixes against known security problems. The second option is to use the web based online tool (FLRTVC Online). This option allows you to upload the output from two commands to the web page and it produces the output that you need to identify security holes that need to be closed. I normally run it directly on the LPAR or VIO server.
To run flrtvc you first need to download the .zip file and then unzip it. You may also need to download the apar.csv file. If your LPAR/VIO does not have access to IBM then you will need to get the file from IBM and upload it to the LPAR yourself. You then edit the script and change SKIPDOWNLOAD from 0 to 1. It will now look for the apar.csv file in the same directory the script is in. Once that is done you can run it in compact mode and produce an output file as follows:
cd /directory where flrtvc is ksh93 ./flrtvc.ksh >systemname-flrtvc-output.csvThen sftp or scp as asci the systemname-flrtvc-output.csv file to your computer and open it with Excel as a .csv file—the delimiter is |. There are a number of flags that you can use but for the most part I use none of them as I want to get everything.
I tend to have the output go to an NSF mounted filesystem so that all of my security reports are in one place. That way you can concatenate them together or at least just download them all from one place. You can also write scripts that grep on certain things in the output and email those to yourself.
The compact output from the FLRTVC script is best viewed in a spreadsheet and is broken down into the following columns:
- Fileset: shows the name of the fileset that is of issue i.e. bos.net.tcp.client
- Current Version: shows the currently installed level i.e. 220.127.116.11
- Type: will be either sec (for security) or hiper.
- EFix: you only see a value here if the actual efix for the problem is installed.
- Abstract: a description of the problem i.e. Vulnerability in BIND
- Unsafe Versions: a list of the fileset levels that are impacted i.e. 18.104.22.168-22.214.171.124
- APARs: provide that actual APAR number i.e. CVE-2015-5477 or IV75031
- Bulletin URL: provides the URL where you can go to read about the vulnerability to get more information
- Download URL: provides the links to get the fix.
Server Firmware and I/O FirmwareA large number of security and other fixes are done in firmware of some kind. Server firmware and I/O firmware updates can resolve many issues and should be done at least once a year, preferably every six months. Those updates can be downloaded ahead of time and prestaged so that you are not dependent on the IBM sites during the maintenance window.
Timing of updates—typically I will wait until firmware, technology levels or service packs have been out for at least one month (preferably two) before I update to them. At that time, I will update my NIM server and then start to migrate the updates through test, dev, QA and finally, production. Having a good update strategy will save you a lot of downtime and will help with securing your systems.
Active Directory (AD) /LDAP IntegrationWhen users are created on AIX systems (or any UNIX*) they’re assigned a default user (UID) and group (GID) number. The system permissions for files use those numbers. For that reason, you want to be sure that a user has the same UID and GID on every system. Doing this and setting permissions correctly should ensure they can’t access files they are not entitled to. You can either do this manually (think huge spreadsheets) or you can integrate your normal users into an AD or LDAP environment.
Implementing AD or LDAP integration on your AIX systems is much easier than it used to be. You will need to work closely with your AD/LDAP admin as well as the security team. A word to the wise, do not put root or other system accounts under the control of AD or LDAP—those have to be local. Instead, you should restrict them to console access only.
Enhanced AccessIf you have admins or others who need enhanced access, then this should be provided using sudo or some other tool. If multiple users are logging in as root then there is no accountability. Using sudo causes everything to be logged. We used to have to install it using rpm and figure out all the prerequisites, etc. Today, we go to the IBM Linux toolbox and download yum.sh and run it. This installs rpm and yum but it does require ftp access to IBM. Once yum is installed you can use yum to install sudo or other tools. You then use visudo to put together the rules. You can allow a user to become root with or without a password and you can also restrict them to only being able to use certain commands as root. This is very useful for level 1 support and DBAs who need privileges to perform certain tasks.
BackupsEveryone thinks about taking backups for data, but data is of no use if you have no OS. It’s critical to take regular mksysb (OS bootable) backups. I normally take them to my NIM server as that is where I would restore the system from. When discussing backups, you need to make sure these bare metal mksysb backups are part of any backup and disaster recovery plan. A mksysb should be taken at least monthly, and before and after any system maintenance. Additionally, I always have two disks (even on the SAN) on the system reserved for rootvg. One is active and the other is one I use to take an alt_disk_copy backup of rootvg before I make changes. You can never have enough backups!
A Multi-Silo Approach to SecuritySecurity needs to be a team, multi-silo approach where everyone works together to provide the multiple layers that ensure the systems are as secure as possible. The security team should be able to provide you with the policies regarding usernames, etc. If you’re integrating with AD or LDAP then most of those policies are implemented there. While it takes a little time to implement the basic security measures above, it’s worth it to make your systems harder to break into. I build security in by default whenever I set up an LPAR or VIO server. It makes life much simpler to do it at that point. However, it’s still relatively easy to implement later although it will most likely require a reboot.
About the author
Jaqui Lynch has over 38 years of experience working with a projects and OSes across vendor platforms, including IBM Z, UNIX systems and more.
See more by Jaqui Lynch