Exit points: checking who controls network access

Network interfaces FTP, ODBC, JDBC, ACS data transfer, file sharing, DDM, reach the database without traversing application menus. The effective perimeter for those connections is therefore object authority, which on unreviewed systems is wider than any decision would suggest.

Exit points are where that perimeter can be narrowed independently of authorities. With no program registered, the request is always allowed.

Checking what is registered

SELECT EXIT_POINT_NAME, EXIT_POINT_FORMAT, EXIT_PROGRAM,
       EXIT_PROGRAM_LIBRARY, EXIT_PROGRAM_NUMBER
  FROM QSYS2.EXIT_PROGRAM_INFO
 ORDER BY EXIT_POINT_NAME;

The absence of rows for QIBM_QZDA* and QIBM_QTMF* is the most frequent outcome, and indicates that for those interfaces no control exists beyond object authority.

The available points for the two relevant families:

SELECT EXIT_POINT_NAME, EXIT_POINT_FORMAT, TEXT_DESCRIPTION
  FROM QSYS2.EXIT_POINT_INFO
 WHERE EXIT_POINT_NAME LIKE 'QIBM_QZDA%'
    OR EXIT_POINT_NAME LIKE 'QIBM_QTMF%'
 ORDER BY EXIT_POINT_NAME;

QIBM_QZDA* covers database access: ODBC, JDBC, data transfer. QIBM_QTMF* covers FTP. The points in these two families are these:

The query returns more rows than points, because the same exit point appears once per format, and the format determines what information the program receives. QIBM_QTMF_SVR_LOGON has three, and the choice matters: the later formats pass data the earlier ones do not.

The two connection-level points

QIBM_QZDA_INIT is called when the database connection opens, before the request is known. QIBM_QTMF_SVR_LOGON performs the same function for FTP, with three formats available.

The other QIBM_QZDA* points act further downstream: SQL1 and SQL2 on SQL statements, NDB1 on native database access, ROI1 on object information requests.

They act on the session rather than the individual operation: a control at these two points covers everything that follows, with a performance impact independent of request volume. The per-command and per-SQL-statement points allow finer control, at a cost per operation.

Record before filtering

A program that blocks on unverified rules interrupts integrations that were never catalogued: interfaces to the ERP, scheduled extractions, third-party procedures.

The first program to register applies no rules: it always returns authorisation and writes a record with profile, source address, requested function and timestamp. After a complete activity cycle that file holds a documented list of actual usage, which is the precondition for defining rules.

It is the same approach as authority collection for object authorities: measurement precedes restriction.

Example: what the check returns, and what follows from it

The results below are illustrative, shown to convey the shape of the data.

On a system never reviewed, the first query typically returns few rows and none on the families that matter:

EXIT_POINT_NAME      EXIT_POINT_FORMAT  EXIT_PROGRAM  EXIT_PROGRAM_LIBRARY
QIBM_QCA_CHG_COMMAND CHGC0100           MONCMD        TOOLLIB

No QIBM_QZDA* or QIBM_QTMF* rows: for ODBC and for FTP no control exists beyond object authority.

After a month of logging only on QIBM_QZDA_INIT, the collection file holds something of this kind, aggregated by profile and origin:

PROFILE    ORIGIN           CONNECTIONS  FIRST        LAST
GESTIONALE 10.0.4.12                812  02/07 06:00  01/08 06:00
MROSSI     10.0.7.44                 47  03/07 09:12  31/07 17:40
UTE0147    10.0.9.201                 6  05/07 02:15  30/07 02:15
BACKUPSRV  192.168.50.9               4  06/07 23:00  27/07 23:00

The four rows read differently from one another. GESTIONALE from a single address, daily at dawn, is a scheduled integration: blocking it would halt a batch run. MROSSI during office hours is a person using a spreadsheet. UTE0147 at 2 a.m. and BACKUPSRV from a different network are the two rows the analysis starts from, because nobody had catalogued them.

The value of logging first lies here: the first two rows are the rules to write, the last two are the questions to ask, and without a month of data both would have been either blocked or let through.

Commercial products

Commercial solutions exist covering logging, rules by group, reporting and alerting. Where regulatory obligations or periodic audits apply, the value is not the filter itself but the reporting and the ongoing maintenance of the product.

Without those obligations, a logging-only program developed in house answers the question that matters — which profiles access from the network, and through which interface — with limited effort.

The check that precedes everything

Before designing a filter, verify whether the service is needed. An FTP server active on a system that does not use it should be disabled rather than regulated:

NETSTAT OPTION(*CNN)
WRKACTJOB SBS(QSYSWRK)

For FTP, disabling and removing it from automatic start:

ENDTCPSVR SERVER(*FTP)
CHGFTPA AUTOSTART(*NO)

The same check applies to other TCP servers active but unused.

Which versions this works on

Exit points predate SQL services. The QSYS2.EXIT_POINT_INFO and QSYS2.EXIT_PROGRAM_INFO views arrived with IBM i 7.4 TR3 and 7.3 TR9. Previously the same information was reachable with WRKREGINF, which cannot be queried via SQL.

Sources

• IBM — QSYS2.EXIT_POINT_INFO
• IBM — QSYS2.EXIT_PROGRAM_INFO
• IBM i 7.6 Security reference