Unsecured FTP, ODBC, and remote command exit points

What Happened

IBM i network server exit points, covering FTP, ODBC, JDBC, DDM, remote command and others, ship with nothing registered on them. Object authority still applies, so this is not an open door, but without an exit program or a network security product there is no granular control over who uses those routes and no log worth reviewing afterwards.

An exit point is simply a defined place where the operating system will call a program of yours before it allows a server request to proceed, giving you the chance to inspect it, permit or refuse it, and record it. IBM provides the hook on every relevant server. What IBM does not provide is the program, so on a default system the hook exists and is empty.

Menu security is what made this into a widespread exposure rather than a technicality. For years, restricting a user to an initial menu and setting LMTCPB(*YES) genuinely was a boundary, because a green screen was the only way onto the machine. That stopped being true a long time ago. ODBC, JDBC, FTP, DDM, remote command and Access Client Solutions all reach the data without ever loading a menu.

The practical version on a modern system: reporting tools and spreadsheets connecting straight to the database, integration jobs moving files over DDM, transfers running over FTP, and all of it authorized by object authority alone with little or no record that anyone reviews.

Why It Matters

A user with object authority to query a file interactively can usually pull that same file through ODBC or FTP. That bypasses application-level and menu-based controls completely, and typically produces no log entry anybody looks at. The authority model is being honoured exactly as configured, which is the uncomfortable part: nothing is malfunctioning.

The missing log is the half that hurts later. You cannot investigate what was never recorded. When a question does arrive, whether from an auditor, a customer, or an incident, the absence of exit point logging is what turns a question you could have answered in an hour into one you cannot answer at all.

This finding also compounds with the other two that assessments keep reporting. Excessive *ALLOBJ gives a profile access to everything, default or shared passwords make that profile reachable, and an unlogged network route is how the data actually leaves. Any one of the three is a finding. Together they are a working method, which is why they should be read as one problem rather than three.

One honest caveat about sequencing. Exit point control is the single change most likely to break a legitimate integration, because you will discover dependencies nobody documented. That is an argument for a monitoring phase before an enforcement phase, not an argument for leaving it alone.

Recommended Actions

• Inventory which network servers are genuinely in use, covering FTP, the host servers behind ODBC and JDBC, DDM and DRDA, and remote command, before deciding what to restrict
• Register exit programs on those exit points, or deploy an exit point control product rather than writing and then maintaining your own indefinitely
• Run in monitor-only mode first and review what real users and integrations actually do, so enforcement does not break month-end processing
• Read the exit point logs on a schedule. Configuring logging once and never reviewing it produces compliance without producing security
• Restrict remote command and DDM to named administrators and specific service accounts, not to groups that happen to include them
• Close or disable servers you are not using at all, since an unused server is far easier to switch off than to police
• Forward exit point activity to your SIEM so network access to IBM i is reviewed alongside everything else rather than in isolation
• Re-check after every operating system upgrade and after any new integration project, because a new project will cheerfully open a route you closed last year

Sources

• IBM i exit point documentation
• IBM i host server and network security reference