IBM i SIEM Security Events for Monitoring

IBM i SIEM Security Event Logs for Monitoring
Companies using Splunk, QRadar or any other SIEM to monitor security incidents, of which also run core business applications on an IBM i, should be forwarding specific data sets and event log sources to their SIEM. Most companies with an IBM i (AS400 or iSeries), often have their most critical business applications running on it, yet the AS400 is commonly the last platform to be added to the SIEM. Security Operation Center Administrators and Architects often underestimate the importance the AS400 and its underlying applications are to their company, or disregard it due to a lack of knowledge. However this ought not to be the case, since the right IBM i software can enable real time event log forwarding in just a few minutes and with very little effort.

There are a core set of recommended IBM i security data streams or event log sources that should be forwarded to your SIEM, depending on the company’s compliance requirement or operational use case. Most security and compliance related objectives will require multiple audit log sources, and may require changing system, user and object audit settings before the IBM i can forward the necessary data sets.

Most SIEMs today can ingest almost any event log source out of the box, where the log data is structured such as Key-Value Pairs KVP and Java Script Object Notation JSON, and some SIEMs prefer the more prevalent Common Event Format CEF or SYSLOG RFC5424 formats, and a few have special formats that work best, such as QRadar Log Event Extended Format LEEF or LogRhythm’s proprietary LOGR. Without the correct formatted logs, SIEMs such as Splunk and QRadar cannot parse and index IBM i data streams, effectively preventing SIEM automation features required to analyze and transform the AS400 event logs into functional searches, alerts and dashboard displays.

Companies using Splunk or IBM QRadar for security incident response or compliance, is a perfect example where functional log sources require the fields to all be mapped accurately in order to trigger automated responses, and is even more critical for Enterprise customers that rely on UBA and other AI features for real-time threat detection or integration with Endpoint Security EDR Solutions. Ransomware and other forms of malware that can damage the IBM i Integrated File System IFS files need to be protected with IBM i Multi-Factor Authentication MFA, but the AS400 also be forwarding these events to the SIEM. Furthermore, if the AS400 IFS is being scanned by Antivirus, the MSGQ scans should also be forwarded to your SIEM.

Odds are, your SIEM team does not have a good understanding of IBM i system security, auditing or its underlying architecture, so selecting the correct SIEM integration tool should be a number one priority. IBM i log forwarding tools for SIEM should not only deliver the correct log format to ingest, the data should make sense to the SIEM team. Another key area of concern is if the vendor keeps up with the changes and additions IBM makes with each new release, to ensure their log sources and data sets stay in synch.

Below are the most common IBM i SIEM security event log forwarding sources recommended for security requirements can be provided based on the compliance initiative. IBM i event log sources and data streams for IT operational analytics ITOA and other specific use cases such as Ticket System integration can also be provided.

QAUDJRN - system security audit journal containing high level events.
Exit Points - application server logs captured by exit programs that monitoring network activity, such as FTP, ODBC, JDBC, RMTSQL, RMTCMD, Pass Through, DRDA, DDM, Signon, Telnet and other host server connections and network commands.
DB2 Database - record and file entries of journaled files, containing user access and changes to database files or tables, of which can include before and after field level changes.
QHST message queue - history log of system, subsystems, objects, devices, traces and other operator messages
SQL Statements - interactive SQL, QSHELL database functions and embedded SQL usage
3rd Party Applications - software packages often have their own log files stored in flat files in the Integrated File System IFS or a DB2 file
Privilege Access Management PAM - users performing profile swaps and adopting authorities for tasks requiring elevated authorities.
Multi-Factor Authentication MFA - users signing onto system with additional security
File Integrity Monitoring FIM -
Static data - user profile details, system values, authorities, objects, file system and other system properties
Performance data - CPU, memory, disk, I/O, job, response times, bandwidth and other resource utilization and critical operational health statistics
Lesser known and Open Source Interface - applications accessing system via lesser known protocols, such as Open Query, Non-SQL Query interfaces, Non-Database Query, Process Extended Dynamic SQL, XCOM, Operations Navigator, Call Level Interface (CLI), JSON and Node.js
OS400 Firewall and Sockets - network traffic over ports and secure protocols not audited or logged by system or exit programs.

Note: If your system has any sensitive, confidential or like data that needs to be protected, it would be wise to use IBM i encryption, masking, scrambling or tokenization data in scope, prior to forwarding the DB2 journal data to your SIEM.

IBM i iSeries AS400 IFS Security, Endpoint Security and Incident Response
In order to respond to security threats, your SIEM must have visibility of the entire IT infrastructure, including user environmental data and specific event types from event log sources. When security incidents involve users with access to the IBM i, analysts must be able to quickly assess which resources are exposed and have the greatest impact to the business. Analysts must be able to make quick decisions to isolate the threats and prevent further damage. If the AS400 has MFA enabled for the File Server, IFS resources with mapped network drives or NFS are well protected and not likely to be damaged by ransomware and other forms of malware. IBM i systems without IFS MFA protection will require analysts to conduct a deep threat analysis and investigate the IBM i user profile’s authorities to IFS directories and files if network file shares are present, and examine the File Server exit program event logs or Object Changes pertaining to the affected users.

There are various ways to forward IBM i data streams, user profile details, authorization lists, object authorities and other environmental and security data to Splunk, but the raw data will be useless if Splunk’s data pipeline cannot normalize the fields for parsing and indexing in which the searches, alerts and dashboards rely on. If the security analysts and SIEM operators have zero to no familiarity of the IBM i architecture and its underlying security schema, the format of the AS400 data streams forwarded to Splunk will be crucial. Even some of the most experienced IBM i administrators are not familiar enough to know or remember which system events correlate to specific security audit entries.

For example: Assume Chester Underhill was a victim of a ransomware attack. Does Mr. Underhill’s profile have write authority to IFS directory that is also a Network File Share NFS? Does the directory contain sensitive or critical data? Does Mr. Underhill’s application server access logs confirm the files within the directory have been compromised or damaged? Are there any other discoverable IFS directories that also impose a risk from Windows Network Neighborhood? Do the IBM i administrators need to block File Server Delete, Rename and Move functions to any IFS directories, or temporarily remove any IFS shares from the network? SIEM operators and security analysts without IBM i experience require simple to understand, actionable intelligence to quickly respond to security incidents. Therefore predefined search filters for incident specific logs, alerts and dashboards are needed to efficiently identify all IBM i resources in scope for isolating and locking down a threat.

Before Splunk can begin monitoring AS400 security events, the correct auditing and journaling must be enabled. At a minimum, most compliance regulations will require the following QAUDJRN system auditing to be enabled (some for in scope user profiles at a bare minimum): *AUTFAIL - Authorization Failures, *CMD - Commands, *CREATE - Creating Objects, *DELETE - Delete Objects, *JOBDTA - Job Tasks, *NETCMN - Network Communications, *OBJAUD - Object Auditing, *PGMFAIL - Program Failures, *SAVRST - Save and Restore Operations, *SECURITY - Security Tasks, *SPLFDTA - Spoolfile Operations and *SYSMGT - System Management Tasks.

Any user profiles with special authorities or that inherit authorities from a group profile will likely need to be flagged in audit logs for various audit scrutiny and tracking. This level of enhanced logging is perhaps a unique feature to some AS400 tools, but can be extremely useful to a SIEM team when performing investigations and analysis. AS400 log forwarding tools that can enrich event logs with contextual information such user’s authorities and asset class details or add descriptions in layman’s terms such as Superuser where a profile possesses *ALLOBJ, *SECADM or other special authorities.

If your SIEM’s cost and performance are of no concern, it is very easy to simply send all AS400 logs to your SIEM. However it is likely best to only send relevant logs and data sets required or that are relevant to your company’s use cases. The AS400 produces an immense amount of data or event logs that can drown many SIEMs. Unless the SIEM is serving as a system of record for long term data archiving, sending all logs will unnecessarily increase your SIEM license costs, especially if the SIEM uses a pricing model like Splunk. Not to mention, sending all events will likely incur performance penalties for SIEM operators, and potential network bottlenecks.

Recommended IBM i logs for SIEM Security & Compliance Use Cases
The most critical IBM i event log source for all SIEMs to ingest are QAUDJRN events. The security audit journal captures general user, object and system related security events that will serve as one of your primary forensic sources for triggering alerts and investigating threats. Below are the minimum recommended QAUDJRN action types that should have auditing enabled and sent to your SIEM:

AD Auditing Changes
This audit group consists of configuration changes that effect system, object or user auditing, and is captured by AD action type under the *SECURITY, *SECCFG or *CHANGE action group depending on the type of auditing enabled, of which includes only a handful of specific action types.

AF Authority Failures
Consists of user violations, validation, authentication errors and unauthorized attempts to access information, TCP/IP ports, hardware, java, invalid tokens, use of secured commands, object failures and other authority failure events. AF actions usually fall under the *AUTFAIL group, but a few can be categorized as *PGMFAIL depending on the type of auditing, of which the Authority Failure group contains over 20 different action types.

AU Enterprise Identity Mapping EIM Configuration
This Enterprise Identity Mapping action can fall under *SECURITY *SECCFG *CHANGE *CREATE or *DELETE depending on the type of auditing enabled and action where an Add, Change or Remove occurred, and it only pertains to IBM i environments that have implemented IBM’s Enterprise Identity Mapping for Single Sign-On SSO using Kerberos.

CD Command String Audit
The *CMD commands grouping shows the specific command that was run by user, and whether it was run from the command line or via a CL program.

CO - Created Objects
The *CREATE action group provides a handful of auditing types that will explain which users created an object on the system, such as user profiles, directories, files, new programs, object attribute changes and other operations. New object auditing information will be useful for various security tasks.

CP - User Profile Changes
User profile changes fall under the *SECURITY or *SECCFG group depending on type of auditing enabled, of which needs to be monitored for many obvious reasons, but security analysts and SIEM operators should also pay specific attention to special authorities, and understand how powerful authorities and other profile settings affect a user’s capabilities on the IBM i.

CY - Cryptographic Configuration Change
IBM i environments with DB2 database or file encryption services running should forward these event logs to the SIEM, as well as forward the logs of the third-party software tools such as Enforcive and Assure Security that are used to perform IBM i field encryption, decryption, masking, scrambling and tokenization functions performed on the DB2 database or IFS Files. Cryptographic Configuration Changed appear in QAUDJRN groups *SECURITY or *SECCFG group depending on type of auditing enabled.

DO - Deleted Objects
Everything on the IBM i platform is considered an object, and this group of actions is small as it has one specific focus, to capture anything deleted, such as files, folders, profiles, programs, journals, receivers, or another object type that is removed from the system except QTEMP library. Deleted Objects fall under the *SECURITY, *SECCFG or *DELETE group depending on type of auditing enabled. If a user has Write access to a mapped network drive or NFS File Share, and the user was a victim of a ransomware or malware attack, hopefully your IBM i system security journal has this auditing enabled, and hopefully you do not see any DO events in QAUDJRN.

DS - DST Profile Changed
IBM i Service tools provides functions for diagnosing system problems, managing storage, and configuring system resources and managing security, of which this audit group captures any changes and function usage of this tool, as well as the user IDs that are able to access it. DST Profile Changes appear under the *SECURITY or *SECCFG group depending on type of auditing enabled.

IM - Intrusion Monitor
OS400’s built-in intrusion detection and prevention system (IDS) logs TCP/IP network activity for attempts to hack into the IBM i, and disrupt or deny service to the system, and other such activities, such as data exfiltration, and other types of attacks in which your IBM i might be used as the source of an attack. When potential intrusions are detected, they will appear under the *ATNEVT group.

JS - Actions that Affect Jobs
Contains logging details of all job activity, including jobs starting, ending, changes, submitting, put on hold, completing, releasing actions which impact of all job types and for all subsystems. Depending on type of auditing enabled, Actions that Affect Jobs will appear in the *JOBDTA or *JOBBAS group.

LD - Link, Unlink or Look up Directory Entry
Any Deleting, Linking, Unlinking or Looking up Directory entries see in QAUDJRN under *OBJAUD, *DELETE or *CHANGE groups depending on type of auditing enabled. If a user has Write access to a mapped network drive or NFS File Share, and the user was a victim of a ransomware or malware attack, hopefully your IBM i system security journal has this auditing enabled, and hopefully you do not see any LD events in QAUDJRN.

NA - Network Attribute Changed
Changing of a network attributes appear under the *SECURITY or *SECCFG group depending on type of auditing enabled.

OM - Object Move or Rename
Any object rename or moves will be see in QAUDJRN under *OBJMGT or *CHANGE group depending on the type of auditing enabled, which include IFS files. If a user has Write access to a mapped network drive or NFS File Share, and the user was a victim of a ransomware or malware attack, hopefully your IBM i system security journal has this auditing enabled, and hopefully you do not see any OM events in QAUDJRN.

OR - Object Restores
Object restore events mean either a new object was restored to the system or one replaced an existing object. Object Restores appear under the *SAVRST or *CHANGE group depending on the type of auditing enabled.

OW - Object Ownership Changed
Changing object ownership events appear under the *CHANGE, *SECURITY or *SECRUN group depending on the type of auditing enabled.

PA - Program Changed to Adopt Authority
Program changed to adopt authority appear under the *SECURITY or *SECCFG group depending on type of auditing enabled.

PG - Change of an Object’s Primary Group
These types of events occur when program used adopts the owner’s authority to gain access to an object and falls under the *SECURITY, *SECRUN, *CHANGE and *PGMADP group depending on type of auditing enabled.

PS - Profile Swap
Profiles swapping events appear under *SECURITY or *SECVFY group depending on the type of auditing enabled.

PW - Invalid Passwords
PW events occur when users enter an incorrect password or use an incorrect user name, and when profiles are disabled as a result of too many failed signon attempts which is in excess of the system value parameter for maximum signon attempts. Invalid password events appear in QAUDJRN under the *AUTFAIL group.

RU - Restoring User Profile Authority
The RSTAUT command will restore a user’s authority and will create a RU event under the *SAVRST group.

SE - Subsystem Management Changes
A subsystem routing entry change will create a SE event in QAUDJRN under the *SECURITY or *SECCFG group depending on type of auditing enabled.

SM - System Management Tasks
The system management *SYSMGT contains over 30 different actions that should be monitored by administrators, of which only a few pertain specifically to security.

SO - Server Security User Information Actions
Add, change and removes appear under the *SECURITY or *SECCFG group depending on type of auditing enabled.

SV - System Value Changes
Changes to system values appear under the *SECURITY or *SECCFG group depending on type of auditing enabled.

VA - Access Control List Changed
Changes to an access control list appear under the *SECURITY or *SECCFG group depending on type of auditing enabled.

VU - Changing a Network Profile
Network profile changes appear under the *SECURITY or *SECCFG group depending on type of auditing enabled.

VV - Changing Network Service Status
Network service status changes appear under the *SERVICE group.

ZC - Object Accessed (Change)
Object Changes appear under *OBJAUD or *CHANGE group depending on type of auditing enabled.

ZR - Object Accessed (Read)
Object Reads appear under *OBJAUD or *CHANGE group depending on type of auditing enabled.

Perhaps equally as important, are user network access event logs (a.k.a. exit points, application servers and ports listening). Exit programs monitor and control how users access the IBM i, its libraries, IFS files, Network File Shares NFS and other objects on the system when a user connects via TCP/IP over IBM i exit points. Exit programs can function very much like a firewall, where policies defined determine which users may use or access the system via the exit point, and which functions can be used and which IBM i resources or objects can be accessed, such as all files in a library and only specific files.

Forwarding exit program audit logs to your SIEM is important for a number of reasons. For one, exit programs capture user activity QAUDJRN and database journals do not, such as commands run over TCP/IP, and application specific operations such update, delete and like functions performed by a JDBC/ODBC application or download and upload functions performed by an FTP process, or deleting and renaming of NFS files on the IFS. Whereas the IBM security audit journal (QAUDJRN) may only show action of read, access or opening of a file, when in reality the user actually downloaded the file to his PC using MS Excel or Client Access Data Transfer utility. At a minimum, it is recommended to use exit programs to monitor most commonly used applications by users, and forward these network event logs to your SIEM.

Centeral Server: QIBM_QZSC_LM, QIBM_QZSC_NLS and QIBM_QZSC_SM
The Central Server exit is used for some types of connections and data mapping operations when an application or client connects to the IBM i server where license management and conversion map retrieval services are required. The License management function performs the initial request from either Data Transfer or PC5250, of which reserves a license for the Client Access user connecting to the IBM i. The Client Server connection remains active until the release delay timeout expires, and the license in use will be held until it is released or the server job is ended. The Central Server Retrieve conversion map function are often used for when an application or client requires ASCII to EBCDIC and EBCDIC to ASCII conversions.

Database Server Entry: QIBM_QZDA_INIT
The database server is perhaps one of the most widely used services by client applications such as Microsoft, IBM and many third party products, and enables computers to use functions included with IBM DB2 Universal Database for IBM i, including remote SQL access, ODBC, JDBC, ADO, OLE DB, .NET and Distributed Relational Database Architecture DRDA access. The Database Server Entry exit is used for the Database Server Logon function.

Database Server Access: QIBM_QZDA_NDB1
Is called for native database requests and is used for the following functions: Create source physical file, Create database file 'based on existing file', Add/clear/delete database file member, Override database file, Delete database file override and Delete file.

Database Server Object Information: QIBM_QZDA_ROI1
Called for requests that retrieve information about certain objects by the database server, such as SQL catalog functions. Information retrieved include: Library or collection, File or table, Field or column, Index, Relational database or RDB, SQL package, SQL package statement, File member, Record format and other special columns.

Database Server SQL Access: QIBM_QZDA_SQL2
Called when ODBC, JDBC, File Transfer, OLEDB, .NET applications like Excel, MSAccess, iNav, Access Solutions and others run SQL requests, such as: Prepare, Open, Execute, Connect, Create package, Clear package, Delete package, Stream fetch, Execute immediate, Prepare and describe, Prepare and execute or prepare and open, Open and fetch, Execute or open, Return package information.

Data Queue Server: QIBM_QHQ_DTAQ
Exchanges using data queues between the IBM i and other systems. A data queue is an object that is used by application programs for communications. Applications can use data queues to pass data between jobs. Multiple system jobs can send or receive data from a single data queue. Data queues can be used to communicate between IBM i machines, to trigger jobs, and to transport data to and from websites. IBM Client Access program provides APIs that can allow applications on a PC or workstation to work with system data queues with the same ease as native applications. This extends the computer’s application communications to include processes running on a remote PC. Often used in java client/server applications to intercommunicate between the PC client and the IBM i server. Another source of data queue APIs is the IBM Toolbox for Java - a library of Java classes supporting the client/server and internet programming model to an IBM i system.

DDM and DRDA: A custom Exit Program is required
The DDM and DRDA application server allows client computers access to the functions included with DB2 UDB for IBM i, providing support for remote SQL access, record level access and remote journal, for example IBM’s DB2 Connect and StartQuest’s StarSQL. DDM Functions: Add Member, Change, Change Data Area, Change Member, Clear, Clear Data Queue, Command, Copy, Create, Delete, Extract, Initialize, Load & Unload, Lock & Unlock, Move, Open, Recieve Data Queue, Rename, Rgzmbr, Remove Member, Rename Member, Retrieve Data Area, Send Data Queue.

FTP Server Logon: QIBM_QTMF_SVR_LOGON
FTP server session authentication, and FTPS explicit over port 21 and FTPS implicit over port 990.

FTP Server Request Validation: QIBM_QTMF_SERVER_REQ
FTP Server functions, such as: CL Command, Create Lib, Delete File, Delete Library, List Files, Receive files a.k.a. PUT or Upload, Rename Files, Send Files a.k.a GET or Download, Set Directory and Profile Swap

FTP Client Request Validation: QIBM_QTMF_CLIENT_REQ
FTP Client functions, such as: CL Command, Create Lib, Delete File, Delete Library, List Files, Receive files a.k.a. GET or Download, Rename Files, Send Files a.k.a PUT or Upload, Set Directory and Profile Swap

File Server or Integrated File System IFS: QIBM_QPWFS_FILE_SERV
IFS access for example: iSeries Navigator, Map Network Drive from Windows Explorer with NFS functions: Allocate Conversation, Change File Attribute, Rename, Create File/Directory, Open Stream File, Delete File/Directory, Move and List File Attributes. The file server allows network clients to store and access files, programs and other information on the IBM i server. The IBM i file server interfaces with the IFS (integrated file system) on the server. The file server can give client applications on remote PCs access to all of the IBM i file systems.

File Transfer: QIBM_QTF_TRANSFER
The PCS400 file transfer functions available send files back to and get files from the IBM i. The legacy or original file transfer protocol is a host-based SNA protocol to transfer files between a PC and IBM I, and includes the following functions: Select, Join, Replace and Extract.

Open Database File Exit Program: QIBM_QDB_OPEN
If used, the Open Database File exit program can monitor and control access to DB2 Files for users trying to perform Reads, Adds, Updates or Deletes from green screen or via the network. Alternatively, the exit program can extend the monitoring and access controls of DB2 Files based on the interface type, such as Interactive SQL STRSQL command, SQL interfaces, Query interfaces, Open Query OPNQRYE, Non-SQL Query Interfaces, ODBC and JDBC Database Host Server, Call Level Interface CLI, Process Extended Dynamic SQL, non-Database Query and XCOM.

Network Commands: QIBM_QCA_CHG_COMMAND
Any command on the system, IBM or commands provide by third-party software vendors can be monitored and controlled when accessing the IBM i via TCP/IP.

Network Print: QIBM_QNPS_ENTRY
Used by Operations Navigator and other applications and allows the viewing of IBM i spool files on the PC, provides remote print support and additional print management when using Client Access functions. The OS/400 network print server allows enhanced client control over print resources on the IBM i server. This print server provides the following capabilities to each client by requesting print serving: Spooled file > Create, seek, open, read, write, close, hold, release, delete, move, send, call exit program, change attributes, retrieve message, answer message, retrieve attributes and list / Writer job > Start, end, and list. / Printer device > Retrieve attributes and list / Output queue > Hold, release, purge, list, and retrieve attributes / Library > List / Printer file > Retrieve attributes, change attributes, and list / Network print server > Change attributes and retrieve attributes.

Pass-through and Remote Signon: A custom Exit Program is required
The Pass-through service uses the SNA protocol and is primarily used for signon connection between two IBM i systems, but can also be used for SNA-based emulation provided by some 5250 emulation software.

Profile Changes: QIBM_QSY_CHG_PROFILE
Profiles Deleted: QIBM_QSY_CRT_PROFILE
Profiles Restored: QIBM_QSY_RST_PROFILE
These three all require a custom Exit Program. There are times where user profile changes or deletions occur in which the QAUDJRN does not provide the information required to understand who, where or what caused the change. These exit program help augment the audit trail with additional details, and can often help restore the profile back to the way it was previously.

Remote SQL Server: QIBM_QRQ_SQL
The Remote SQL server QXDAEDRSQL allows remote computer access to the functions included with DB2 UDB for IBM I, such as remote SQL access, access to DB2 files through the XDA interface, and provides the following database functions: Connect, Delete, Update, Execute, ExecutePM, Select, SelectPM, SelectVal, RMTCALL, SelectPkg, ExecPgk, CreatePkg and PreptoPkg.

Remote Command and Remote Program Call: QIBM_QZRC_RMT
The remote command and distributed program call server support allows users and applications to issue system commands and call programs. The distributed program call support allows applications to call native programs and pass parameters (input and output). After the program runs on the server, the output parameter values return to the client application. This process allows applications to access system resources easily without concerns about the communications and conversions that must take place. It is used by Operations Navigator and other applications to perform these two functions: RMTCMD & RMTPGM

REXEC Server Logon: QIBM_QTMX_SVR_LOGON
The TCP/IP server logon exit point provides additional control over authenticating a user and setting up the user's environment for the REXEC server. Called for additional control over authenticating a user and setting up the user's environment for the REXEC server. The Remote Execution REXEC server is a TCP/IP application that allows a client user to submit system commands to a remote system. The Remote Execution protocol allows processing of commands or programs on any host in the network. The local host then receives the results of the command processing. The user's client program sends the user identifier, password, and command to run to the server. The server validates the user, runs the requested command, and returns the results of the command to the client. You run IBM i command processor commands by specifying QCAPCMD as the target of the client REXEC. Qshell command interpreter (IBM i option 30).You can use the Qshell interpreter by specifying qsh as the target of client REXEC. You can run any IBM i program in a "child" (spawned) job by specifying the complete path to the program or shell script as the target of the REXEC command. The remote command and distributed program call server support allows users and applications to issue system commands and call programs. The distributed program call support allows applications to call native programs and pass parameters (input and output). After the program runs on the server, the output parameter values return to the client application. This process allows applications to access system resources easily without concerns about the communications and conversions that must take place. It is used by Operations Navigator and could be used by other clients.

REXEC Server Request Validation: QIBM_QTMX_SERVER_REQ
The Remote Execution (REXEC) server is a TCP/IP application that allows a client user to submit system commands to a remote system. The Remote Execution Protocol (REXEC) allows processing of commands or programs on any host in the network. The local host then receives the results of the command processing. The user's client program sends the user identifier, password, and command to run to the server. The server validates the user, runs the requested command, and returns the results of the command to the client. You run IBM i command processor commands by specifying QCAPCMD as the target of the client REXEC. Qshell command interpreter (IBM i option 30).You can use the Qshell interpreter by specifying qsh as the target of client REXEC. You can run any i5/OS program in a "child" (spawned) job by specifying the complete path to the program or shell script as the target of the REXEC command. The remote command and distributed program call server support allows users and applications to issue system commands and call programs. The distributed program call support allows applications to call native programs and pass parameters (input and output). After the program runs on the server, the output parameter values return to the client application. This process allows applications to access system resources easily without concerns about the communications and conversions that must take place. It is used by Operations Navigator and could be used by other clients.

Telnet Device Initialization: QIBM_QTG_DEVINIT
Telnet Device Initialization is the starting of a telnet session. This point is not related to the sign off process and the opening of a 5250 interactive job on the IBM i. It is triggered when a Telnet device is created on the host of which presents the sign on screen. This exit is useless unless it is paired and integrated with OS400 Signon, which requires a custom program for the SIGNON function.

Telnet Device Termination: QIBM_QTG_DEVTERM
Telnet Device Termination is the exiting or ending of a telnet session. This exit is useless unless it is paired and integrated with OS400 Signoff, which requires a custom program for the SIGNOFF function.

TCP Signon Server: QIBM_QZSO_SIGNONSRV
Signon server authenticates user profiles and passwords received from client applications to signon to the IBM i and also prevents access to the system by users with expired passwords, validates user profile passwords and returns user profile security information for use with password caching, for example IBM i Navigator. Signon Server is perhaps the most heavily used authentication service on the IBM i.

Trivial FTP TFTP: QIBM_QTOD_SERVER_REQ
The trivial file transfer protocol TFTP provides basic file transfer functionality, of which does not require user authentication. TFTP works with either Bootstrap Protocol (BOOTP) or Dynamic Host Configuration Protocol (DHCP) to provide support for some legacy applications and devices.

Some of these services or exit points should not even be in listening mode on your system, but if they are or started in the future without your knowledge, you cannot log, audit and know who is using these services, and how users are accessing your system if you do not have the corresponding exit program activated. If your IBM i is one of your company’s primary workhorses and contains sensitive or critical data, the financial impact of an outage or security breach would be significant. When lockdown mode is engaged for a security breach, operators can afford to be researching systems the SIEM has no visibility. Send these critical event logs to your SIEM and SOC operators can be prepared for the worse.