Checks how old the installed AIX operating system build is, using the build week the operating system reports. An old build is missing years of security and stability fixes, which leaves the system exposed to known attacks and reliability problems.
# oslevel -s built week 2546 (~9 months ago)
This check confirms that the AIX release is still inside the IBM standard support window, so it keeps receiving security fixes. A release past its end-of-support date no longer gets IBM security fixes, leaving newly disclosed CVEs open on the host; the check flags it for upgrade to a supported release, with a Software Support Service Extension only as a bridge. On a VIOS, or when not running as root, the check does not assess and reports NOT_ASSESSED.
# oslevel -s 7300-04-00-2546 -- no announced end of support
This check confirms the AIX (or VIOS) Technology Level is current for its release and still inside its service-pack fix-support window. A box that lags the release latest Technology Level, or whose TL has passed its fix-support end date, is no longer receiving the defect and security fixes IBM publishes for the current TL, so newly disclosed CVEs can remain open. On a VIOS the underlying AIX level is a secondary signal behind the VIOS level.
# oslevel -s 7300-04 (latest TL)
System firmware currency checks whether the firmware level, its supported hardware window, and the Update Access Key that entitles firmware updates are all current. Firmware that falls behind its supported family, or that runs on hardware whose support has ended, leaves a system open to unfixed firmware defects and without an IBM fix path when a part fails. An expired Update Access Key can silently block an emergency firmware update, turning a recoverable problem into an outage.
The measured firmware lifecycle evidence has one or more currency constraints: family FW950 current; hardware support ended 2026-01-31; firmware UAK valid through 2027-02-17.
# lsmcode -c VL950_168 -- family FW950 current; hardware support ended 2026-01-31; firmware UAK valid through 2027-02-17
This check reads the machine type/model from prtconf and looks it up in a bundled IBM hardware-generation reference table to decide whether the LPAR hardware is still in active support. Hardware past its end-of-support date fails when the LPAR has physical I/O adapters of its own; a fully-virtual LPAR warns instead, because the hardware belongs to the host provider; an unknown machine type passes for manual verification on the IBM lifecycle pages.
This hardware generation is past IBM support, but this LPAR has no physical I/O adapters -- the hardware is the host provider's to maintain (PowerVS or your VIOS estate). Confirm whose problem this is.
# prtconf 9009-22A (POWER9) -- hardware support ended 2026-01-31 (fully-virtual LPAR)
IBM firmware and AIX updates require a current Update Access Key. This check reads the expiry date of the key and reports whether it has expired or is within 30 days of doing so. An expired key silently blocks any update released after the expiry date, and that is usually discovered only during an emergency fix, when the delay hurts most.
# lparstat -u valid through 2027-02-17
This control verifies that the at command, which schedules one-off jobs on the system, is restricted by an allow list rather than a deny list: the file /var/adm/cron/at.deny must be absent and /var/adm/cron/at.allow must name root. If a deny list governs access instead, any account not explicitly blocked is allowed by default, so an unprivileged or compromised user could queue a job to run commands later and use it to execute code or hold on to access.
/var/adm/cron/at.deny exists, so at(1) authorization is governed by a deny list; a user not listed is permitted by default instead of being required to appear in the allow list.
# ls -ld /var/adm/cron/at.deny /var/adm/cron/at.deny present
This control checks that the mail queue directory /var/spool/mqueue exists and is accessible only to the root account. That directory holds outbound messages waiting to be delivered, including their contents. If it is missing or left open to other users, those messages could be read or altered before they are sent, exposing email content and allowing tampering.
A missing or wrongly-accessed /var/spool/mqueue lets an unintended identity read or alter queued mail files.
# ls -ld /var/spool/mqueue /var/spool/mqueue mode=drwxrwx--- owner=root group=system; requires drwx------ root:system; deviates: mode
This control checks the system-wide password policy that sets a minimum length for every new password. It reads that setting for the default account in the file /etc/security/user and expects at least 14 characters. If it fails, users who inherit the default policy can pick very short or empty passwords, which are easy to guess or crack and let an attacker sign in as that user.
Accounts inheriting the default stanza may set passwords shorter than the CIS baseline of 14 characters.
# lssec -f /etc/security/user -s default -a minlen minlen=10; CIS baseline requires at least 14
This control checks the failed-login limit in the default AIX account settings, the loginretries attribute in the file /etc/security/user. A low limit locks an account after a few wrong passwords, which stops an attacker from trying thousands of guesses until one works. If the limit is missing or set too high, an attacker can keep guessing a password and eventually take over the account.
Accounts inheriting the default stanza receive a weaker loginretries policy.
# lssec -f /etc/security/user -s default -a loginretries loginretries=0; required between 1 and 3 inclusive
This control checks the default password expiry setting (maxage) in the /etc/security/user file, which sets how long a password stays valid before it must be changed. If that value is set to zero or beyond the approved limit, passwords never expire or stay usable far too long, so a stolen password keeps working until it is discovered and changed by hand.
Accounts inheriting the default stanza receive a weaker maxage policy.
# lssec -f /etc/security/user -s default -a maxage maxage=13; required between 1 and 8 inclusive
This check confirms that no account in the system password file (/etc/security/passwd) has a blank password. An account with a blank password lets anyone sign in to it without entering a credential. If the check fails, an attacker who can reach the system login can take over that account and everything it is allowed to do.
At least one account stanza has nothing stored after 'password =', so that account can be signed into without supplying a credential.
# test -r /etc/security/passwd blank password in /etc/security/passwd: root
This control inventories every setuid and setgid program on the system and confirms each one is authorized. A setuid or setgid program runs with the privileges of its owner, usually root, no matter who starts it. An unauthorized one can let any user run commands as root, so a planted or unapproved program of this kind hands an attacker full control of the system.
At least one setuid/setgid file exists on disk that no approved baseline entry, site exception, or installed fileset accounts for; it may be unauthorized.
# mount 48 of 277 setuid/sgid file(s) are not owned by any installed fileset; 3 unresolved
This control confirms that the Network Information Service (NIS) client software is not installed on the system. NIS is a legacy directory service that shares account and password information across the network with little protection, so a system running the NIS client can have its login credentials exposed or be made to trust a malicious NIS server that an attacker controls.
The NIS client fileset is present in the installed-software database; the host can provide NIS client services.
# lslpp -L bos.net.nis.client bos.net.nis.client is installed (lslpp rc=0)
The adm account is a built-in AIX account used for system administration and accounting, and it is not meant for people to log into. This check confirms the account is either absent or fully locked down, with local and remote login disabled, a non-working shell, and the account locked. If it can still be logged into, an attacker who takes it over gains a foothold with access to that administrative and accounting data, which could be read or altered.
The adm account retains at least one usable login path or is not locked.
# lsuser -a login rlogin shell account_locked ALL login=true, rlogin=true, shell=(unset), account_locked=false; requires login=false rlogin=false shell=/usr/bin/false account_locked=true; deviates: login rlogin shell account_locked
This control checks the AIX password policy setting that requires a minimum number of letters in new passwords. If the setting is missing or set too low, users can pick passwords with few or no letters, like a phone number or date. Those are easy for an attacker to guess, letting them log into accounts on the system directly, with no technical exploit needed.
The alphabetic-character minimum is disabled, below three, or outside the valid AIX range.
# lssec -f /etc/security/user -s default -a minalpha minalpha=2 (below 3 or outside valid AIX range 0..8)
This control checks that the system audit configuration file /etc/security/audit/config turns on logging for a required set of trusted-execution events by default, including attempts to run untrusted programs, writes to protected files, and changes to security policy and security databases. If any required event type is missing from the default audit set, those activities happen without leaving a record. An attacker could then run unauthorized code or change security settings with no audit trail for detection or investigation.
The audit configuration has a classes: stanza without a default = line, so the required class set is never selected.
# cat /etc/security/audit/config classes: stanza present but no default = line
This check confirms the built-in bin account cannot be used to sign in to the system. It passes when the account is absent or locked, with local login, remote login, and command-shell access all turned off. If the account stays open, bin owns many trusted system programs, so an attacker who logs in as bin gains an interactive shell and a direct way to alter those files.
The bin account retains at least one usable login path or is not locked.
# lsuser -a login rlogin shell account_locked ALL login=true, rlogin=true, shell=(unset), account_locked=false; requires login=false rlogin=false shell=/usr/bin/false account_locked=true; deviates: login rlogin shell account_locked
The daemon account is a built-in AIX system account that runs background services and should never be able to accept a login. This control verifies the account is locked, has no usable login shell, and allows no remote login. If it is left able to log in, an attacker who obtains its credentials gains an interactive foothold on the system and access to the files that identity owns.
The daemon account retains at least one usable login path or is not locked.
# lsuser -a login rlogin shell account_locked ALL login=true, rlogin=true, shell=(unset), account_locked=false; requires login=false rlogin=false shell=/usr/bin/false account_locked=true; deviates: login rlogin shell account_locked
This control checks that the default password policy points to a dictionary of common words, so AIX rejects them when a user chooses a new password. If no dictionary is set, or the setting is malformed, users can pick easy-to-guess passwords such as password or welcome, which are the first words an attacker tries, making accounts much quicker to break into.
The default password policy has no dictionary configured, so dictionary-word checks are not enforced for accounts inheriting this stanza.
# lssec -f /etc/security/user -s default -a dictionlist dictionlist is unset
This check verifies that a new password must differ from the previous password by at least six characters. If that rule is missing or set too low, someone can change a password while keeping nearly all of the old one. Anyone who already knew the old password could then guess the replacement with little effort, so the change provides no real protection.
The default password policy permits a new password with fewer than six characters changed, or contains an invalid numeric setting.
# lssec -f /etc/security/user -s default -a mindiff mindiff=0
This control checks that the built-in guest account is either absent from the system or fully locked down, with local and remote login disabled, a non-working shell, and the account itself locked. If the guest account can still be used to log in, an attacker gains an easy, well-known foothold on the system from which to explore and escalate.
The guest account retains at least one usable login path or is not locked.
# lsuser -a login rlogin shell account_locked ALL login=true, rlogin=true, shell=(unset), account_locked=false; requires login=false rlogin=false shell=/usr/bin/false account_locked=true; deviates: login rlogin shell account_locked
This control checks whether the hostmibd service is enabled at boot or running now. hostmibd is a helper that answers SNMP queries about the hardware and software of the machine, and most systems never use it. When it is left on unnecessarily, it is an extra network service an attacker could query for details about the host or probe for weaknesses.
The hostmibd dpi2 SNMP sub-agent serves RFC 2790 MIB variables and adds avoidable exposure where SNMP is not required.
# cat /etc/rc.tcpip hostmibd starts at boot in /etc/rc.tcpip and is active in the SRC inventory
The lpd account exists only to run the line printer service and should never be able to log in interactively. This control confirms the account is either removed entirely or locked with all of its local, remote, and shell login paths disabled. If it fails, the lpd account can still be used to sign in, giving whoever holds it a working entry point into the system.
The lpd account retains at least one usable login path or is not locked.
# lsuser -a login rlogin shell account_locked ALL login=true, rlogin=true, shell=(unset), account_locked=false; requires login=false rlogin=false shell=/usr/bin/false account_locked=true; deviates: login rlogin shell account_locked
This control checks the AIX maxrepeats password setting, which caps how many times a single character may be repeated in a new password. If repeats are not tightly limited, users can set passwords built mostly from one repeated character, and attackers can guess those weak passwords much faster and take over the accounts.
The maxrepeats setting is absent, ineffective, invalid, or exceeds the CIS ceiling of four.
# lssec -f /etc/security/user -s default -a maxrepeats maxrepeats=8; required between 1 and 4 inclusive
The nobody account is a well-known, built-in account that ships with AIX and is meant to have no way to log in. This control checks that the account is either not present or fully locked down with every login path disabled. If it still allows a login, an attacker can sign in as nobody and use that known account as a foothold to run commands and work toward higher access.
The nobody account retains at least one usable login path or is not locked.
# lsuser -a login rlogin shell account_locked ALL login=true, rlogin=true, shell=(unset), account_locked=false; requires login=false rlogin=false shell=/usr/bin/false account_locked=true; deviates: login rlogin shell account_locked
This control checks the minother setting in the AIX default password rules, which requires each password to contain a minimum number of non-alphabetic characters such as digits or symbols. It passes when that minimum is between three and eight. If the setting is missing, too low, or outside the valid range, passwords may be made up almost entirely of letters, which attackers can guess or crack much faster.
The non-alphabetic-character minimum is disabled, below three, or outside the valid AIX range.
# lssec -f /etc/security/user -s default -a minother minother=1 (below 3 or outside valid AIX range 0..8)
This control checks that the legacy nuucp system account is either removed or fully locked down by disabling its local login, remote login, and login shell, and by locking the account itself. The nuucp account exists on AIX for the obsolete UUCP file-transfer service, and a well-known default account like this is a common first target for attackers. If the account is left active with a usable login path, an attacker could log in under that identity and use it as a foothold to move deeper into the system.
The nuucp account retains at least one usable login path or is not locked.
# lsuser -a login rlogin shell account_locked ALL login=true, rlogin=true, shell=/usr/sbin/uucp/uucico, account_locked=false; requires login=false rlogin=false shell=/usr/bin/false account_locked=true; deviates: login rlogin shell account_locked
This control checks that the AIX default password policy prevents users from reusing recent passwords. It reads the password history setting in the /etc/security/user file, which must keep the last 20 to 50 passwords out of reuse. If that history is missing, too small, or switched off, a user can cycle back to a password that was already exposed, so forced password changes give no real protection.
The password-history count is below twenty, absent with a weak default, or numerically invalid.
# lssec -f /etc/security/user -s default -a histsize histsize=4 is below CIS minimum 20
This control checks whether the qdaemon print spooler service is active on the system. qdaemon processes queued print jobs, and running it when printing is not needed leaves an unnecessary service live that adds to the code an attacker can target. If the check fails, that avoidable service exposure is present without a business need to offset it.
The qdaemon subsystem is active and adds avoidable service exposure.
# lssrc -a qdaemon active in the SRC inventory
This control confirms that the sendmail mail service is not in use, by checking that it is not started at boot in /etc/rc.tcpip and not running as a service. Sendmail is an older mail daemon with a long history of remotely exploitable vulnerabilities, so leaving it running on a server that does not handle mail exposes an unnecessary, attackable network service. If this control fails, an attacker who can reach that open port may be able to exploit a known sendmail flaw to run code or gain privileged access.
The sendmail daemon is listening as a mail server; it has a long vulnerability history and should be disabled on non-mail servers.
# cat /etc/rc.tcpip sendmail starts at boot in /etc/rc.tcpip
This control checks whether the AIX network analysis package bos.net.snapp is installed on the server. It is a specialized diagnostic tool that most production systems do not need. If it is present, anyone who gains access to the server has a ready-made way to observe network traffic, and the system carries an extra rarely used package that adds attack surface.
The snapp fileset is present on this system.
# lslpp -qcL bos.net.snapp installed (1 inventory row(s))
The sys account is a built-in AIX system account that owns system files and is not meant for anyone to sign in to. This check confirms the account is absent, or that it is locked with its local login, remote login, and login shell all disabled. If any of those login paths is left open, an attacker who obtains the account gains an interactive foothold on the system and access to the files that identity owns.
The sys account retains at least one usable login path or is not locked.
# lsuser -a login rlogin shell account_locked ALL login=true, rlogin=true, shell=(unset), account_locked=false; requires login=false rlogin=false shell=/usr/bin/false account_locked=true; deviates: login rlogin shell account_locked
This check confirms the uucp system account has every login path closed and is locked. The uucp account belongs to a legacy file-transfer service and is not meant for anyone to sign in to. If it keeps a usable local or remote login path, an attacker who takes it over can use this trusted system account to move or alter transferred files and hide their activity.
The uucp account retains at least one usable login path or is not locked.
# lsuser -a login rlogin shell account_locked ALL login=false, rlogin=false, shell=(unset), account_locked=false; requires login=false rlogin=false shell=/usr/bin/false account_locked=true; deviates: shell account_locked
Trusted Execution enforces that only programs approved in the system trust database are allowed to run, so a modified or planted executable is blocked before it starts. This check also confirms that the system records those enforcement events in its syslog. If it fails, tampered or malicious code can run, and the log of what was blocked or allowed is lost.
Trusted Execution is not enforcing executable integrity with CHKEXEC; the control requires both attributes on.
# /usr/sbin/trustchk -p TE CHKEXEC Trusted Execution disabled - TE and CHKEXEC are both off
This control checks that the FTP deny list (/etc/ftpusers) includes the root account, so the FTP daemon refuses root logins. If that entry is missing, the server will accept root logins over FTP, letting an attacker guess or capture the root password on an unencrypted connection and take full control of the system.
With the deny mechanism missing there is no entry blocking root, so root login over FTP is permitted if the daemon runs.
# grep '^root$' /etc/ftpusers /etc/ftpusers is absent (rc=2), so no FTP deny entry for root exists
This check confirms that the built-in system accounts, including root, are listed in /etc/ftpusers, the file that blocks those accounts from signing in over FTP. If any of them are missing, an attacker could sign in over FTP as root or another system account on any system where an FTP service is running, and FTP sends passwords in clear text. That could give an attacker full control of the system or a way to act as a trusted service account.
Without /etc/ftpusers no account is denied FTP access, so root and the system accounts may authenticate over FTP wherever an FTP daemon is enabled.
# ls -ld /etc/ftpusers /etc/ftpusers absent (ls rc=2): no account is denied FTP access
This control verifies that scheduled-job access on the server is restricted to an approved list. It confirms the file /var/adm/cron/cron.deny does not exist and that /var/adm/cron/cron.allow names the root and adm accounts. If it fails, users who were not approved could create recurring jobs, giving an attacker a way to schedule malicious or persistent activity on the system.
cron.deny exists, so any user not listed in it is allowed -- the weaker access-control path.
# ls -ld /var/adm/cron/cron.deny /var/adm/cron/cron.deny present
This control runs the AIX account-file checker in report-only mode to confirm that every local account is recorded consistently across the two files that define it: /etc/passwd and /etc/security/passwd. The account list lives in the first file while the stored password and other protections live in the second, so the two must agree. If the records drift apart or are damaged, an account can lose its stored password and other protections and authenticate without the password the policy requires, or a legitimate user can be locked out entirely.
pwdck -n ALL exited 114, which is how it reports that it found problems, and it wrote defect lines, so at least one /etc/passwd or /etc/security/passwd stanza is inconsistent.
# pwdck -n ALL pwdck -n ALL exited 114 with 24 defect lines naming 12 accounts: esaadmin, invscout, ipsec, lp, nuucp, pj, ragent, root, and 4 more
This check confirms that the root account on an AIX system is locked down: root cannot sign in directly over the network, and only a named administrator group may switch to the root user. If either gate is left open, anyone who guesses or steals the root password could take over the entire system, with no record of who did it.
root can log in directly over the network (rlogin=true) AND any user may attempt su to root (sugroups=ALL) -- the classic 'root wide open' pair. Either alone is a gap; together, root is one guessed password away from a network login with no accountability. This is the OS account gate in /etc/security/user, separate from sshd's PermitRootLogin.
# lssec -f /etc/security/user -s root -a rlogin -a sugroups -a admin -a expires rlogin=true + sugroups=ALL (root wide open)
This control verifies that /etc/hosts, the file that maps hostnames to network addresses, is writable only by its owner and readable only by its owner and group. If the file is left more permissive than this, an attacker or a compromised account could add or alter entries to redirect connections for trusted systems to a machine they control, intercepting traffic or disrupting name resolution.
/etc/hosts violates the required mode boundary and could let an unintended identity alter trusted configuration.
# ls -ln /etc/hosts /etc/hosts mode=0664
This check confirms that the inetd configuration file at /etc/inetd.conf grants no more than owner read and write plus group read, with no access for everyone else. That file tells the inetd daemon which network services to start on demand, often with elevated privileges. If a wider set of users could write to it, someone could register a rogue service that runs with those privileges and opens a hidden way into the system.
/etc/inetd.conf violates the required mode boundary and could let an unintended identity alter trusted configuration.
# ls -ln /etc/inetd.conf /etc/inetd.conf mode=0664; requires no bits beyond 0640
This control checks that the sendmail configuration file /etc/mail/sendmail.cf is owned by root, belongs to the system group, and allows no one outside those accounts to read or change it. If those permissions are loosened, another user could edit the file to reroute, capture, or corrupt the mail the system sends.
/etc/mail/sendmail.cf deviates from the required root:system owner/group and -rw-r----- mode boundary and could let an unintended identity alter trusted mail configuration.
# ls -l /etc/mail/sendmail.cf /etc/mail/sendmail.cf mode=-rw------- owner= group=; requires -rw-r----- root:system; deviates: mode owner group
This control verifies the permissions on /etc/mail/submit.cf, the Sendmail mail submission configuration file, and requires that the file is no more open than writable by its owner and readable by its group, with nothing available to other users. A file left more open than this could be changed by someone who should not control it, letting them tamper with mail submission settings or redirect outbound mail.
/etc/mail/submit.cf violates the required mode boundary and could let an unintended identity alter trusted configuration.
# ls -ln /etc/mail/submit.cf /etc/mail/submit.cf mode=0644; requires no bits beyond 0640
This control checks the permissions on the /etc/security directory, where AIX keeps trusted security settings such as user and group definitions and login policy. The directory must give full access only to root, read and search access to the security group, and no access at all to anyone else, and it must keep the setgid flag that carries the security group onto new files. If the permissions are looser, an ordinary user could read or alter this configuration and weaken or bypass system access controls.
/etc/security violates the required mode boundary and could let an unintended identity alter trusted configuration.
# ls -ldn /etc/security /etc/security mode=0750
This control checks the permissions on the /var/adm/sa directory, where the system keeps its daily system activity data. The directory must not be writable by group members or by other users. If it is, someone without administrative rights could modify or delete those records, corrupting the activity data used to review how the system is running.
/var/adm/sa violates the required mode boundary and could let an unintended identity alter trusted configuration.
# ls -ldn /var/adm/sa /var/adm/sa mode=0775; requires no bits beyond 0755
This control checks the permissions on /var/tmp/hostmibd.log, the log file written by the AIX host monitoring daemon, and requires that nothing beyond owner read and write plus group read is granted. If it fails, other users can read or change that log, exposing monitoring data about the host or letting the log record be tampered with.
/var/tmp/hostmibd.log violates the required mode boundary and could let an unintended identity alter trusted configuration.
# ls -ln /var/tmp/hostmibd.log /var/tmp/hostmibd.log mode=0644; requires no bits beyond 0640
This control checks that every JFS filesystem on the system is mounted with the nodev option, which stops the operating system from treating files on those filesystems as hardware devices. If a JFS filesystem is mounted without nodev, a local user who can write to it can create a fake device file and use it to reach raw storage, gaining read or write access to data and privileges they should not have.
A JFS filesystem is defined or mounted without the nodev mount option, so device nodes on that filesystem are interpreted by the kernel -- a local user able to create a file there can forge a device node and escalate privilege. The root filesystem on /dev/hd4 is the single allowed exception.
# lsfs JFS filesystem(s) without nodev: /dev/hd1 -- /home jfs2 65536 rw yes no /dev/hd2 -- /usr jfs2 5701632 rw yes no /dev/hd9var -- /var jfs2 1638400 rw yes no /dev/hd3 -- /tmp jfs2 2621440 rw yes no /dev/hd11admin -- /admin jfs2 262144 rw yes no /dev/hd10opt -- /opt jfs2 3604480 rw yes no /dev/livedump -- /var/adm/ras/livedump jfs2 524288 rw yes no /dev/rep00 -- /usr/sys/inst.images jfs2 16973824 rw yes no /dev/hd2 /usr jfs2 Aug 14 19:55 rw,log=/dev/hd8 /dev/hd9var /var jfs2 Aug 14 19:55 rw,log=/dev/hd8 /dev/hd3 /tmp jfs2 Aug 14 19:55 rw,log=/dev/hd8 /dev/hd1 /home jfs2 Aug 14 19:56 rw,log=/dev/hd8 /dev/hd11admin /admin jfs2 Aug 14 19:56 rw,log=/dev/hd8 /dev/hd10opt /opt jfs2 Aug 14 19:56 rw,log=/dev/hd8 /dev/livedump /var/adm/ras/livedump jfs2 Aug 14 19:56 rw,log=/dev/hd8 /dev/rep00 /usr/sys/inst.images jfs2 Aug 14 19:56 rw,log=INLINE
This control checks the command search path (PATH), the list of directories the system searches to find programs, and verifies that every entry is a real, absolute directory owned by the system (root or bin) and not writable by other users. If the path holds an empty, missing, relative, or writable entry, a malicious program planted in one of those locations can run in place of a legitimate command. The result is command hijacking, where an attacker can execute arbitrary code when a normal command or login script runs.
A PATH entry can place an unintended directory ahead of the system search order, or an empty entry can resolve commands against the current directory.
# echo "${PATH}"
PATH entry 5 "/usr/ucb" is group-writable.; PATH entry 8 "/usr/ios/cli" does not exist.This control checks that the SNMP network-management software is not installed on the system. It fails if the SNMP client or server package is present in the package inventory. SNMP often runs with well-known default community passwords and sends data without encryption, so an installed copy can give a network attacker a way to read system details or change settings.
An SNMP package is registered in the package inventory, so the SNMP service is part of this host's exposed software surface.
# lslpp -Lcq bos.net.tcp.snmp SNMP client fileset bos.net.tcp.snmp is installed and the SNMP server fileset bos.net.tcp.snmpd is installed
This control checks the rcnfs boot entry that controls whether the NFS file-sharing service starts automatically when the system boots. A machine that does not need to share files should not be running NFS; if this entry is present, the system boots into a file-sharing service that an attacker can probe and, where its settings are weak, use to reach files on the host. DISA STIG V-215352 states the rule as a prohibition: running "lsitab rcnfs" must yield no output at all, so the check fails whenever any rcnfs record exists in /etc/inittab.
An rcnfs entry exists in /etc/inittab, so the NFS daemon set is started at boot and the host presents an NFS attack surface it may not need.
# lsitab rcnfs lsitab rcnfs returned 1 record(s) - rcnfs record present in /etc/inittab: rcnfs:23456789:wait:/etc/rc.nfs > /dev/console 2>&1 # Start NFS Daemons
SNMP lets remote management tools read and write information about a system over the network. SNMP community strings are the password that controls this access, and many systems ship with a well-known default such as public or private. The STIG also flags any uncommented default-password token (smux peer password, private, and similar) in the SNMP configuration. If one of these defaults is still in use, anyone who can reach the box on the network can read, or even modify, its SNMP data.
An uncommented line of the SNMP configuration uses a default password token (public/private/password) -- anyone on the network can read, or write, system data.
# test -e /etc/snmpd.conf default SNMP password in use
This control checks that address-space layout randomization is running at full strength on the system. ASLR loads each program and its data at unpredictable memory locations, so an attacker who finds a memory-corruption flaw in software cannot reliably predict where to redirect execution. If this protection is weak or disabled, memory addresses become predictable and an attacker can more easily turn such a flaw into the ability to run their own code on the system.
At least one ASLR tunable is present but not at the mandated full-strength value, weakening address-space randomization.
# /usr/sbin/vmo -aF aslr=0 (required 2)
This check scans the whole local filesystem tree from / for any file or directory whose numeric owner no longer resolves to a known account. When an account is removed, the files it owned are left behind with an unresolvable owner: no one is accountable for them, they escape normal access review and cleanup, and a later account that reuses the same numeric ID silently takes ownership of them. Any such file or directory is a finding.
At least one file or directory among the paths the scan could read has no valid owner. An entry without an assigned owner is detached from any accountable identity and from the lifecycle that reassigns or removes it, which DISA STIG V-215340 prohibits. Some paths were unreadable, so the scan is partial.
# find / -prune -print 256 file(s) or directory(ies) with no valid owner; first: /etc/mobte/models/blackOutReg.json; some paths unreadable
SSH sessions that sit idle too long can leave an open doorway into the system if the user walks away from a logged-in terminal. This control checks the SSH server idle-session timeout settings, ClientAliveInterval and ClientAliveCountMax, to confirm abandoned sessions are automatically disconnected within fifteen minutes. If they are not, an unattended session can be hijacked by anyone who reaches that machine, and stale connections keep consuming system resources.
ClientAliveInterval 0 disables idle-session timeout entirely -- abandoned SSH sessions remain open indefinitely.
# sshd -T ClientAliveInterval 0 (disabled)
SSH MaxAuthTries limits how many login attempts a single SSH connection is allowed before the server closes it, and this check confirms that limit is four or fewer. If the limit is set higher, an attacker who reaches the SSH service can make many password guesses per connection before being cut off, which makes brute-force password guessing faster and more likely to succeed.
MaxAuthTries is 6 -- exceeds the required maximum of 4.
# sshd -T 6
An interactive shell session can keep running until someone closes it. This check verifies that /etc/profile sets both TMOUT and TIMEOUT to 600 seconds or less, uncommented, so an idle login session is terminated after 10 minutes of inactivity (DISA STIG V-215320). Without it, an unattended session stays open and anyone who reaches it can act with the full privileges of that account.
No active TMOUT/TIMEOUT assignment is present in /etc/profile, so idle login sessions are not terminated after 10 minutes.
# grep -E ' TMOUT|TIMEOUT' /etc/profile no active TMOUT/TIMEOUT directive in /etc/profile (commented or blank)
This control verifies that a login banner is set in the AIX login settings file /etc/security/login.cfg. That banner appears before the login prompt and tells anyone who connects that only authorized use is permitted. If it is missing, the system shows the login prompt without that authorized-use warning, which weakens legal notice against unauthorized access and removes a visible deterrent to misuse.
No login banner (herald) is configured -- a CIS AIX 7 v1.2.0 section 4.7.1 finding.
# lssec -f /etc/security/login.cfg -s default -a herald herald absent; not configured in login.cfg default stanza
This check confirms whether AIX was installed using the Secure by Default option, which installs a minimal software set and leaves out remote-access programs such as telnet and ftp that send passwords across the network as readable text. If that option was not selected at installation, those programs can be present and reachable, so anyone able to read network traffic could capture login passwords, and services such as rsh, rcp and sendmail add extra remote-access points an attacker can probe.
Software that a Secure by Default installation never installs is present on this system, so this system was not installed with Secure by Default.
# ls -l /etc/security/aixpert/log SbD-excluded software installed (2): /usr/sbin/sendmail, bos.net.tcp.sendmail
This control checks that the SSH service is configured with an allow list or deny list of users or groups (AllowUsers, AllowGroups, DenyUsers, or DenyGroups). When none of these is set, the server accepts remote login attempts for every account that has a working password or key, so a single weak or leaked credential opens a way in.
The SSH daemon has no user-level or group-level access restriction configured, so the effective configuration does not constrain who may authenticate.
# lslpp -L openssh.base.server no AllowUsers/AllowGroups/DenyUsers/DenyGroups directive in the effective sshd configuration
SSH encrypts each connection with a session key, and the server is meant to negotiate a fresh key so that no single key protects too much traffic. This control reads the effective rekey limit and treats only the exact pairing of 1073741824 bytes and 3600 seconds as meeting the requirement; any other pairing, or none at all, is reported as not meeting it. Where no limit is enforced, one key can cover an entire long-lived session, so an attacker who recovers that key can decrypt far more of the traffic.
The SSH server does not enforce the required session-key renegotiation boundary because the effective rekeylimit differs from 1073741824 bytes and 3600 seconds.
# sshd -T rekeylimit 0 0
This control checks the default umask value in /etc/security/user, the AIX file that holds user settings. That value controls the permissions automatically given to every new file and directory a user creates. If it is missing or too permissive, new files and directories can be created readable or writable by other users on the system, exposing data or letting others change it.
The default umask is missing or less restrictive than 027, so new files can be created with wider permissions than intended.
# lssec -f /etc/security/user -s default -a umask default umask present but less restrictive than 027
This check confirms the SSH file-transfer subsystem is configured to create uploaded files with a restrictive permission mask and to record transfer activity in the system log. If it is not, files a user uploads can be created with permissions that let other local users read or change them, and file transfers can go unrecorded, leaving misuse undetected.
The effective SFTP subsystem does not enforce the required umask and logging policy, so transfers may be exposed or go unlogged.
# test -x /usr/sbin/sshd effective SFTP subsystem line is present but its arguments are not '-u 027 -f AUTH -l INFO' or '-u 027 -f AUTH -l VERBOSE'
This check confirms that every local, non-system user account has a home directory that exists, is not writable by the group or by other users, and carries no extended access-control list. If a home directory fails this check, another account on the system can write into it and plant or modify files there, which can let an attacker take over the account or tamper with its data.
The home directory of a non-system account grants group or other users write access, so another identity can alter the account's files.
# lsuser -R files -a id home ALL home /var/run/opencryptoki of slotd is group- or world-writable
This control verifies that switching to the root account with the su command is restricted to members of a defined group (the sugroups attribute of the root account). When sugroups is blank or ALL, any group can attempt su to root, opening a wider route to full control of the machine.
The root account leaves su open to every group: sugroups is blank or ALL, contrary to DISA STIG V-215338.
# lsuser -a sugroups root sugroups=ALL
This check confirms the root account home directory (taken from /etc/passwd, other than /) has mode 0700 exactly and is restricted to root. That directory holds the startup files that run every time the root account logs in. If it is missing, owned by someone else, or has a mode other than 0700, another user could alter those startup files to steal secrets or sneak commands into the root login.
The root account uses / as its home directory, exposing root dotfiles to every user on the system.
# sh -c "grep \\"^root\\" /etc/passwd | awk -F\\":\\" '{print \\$6}'"
root home=/This control confirms the system is configured not to write core dump files when a program crashes, by checking that the default core file size limits in /etc/security/limits are set to zero and that fullcore is off. A core dump is a copy of the memory of a crashed program, which can contain passwords, encryption keys, and other sensitive data. If these dumps are enabled, anyone with access to the system could read the files and recover that information.
The system is able to write process core dump files, and a full-size dump captures process memory that can include credentials and keys.
# lssec -f /etc/security/limits -s default -a core -a core_hard core=2097151 and core_hard is unset in the default stanza of /etc/security/limits, so the AIX default unlimited hard core limit applies
This control verifies the sendmail PrivacyOptions setting in /etc/mail/sendmail.cf contains the goaway keyword, which disables the SMTP EXPN and VRFY features (among others). With EXPN or VRFY active, anyone can ask the mail server whether an address or mailing list exists and harvest valid addresses for spam or targeted attacks.
Without goaway in PrivacyOptions, sendmail answers VRFY/EXPN queries and leaks account information over SMTP.
# ls -ld /etc/mail/sendmail.cf PrivacyOptions is present but does not include goaway
This control checks that the entries in /var/adm/ras, the AIX directory that holds system error reports and diagnostic logs, are not readable or writable by ordinary users. That directory is where the machine records hardware and software faults and other runtime events. If any entry is left open to world read or write, an attacker could read log detail or alter the records used to detect and investigate incidents, making an intrusion harder to prove.
World-readable or world-writable entries under /var/adm/ras expose log evidence that an attacker could read or alter.
# ls -ln /var/adm/ras /var/adm/ras: 24 of 31 entries allow world read or write
This check reads the logindelay setting in /etc/security/login.cfg, which sets how many seconds the system waits after a failed login before allowing another attempt, growing with each failure. The setting must be at least 10 seconds. If it is missing or set lower, the system does not slow down repeated password guessing, and an attacker can hammer the login prompt at full speed until a password is guessed.
logindelay is below 10 seconds or absent, so failed login attempts are not meaningfully throttled -- a CIS AIX 7 v1.2.0 section 4.7.2 finding.
# lssec -f /etc/security/login.cfg -s default -a logindelay logindelay=0 seconds (below 10-second minimum)
This control checks the AIX setting that locks an account after no more than three failed login attempts. If that limit is missing, zero, or set above three, an account either never locks or locks only after many more wrong passwords. An attacker can then keep guessing passwords until one works, which is how automated brute-force login attacks break in.
loginretries is zero or unset, which means unlimited login attempts -- a CIS AIX 7 v1.2.0 section 4.7.3 finding.
# lssec -f /etc/security/user -s default -a loginretries loginretries=0 (invalid non-positive value)
This control checks that the AIX login prompt closes within 30 seconds if no one finishes typing a password, by reading the logintimeout setting in /etc/security/login.cfg. If the prompt stays open longer, an abandoned login prompt remains live at a terminal, giving someone who walks up more time to attempt a password and leaving the login process tied up.
logintimeout is absent, zero, or above 30 seconds -- a CIS AIX 7 v1.2.0 section 4.7.4 finding.
# lssec -f /etc/security/login.cfg -s usw -a logintimeout logintimeout=60 seconds (above 30-second maximum)
This check reads the effective SSH cipher list and confirms the server offers only strong, modern ciphers. If the server still offers broken or deprecated ciphers such as CBC, arcfour, 3DES, or Blowfish, an attacker watching the connection may be able to downgrade the session to a weak cipher and decrypt traffic that looked secure.
sshd_config has no uncommented Ciphers directive, so the effective cipher list is a silent default that DISA STIG V-215402 does not accept.
# sshd -T no explicit Ciphers line in sshd_config
This check confirms that the syslog configuration has at least one active logging rule and that the log files it is expected to write to exist on disk. If it fails, the system may not be recording events at all. An attacker could then act without leaving a trace of failed logins or other suspicious activity, and operators would have no log trail to investigate a breach or diagnose an outage.
syslog.conf defines logging rules but at least one of the expected log outputs is missing, so some logged events are not being collected.
# egrep -v "(^$)|(^#)" /etc/syslog.conf 4 active syslog.conf rule line(s); fewer than three expected log destinations present
This check confirms that every local, non-system user account has a home directory that exists, is not writable by the group or by other users, and carries no extended access-control list. If a home directory fails this check, another account on the system can write into it and plant or modify files there, which can let an attacker take over the account or tamper with its data.
At least one in-scope non-system account home directory is missing, grants group or other users write access, or carries an extended ACL, so another identity can alter that account's files.
# lsuser -R files -a id home ALL at least one in-scope non-system account home is absent, grants group or world write, or carries an ACL
This control checks that the syslogd logging daemon is running with the -r option, which makes it accept incoming log messages sent from other systems. If it is running without that option, log messages from other computers are silently discarded, so break-in attempts or misuse on those systems never reach the central log.
The syslogd daemon is not running, or is running without -r, so inbound messages are not collected.
# ps -ef syslogd running without the -r flag
This check verifies that the AIX audit subsystem is running. The audit subsystem keeps a record of user and account activity. If auditing is off, an incident leaves no trail and you cannot reconstruct who did what afterward.
No audit trail -- you cannot answer 'who did what' after an incident.
# audit query auditing off
This check reads the default password rules that every new account on the system inherits: how long a password stays valid, its minimum length, how many failed logins are allowed, and how many old passwords are remembered. If those defaults are weak, each account created afterwards starts out weak too, which makes passwords easier to guess or reuse and the system easier to break into.
The default password rules are weaker than any standard requires -- every new account inherits them.
# lssec -f /etc/security/user -s default -a maxage -a minlen -a loginretries -a histsize weak: loginretries=0
This check scans the whole local filesystem tree from / for files named .netrc. A .netrc file stores a remote host, an account name and the password of that account in plain text so that ftp and rexec can log in without an interactive password exchange. Anyone who can read the file (its owner, root, a backup copy, or an attacker who gains any foothold on the host) obtains working credentials for the remote systems it names and can reuse them elsewhere. Any .netrc file anywhere on the system is a finding.
A system-wide scan found no .netrc file among the paths it could read. Some paths were unreadable, so a .netrc on an unreadable path would not have been listed; DISA STIG V-215403 requires none on the system.
# find / -prune -print no .netrc files found under / (some paths unreadable)
This check finds shared directories that every user can write to but that are missing the sticky bit, the setting that keeps users from deleting or renaming files they do not own. Without that protection, any local user can remove or replace files belonging to other users, which can disrupt running services and may be used to run a program as another account.
Readable public directories carry the sticky bit, but some paths were unreadable so a hidden violation cannot be ruled out.
# find / -type d -perm -002 ! -perm -1000 no world-writable directories missing the sticky bit (some paths unreadable)
The internet super-server (inetd) is a legacy daemon that listens on many network ports and starts older services such as telnet, FTP, and remote shell on demand. This check identifies systems where inetd is still started at boot from /etc/rc.tcpip or running as an active subsystem. Leaving it enabled when no inetd-managed service is actually required keeps unused ports listening and can let an attacker reach older, unencrypted services that bypass normal access controls.
The inetd super-daemon is in use. CIS requires it disabled only when no inetd-managed service is required, so this needs operator review; individual inetd services are assessed separately.
# cat /etc/rc.tcpip inetd starts at boot in /etc/rc.tcpip and is active in the SRC inventory - CIS permits inetd only while a required inetd service remains
This control checks whether the portmap service, the RPC port mapper, is running on the system. It flags portmap when it is set to start at boot in the file /etc/rc.tcpip or is already active as a running service. If portmap runs while nothing on the system genuinely needs RPC, it gives a remote attacker a live list of the services and port numbers to attack, plus a well-known network service with a long history of security flaws.
The portmap RPC mapper is in use. CIS permits it only where RPC is required (NFS server, NIS, CDE, or RPC-dependent software), so this needs operator review.
# cat /etc/rc.tcpip portmap starts at boot in /etc/rc.tcpip and is active in the SRC inventory - CIS permits portmap only where RPC is required
This control checks that the AIX tcp_tcpsecure network setting is fully turned on. When enabled, the setting blocks forged TCP packets from resetting or hijacking a connection that is already in progress. If it is off, an attacker could send a forged packet to knock a live session offline or inject data into it, causing outages and tampering with in-flight traffic.
tcp_tcpsecure=0 -- TCP connection attack protection is not fully configured (0 is the unhardened AIX default; this check accepts only 7 pending CIS text verification).
# no -o tcp_tcpsecure tcp_tcpsecure=0
This control checks that AIX is configured so NFS clients use privileged reserved ports when they connect to NFS servers. NFS servers treat the source port as a weak form of authentication, so a client connecting from an ordinary unprivileged port is easier to impersonate. If the setting is off, NFS clients may use unprivileged ports, letting an attacker spoof NFS traffic that a server may wrongly trust.
NFS reserved ports are NOT enabled (0) -- NFS clients may use unprivileged ports, weakening NFS client authentication.
# nfso -o nfs_use_reserved_ports nfs_use_reserved_ports=0
This control checks that AIX TCP path-MTU discovery is disabled, as required by the baseline. When the setting is left on, the system keeps per-connection packet-size state based on ICMP traffic, which an attacker on an untrusted network can abuse to stall or break connections and cause a denial of service. A failed check means the system remains open to that attack.
TCP path-MTU discovery is enabled (1) -- per-path ICMP-driven state that can be abused for DoS.
# no -o tcp_pmtu_discover tcp_pmtu_discover=1
This control checks that the udp_pmtu_discover network setting is turned off (value 0). That setting controls UDP path-MTU discovery, which keeps per-path state driven by ICMP messages. If it is left on, an attacker on an untrusted network can abuse that state to cause a denial of service.
UDP path-MTU discovery is enabled (1) -- per-path ICMP-driven state that can be abused for DoS.
# no -o udp_pmtu_discover udp_pmtu_discover=1
AIX limits how much of its network memory pool can be in use before it starts refusing new sockets, and sockthresh is the setting that holds that limit. This check reads the current value and expects a hardened one well below the level AIX ships with, rather than the stock setting. A limit left at or near the shipped level lets a runaway or hostile process consume the network memory pool and leave other services unable to open connections.
sockthresh=85 -- at or above the AIX shipped default, so the socket-creation memory cap is not configured for hardening.
# no -o sockthresh sockthresh=85
The /audit directory is where the AIX audit subsystem writes its trail and bin files, the raw record of security-relevant activity on the machine. This control verifies that the directory is assigned to the audit group. If it belongs to some other group, members of that group could alter or erase the audit trail and hide evidence of unauthorized activity.
# ls -ldn /audit /audit group_gid=10
This check confirms that the /audit directory, where AIX stores audit records, is readable only by its owner and the audit group, with no access for other users. If those permissions are loosened, other accounts on the system could read the audit trail to learn what is being monitored, or alter or delete audit records to hide their activity.
# ls -ldn /audit /audit mode=0750
This control checks that the /audit directory, where the system keeps its audit records, is owned by the root account. If any other account owns that directory, it could alter or erase the audit records, letting someone hide evidence of unauthorized activity.
# ls -ldn /audit /audit owner_uid=0
This check confirms that /etc/group, the file that records which users belong to which groups, is owned by the correct trusted system group. If a different group owns it, the members of that group could change group memberships and grant themselves access to protected systems and data.
# ls -ln /etc/group /etc/group group_gid=7
This check confirms the group database file, /etc/group, is writable only by its owner. That file lists which users belong to which groups, including groups that grant administrator-level access. If another account could write to it, a user could add themselves to a privileged group and take control of the system.
# ls -ln /etc/group /etc/group mode=0644
This check confirms that the group database file /etc/group is owned by the root account. If any other account owns this file, that account can rewrite group memberships and add itself to privileged groups, gaining access that is normally restricted.
# ls -ln /etc/group /etc/group owner_uid=0
This control verifies that /etc/hosts, the file that maps host names to network addresses, is owned by group 0 - the AIX system group. If the file belongs to another group, members of that group could rewrite host name entries and redirect traffic to systems they control, allowing impersonation of trusted servers and interception of connections.
# ls -ln /etc/hosts /etc/hosts group_gid=0
This control checks that the inetd configuration file is owned by group 0, the AIX system group. inetd is the service that listens on network ports and starts the right program when a connection arrives. If another group owns this file, any user in that group could alter which programs the network launches, opening the system to unauthorized access.
# ls -ln /etc/inetd.conf /etc/inetd.conf group_gid=0
This control checks that /etc/inetd.conf, the configuration file for the inetd network services daemon, is owned by the root account. If any other user owns this file, that user could edit it to run attacker-chosen programs or start unwanted network services, opening a backdoor or persistent foothold on the system.
# ls -ln /etc/inetd.conf /etc/inetd.conf owner_uid=0
This control checks that the login message file /etc/motd is assigned to the bin group (group ID 2). If that file is assigned to any other group, the accounts in that group could rewrite the message every user sees at sign-in, planting a false or misleading notice that appears to come from the system.
# ls -ln /etc/motd /etc/motd group_gid=2
This control checks the permissions on /etc/motd, the message every user sees at login, and verifies that no one except the file owner can change it. If those permissions are too loose, another user could rewrite that message to show false or misleading instructions to everyone signing in, as if the system itself had issued them.
# ls -ln /etc/motd /etc/motd mode=0444
This control checks that /etc/motd, the login message shown to every user, is owned by the trusted system account named bin. Because everyone who signs in treats that message as coming from the system, only a trusted owner should be able to change it. If any other account owns the file, that account could rewrite the banner and present false or misleading text to everyone who logs in.
# ls -ln /etc/motd /etc/motd owner_uid=2
This control checks the permissions on the /etc/motd file, the message shown to users when they log in. If anyone other than the file owner can write to this file, they could replace that message with a fake or misleading notice that every user sees at login.
# ls -ld /etc/motd /etc/motd mode=-r--r--r-- group-write=- other-write=-
This control verifies that the file /etc/passwd, which defines the accounts on the system, belongs to group 7, the security administration group. If a different group owns it, members of that group could edit the file to add or change accounts and gain unauthorized access to the system.
# ls -ln /etc/passwd /etc/passwd group_gid=7
This control verifies that the system account file /etc/passwd allows write access only to the root owner, with all other users limited to read-only. That file maps account names to user IDs, and it must stay protected so ordinary users cannot change it. If it is writable by anyone else, an attacker could add or alter an account to gain administrator-level access to the system.
# ls -ln /etc/passwd /etc/passwd mode=0644
This control verifies that the system account file /etc/passwd is owned by root (user ID 0). If any other account owns it, that account could add users, change user IDs, or modify the root entry to gain access or full control of the system.
# ls -ln /etc/passwd /etc/passwd owner_uid=0
This check confirms which group owns the /etc/security directory, the folder where AIX keeps its account, password, and login settings. If a group other than the dedicated security group owns it, members of that group could alter those settings to add privileged users, weaken password rules, or lock administrators out of the system.
# ls -ldn /etc/security /etc/security group_gid=7
This check verifies that the /etc/security directory is owned by the root account. That directory holds the trusted security settings for the system, including password rules and login restrictions. If any other account owns it, that account could change those settings and weaken or bypass the protections they are meant to enforce.
# ls -ldn /etc/security /etc/security owner_uid=0
This control checks that the /etc/security/audit directory is owned by the audit group. That directory holds the configuration that decides what the AIX security audit records. If a different group owns it, members of that group could change the audit settings, leaving the record of activity on the system able to be altered or erased.
# ls -ldn /etc/security/audit /etc/security/audit group_gid=10
This check confirms that the /etc/security/audit directory, which holds the system audit configuration, is locked down so only the root account and its group can read or change it. If the directory is opened up too far, someone who should have no access could read the audit settings or alter them to weaken or disable auditing. That would leave an activity record that cannot be trusted to catch misuse.
# ls -ldn /etc/security/audit /etc/security/audit mode=0750
This control verifies that the AIX audit configuration directory, /etc/security/audit, is owned by the root account. If a non-root user owns this directory, that user could change or remove the settings that record security events, so tampering with the system could go unlogged and unnoticed.
# ls -ldn /etc/security/audit /etc/security/audit owner_uid=0
This control checks that the AIX system logging configuration file /etc/syslog.conf is owned by the system group (group 0). If a different group owns the file, members of that group could rewrite or disable system logging, redirecting or hiding the log records that show what happened on the system.
# ls -ln /etc/syslog.conf /etc/syslog.conf group_gid=0
This control checks the permissions on /etc/syslog.conf, the file that controls how and where the system records its logs. It must allow writing only by the owner and reading only by the owner and group, with no access for everyone else. If other users could write to this file, an attacker could redirect or disable logging to hide an intrusion, and over-broad read access could expose sensitive log configuration details.
# ls -ln /etc/syslog.conf /etc/syslog.conf mode=0600
This control checks that the file /var/adm/cron/log belongs to the cron group, numeric group ID 8. That file holds the record of jobs the system runs automatically on a schedule. If a different group owns it, an unintended identity could read or alter that log, hiding or tampering with the record of scheduled activity.
# ls -ln /var/adm/cron/log /var/adm/cron/log group_gid=8
This check confirms that the cron log file (/var/adm/cron/log) is not readable or writable by ordinary users, so only the file owner and its group can access it. If the permissions are too open, an unprivileged account could read scheduled job details or alter the log to hide or fake cron activity, destroying the record of what jobs ran and when.
# ls -ln /var/adm/cron/log /var/adm/cron/log mode=0660
This check confirms the AIX cron log file (/var/adm/cron/log) is owned by the system bin account (UID 2). If another account owns the log, it can rewrite or erase the record of scheduled jobs, so evidence of unauthorized cron activity could be hidden or falsified.
# ls -ln /var/adm/cron/log /var/adm/cron/log owner_uid=2
This check confirms that /var/adm/sa, the directory holding the systems daily performance and activity records, is owned by the system administration group (adm, group ID 4). If a different group owns that directory, members of that group could read or alter those activity records, which could hide problems or throw off investigations that depend on that data.
# ls -ldn /var/adm/sa /var/adm/sa group_gid=4
This check confirms that the directory /var/adm/sa is owned by the adm account. That directory stores the activity data used to review what the machine has been doing. If another account owns it, that account could alter or erase those records and hide evidence of activity on the system.
# ls -ldn /var/adm/sa /var/adm/sa owner_uid=4
This control checks that the AIX resource-manager startup log /var/ct/RMstart.log is assigned to the system group, the only group allowed to manage it. That keeps the log a trustworthy record of how the system started. If the file belongs to a different group, members of that group could alter or erase it and hide evidence of tampering.
# ls -ln /var/ct/RMstart.log /var/ct/RMstart.log group_gid=0
This control checks the permissions on /var/ct/RMstart.log, the startup log for AIX resource monitoring, and requires that only its owning account can write to it, with read access limited to the owner and the owner group. If the permissions are looser, an unauthorized local user could alter or erase the log to hide or falsify monitoring records, or read information they should not see.
# ls -ln /var/ct/RMstart.log /var/ct/RMstart.log mode=0640
This control verifies that the log file /var/ct/RMstart.log is owned by the root account. If another user owns it, that user can modify or replace the file, so the record of system startup it contains can no longer be trusted.
# ls -ln /var/ct/RMstart.log /var/ct/RMstart.log owner_uid=0
This control checks the permissions and ownership of /var/spool/clientmqueue, the directory where locally submitted outbound mail waits to be sent. Only the mail service is supposed to access the directory. If it is left open to other accounts, a local user could read messages waiting in the outbound queue or tamper with them before delivery.
# ls -ld /var/spool/clientmqueue mode=drwxrwx--- owner=smmsp group=smmsp
This check verifies that the directory where the at scheduler queues one-time jobs, /var/spool/cron/atjobs, belongs to the cron group. The at service stores pending jobs there and runs them later under the account of the user who submitted them. If a different group owns that directory, members of that group could read or alter the queued jobs and change what commands run automatically on the system.
# ls -ldn /var/spool/cron/atjobs /var/spool/cron/atjobs group_gid=8
This check confirms that the directory holding scheduled at jobs is locked down so ordinary users cannot read, change, or add to it. That directory can contain commands that will run later under another account. If the permissions are too open, another user could read the contents of pending jobs or place their own job to run with privileges they do not have.
# ls -ldn /var/spool/cron/atjobs /var/spool/cron/atjobs mode=0770
This check confirms that the /var/spool/cron/atjobs directory, which holds queued one-time scheduled jobs, is owned by the bin system account. If any other account owns this directory, that account could add, alter, or delete scheduled jobs and run commands under root or another user when those jobs execute.
# ls -ldn /var/spool/cron/atjobs /var/spool/cron/atjobs owner_uid=2
This check confirms that the directory holding scheduled jobs (/var/spool/cron/crontabs) belongs to the cron group. If a different group owns that directory, people in that group could change or add scheduled jobs, running commands under other accounts or silently tampering with scheduled work.
# ls -ldn /var/spool/cron/crontabs /var/spool/cron/crontabs group_gid=8
This control checks the permissions on /var/spool/cron/crontabs, the directory that holds scheduled jobs for the system. The directory must grant access only to its owner and the cron group, with nothing for any other user. If others could reach it, they could read, change, or plant scheduled jobs, and those jobs run under the accounts that own them, potentially giving an attacker elevated control or disrupting important work.
# ls -ldn /var/spool/cron/crontabs /var/spool/cron/crontabs mode=0770
This control checks that /var/spool/cron/crontabs, the directory that holds scheduled-job definitions, is owned by its intended trusted system account. Cron runs those jobs automatically, often with high privileges. If a different account owns the directory, it can rewrite those jobs to run its own commands on schedule, giving an attacker persistent privileged access or a way to disrupt critical scheduled work.
# ls -ld /var/spool/cron/crontabs /var/spool/cron/crontabs owner=bin
This control checks that /var/tmp/hostmibd.log, the log written by the daemon that reports the hardware and software inventory of the system, belongs to the system group (group ID 0). If a different group owns the log, members of that group could read the host details recorded in it or change the log to hide or falsify activity.
# ls -ln /var/tmp/hostmibd.log /var/tmp/hostmibd.log group_gid=0
This check verifies that the log file /var/tmp/hostmibd.log is owned by root, the privileged account on the system. The file is written by hostmibd, the AIX system monitoring daemon, so if any other account owns it, that account can alter or replace the log to hide activity or insert false entries and the file can no longer be trusted as a record of system events.
# ls -ln /var/tmp/hostmibd.log /var/tmp/hostmibd.log owner_uid=0
This control checks that the SNMP monitoring log file /var/tmp/snmpdv3.log is owned by the system group rather than an ordinary user group. SNMPv3 logs can contain usernames, management settings, and evidence of monitoring activity. If the file belongs to a different group, users in that group could read or tamper with the log, exposing sensitive management details or hiding signs of unauthorized access.
# ls -ln /var/tmp/snmpdv3.log /var/tmp/snmpdv3.log group_gid=0
This check confirms the SNMPv3 agent log file /var/tmp/snmpdv3.log is readable only by its owner and group and writable only by its owner. If other users could read or change this file, an attacker could read the SNMP activity it records or alter the log to hide unauthorized changes.
# ls -ln /var/tmp/snmpdv3.log /var/tmp/snmpdv3.log mode=0640
This control checks that the SNMP version 3 log file /var/tmp/snmpdv3.log is owned by the root account on AIX. SNMP is the service used to monitor and manage the system over the network, and this log records its activity. If another account owns the log, that account can rewrite or delete it, hiding signs of tampering and destroying the record of SNMP management activity.
# ls -ln /var/tmp/snmpdv3.log /var/tmp/snmpdv3.log owner_uid=0
This control reads the AIX directed_broadcast network setting to confirm the server drops directed broadcast packets. If directed broadcasts are accepted, an attacker can send them with a forged source address and have the server bounce them in bulk to the spoofed target, using this machine to amplify a flood aimed at someone else.
# no -o directed_broadcast directed_broadcast = 0 (dropped)
This check scans the /etc/passwd account file for entries that share the same user ID number or the same login name. When two logins share a user ID, the system treats them as the same account, so one can access the files and privileges of the other and no one can tell which login took an action. A duplicate login name can also let the wrong account be authorized or audited.
# cat /etc/passwd no duplicate UIDs or usernames in /etc/passwd
This control checks the command search path assigned to the root account at login for entries that point to the current directory. When the current directory is in that path, a command run as root can silently execute a file planted there by another user instead of the real system command. That lets an attacker run anything they choose with full administrator privileges.
# ls -l /etc/environment /etc/profile /.profile declared root login PATH has no '.', empty, or relative component; /.profile does not exist on this host and declares no PATH
This control walks the crontab of the account running the scan and checks every command listed by full path, plus each directory above it, for write access beyond root and the bin account. If a cron command or one of its parent directories can be written by other users, someone could swap in their own program that the system then runs automatically on schedule, often with root privileges.
# crontab -l all inspected cron command path components are clean
This check confirms that every local, non-system user account has a home directory that exists, is not writable by the group or by other users, and carries no extended access-control list. If a home directory fails this check, another account on the system can write into it and plant or modify files there, which can let an attacker take over the account or tamper with its data.
# lsuser -R files -a id home ALL no in-scope non-system account home is absent
This control checks whether any account is exempt from password strength and history rules because of the NOCHECK flag in the AIX password database. An account with this flag can be given a weak or previously used password, which gives an attacker a much easier way to break in through a normal login.
# awk '/^[^ \\t:][^:]*:[ \\t]*$/ { u=$1; sub(/:[ \\t]*$/,"",u); n++ } $1=="flags" && $2=="=" && $0 ~ /NOCHECK/ && u!="" { k++; if (k<=6) users=(users=="")?u:users","u } END { printf "scanned=%d nocheck=%d users=%s\\n", n, k, users }' /etc/security/passwd
9 stanza(s) scanned; no NOCHECK flagChecks whether any non-system account has password aging turned off, which lets its password last forever. A password that never expires stays usable long after the person who set it has left, and it gives attackers a standing way into the system that nobody is watching.
# lsuser -a account_locked maxage ALL no non-system account with maxage=0 (1 locked)
Every normal user account on the system has a home directory that should be owned by the account itself or by the root administrator. This control confirms that each active non-system account has a home directory that exists and is owned by the right account. If a home directory is missing or owned by someone else, that other user could plant or alter the login files and keys inside it and take over the account.
# lsuser -R files -a id home account_locked ALL n=7 accounts compliant
This check finds privileged accounts, meaning root and any account marked as an administrator, that have not been used in more than 90 days or have never logged in while their password never expires. A dormant account that still holds high privilege is an ideal target for an attacker, because no one notices when a forgotten account gets used, and a password that never expires outlives the person who set it.
# lsuser -a admin maxage account_locked time_last_login ALL 1 privileged account(s), none stale
This check confirms that every active local user account has a home directory that actually exists on disk. If an account is missing its home directory, the person may be unable to log in, or programs running under that account may write files into an unexpected location such as a shared or system-owned directory. That can break services and expose or corrupt data.
# lsuser -R files -a id home account_locked ALL accounts_checked=7 accounts=nobody slotd ragent snapp ipsec smmsp pj
This control checks whether any regular file on a local JFS or JFS2 filesystem is world-writable, meaning any user on the system can change it. If such files exist, anyone with an account could modify or replace programs, scripts, and configuration files, which can lead to tampering with system behavior or unauthorized access.
# find / \\( -fstype jfs -o -fstype jfs2 \\) -type f -perm -o+w -ls no world-writable regular file on any local JFS or JFS2 filesystem
This control checks the permissions on personal configuration files (dotfiles such as .profile and .kshrc) kept in home directories. It fails if any of these files can be written by other users or by the group. When that happens, another account can rewrite a startup or login file and use it to take over a session or capture stored credentials.
# lsuser -a home ALL 2 user configuration files, none writable by group or other
This control checks whether the server answers ICMP address mask requests, which reveal the subnet mask of its local network to anyone who asks. A server that sends these replies makes it easier for an attacker to map the network and plan further attacks. Leaving this enabled exposes network structure that should stay private.
# no -o icmpaddressmask icmpaddressmask = 0
This control checks whether the host ignores ICMP redirect messages rather than using them to update its routing table. If the host accepts these messages, an attacker who can send one can silently rewrite the routing table and steer traffic to a machine they control, enabling interception or denial of service.
# no -o ipignoreredirects ipignoreredirects = 1
This check verifies that the AIX network option ipsendredirects is turned off so the system does not send ICMP redirect messages that tell other hosts to change their route. Redirect messages should come only from routers; a regular host that emits them leaks its view of the network and can be used to steer traffic toward a machine an attacker controls, allowing traffic to be redirected or intercepted.
# no -o ipsendredirects ipsendredirects = 0
This check confirms the system does not answer ICMP timestamp requests, which would reveal its exact current time to anyone who asks. If the system does answer them, an attacker can learn the clock time and use it to defeat time-based protections such as login codes and replay windows, or to time attacks across systems. The check passes when the icmptimestamp network setting is 0, meaning timestamp replies are turned off.
# no -o icmptimestamp icmptimestamp=0
Source-routed IP packets carry instructions telling the network which path they must take. This check verifies the system is set to reject such packets rather than accept them. If it accepts them, an attacker can force traffic along a route they control, bypassing firewall rules and routing policy.
# no -o ipsrcrouterecv ipsrcrouterecv = 0
This control checks the password and group files (/etc/passwd and /etc/group) for any line that begins with a plus sign. A leading plus turns on a legacy network directory feature called NIS, so this machine will accept users and groups served from the network instead of only the ones defined locally. If that entry is present, anyone who can control or impersonate that network directory could add accounts, including privileged ones, and use them to log in to this system.
# grep "^+" /etc/passwd /etc/group no + entries in /etc/passwd or /etc/group
This control reviews the NFS export rules in the /etc/exports file and the list of filesystems currently being exported, looking for exports that give root authority to anonymous or broadly defined clients, or that allow write access without limiting which clients may connect. A failing export lets any client that can reach the NFS service read and change the exported files as root, so an attacker could view or alter data without needing a valid account.
# test -e /etc/exports this host exports no filesystems
This control checks the NFS export configuration file /etc/exports to confirm that no export grants access to a client named localhost, 127.0.0.1, or ::1. Because a remote host can claim these loopback names for itself, an export that trusts them can be mounted over the network by a machine the administrator never authorized, exposing the shared directory and the data in it.
# test -e /etc/exports this host has no /etc/exports definition file
This control checks four CDE desktop programs under /usr/dt/bin (dtaction, dtappgather, dtprintinfo, and dtsession) to confirm none is marked setuid or setgid, a setting that makes a program run with the file owner or group privileges instead of the user who launched it. CDE programs carrying this setting have a history of defects that let an ordinary local user escalate to root. A program left set could therefore hand an attacker with any account on the system full administrative control.
# ls -ld /usr/dt/bin/dtaction /usr/dt/bin/dtappgather /usr/dt/bin/dtprintinfo /usr/dt/bin/dtsession no CDE dt binaries present under /usr/dt/bin (probe rc=2, empty); nothing carries setuid/setgid
This check inspects the inetd configuration for remote-access services that transmit passwords and session data as readable plain text, such as telnet, ftp, and the r-commands like rlogin and rsh. When one of these services is enabled, credentials and everything typed in a session travel across the network in a form anyone watching the wire can read. If they stay on, an attacker who can see that traffic can capture the credentials and use them to take over accounts.
# grep -E '^[[:space:]]*(telnet|telnetd|ftp|ftpd|shell|login|exec|rsh|rlogin)[[:space:]]' /etc/inetd.conf none enabled
This control verifies that every NFS share this system mounts from a remote server has the nosuid and nodev options set. If nosuid is missing, a program planted on the remote share can run with elevated privileges on this system; if nodev is missing, device files on the share are treated as local devices. Either condition lets a compromised or hostile file server gain more access than a shared directory should allow.
# ls -ld /etc/filesystems no NFS client mounts configured in /etc/filesystems
This control checks that the FTP service, when enabled, is configured in /etc/inetd.conf to create files with a umask of 027, which keeps the files it creates from being world-readable or world-writable. If that setting is missing or weaker, files the FTP daemon creates can be read or changed by accounts that should not have access, exposing uploaded data or allowing it to be altered.
# grep '^ftp[[:blank:]]' /etc/inetd.conf ftp service not defined in /etc/inetd.conf
Not applicable to this system's role.
This check confirms the system has no host-based trust database, meaning neither /etc/rhosts.equiv nor /etc/shosts.equiv exists. When one of these files is present, a remote host named in it is trusted to access accounts on this system without a password. An attacker who controls that trusted host could then log in here without any credential, bypassing normal authentication.
# ls -l /etc/[rs]hosts.equiv neither /etc/rhosts.equiv nor /etc/shosts.equiv exists
This check confirms that every local, non-system user account has a home directory that exists, is not writable by the group or by other users, and carries no extended access-control list. If a home directory fails this check, another account on the system can write into it and plant or modify files there, which can let an attacker take over the account or tamper with its data.
# lsuser -R files -a id home ALL no in-scope non-system account home carries an access control list
This control verifies that the legacy r-command filesets bos.net.tcp.rcmd and bos.net.tcp.rcmd_server are either not installed or have every owned file stripped of all read, write, and execute permissions. These r-command tools let one host run commands and copy files on another using host-based trust instead of a user password, and they send all traffic in clear text. If the filesets remain installed and usable, anyone who can reach the network could run commands or copy files on remote systems without credentials, and passwords or data in transit could be captured.
# lslpp -L bos.net.tcp.rcmd_server neither bos.net.tcp.rcmd nor bos.net.tcp.rcmd_server is installed (lslpp -L rc=1 for both)
This control checks /etc/security/passwd for user accounts whose stored password is still protected by the old crypt method, a weak 56-bit algorithm that is easy to crack. If any non-system account still uses it, an attacker who obtains the stored hashes can quickly recover the real passwords and log in as those users. The check reports the affected account names.
# awk '/^[^ \\t:][^:]*:[ \\t]*$/ { u=$1; sub(/:[ \\t]*$/,"",u); n++ } $1=="password" && $2=="=" && NF==3 && length($3)==13 && u!="" && u !~ /^(adm|bin|daemon|invscout|ipsec|lp|lpd|nobody|nuucp|sshd|sys|uucp|esa|srvproxy|imnadm|anonymou|ftp)$/ { k++; if (k<=6) users=(users=="")?u:users","u } END { printf "scanned=%d crypt=%d users=%s\\n", n, k, users }' /etc/security/passwd
9 stanza(s) scanned; no legacy crypt hashThis control checks that every group on the system has a unique numeric ID (GID) and a unique name, as recorded in the /etc/group file. If two groups share a GID or a name, the system cannot tell them apart, so a user in one group can silently gain the file and directory access granted to another, and access controls stop working as designed.
# cat /etc/group all /etc/group GIDs and group names are unique
This check looks in /etc and /usr/local/bin for files that any user can write to. A file that anyone can modify is a risk because an ordinary user could change system settings or replace a program with a hostile copy. Finding such a file means the system is open to that kind of tampering.
# sh -c 'test -d /etc && echo yes || echo no' no world-writable files in /etc (/usr/local/bin not present, skipped)
This check confirms the AIX setting that controls whether the system accepts source-routed packets sent to other machines is turned off. Source routing lets whoever sends a packet choose the path it takes across the network. If the setting is left on, an attacker can steer traffic around firewalls and other network controls so it reaches systems that should be unreachable.
# no -o nonlocsrcroute nonlocsrcroute = 0
The dt Xconfig file controls how the CDE graphical login screen behaves, including the programs it runs at login. This control checks that the file is owned by root and cannot be written by ordinary users. If a regular user could edit it, they could make the login program run commands with root privileges and take control of the system.
# lslpp -qcL 'X11.Dt*' CDE not installed (fileset query empty); no dt Xconfig file exists or is consumed
This control checks that the Xresources configuration files for the CDE desktop, located under /etc/dt/config and /usr/dt/config, are owned by root and cannot be written by other users. These files supply settings that are applied to every CDE login session, including the login screen. If a non-root user can edit them, that user could inject changes into the login sessions of other users or tamper with the login screen itself.
# lslpp -qcL 'X11.Dt*' CDE not installed (fileset query empty); no dt Xresources file exists or is consumed
This control checks the CDE Xservers configuration file, which the login manager uses to start the local X display server, to confirm it is owned by root and cannot be changed by other users. If a non-root user can modify this file, they could alter how the X server launches, possibly running their own commands with the server privileges or tampering with the login screen. This check applies only when the CDE desktop environment is installed.
# lslpp -qcL 'X11.Dt*' CDE not installed (fileset query empty); no dt Xservers file exists or is consumed
This control checks how many weeks must pass before a previously used password can be used again, a reuse window stored in the histexpire attribute of the /etc/security/user file. It expects that window to be at least fifty-two weeks. If the window is missing or too short, someone who already knows an older password can reuse it almost as soon as the account changes to a new one, defeating the benefit of password rotation.
# lssec -f /etc/security/user -s default -a histexpire histexpire=52 weeks
This control verifies that remote graphical login to the system through XDMCP is turned off. XDMCP is the service that lets other machines open the CDE login screen over the network, and the connection is not encrypted. If it is left enabled, anyone who can reach the system over the network can pull up the login screen and attempt to log in, and usernames and passwords typed there can be captured in transit.
# lslpp -qcL 'X11.Dt*' CDE not installed (fileset query empty); no dtlogin exists to accept XDMCP connections
This control checks that the server is configured not to send source-routed packets, where the sender writes the route a packet takes into the packet itself. If sending source-routed packets is enabled, an attacker can dictate the return path of traffic, steering it around firewalls and routing controls.
# no -o ipsrcroutesend ipsrcroutesend = 0
This control checks that the AIX network setting ipsrcrouteforward is off, so the host will not forward IP packets that carry a source-route header. Source-routed packets let the sender choose the path traffic takes, so if forwarding is on an attacker can steer traffic around firewalls and reach parts of the network that should be off-limits.
# no -o ipsrcrouteforward ipsrcrouteforward=0
The AIX host has a network setting, ip6srcrouteforward, that controls whether it forwards source-routed IPv6 packets. If the setting is not zero, an attacker can write a route into a packet and steer that traffic around firewalls and routing rules to reach systems that should be unreachable from the outside.
# no -o ip6srcrouteforward ip6srcrouteforward=0
This control checks the boot file /etc/rc.tcpip to confirm the IPv6 router service (ndpd-router) is disabled, so the machine will not start acting as an IPv6 router when it boots. If this fails, the machine could come up advertising itself as a router and forwarding IPv6 traffic, which lets an attacker redirect or intercept that traffic or knock IPv6 connectivity offline on the network.
# grep '^#start[[:blank:]]/usr/sbin/ndpd-router' /etc/rc.tcpip ndpd-router start directive present in /etc/rc.tcpip
This control checks whether the CDE calendar service (cmsd) is enabled in /etc/inetd.conf. When it is enabled, the server exposes a remote procedure call service with a history of remotely exploitable flaws, which an attacker can use to gain root-level control of the system.
# grep -E '^[ ]*cmsd[ ]' /etc/inetd.conf cmsd not active in /etc/inetd.conf
This check verifies that the CDE graphical login screen does not reveal the host name before a user signs in. When CDE is in use, its default greeting shows the host name unless a site-defined label replaces it. If the check fails, anyone who can reach the login prompt sees the host name without authenticating, which gives an attacker useful reconnaissance about the system.
# lslpp -qcL 'X11.Dt*' CDE not installed (fileset query empty); no CDE login screen exists to reveal the host name
This control checks whether the CDE subprocess control service (dtspcd) has an active entry in the /etc/inetd.conf network configuration file. That service listens on the network and has a history of buffer overflow vulnerabilities that let a remote attacker gain root access to the system. If the check fails, an unnecessary and dangerous network service is left running and reachable.
# grep -E '^[ ]*dtspc[ ]' /etc/inetd.conf dtspc not active in /etc/inetd.conf
This check confirms that the IPv6 Neighbor Discovery daemon, ndpd-host, is set to start at boot by looking for its start entry in the /etc/rc.tcpip startup file. ndpd-host plays the role for IPv6 that ARP plays for IPv4: it finds neighboring devices, keeps the neighbor cache current, and learns about local routers. If the start entry is missing, the daemon does not run after a reboot, and IPv6 traffic can fail because the host cannot reach neighbors or find a route off its own network.
# grep '^#start[[:blank:]]/usr/sbin/ndpd-host' /etc/rc.tcpip the '#start /usr/sbin/ndpd-host' directive is present in /etc/rc.tcpip
This control verifies that the IPv6 autoconfiguration service is set to start automatically from the TCP/IP startup file /etc/rc.tcpip at every boot. If that startup entry is missing, the server will not configure its IPv6 addresses on its own, so IPv6 network services can fail after a reboot or when the network changes.
# grep "^#start[[:blank:]]/usr/sbin/autoconf6" /etc/rc.tcpip /etc/rc.tcpip starts autoconf6 at boot (uncommented '#start' entry for /usr/sbin/autoconf6)
This control checks whether the Network Installation Management (NIM) master software package is installed on the system. A NIM master is a privileged server that can push operating system installs and run commands on the other AIX systems it manages. If one is present where it is not intended, taking over that system gives an attacker a ready-made way to control every machine it manages.
# lslpp -qcL bos.sysmgt.nim.master not installed
This control checks whether the NIS server software package bos.net.nis.server is installed on the system. NIS is a legacy network authentication service that stores account names and password hashes and answers queries from other machines, and a modern system rarely needs one. If the package is present, a NIS server could be answering those queries over the network, letting an attacker harvest usernames and password hashes or feed false data to systems that trust the server.
# lslpp -L bos.net.nis.server bos.net.nis.server not installed
This control verifies that the OpenSSH client and server software packages are both installed and healthy. OpenSSH is what provides encrypted remote logins and file transfers to and from the system. If either package is missing or damaged, administrators may lose secure remote access, and connections could fall back to unencrypted protocols that expose passwords and data to anyone watching the network.
# lslpp -L openssh.base.client openssh.base.client and openssh.base.server are both installed and healthy (client state COMMITTED, server state COMMITTED)
This control checks that the SSH client configuration file (/etc/ssh/ssh_config) belongs to the system group. If a different group owns it, members of that group could edit the file to change how SSH connections from the system behave, weakening security or redirecting traffic without needing system-level access.
# ls -ln /etc/ssh/ssh_config OpenSSH client configuration file group_gid=0
This control checks the permissions on /etc/ssh/ssh_config, the OpenSSH client configuration file that all SSH connections on the host read by default. If the file is writable by anyone other than root, that account could silently change how SSH clients connect, for example redirecting them to an untrusted host or disabling the checks that detect an imposter. That would let a non-root user undermine the security of every outgoing SSH connection.
# ls -ln /etc/ssh/ssh_config OpenSSH client configuration file mode=0644
This control verifies that the OpenSSH client configuration file /etc/ssh/ssh_config is owned by root. If another user owns the file, that user can rewrite it to change how SSH behaves for everyone on the system, including weakening host key checking or redirecting outbound connections.
# ls -ln /etc/ssh/ssh_config OpenSSH client configuration file owner_uid=0
This control checks that the SSH server configuration file /etc/ssh/sshd_config belongs to the system group, the group with ID 0 on AIX. That file controls how users connect to the system remotely and how they prove their identity. If any other group owns it, members of that group could rewrite the file to weaken login checks or grant themselves access.
# ls -ln /etc/ssh/sshd_config OpenSSH daemon configuration file group_gid=0
This check verifies that the SSH server configuration file, /etc/ssh/sshd_config, grants write access only to its owner. If any other user or group can write the file, a non-administrative account could edit the rules that control remote login and then cause the server to load the changed settings. That could let an attacker grant themselves access or weaken the authentication the server enforces.
# ls -ln /etc/ssh/sshd_config OpenSSH daemon configuration file mode=0600
This control checks that the SSH server configuration file /etc/ssh/sshd_config is owned by the root account. This file sets the rules for how the system accepts remote logins. If a non-root account owns the file, that account or anyone who takes it over could change those rules to open a way into the system.
# ls -ln /etc/ssh/sshd_config OpenSSH daemon configuration file owner_uid=0
This check inspects the PATH line in the file /etc/environment and flags any entry that is a bare dot, an empty slot, or a single relative character. Such entries let an attacker place a look-alike program in a directory that is searched ahead of trusted system commands, so a routine command can silently run the planted program instead.
# ls -ld /etc/environment PATH assignment in /etc/environment is clean
This control verifies that the SMTP greeting offered by sendmail does not disclose the sendmail version. The SmtpGreetingMessage parameter in /etc/mail/sendmail.cf must not contain the $v or $Z macros; a greeting that expands those macros reveals the exact sendmail version to any connecting client, giving an attacker the information needed to target version-specific weaknesses.
# ls -ld /etc/mail/sendmail.cf the SmtpGreetingMessage value does not contain the $v or $Z macro
This control checks the version of the SSH server installed on the system and confirms it is OpenSSH major version 9 or newer. Older SSH releases no longer receive current security fixes. A system still running one can be reached by attackers who exploit known weaknesses in that old software to break in or take over the machine.
# sshd -V 9
This check verifies that direct root login over SSH is disabled on the system. If it is left enabled, the shared root password becomes the single secret an attacker needs for full control, and actions taken as root leave no record of who performed them.
# /usr/bin/lslpp -Lc openssh.server.rte SSH server fileset openssh.server.rte is not installed; root remote login is not possible
This control checks that the system is configured to hash passwords with a Loadable Password Algorithm, either ssha512 or ssha256, instead of the legacy DES crypt default. If it fails, stored passwords are protected only by the old DES method, which ignores everything past the eighth character. An attacker who obtains the password file can then crack even long passwords far more quickly.
# lssec -f /etc/security/login.cfg -s usw -a pwd_algorithm ssha256
This control checks the AIX password rule that sets the minimum number of digits every new password must contain. If the rule is unset or set to zero, users can choose passwords with no digits at all, making them easier to guess or crack and leaving accounts open to compromise.
# lssec -f /etc/security/user -s default -a mindigit mindigit=1
This check reads the minloweralpha password setting from the system default policy to confirm that every new password must include at least one lower-case letter. If the setting is missing or zero, accounts can be given passwords with no lower-case letters, which narrows the range of passwords an attacker has to try and makes them easier to guess.
# lssec -f /etc/security/user -s default -a minloweralpha minloweralpha=1
This control checks the AIX password policy setting that decides how many special characters, such as symbols or punctuation, every new password must contain. If the setting is not enforced, users can create passwords made only of letters and numbers, which are much easier for an attacker to guess or crack. That leaves accounts vulnerable to unauthorized access.
# lssec -f /etc/security/user -s default -a minspecialchar minspecialchar=1
This check confirms that the system password policy requires every new password to contain at least one upper-case letter, using the minupperalpha setting in the default user profile. If that requirement is absent or set to zero, new passwords may contain no upper-case letters at all, making them easier for an attacker to guess or crack.
# lssec -f /etc/security/user -s default -a minupperalpha minupperalpha=1
This control checks the default password maximum age setting in the /etc/security/user file and requires it to be between 1 and 52 weeks. A setting of zero disables password expiry, so a stolen or guessed password remains usable indefinitely. A value above 52 weeks keeps passwords valid for more than a year, giving an attacker that much longer to use a compromised account.
# lssec -f /etc/security/user -s default -a maxage maxage=13
This control checks whether the DHCP client service is running on the server or set to start at boot. Servers should hold a fixed address, but a running DHCP client accepts its IP address, gateway, and name servers from any DHCP server that responds on the network. If this fails, an attacker who places a rogue DHCP server on the network could point the system at hostile settings and redirect its traffic, or the address could change and break connectivity.
# cat /etc/rc.tcpip dhcp client (dhcpcd/dhcpcd6) not started in /etc/rc.tcpip and not active in the SRC inventory
This check confirms the DHCP relay service (dhcprd) is not running on the system. dhcprd forwards address requests between networks, so it should only be enabled on a server that is meant to act as a relay. If it runs where it is not needed, an attacker who can reach it could feed clients false network settings, such as a wrong gateway or name server, to redirect their traffic or intercept it.
# cat /etc/rc.tcpip dhcprd not started in /etc/rc.tcpip and not active in the SRC inventory
This check confirms the system is not running a DHCP server service (dhcpsd), either now or set to start at boot. A server that unexpectedly hands out IP addresses and network settings can let an attacker redirect traffic from other machines, or hand out conflicting addresses that break the network.
# cat /etc/rc.tcpip dhcpsd not started in /etc/rc.tcpip and not active in the SRC inventory
This control checks whether the dt subsystem, the CDE graphical desktop, is running on the server. A server has no business need for a graphical desktop. If dt is active, legacy desktop and session services stay exposed where an attacker can target them to break in or disrupt the system.
# lssrc -a dt not defined in the complete SRC inventory
This control checks that the FTP file transfer service, when enabled, shows a login banner telling anyone who connects that the system is for authorized use only and that activity may be monitored and reported. If the banner is missing or wrong, people who connect over FTP are never told the system is monitored, so unauthorized or improper use cannot be clearly tied to a user who was warned. That weakens the ability to enforce acceptable use and to hold users accountable for what they do on the system.
# grep '^ftp[[:blank:]]' /etc/inetd.conf ftpd not configured in /etc/inetd.conf; no ftpd login banner is presented
Not applicable to this system's role.
This control checks whether the gated routing service is set to start at boot in /etc/rc.tcpip or is currently running as a system service. The gated service provides legacy network routing protocols (RIP, OSPF, and BGP) and has no legitimate purpose on a server that is not a network router. If it is running where it should not be, it can advertise or redirect routes on the network, hijacking or disrupting traffic, and it exposes an unneeded legacy service to attack.
# cat /etc/rc.tcpip gated not started in /etc/rc.tcpip and not active in the SRC inventory
This check confirms the SSH server allows only approved message authentication (MAC) algorithms, which guard against tampering with data sent over an SSH connection. If an unapproved algorithm is enabled, an attacker able to intercept the connection could alter or forge transmitted data without being detected.
# sshd -T MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
This control checks which key-exchange algorithms the SSH server will accept, flagging the server if any of three deprecated SHA-1 based algorithms are still enabled. Key exchange is the handshake that sets up the encryption for every SSH session, and these older algorithms use cryptography that attackers can now break. If the check fails, an attacker who can observe or intercept a connection may be able to defeat that encryption and read the session, including logins and any data transferred.
# sshd -T kexalgorithms sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,mlkem768x25519-sha256,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
This control checks whether the legacy bootps (BOOTP) network service is still enabled in the file /etc/inetd.conf. BOOTP is an old, unauthenticated startup protocol that modern AIX servers do not need, so an enabled entry means the host runs an extra clear-text network service. If it fails, attackers can misuse that service to amplify denial-of-service floods against other systems or probe the server for a way in.
# grep -E '^[ ]*bootps[ ]' /etc/inetd.conf bootps not active in /etc/inetd.conf
This check confirms that the legacy comsat mail-notification service is disabled in /etc/inetd.conf. Comsat is an obsolete service that inetd starts to announce incoming mail to logged-in users, and it accepts unauthenticated, unencrypted messages from the network. A failing result means the host exposes an unnecessary, unmaintained remote service that an attacker can reach to spoof notifications on user terminals or probe for a way in.
# grep -E '^[ ]*comsat[ ]' /etc/inetd.conf comsat not active in /etc/inetd.conf
This control checks whether the legacy daytime network service is enabled in the /etc/inetd.conf file on the server. Daytime is an outdated clear-text service that sends the current date and time in response to any connection and has no legitimate purpose on a modern system. When it stays enabled, anyone on the network can query it, and attackers can use it to amplify denial-of-service traffic against other hosts or as a foothold for probing the server.
# grep -E '^[ ]*daytime[ ]' /etc/inetd.conf daytime not active in /etc/inetd.conf
This control checks whether the legacy echo service is active in the file /etc/inetd.conf. The echo service is an old clear-text utility that simply echoes back whatever data it receives and has no modern business purpose. If it is left enabled, an attacker can bounce and amplify traffic against other systems through it, and it gives outsiders one more unneeded way to reach the server.
# grep -E '^[ ]*echo[ ]' /etc/inetd.conf echo not active in /etc/inetd.conf
This control checks whether the legacy exec remote-execution service is enabled in the file /etc/inetd.conf. When enabled, that service accepts commands from remote users and sends login credentials in clear text, so anyone on the network can read them. If the check fails, an attacker can run commands on the server or capture the passwords used to connect.
# grep -E '^[ ]*exec[ ]' /etc/inetd.conf exec not active in /etc/inetd.conf
The finger service lets anyone on the network ask a server for details about its user accounts, such as login names, real names, and who is currently signed in. This check confirms the finger service is not enabled in /etc/inetd.conf. If it is running, an attacker can silently harvest account names to fuel password-guessing and social-engineering attacks against specific users.
# grep -E '^[ ]*finger[ ]' /etc/inetd.conf finger not active in /etc/inetd.conf
This check looks for the FTP file-transfer service running through inetd on the system. FTP sends login names, passwords, and files across the network in plain text, so a failed check means FTP is active and anyone able to watch that traffic can steal credentials or read the data being transferred.
# grep -E '^[[:space:]]*(telnet|telnetd|ftp|ftpd|shell|login|exec|rsh|rlogin)[[:space:]]' /etc/inetd.conf ftpd not active in /etc/inetd.conf
This control checks the internet services configuration file /etc/inetd.conf to confirm the legacy imap2 email service is not enabled. imap2 is an obsolete mail service that transmits messages and login credentials in clear text, so an active entry exposes an unencrypted mail channel that an attacker on the network could read or use as an entry point into the system.
# grep -E '^[ ]*imap2[ ]' /etc/inetd.conf imap2 not active in /etc/inetd.conf
This check verifies that the legacy instsrv network-install service is not enabled in the inetd configuration file. If instsrv is enabled, the host answers unauthenticated, unencrypted install requests from anywhere on the network, giving attackers an extra remote entry point to probe and abuse.
# grep -E '^[ ]*instsrv[ ]' /etc/inetd.conf instsrv not active in /etc/inetd.conf
This control checks whether the legacy klogin remote-login service is enabled in the system inetd configuration file (/etc/inetd.conf). klogin is an old network login service that predates SSH and is not needed on a modern server. If it is left enabled, attackers gain another way to attempt remote logins, which can become an entry point into the system.
# grep -E '^[ ]*klogin[ ]' /etc/inetd.conf klogin not active in /etc/inetd.conf
This check verifies that the legacy kshell remote-shell service is not enabled in the inetd configuration file /etc/inetd.conf. kshell lets a remote client run commands on the system over an unencrypted, weakly authenticated connection that predates modern security controls. If it is enabled, an attacker who can reach the host can try to execute commands remotely, and everything sent over the connection travels in clear text where it can be intercepted.
# grep -E '^[ ]*kshell[ ]' /etc/inetd.conf kshell not active in /etc/inetd.conf
This control checks whether the legacy netstat network service is enabled in the inetd configuration file /etc/inetd.conf. If it is running, the system answers unauthenticated requests from the network with clear-text status information, revealing active connections and adding a remote service an attacker can probe or use as a foothold.
# grep -E '^[ ]*netstat[ ]' /etc/inetd.conf netstat not active in /etc/inetd.conf
This check examines the file /etc/inetd.conf to confirm that the obsolete ntalk service, which lets users exchange real-time talk messages over the network, is not enabled. If ntalk is left active, the system answers network talk requests, exposing an old clear-text service that an attacker can reach and misuse. A failure here means the machine is running unnecessary remote attack surface.
# grep -E '^[ ]*ntalk[ ]' /etc/inetd.conf ntalk not active in /etc/inetd.conf
This control checks whether the legacy pcnfsd service is enabled in the file /etc/inetd.conf. pcnfsd is an old network service that exchanges data in the clear and was built for trusted networks, so keeping it running leaves an unencrypted, unauthenticated entry point that remote attackers can use to gain a foothold on the system or to reflect and amplify traffic against other targets. If the check fails, that service is active and reachable.
# grep -E '^[ ]*pcnfsd[ ]' /etc/inetd.conf pcnfsd not active in /etc/inetd.conf
This check looks for an active POP3 mail-retrieval service in the system network service configuration file /etc/inetd.conf. POP3 is a legacy protocol that sends account names and passwords in clear text, so an active entry means the system is configured to accept remote connections to an outdated service. If the check fails, anyone who can reach that port can read credentials off the network or attack the aging service as a foothold into the system.
# grep -E '^[ ]*pop3[ ]' /etc/inetd.conf pop3 not active in /etc/inetd.conf
This check verifies that the legacy rexd service is not active in the inetd configuration file /etc/inetd.conf. rexd is an old remote-execution service that lets a remote system run commands on this host with no strong authentication. If it is enabled, an attacker who can reach it over the network may run commands on the system, potentially taking it over.
# grep -E '^[ ]*rexd[ ]' /etc/inetd.conf rexd not active in /etc/inetd.conf
This check detects whether the legacy rlogin remote-login service is still enabled in the /etc/inetd.conf network services file. rlogin transmits usernames, passwords, and the entire session in plain text, so anyone able to observe network traffic can capture live credentials and take over the connection. A system that still runs it also keeps an unnecessary, outdated remote entry point open.
# grep -E '^[ ]*login[ ]' /etc/inetd.conf rlogin not active in /etc/inetd.conf
This check reads the inetd service configuration to see whether the legacy rquotad daemon is still enabled. rquotad is an outdated, unencrypted network service that reports disk-quota information to remote systems and is rarely needed today. Leaving it enabled gives attackers an extra clear-text service to probe or exploit as a foothold.
# grep -E '^[ ]*rquotad[ ]' /etc/inetd.conf rquotad not active in /etc/inetd.conf
This check verifies that the legacy rstatd service is not enabled in the /etc/inetd.conf network services file. rstatd is an outdated clear-text service that lets remote machines read the uptime and load statistics of a host over the network. If it is left active, anyone who can reach the server can gather those details, and the old service can be abused as a foothold or to amplify attacks against other systems.
# grep -E '^[ ]*rstatd[ ]' /etc/inetd.conf rstatd not active in /etc/inetd.conf
This control checks whether the legacy rsync file service is enabled in the inetd configuration file (/etc/inetd.conf). When it is active, rsync listens as a clear-text network service that an attacker could use to move files onto or off the system or abuse to amplify attacks aimed at other hosts. A failing result means the machine exposes a file transfer service it likely does not need.
# grep -E '^[ ]*rsync[ ]' /etc/inetd.conf rsync not active in /etc/inetd.conf
This check verifies that the legacy rusersd service is not enabled in the inetd configuration file /etc/inetd.conf. rusersd answers remote requests for the list of users currently logged in without any authentication, so leaving it on lets anyone on the network harvest valid account names and see who is connected.
# grep -E '^[ ]*rusersd[ ]' /etc/inetd.conf rusersd not active in /etc/inetd.conf
This control checks whether the legacy rwalld service is still enabled in the /etc/inetd.conf file. rwalld lets a remote computer broadcast a text message to the terminal of every user logged in on the system, with no login or authentication. If it is left on, anyone who can reach the machine over the network can flood or spoof messages on every screen, disrupting work or tricking users with fake alerts.
# grep -E '^[ ]*rwalld[ ]' /etc/inetd.conf rwalld not active in /etc/inetd.conf
This check confirms that the legacy remote shell service is disabled in the inetd configuration. That service lets a remote computer run commands on the server using weak host-based trust and no encryption. If it is left enabled, an attacker can run commands on the server without a proper login, and anything it sends can be read by others on the network.
# grep -E '^[ ]*shell[ ]' /etc/inetd.conf shell not active in /etc/inetd.conf
This check confirms that the legacy sprayd network service is not enabled in /etc/inetd.conf. When sprayd is active, the system exposes an unauthenticated clear-text service that attackers can abuse to amplify network traffic or use as a foothold for further attacks, which adds avoidable remote attack surface.
# grep -E '^[ ]*sprayd[ ]' /etc/inetd.conf sprayd not active in /etc/inetd.conf
The talk service is a legacy internet chat service that sends messages in clear text with no encryption or authentication. This check verifies that talk is not active in the /etc/inetd.conf file. If it is left running, an attacker can reach an unencrypted service that acts as an easy foothold and can be abused to amplify traffic aimed at other systems.
# grep -E '^[ ]*talk[ ]' /etc/inetd.conf talk not active in /etc/inetd.conf
This control checks whether the Telnet remote-login service is still enabled in the inetd service configuration file on the system. Telnet sends everything it carries, including user names and passwords, across the network as readable text. If the check fails, anyone able to watch traffic to or from the host can capture those login credentials and use them to take over accounts.
# grep -E '^[[:space:]]*(telnet|telnetd|ftp|ftpd|shell|login|exec|rsh|rlogin)[[:space:]]' /etc/inetd.conf telnetd not active in /etc/inetd.conf
This control checks that the legacy tftpd file-transfer service is not enabled in the /etc/inetd.conf configuration file. TFTP transfers files with no authentication or encryption, so a running service lets anyone on the network read or place files on the system, and it can be used to amplify denial-of-service traffic.
# grep -E '^[ ]*tftpd[ ]' /etc/inetd.conf tftpd not active in /etc/inetd.conf
This check verifies that the legacy time service is not enabled in the /etc/inetd.conf configuration file. The time service is an outdated clear-text network service with no modern need. If it is left enabled, it opens an extra port for an attacker to probe and can be abused as a reflection source for denial-of-service traffic.
# grep -E '^[ ]*time[ ]' /etc/inetd.conf time not active in /etc/inetd.conf
This check verifies that the legacy uucp service is disabled in /etc/inetd.conf, the file that controls which network services the system listens for. uucp is an obsolete file-transfer and messaging service that sends data without encryption. If it is left enabled, the system listens for connections on a service modern servers rarely need, giving attackers one more clear-text entry point to probe or exploit.
# grep -E '^[ ]*uucp[ ]' /etc/inetd.conf uucp not active in /etc/inetd.conf
This check verifies that the legacy xmquery network service is not enabled in the inetd configuration file /etc/inetd.conf. xmquery is an obsolete clear-text service that almost no environment needs, so leaving it active gives attackers an extra remote service to probe and possibly abuse as a foothold or an amplification relay.
# grep -E '^[ ]*xmquery[ ]' /etc/inetd.conf xmquery not active in /etc/inetd.conf
This check reports whether the CDE graphical login service (dtlogin) is set to start automatically at boot through the dt entry in the system init table. If that entry is present, a server that does not need a desktop login is still running an extra login service that listens for graphical logins, enlarging the surface an attacker can probe and attack.
# lsitab -a lsitab dt yields no output: no dt entry in the init table
This check verifies that the named DNS server service is not running on the server. It checks whether named is set to start from the boot configuration file /etc/rc.tcpip or is already active as a system service. If named runs on a server that is not meant to be a DNS server, it leaves an unmanaged DNS service answering queries on the network, which attackers can abuse to reflect and amplify traffic or probe for a way in.
# cat /etc/rc.tcpip named not started in /etc/rc.tcpip and not active in the SRC inventory
This control checks the default AIX password settings to confirm that a password, once it reaches its expiry date, can be changed by its holder for only a short capped window before an administrator must reset it. If that window is set to unlimited, or password expiry is switched off, an old or stolen password never forces a reset and an attacker who has one can keep control of the account indefinitely.
# lssec -f /etc/security/user -s default -a maxexpired -a maxage maxexpired=4 weeks; maxage=13 weeks
This control checks whether the legacy Common Desktop Environment (CDE) is installed on the server. CDE includes background network services and privileged helper programs that have a long history of exploitable security flaws. If the check fails, that legacy desktop software is present and leaves extra attack surface that an attacker could target, even though no workload on the system needs it.
# lslpp -qcL 'X11.Dt*' no X11.Dt fileset in the package inventory (query rc=1, empty)
This control checks whether the host has the NFS file-sharing server installed (the bos.net.nfs.server package). NFS lets a system share its filesystems with other computers over the network, so a host with this server can serve its files to network clients. When that server exists on a system that does not need to export files, there is a real risk that its data gets shared with machines that should not have access to it.
# lslpp -L bos.net.nfs.server is not present in the installed-fileset inventory
This check looks at the running service inventory to see whether the piobe print subsystem is active. piobe is the AIX print job backend and is often left running on servers that never print. Any subsystem left active is more privileged code running, more to patch and monitor, and more attack surface than the business asked for on a machine with no printing role.
# lssrc -a piobe not defined in the complete SRC inventory
This control confirms that the OpenSSH login banner file, /etc/ssh/ssh_banner, is owned by the system group. If it belongs to some other group, members of that group could change the message shown to everyone who connects over SSH, replacing the required warning with misleading or deceptive text.
# ls -ln /etc/ssh/ssh_banner OpenSSH login banner file absent
Component not installed on this system.
This control checks the permission settings on /etc/ssh/ssh_banner, the file whose text Secure Shell shows to anyone connecting before they log in. The file must not be writable by anyone other than its owner. If it is writable by others, any unprivileged user could replace that text with a false or misleading message, so everyone who connects would see a banner that no longer reflects an approved notice.
# ls -ln /etc/ssh/ssh_banner OpenSSH login banner file absent
Component not installed on this system.
Secure Shell can display a login banner to anyone connecting to the system, and that text is stored in the file /etc/ssh/ssh_banner. This control checks that the banner file is owned by the root account. If a different account owns it, that account can change the banner text, so the message shown to users is no longer under administrator control and could be altered to mislead people or hide unauthorized tampering.
# ls -ln /etc/ssh/ssh_banner OpenSSH login banner file absent
Component not installed on this system.
The SMIT log (/smit.log) records the system management actions performed through the AIX System Management Interface Tool. This check confirms the log is group-owned by the system group (GID 0). If a different group owns it, members of that group could alter or delete entries in the log, hiding or falsifying the record of administrative changes made on the system.
# lsuser -a home root /smit.log absent
Component not installed on this system.
This check verifies that the log file /smit.log grants no permission beyond owner read and write plus group read. /smit.log is where AIX SMIT, the system management tool, records the administrative actions run through it. If those permissions were looser, an unprivileged user could alter or delete the log and erase the record of what was changed, hiding unauthorized activity.
# lsuser -a home root /smit.log absent
Component not installed on this system.
The /smit.log file is the record of system administration changes made through the AIX management tool. This control confirms that file is owned by the root account. If a different user owns it, that user could alter or erase the log and hide the record of changes made to the system.
# lsuser -a home root /smit.log absent
Component not installed on this system.
This control checks that /var/adm/cron/at.allow, the file that lists who may schedule deferred jobs with the at command, is owned by the system group sys. If that file belongs to a different group, members of that group could rewrite it to add themselves or others to the allowed list, tampering with a trusted administrative file.
# ls -ln /var/adm/cron/at.allow /var/adm/cron/at.allow absent
Component not installed on this system.
This control checks the permissions on /var/adm/cron/at.allow, the file that lists which users are allowed to schedule one-time jobs with the at command. It must be readable only by root, with no group or world access. If the file is writable by others, an unauthorized user could edit the list to grant themselves or another account the ability to schedule jobs, running commands at a time they choose.
# ls -ln /var/adm/cron/at.allow /var/adm/cron/at.allow absent
Component not installed on this system.
The file /var/adm/cron/at.allow lists which users are allowed to schedule at jobs on the system. This control checks that the file is owned by root. If a non-root user owns it, that user could rewrite the list to grant scheduling rights or alter trusted configuration.
# ls -ln /var/adm/cron/at.allow /var/adm/cron/at.allow absent
Component not installed on this system.
This control checks that the group owner of the /var/adm/cron/cron.allow file is the sys group. That file is the list of users allowed to schedule jobs through cron, so it should stay under system control. If a different group owns the file, members of that group could modify it to grant themselves or others the ability to run scheduled jobs they are not authorized to run.
# ls -ln /var/adm/cron/cron.allow /var/adm/cron/cron.allow absent
Component not installed on this system.
This check verifies the permission settings on /var/adm/cron/cron.allow, the file that lists which users are allowed to schedule recurring cron jobs. The file must be read-only, readable only by its owner. If it is writable, an unauthorized user could edit the list to grant themselves or others the ability to schedule jobs, gaining persistent execution on the system.
# ls -ln /var/adm/cron/cron.allow /var/adm/cron/cron.allow absent
Component not installed on this system.
This control checks that the cron allow-list file /var/adm/cron/cron.allow is owned by root. That file controls which users may schedule automated jobs through cron. If a non-root account owns it, that account can rewrite the list to grant itself or others cron access, opening a path to running unauthorized scheduled commands on the system.
# ls -ln /var/adm/cron/cron.allow /var/adm/cron/cron.allow absent
Component not installed on this system.
This control checks that the system log file /var/tmp/dpid2.log is owned by the system group rather than an ordinary user group. If a non-system group owns the file, members of that group can read or alter the log, which lets them tamper with records or see detail meant only for system administration.
# ls -ln /var/tmp/dpid2.log /var/tmp/dpid2.log absent
Component not installed on this system.
This control checks the permission bits on the dpid2 log file /var/tmp/dpid2.log, which must be no more open than owner read and write with group read only (0640). If the file is more permissive, other accounts on the system can read or rewrite the log. That lets someone tamper with or erase the log entries, hiding activity and destroying the evidence that security and operations staff rely on.
# ls -ln /var/tmp/dpid2.log /var/tmp/dpid2.log absent
Component not installed on this system.
This control checks that the log file /var/tmp/dpid2.log is owned by root, the system administrator account (UID 0). If any other account owns the file, that account can rewrite, replace, or delete it, and so could hide or alter the records the service has written that operations and incident review depend on.
# ls -ln /var/tmp/dpid2.log /var/tmp/dpid2.log absent
Component not installed on this system.
This check confirms that the SNMP daemon log file /var/tmp/snmpd.log belongs to the system group. If a different group owns the file, members of that group can alter or replace the log, so the record of SNMP activity can no longer be trusted.
# ls -ln /var/tmp/snmpd.log /var/tmp/snmpd.log absent
Component not installed on this system.
This check verifies that the SNMP daemon log file /var/tmp/snmpd.log grants no more access than mode 0640, so only its owner can write it and only its group can read it. If the permissions are looser, unprivileged users could read the SNMP activity the log records or alter its contents. A log that others can change stops being trustworthy and could hide SNMP activity or mislead an investigation.
# ls -ln /var/tmp/snmpd.log /var/tmp/snmpd.log absent
Component not installed on this system.
This control verifies that the SNMP service log at /var/tmp/snmpd.log is owned by the root account. The SNMP daemon records its activity in this file, so its contents are relied on as a trustworthy record of what the service did. If another account owns the file, that account can rewrite, erase, or replace the log, letting an attacker hide or falsify SNMP activity and corrupt the record administrators depend on.
# ls -ln /var/tmp/snmpd.log /var/tmp/snmpd.log absent
Component not installed on this system.
This control checks whether the server is configured to mount remote file systems over NFS, as recorded in the /etc/filesystems file. If any such NFS client mount is still configured, the server will connect to a remote system and treat its files as if they were local. An attacker who controls that remote system could use the mount to plant programs that run with administrator privileges, which can lead to full system compromise.
# ls -ld /etc/filesystems no NFS client mounts configured in /etc/filesystems
This control checks that the root account is configured to use the Korn shell (/usr/bin/ksh) as its login shell. The root account is the built-in account used for system recovery and administration, so its shell must be a known, working shell. If the shell is set to something else or left blank, a root login may fail or run an unexpected program, which can lock administrators out of the system or hide tampering.
# lsuser -a shell root root shell=/usr/bin/ksh
This control checks whether the legacy routed service is running, either started at boot from /etc/rc.tcpip or active in the service inventory. Routed maintains routing tables using the old RIP1 protocol, which accepts updates from anyone on the network without authentication. If it is left enabled, an attacker could feed it bogus routes to redirect or disrupt traffic on this host.
# cat /etc/rc.tcpip routed not started in /etc/rc.tcpip and not active in the SRC inventory
This check confirms the rwhod service is not in use, meaning it is not started at boot from /etc/rc.tcpip and not running as an active system service. rwhod is a legacy daemon that broadcasts the names of logged-in users across the network, which is rarely needed and lets anyone on the wire see who is using the system. A failure means the server is running that service, leaking login information and exposing an extra network service that attackers can probe.
# cat /etc/rc.tcpip rwhod not started in /etc/rc.tcpip and not active in the SRC inventory
This check verifies whether the obsolete chargen (Character Generator) service is enabled in the AIX inetd configuration file. Chargen streams characters to anyone who connects, needs no authentication, and has no business purpose. If it stays enabled, attackers can use it to amplify denial-of-service traffic or as an unneeded entry point for probing the system.
# grep -E '^[ ]*chargen[ ]' /etc/inetd.conf chargen not active in /etc/inetd.conf
This check inspects the inetd configuration to see whether the legacy discard service is enabled. Discard is an obsolete network service that silently throws away anything sent to it and has no legitimate use on a modern system. If it is left running, it becomes an unnecessary network entry point that attackers can abuse to tie up system or network resources.
# grep -E '^[[:space:]]*discard[[:space:]]' /etc/inetd.conf discard not active in /etc/inetd.conf
This control checks whether the obsolete timed network service is running, either started at boot from the /etc/rc.tcpip file or active as a running system service. timed provides a legacy UNIX time service that has been replaced by NTP. Leaving it running exposes an outdated and unnecessary network service that widens the attack surface and can give any system that still connects to it unreliable time.
# cat /etc/rc.tcpip timed not started in /etc/rc.tcpip and not active in the SRC inventory
This check confirms the writesrv write server is not running. writesrv is a network service that lets someone, including a user on another machine, push a message straight onto the screen of a logged-in user through the write command. If it is left active, that service is an unnecessary opening on the machine, and it can be used to send spam or spoof messages that interrupt a user or trick them into trusting a fake sender.
# lssrc -a writesrv inoperative in the SRC inventory
This control checks the Common Desktop Environment (CDE) screensaver lock timing on AIX systems. It verifies that an unattended desktop session blanks and locks itself within ten minutes or less, as set by the saverTimeout and lockTimeout settings in the CDE session configuration. If those settings are missing or set too high, a logged-in desktop left unattended stays unlocked, letting anyone with physical access to the console use the session and everything the signed-in user can reach.
# lslpp -qcL 'X11.Dt*' CDE not installed (fileset query empty); no CDE session manager exists to run a screensaver lock
This control checks that root is the only account with UID 0, the special number that gives an account full control over the machine. If any other account also has UID 0, every one of those accounts can act as the administrator. That means a single compromised password among them lets an attacker take over the whole system.
# awk -F: '$3==0 {print $1}' /etc/passwd
root onlyThis control checks the SSH server setting PermitUserEnvironment, which decides whether users may bring their own environment variables into a login session. When enabled, a user can supply environment values that the server then applies to programs run in that session. A compromised account could use these values to bypass restrictions in environment-sensitive programs, gaining access or actions the system should not allow.
# sshd -T PermitUserEnvironment no
SSH can be configured to trust a connection based on the machine it comes from, through host-based authentication or rhosts files, instead of checking the credentials that belong to the account being logged into. This check verifies that the SSH server has IgnoreRhosts set to yes and HostbasedAuthentication set to no, so every login must prove its own identity. If either setting is wrong, someone who gains access to one trusted machine, or who can plant an rhosts entry, could log in to other accounts without supplying the password or key for those accounts.
# sshd -T IgnoreRhosts yes, HostbasedAuthentication no
This control checks that the SSH service is set to display a warning message before anyone can log in, and that the message file actually exists. If no banner is shown, people connecting over SSH get no advance notice that the system is monitored and restricted to authorized use, which removes a simple deterrent and weakens the legal footing for holding an intruder accountable.
# sshd -T Banner /etc/issue; regular file present
This control checks the logging level of SSH, the service that allows remote login to the system. SSH must be set to INFO or VERBOSE so that login attempts and authentication failures are written to the security log. If the level is set too low, break-in attempts go unrecorded and an attacker leaves no trace; if it is set to DEBUG, the logs can fill with sensitive detail about accounts and sessions that should not be exposed.
# sshd -T LogLevel INFO
This control verifies that the SSH service rejects logins from accounts with no password. It checks the effective PermitEmptyPasswords setting in the SSH server configuration. If empty passwords are allowed, any account left without a password can be logged into over the network with no credentials at all.
# sshd -T PermitEmptyPasswords no
NOT FIXED - Multiple vulnerabilities impact AIX due to OpenSSL Open exposure: the installed level 3.0.16.1000 is inside the unsafe range; fixed in See Bulletin.
openssl.base has an open FLRTVC exposure (CVE CVE-2025-15467)
# cve-table parse of the FLRTVC report (--exposure input) openssl.base 3.0.16.1000: open FLRTVC exposure, CVE CVE-2025-15467, CVSS 9.8, bulletin https://aix.software.ibm.com/aix/efixes/security/openssl_advisory46.asc
NOT FIXED - Multiple vulnerabilities impacts AIX due to cURL libcurl (CVE-2026-10536 CVE-2026-11856 CVE-2026-8286 CVE-2026-8458 CVE-2026-8924 CVE-2026-8927 CVE-2026-8932 CVE-2026-9547) Open exposure: the installed level 8.5.0.2 is inside the unsafe range; fixed in See Bulletin.
oss.lib.libcurl has an open FLRTVC exposure (CVE CVE-2026-10536)
# cve-table parse of the FLRTVC report (--exposure input) oss.lib.libcurl 8.5.0.2: open FLRTVC exposure, CVE CVE-2026-10536, CVSS 9.8, bulletin https://aix.software.ibm.com/aix/efixes/security/curl_advisory11.asc
NOT FIXED - Multiple vulnerabilities in OpenSSH affect AIX Open exposure: the installed level 9.9.3015.2000 is inside the unsafe range; fixed in See Bulletin.
openssh.base.client has an open FLRTVC exposure (CVE CVE-2026-35385)
# cve-table parse of the FLRTVC report (--exposure input) openssh.base.client 9.9.3015.2000: open FLRTVC exposure, CVE CVE-2026-35385, CVSS 8.1, bulletin https://aix.software.ibm.com/aix/efixes/security/openssh_advisory21.asc
NOT FIXED - Multiple vulnerabilities in OpenSSH affect AIX Open exposure: the installed level 9.9.3015.2000 is inside the unsafe range; fixed in See Bulletin.
openssh.base.server has an open FLRTVC exposure (CVE CVE-2026-35385)
# cve-table parse of the FLRTVC report (--exposure input) openssh.base.server 9.9.3015.2000: open FLRTVC exposure, CVE CVE-2026-35385, CVSS 8.1, bulletin https://aix.software.ibm.com/aix/efixes/security/openssh_advisory21.asc
NOT FIXED - Multiple vulnerabilities impact AIX due to OpenSSL Open exposure: the installed level 3.0.16.1000 is inside the unsafe range; fixed in See Bulletin.
openssl.base has an open FLRTVC exposure (CVE CVE-2026-28387)
# cve-table parse of the FLRTVC report (--exposure input) openssl.base 3.0.16.1000: open FLRTVC exposure, CVE CVE-2026-28387, CVSS 8.1, bulletin https://aix.software.ibm.com/aix/efixes/security/openssl_advisory47.asc
NOT FIXED - AIX is vulnerable to an out-of-bounds read (CVE-2025-9230 CVE-2025-9232) due to OpenSSL Open exposure: the installed level 3.0.16.1000 is inside the unsafe range; fixed in See Bulletin.
openssl.base has an open FLRTVC exposure (CVE CVE-2025-9230)
# cve-table parse of the FLRTVC report (--exposure input) openssl.base 3.0.16.1000: open FLRTVC exposure, CVE CVE-2025-9230, CVSS 7.5, bulletin https://aix.software.ibm.com/aix/efixes/security/openssl_advisory45.asc
NOT FIXED - Multiple vulnerabilities impact AIX due to OpenSSL Open exposure: the installed level 3.0.16.1000 is inside the unsafe range; fixed in See Bulletin.
openssl.base has an open FLRTVC exposure (CVE CVE-2026-34180)
# cve-table parse of the FLRTVC report (--exposure input) openssl.base 3.0.16.1000: open FLRTVC exposure, CVE CVE-2026-34180, CVSS 7.5, bulletin https://aix.software.ibm.com/aix/efixes/security/openssl_advisory48.asc
NOT FIXED - AIX is vulnerable to a denial of service (CVE-2025-9086) due to cURL libcurl Open exposure: the installed level 8.5.0.2 is inside the unsafe range; fixed in See Bulletin.
oss.lib.libcurl has an open FLRTVC exposure (CVE CVE-2025-9086)
# cve-table parse of the FLRTVC report (--exposure input) oss.lib.libcurl 8.5.0.2: open FLRTVC exposure, CVE CVE-2025-9086, CVSS 7.5, bulletin https://aix.software.ibm.com/aix/efixes/security/curl_advisory8.asc
NOT FIXED - AIX Xorg X Server is vulnerable to memory corruption or a denial of service (CVE-2025-62230 CVE-2025-62231) Open exposure: the installed level 7.3.4.0 is inside the unsafe range; fixed in 7300-04-01.
x11.base.rte has an open FLRTVC exposure (CVE CVE-2025-62230)
# cve-table parse of the FLRTVC report (--exposure input) x11.base.rte 7.3.4.0: open FLRTVC exposure, CVE CVE-2025-62230, CVSS 7.3, bulletin https://aix.software.ibm.com/aix/efixes/security/xorg_advisory5.asc
NOT FIXED - Multiple vulnerabilities in Python affect AIX Open exposure: the installed level 3.11.13.1 is inside the unsafe range; fixed in See Bulletin.
python3.11.base has an open FLRTVC exposure (CVE CVE-2026-2297)
# cve-table parse of the FLRTVC report (--exposure input) python3.11.base 3.11.13.1: open FLRTVC exposure, CVE CVE-2026-2297, CVSS 5.7, bulletin https://aix.software.ibm.com/aix/efixes/security/python_advisory20.asc
NOT FIXED - AIX is vulnerable to denial of service due to zlib (CVE-2026-27171) Open exposure: the installed level 4.20.1.2001 is inside the unsafe range; fixed in See Bulletin.
rpm.rte has an open FLRTVC exposure (CVE CVE-2026-27171)
# cve-table parse of the FLRTVC report (--exposure input) rpm.rte 4.20.1.2001: open FLRTVC exposure, CVE CVE-2026-27171, CVSS 5.5, bulletin https://aix.software.ibm.com/aix/efixes/security/zlib_advisory3.asc
NOT FIXED - Vulnerability impacts AIX due to cURL libcurl (CVE-2025-14524) Open exposure: the installed level 8.5.0.2 is inside the unsafe range; fixed in See Bulletin.
oss.lib.libcurl has an open FLRTVC exposure (CVE CVE-2025-14524)
# cve-table parse of the FLRTVC report (--exposure input) oss.lib.libcurl 8.5.0.2: open FLRTVC exposure, CVE CVE-2025-14524, CVSS 5.3, bulletin https://aix.software.ibm.com/aix/efixes/security/curl_advisory9.asc
NOT FIXED - Multiple vulnerabilities impacts AIX due to cURL libcurl (CVE-2025-14819 CVE-2026-1965 CVE-2026-3783 CVE-2026-3784 CVE-2026-5545) Open exposure: the installed level 8.5.0.2 is inside the unsafe range; fixed in See Bulletin.
oss.lib.libcurl has an open FLRTVC exposure (CVE CVE-2025-14819)
# cve-table parse of the FLRTVC report (--exposure input) oss.lib.libcurl 8.5.0.2: open FLRTVC exposure, CVE CVE-2025-14819, CVSS 5.3, bulletin https://aix.software.ibm.com/aix/efixes/security/curl_advisory10.asc
NOT FIXED - Multiple vulnerabilities in Python affect AIX Open exposure: the installed level 3.11.13.1 is inside the unsafe range; fixed in See Bulletin.
python3.11.base has an open FLRTVC exposure (CVE CVE-2025-12084)
# cve-table parse of the FLRTVC report (--exposure input) python3.11.base 3.11.13.1: open FLRTVC exposure, CVE CVE-2025-12084, CVSS 5.3, bulletin https://aix.software.ibm.com/aix/efixes/security/python_advisory19.asc
NOT FIXED - Vulnerabilities in libxml2 (CVE-2026-0989 CVE-2026-0990 CVE-2026-0992) affect AIX Open exposure: the installed level 7.3.4.0 is inside the unsafe range; fixed in 7300-04-01.
bos.rte.control has an open FLRTVC exposure (CVE CVE-2026-0989)
# cve-table parse of the FLRTVC report (--exposure input) bos.rte.control 7.3.4.0: open FLRTVC exposure, CVE CVE-2026-0989, CVSS 3.7, bulletin https://aix.software.ibm.com/aix/efixes/security/libxml2_advisory11.asc
NOT FIXED - AIX is vulnerable to potential code execution (CVE-2025-61984 CVE-2025-61985) due to OpenSSH Open exposure: the installed level 9.9.3015.2000 is inside the unsafe range; fixed in See Bulletin.
openssh.base.client has an open FLRTVC exposure (CVE CVE-2025-61984)
# cve-table parse of the FLRTVC report (--exposure input) openssh.base.client 9.9.3015.2000: open FLRTVC exposure, CVE CVE-2025-61984, CVSS 3.6, bulletin https://aix.software.ibm.com/aix/efixes/security/openssh_advisory20.asc
NOT FIXED - AIX is vulnerable to potential code execution (CVE-2025-61984 CVE-2025-61985) due to OpenSSH Open exposure: the installed level 9.9.3015.2000 is inside the unsafe range; fixed in See Bulletin.
openssh.base.server has an open FLRTVC exposure (CVE CVE-2025-61984)
# cve-table parse of the FLRTVC report (--exposure input) openssh.base.server 9.9.3015.2000: open FLRTVC exposure, CVE CVE-2025-61984, CVSS 3.6, bulletin https://aix.software.ibm.com/aix/efixes/security/openssh_advisory20.asc
NOT FIXED - Vulnerability in libxml2 (CVE-2025-8732) affects AIX Open exposure: the installed level 7.3.4.0 is inside the unsafe range; fixed in 7300-04-01.
bos.rte.control has an open FLRTVC exposure (CVE CVE-2025-8732)
# cve-table parse of the FLRTVC report (--exposure input) bos.rte.control 7.3.4.0: open FLRTVC exposure, CVE CVE-2025-8732, CVSS 3.3, bulletin https://aix.software.ibm.com/aix/efixes/security/libxml2_advisory10.asc
NOT FIXED - Vulnerabilities in IBM AIX and PowerVM VIOS Open exposure: the installed level 7.3.4.0 is inside the unsafe range; fixed in 7300-04-02.
bos.mp64 has an open FLRTVC exposure (CVE CVE-2025-12817)
# cve-table parse of the FLRTVC report (--exposure input) bos.mp64 7.3.4.0: open FLRTVC exposure, CVE CVE-2025-12817, CVSS 3.1, bulletin https://aix.software.ibm.com/aix/efixes/security/aix_vios_advisory.asc
NOT FIXED - AIX Perl is vulnerable to a null pointer dereference (CVE-2026-24515) and an integer overflow (CVE-2026-25210) Open exposure: the installed level 5.38.2.3 is inside the unsafe range; fixed in See Bulletin.
perl.rte has an open FLRTVC exposure (CVE CVE-2026-24515)
# cve-table parse of the FLRTVC report (--exposure input) perl.rte 5.38.2.3: open FLRTVC exposure, CVE CVE-2026-24515, CVSS 2.5, bulletin https://aix.software.ibm.com/aix/efixes/security/perl_advisory13.asc
NOT FIXED - AIX Python is vulnerable to a null pointer dereference (CVE-2026-24515) and an integer overflow (CVE-2026-25210) Open exposure: the installed level 3.11.13.1 is inside the unsafe range; fixed in See Bulletin.
python3.11.base has an open FLRTVC exposure (CVE CVE-2026-24515)
# cve-table parse of the FLRTVC report (--exposure input) python3.11.base 3.11.13.1: open FLRTVC exposure, CVE CVE-2026-24515, CVSS 2.5, bulletin https://aix.software.ibm.com/aix/efixes/security/python_advisory18.asc
NOT FIXED - LPAR may leak kernel memory hang or crash Open exposure: the installed level 7.3.4.0 is inside the unsafe range; no usable CVSS score.
# cve-table parse of the FLRTVC report (--exposure input) not assessed - exposure row for bos.mp64 carries no usable CVSS score (https://www.ibm.com/support/pages/node/7259584)
The probe ran but its output couldn't be parsed. not assessed - exposure row for bos.mp64 carries no usable CVSS score (https://www.ibm.com/support/pages/node/7259584) If left unresolved, this is a high exposure.
NOT FIXED - Some FC adapters may not recover from temporary SAN errors Open exposure: the installed level 7.3.4.0 is inside the unsafe range; no usable CVSS score.
# cve-table parse of the FLRTVC report (--exposure input) not assessed - exposure row for devices.pciex.7710612214105006.com carries no usable CVSS score (https://www.ibm.com/support/pages/node/7278066)
The probe ran but its output couldn't be parsed. not assessed - exposure row for devices.pciex.7710612214105006.com carries no usable CVSS score (https://www.ibm.com/support/pages/node/7278066) If left unresolved, this is a high exposure.
NOT FIXED - AIX is vulnerable to denial of service and possible code execution due to Perl (WS-2025-0004) Open exposure: the installed level 5.38.2.3 is inside the unsafe range; no usable CVSS score.
# cve-table parse of the FLRTVC report (--exposure input) not assessed - exposure row for perl.rte carries no usable CVSS score (https://aix.software.ibm.com/aix/efixes/security/perl_advisory12.asc)
The probe ran but its output couldn't be parsed. not assessed - exposure row for perl.rte carries no usable CVSS score (https://aix.software.ibm.com/aix/efixes/security/perl_advisory12.asc) If left unresolved, this is a high exposure.
NOT FIXED - IBM.SoftwareRM subsystem may kill all processes on an LPAR Open exposure: the installed level 3.3.4.0 is inside the unsafe range; no usable CVSS score.
# cve-table parse of the FLRTVC report (--exposure input) not assessed - exposure row for rsct.opt.softwarerm carries no usable CVSS score (https://www.ibm.com/support/pages/node/7262728)
The probe ran but its output couldn't be parsed. not assessed - exposure row for rsct.opt.softwarerm carries no usable CVSS score (https://www.ibm.com/support/pages/node/7262728) If left unresolved, this is a high exposure.
This check confirms that the tracked security APARs for the technology level are installed, credited either to a Service Pack (instfix -ik) or to an installed interim fix (emgr -lv3). A tracked APAR missing from both means the box is still exposed to a published, fixed vulnerability (CVE-2025-36250, NIM nimesis remote command execution) whose fix is available but not applied.
This box is exposed to published, fixed vulnerabilities -- the fix exists and is not applied.
# oslevel -s missing: IJ59563 (CVE-2026-16923) IJ57378 (HIPER-7278066)
This control checks that the host keeps its clock synchronized using the Network Time Protocol (NTP). A compliant host has the NTP daemon active, at least one time server configured in /etc/ntp.conf, and an NTP poll interval bound (maxpoll) of 16 (about 18 hours) or less so the clock is disciplined at least every 24 hours. When time sync is missing, too sparsely polled, or the clock drifts, log timestamps become unreliable and time-sensitive security features such as Kerberos and TLS can fail.
No working time sync -- clock drift breaks log correlation, Kerberos and TLS.
# lssrc -s xntpd xntpd inoperative; no time server configured; no active maxpoll bound configured
This control checks that the system is set up to record its own hardware and software configuration on a regular schedule, and that its inventory log is saved to a local file. If either of these is missing, there is no dependable record of how the system was set up, so changes from an outage or an intruder can go unnoticed and are hard to reconstruct afterward.
System configuration capture is incomplete: a scheduled run of /usr/sbin/lsconf -v or its syslog routing to a path containing syslog/inventory.log is missing.
# crontab -l no cron entry runs /usr/sbin/lsconf -v; syslog.conf has no entry routing local1.info to a path containing syslog/inventory.log
This check verifies that the system is configured to forward log entries to a remote log server rather than keeping the record only on the machine itself. If no remote destination is set, an attacker who gains access can delete or rewrite the local logs to erase evidence, and a disk or system failure can destroy the only copy of the record.
No syslog rule forwards log entries to a remote host; the log survives only until the box dies.
# cat /etc/syslog.conf no remote target
rootvg is the volume group that holds the AIX operating system. Mirroring it keeps a second copy of every operating-system file on another disk, so the server keeps running if one disk fails. A rootvg that is unmirrored, partially mirrored, or running with a stale or missing mirror copy is a single disk failure away from a full outage.
The OS lives on one disk -- a single point of failure unless the backing storage is RAID/SAN-protected. Verify which.
# lsvg -p rootvg 1 disk, unmirrored
This control measures how much free space is left in each active volume group, the storage pools that filesystems draw from when they need to grow. If any volume group falls below five percent free, there is no headroom to enlarge a filesystem when it fills up, so applications and users can be blocked from writing data at the moment storage is needed most.
A volume group is under 5% free -- no headroom to extend a filesystem in an emergency.
# lsvg -o rootvg 1% free
This check measures how full every filesystem is, including the root, /var, and /tmp mounts and all other storage volumes, and how much capacity is left for new files. A filesystem that fills up can no longer write logs, spool jobs, or complete user logins, and any service that needs to write to it stops. A near-full filesystem is an early warning that an outage is about to happen.
Getting tight -- risk of a fill-up outage.
# df -g 87% used
This check reads the file of kernel settings that AIX will apply at the next reboot. It flags any non-default values so each change can be reviewed and justified. Unreviewed kernel tuning can alter memory, network, or storage behavior in ways that surprise operators or hurt performance.
Kernel tunables are changed from default for next boot -- deliberate tuning or archaeology? document each.
# cat /etc/tunables/nextboot 3 changed tunable line(s)
AIX records system performance over time using a background collector such as topasrec, nmon, or njmon. This check confirms that at least one of those collectors is actively running. If none is running, no performance history is being saved, leaving capacity planning and the investigation of past slowdowns or outages to guesswork.
No performance-history collection -- sizing and incident forensics become guesswork.
# ps -e -o comm none running (checked exact commands: topasrec, xmwlm, nmon, topas_nmon, njmon, njmon_aix<digits>_v<digits>)
This control checks that system logging is set up to forward a copy of its records to a remote server, shown by an @ entry in the /etc/syslog.conf file. Forwarding keeps an independent copy of the logs so they survive a crash, disk failure, or an attack on the host itself. If no remote target is set, the only copy of the logs lives on the machine that produced them, so an attacker who takes it over can wipe the evidence and a hardware failure destroys the record of what happened.
No remote syslog target -- logs die with the box, exactly when you need them.
# grep @ /etc/syslog.conf no remote target
This check reads the AIX error-notification database and reports what happens when the system logs a hardware or disk error. It distinguishes alerts that page or email an on-call responder from errors that only reach the built-in call-home path or that go nowhere. If no alert method is configured, a failing disk or other critical error is logged but never reaches a person, so a serious problem can go unnoticed until it causes an outage.
The default diagela stanzas forward hardware errors to the diagnostics / Service Focal Point path (call-home, if enabled on the HMC/service processor), but no stanza runs a site alert script -- nothing pages or mails your on-call on a critical or disk error.
# odmget errnotify default errnotify only (diagela call-home present, no site paging)
This check verifies that the system can find its own hostname in its local hosts file. When the system has no valid local entry for its own name, applications and security certificates may misbehave or refuse to work. That leaves the machine with incomplete local host configuration and no reliable way to address itself by name.
Tools and certs can misbehave when the box has no local entry for its own hostname; PTxray deliberately did not query DNS.
# hostname aix-lab1 does not self-resolve locally -- no matching /etc/hosts entry; resolution order not declared/readable
This check confirms that an AIX system has a consistent set of installed fileset requisites and dependencies. lppchk -v verifies that every installed fileset has all prerequisites present and matching, corroborated by an independent lppchk -m3 -v escalation and a real lslpp -qcL fileset inventory. A fileset with missing or mismatched prerequisites can block update_all and install_all_updates the same way a BROKEN state does, even when the recorded state of the fileset itself looks fine. The check only runs read-only lppchk and lslpp commands; it never writes anything.
# lslpp -qcL consistent
This control verifies that the server has a real system dump device configured so that a crash can be captured for later diagnosis. If the primary dump device is unset or disabled, a system panic produces no dump at all, and the cause of the outage must be guessed rather than determined from evidence.
# sysdumpdev -l primary: /dev/lg_dumplv
This control reviews the AIX error log and counts the non-informational error entries recorded in the last seven days. Hardware faults such as a failing disk or power supply, and software failures, announce themselves in this log before they cause an outage. A system with many recent errors is actively misbehaving and is at risk of an unplanned failure or data loss.
# odmget errnotify 0 error entries (1 informational ignored)
A default route tells the system where to send traffic that is not for its own local network. If it is missing, traffic to other networks goes nowhere and the system may become unreachable or lose access to remote services.
# netstat -r IPv4 default route present in netstat -r route tree
Checks that the AIX system has at least one DNS nameserver configured in /etc/resolv.conf. If no nameserver is present, the system cannot translate hostnames into network addresses, which can break backups, software updates, authentication, and any other service that relies on name resolution.
# grep nameserver /etc/resolv.conf 1 nameserver(s)
This control checks that each multipath disk actively probes the health of its redundant storage paths, so a failed path is found quickly. When path health checks are disabled or run too slowly, a dead path can go unnoticed until live traffic hits it, causing I/O errors or an outage even though a healthy redundant path was available.
# lspath MPIO disks=1; showing 1 of 1; applicable=1; attribute not applicable=0; unreadable=0; table: disk interval mode | hdisk0 60 nonactive
This check verifies that disks expected to have redundant paths to their storage actually have more than one working path, so a single cable or adapter failure cannot cut a disk off from its data. It flags a disk that has a failed or disabled path, or that is down to a single working path. If that last path then fails, the disk becomes unavailable and the applications or databases on it stop until a path is restored.
# lspath 8 paths / 1 disks, all enabled
This check measures how full every filesystem is, including the root, /var, and /tmp mounts and all other storage volumes, and how much capacity is left for new files. A filesystem that fills up can no longer write logs, spool jobs, or complete user logins, and any service that needs to write to it stops. A near-full filesystem is an early warning that an outage is about to happen.
# df -g 49% used
This check measures how full every filesystem is, including the root, /var, and /tmp mounts and all other storage volumes, and how much capacity is left for new files. A filesystem that fills up can no longer write logs, spool jobs, or complete user logins, and any service that needs to write to it stops. A near-full filesystem is an early warning that an outage is about to happen.
# df -g 16% used
This check measures how full every filesystem is, including the root, /var, and /tmp mounts and all other storage volumes, and how much capacity is left for new files. A filesystem that fills up can no longer write logs, spool jobs, or complete user logins, and any service that needs to write to it stops. A near-full filesystem is an early warning that an outage is about to happen.
# df -g no filesystem above 90% inodes
This control checks the version of IBM SDK Java installed on an AIX or VIOS system. IBM no longer ships security fixes for Java 7 and earlier, which reached end of service in 2022. A system still running Java 7 or earlier carries an unpatched runtime that exposes applications to vulnerabilities with no fix available.
# lslpp -qcL Java* Java 8 installed (Java8_64.jre 8.0.0.851, Java8_64.sdk 8.0.0.851)
This control measures how full the paging space of the system is. Paging space is the disk overflow used when physical memory runs short. If it fills up, the system can no longer allocate memory to running programs and will start killing them, and heavy use in the meantime means the machine is swapping to disk and running slowly.
# lsvg -o 1 space(s), 3% used
This control checks that the /tmp directory is a separate filesystem and that every JFS2 filesystem has a log device. If /tmp shares space with the root filesystem, a process that fills /tmp can also fill root, stopping logins and logging across the whole system. A JFS2 filesystem with no log device takes longer to recover and is more likely to lose or corrupt data after a crash.
# mount /tmp separate; 9 jfs2 mount(s), all logged; 9 using default atime
Detects whether an AIX box is a NIM client and names its NIM master. On a NIM-managed LPAR the mksysb and lpp_source restore images normally live on the master, so a thin local backup story is expected -- this check confirms the OS restore point is centralized there and tells you which master to verify.
# ls /etc/niminfo not a NIM client -- /etc/niminfo absent
Component not installed on this system.
This check inspects the Shared Ethernet Adapter of a VIOS and CAA cluster state to infer whether the box is a single point of failure. A failover-ready SEA (ha_mode auto/standby, a control channel, a priority) or a CAA cluster implies a partner VIOS and passes; a SEA that cannot fail over, with no cluster to replace it, fails; and when no SEA and no cluster are visible the check reports not-applicable. It also records the SEA failover posture as its own finding.
# cluster -status no SEA, no CAA cluster (sea probe rc=0, cluster probe rc=127)
Reason not typed by the check.
This check reports the health of the Shared Storage Pool (SSP) / CAA cluster on a VIOS. If a node or the pool reports DOWN, DEGRADED, FAILED or INCOMPLETE, shared storage for the SSP may have lost a redundant path, so it warns. When the cluster and all nodes report OK it passes, and when no cluster is defined it is not applicable.
# ioscli cluster -status no CAA/SSP cluster present
Reason not typed by the check.
This check reports whether the system has any interim fixes installed. Interim fixes are temporary patches shipped ahead of a formal operating system update. An interim fix left in place can block the next operating system update from installing cleanly.
# emgr -l none installed
This check looks for a standby copy of the operating system left behind by a previous multibos or alternate-disk operation, detected as bos_-prefixed logical volumes or a mounted /bos_inst filesystem. If that standby copy remains, an AIX migration can be blocked or forced onto an unexpected sequence, risking a failed or delayed upgrade and a wasted maintenance window.
# lsvg -l rootvg none
Mirroring keeps a second copy of data so that if one disk fails the system can keep running from the other. This control checks that mirrored copies are actually stored on separate physical disks rather than stacked on the same disk. If both copies sit on one disk, a single disk failure destroys both, so the mirror offers no real protection.
# lsvg -o no mirrored LVs
This check measures how full every filesystem is, including the root, /var, and /tmp mounts and all other storage volumes, and how much capacity is left for new files. A filesystem that fills up can no longer write logs, spool jobs, or complete user logins, and any service that needs to write to it stops. A near-full filesystem is an early warning that an outage is about to happen.
# df -g none above 90%; repo (informational): /usr/sys/inst.images 100%
This control reviews the system hardware error log for permanent failures recorded over the last 30 days. A permanent hardware error means a component such as memory, a disk, or a processor has already begun to fail and will not recover on its own. If these signs go unmonitored, the failing part can take the system down or corrupt data without warning.
# errpt -d H -T PERM -s <cutoff> none
This control looks in the AIX crash directory /var/adm/ras for vmcore dump files changed within the last 30 days. A vmcore file is the memory image AIX writes when the server crashes, so its presence means the system stopped unexpectedly. If this check fails, the cause of that crash may still be unknown, and the same fault could strike again, causing further unplanned downtime.
# find /var/adm/ras -name vmcore* -mtime -30 -print none in 30 days
This check confirms every vSCSI backing LUN on a VIOS is free of SCSI reservation (reserve_policy no_reserve), so dual-VIOS vSCSI failover can actually work. A reserved backing LUN fails silently: everything looks mapped and dual, but the partner VIOS cannot open the LUN and the disk of the client never comes back on failover.
# ioscli lsmap -all no vSCSI host adapter (vhost) on this box
Reason not typed by the check.
This check scans the recent system error log for early warning signs that a hardware component is failing, such as disk errors, SAN or SCSI path faults, power or thermal events, memory errors, lost logical volumes, adapter resets, and dump-device faults. These are the patterns that show a part is wearing out before it fails completely. If they go undetected, a disk, memory module, or storage path can fail without warning and take the system down in an unplanned outage.
# errpt -a -s <cutoff> none in 7 days
This control reads the last seven days of the AIX error log and decodes the error labels against a table of known-critical hardware and storage labels. It flags any disk or logical-volume subsystem that is failing repeatedly or permanently. If it fails, a degrading disk or storage component keeps logging errors until it fails outright, turning a repairable fault into an unplanned outage.
# errpt -a -s <cutoff> no non-informational errors in 7 days
This control checks that every AIX paging space is active and the same size, so the system spreads memory paging evenly across all of them. If one space is smaller or inactive, paging piles onto the remaining spaces and the system can run short of usable paging capacity and slow or stop under memory load, even when total paging space looks sufficient.
# lsps -a single paging space defined; multi-space parity not applicable
This check reviews where a system keeps its paging space, the disk area used when memory runs low. If several paging spaces share one physical disk, or all paging space sits in the system volume group while other disks are available, the disk becomes a single point of contention and cannot work in parallel. Under heavy memory demand the system can slow sharply or stop responding, interrupting service.
# lsvg -o 1 paging space(s), no single-disk contention Total paging 512MB vs 4096MB RAM.
Mirroring keeps a second copy of data so that if one disk fails the system can keep running from the other. This control checks that mirrored copies are actually stored on separate physical disks rather than stacked on the same disk. If both copies sit on one disk, a single disk failure destroys both, so the mirror offers no real protection.
# lsvg -o rootvg 32MB PP, 639 PP/disk
This check confirms the system timezone (TZ) is set explicitly in /etc/environment, so logs, scheduled jobs, and timestamps reflect the correct local time. If it is unset, the system may record ambiguous local times, which can confuse audit trails and make incident review unreliable.
# grep '^TZ=' /etc/environment TZ=CST6CDT
This control checks the AIX Update Access Key expiry date reported by the operating system. The key is a Power10-and-later entitlement; earlier hardware does not carry one. If the key expires, the system silently blocks installing AIX levels released after the expiry date and can stop a live partition migration to a destination that requires a newer entitlement.
# lparstat -u n/a (Power10+ only)
Not applicable to this platform variant.
This control reads the installed OpenSSL and OpenSSH fileset versions on an AIX or VIOS system and flags any OpenSSL release older than the 3.x line. OpenSSL versions before 3.0 have reached the end of upstream support, so a system running them stops receiving current security fixes for its cryptographic stack. If the installed levels cannot be read, the state of that stack is unknown.
# lslpp -qcL openssh.base.server openssl.base openssh 9.9.3015.2000, openssl 3.0.16.1000
This check confirms that a fully-mirrored rootvg lists at least two normal-mode boot devices, so the box can still boot from the surviving mirror copy after a disk is lost. It only applies when rootvg is fully mirrored across two or more disks -- on an unmirrored box it reports not-applicable, and when the boot list cannot be read (for example when not running as root) it warns. A rootvg whose layout probes fail to return a readable layout is not assessed.
# lsvg -p rootvg rootvg not fully mirrored (NPV=1, MIRR=none)
Reason not typed by the check.
This check confirms the AIX error-logging daemon is running and that its error log is large enough to keep a reasonable history of hardware and software failures. If the daemon is stopped, new errors are never recorded, so failing hardware or software can go unnoticed until an outage occurs. If the log is too small, older entries are overwritten quickly and evidence of an earlier fault can be gone before it is investigated.
# ps -e -o comm errdemon running; errlog 1048576 bytes, duplicate-removal true
This check reports the state of the PowerHA (HACMP) high-availability cluster on an AIX system, but only when the PowerHA cluster filesets are actually installed. A cluster that is not in the ST_STABLE state cannot fail over, so the standby node that is supposed to take over when a node dies will not, and the outage the cluster exists to prevent is exactly what happens.
# lslpp -L cluster.es.server.rte PowerHA not installed -- cluster.es.server.rte absent (lslpp rc=1); no cluster state to report
Component not installed on this system.
This control checks that the AIX dump device is large enough to hold a full system dump for the amount of memory the LPAR has. The operating system writes the contents of memory to this device when it crashes, so support staff can diagnose the cause. When the device is too small, a crash dump is cut short and the evidence needed to explain the failure is lost.
# sysdumpdev -l device 4096 MB covers estimated dump 1381 MB
This check confirms the boot image on a system is current with the kernel that is installed. After a kernel update, if the boot image was not rebuilt, the machine can start up running the old kernel or fail to start at all. The check flags systems whose kernel is newer than their last boot, which means a reboot is pending and the boot image may be stale.
# lslpp -h bos.mp64 booted Aug 14, after kernel bos.mp64 install 11/21/25
This check verifies that every Shared Ethernet Adapter on a VIOS is configured to fail over to its partner VIOS: ha_mode is auto or standby, a control channel (or a CAA cluster) is in place to arbitrate the primary/backup roles, and each side has a priority. Without that, one VIOS is a single point of failure for every client LPAR bridged through its SEA -- when it goes down, the network goes down with it.
# ioscli cluster -status no Shared Ethernet Adapter (SEA) present
Reason not typed by the check.
This check reads the error counters on each Fibre Channel storage adapter, counting CRC errors, link failures, and loss-of-sync events recorded since the last boot. Rising counts point to failing cabling, optics, or a switch port, which can corrupt or stall the storage traffic the server depends on. If it fails, storage access can slow, drop, or go down entirely, and data in transit may be lost.
# lsdev -c adapter virtual FC adapter: counters not exposed to the client LPAR
Reason not typed by the check.
This check verifies that every virtual SCSI host adapter (vhost) on a VIOS has a live backing device, so the client LPARs mapped to them are actually being served their vSCSI disks. A vhost with no virtual target device, or a target left "Status Defined" (offline), means a client LPAR disk is not being served -- usually left behind by a rebuild or a failed backing hdisk.
# ioscli lsmap -all no vhost lines from 'ioscli lsmap -all'
Reason not typed by the check.
This check confirms whether quorum is enabled on a fully-mirrored rootvg. On a 2-disk mirror, QUORUM=2 can keep the surviving disk from varying on at boot after a disk failure, so most shops disable it (chvg -Qn rootvg). Reports PASS when quorum is disabled, WARN when it is enabled, and NOT_APPLICABLE when rootvg is not a full mirror.
# lsvg -p rootvg no mirrored rootvg (NPV=1, MIRR=none)
Reason not typed by the check.
<div class="prov">
<div>DATA SOURCES</div>
<div class="provrow"><span class="chip src">cisa-kev</span> <span class="provmeta">live-fetched · as of 2026-08-27 · 2d</span> <span class="provsha" title="downloaded">downloaded</span></div>
<div class="provrow"><span class="chip src">ibm-apar-csv</span> <span class="provmeta">live-fetched · as of 2026-08-25 · 4d</span> <span class="provsha" title="downloaded">downloaded</span></div>
<div class="provrow"><span class="chip src">ibmi-psp-group-levels</span> <span class="provmeta">live-fetched · as of 2026-08-18 · 11d</span> <span class="provsha" title="downloaded">downloaded</span></div>
<div class="provrow"><span class="chip src">ibm-flrt-firmware</span> <span class="provmeta">live-fetched · as of 2026-08-28 · 1d</span> <span class="provsha" title="downloaded">downloaded</span></div>
</div>