Skip to main content

Secure InterSystems Processes and Operating-System Resources

Introduction

This document describes how to reduce the potential attack surface available to an intruder by hardening the operating system on which an instance of an InterSystems IRIS® data platform runs. Topics include:

  • The operating system services that an InterSystems IRIS instance requires

  • The various types of InterSystems IRIS processes, along with the purpose of each

  • Methods for identifying the function of InterSystems IRIS processes in a running instance

  • How to remove or disable optional InterSystems IRIS processes that your site may not need

  • Processes required by an instance that is running, in addition to either the iris process on UNIX® or the irisdb.exe process on Windows

  • The TCP and UDP ports for InterSystems IRIS processes, along with the purpose of each

InterSystems IRIS Processes

Most processes comprising an InterSystems IRIS instance use the iris executable on UNIX® and the irisdb.exe executable on Windows, and each of these files resides in the bin directory under the installation directory. A running instance uses a number of system processes to coordinate and support the processes running user code. InterSystems IRIS processes can be examined in the Management Portal under System Operation > Processes.

Core Processes

Core system processes are started early in the initialization of an instance and have no value in the User column. You can identify these processes by the value in the Routine column which, in the case of system processes, does not always contain the name of an InterSystems IRIS routine. The Routine column lists the following core system processes by name:

  • CONTROL — Creates and initializes shared memory and provides various control functions.

  • WRTDMN — Performs all writes to databases and WIJ (the write daemon).

  • GARCOL — Garbage collects large kills.

  • JRNDMN — Performs journal writes.

  • EXPDMN — Performs database expansions.

  • AUXWD — Performs write daemon tasks (write daemon auxiliary workers).

  • MONITOR — Writes alerts to the alert file and transmits email alerts.

  • CLNDMN — Detects dead processes and cleans up stranded resources.

  • RECEIVE — Manages ECP worker processes.

  • ECPWork — Performs ECP tasks (ECP worker process).

  • %SYS.SERVER — Accepts TCP requests and dispatches workers to serve them (the superserver process).

  • %CSP.Daemon — Manages expiration of web sessions.

  • LMFMON — Monitors the InterSystems IRIS license and sends usage data to the license server over UDP.

  • %SYS.Monitor.xxx — Performs system monitor tasks (various system monitor workers).

  • SYS.Monitor.xxx — Writes alerts to alert file and transmits email alerts.

Do not stop the core system processes. Doing so disrupts the normal operation of an InterSystems IRIS instance.

A number of other InterSystems IRIS system processes are started after the core system processes. Many are started dynamically. These processes have a value displayed in the User column. Many of them are optional and are not started unless needed or configured. These processes can usually be identified by the values of the Routine, User, and Client EXE columns of the process display.

The task manager process (TASKMGR) is created during instance startup. It starts various scheduled system and user defined tasks and runs with the settings:

  • Username = TASKMGR

  • Routine = %SYS.TaskSuper.1

  • Operating System Username = TASKMGR

If you are not using ECP, you can prevent the ECPWork process from being started:

  1. From the Management Portal, select System Administration > Configuration > Connectivity > ECP settings and set the maximum number of application and data servers to zero.

  2. Disable the ECP service.

ECP Server Processes

ECP server processes that are dynamically started have a routine name beginning with “ECP”. The user name or Operating System Username is usually Daemon or %System, but it may be the name of the Instance Service user on Windows. Examples of process names follow:

  • ECPCliR – ECP client reader

  • ECPCliW – ECP client writer

  • ECPSrvR – ECP server reader

  • ECPSrvW – ECP server writer

Web Server Processes

Web server processes are dynamically started. They will display CSPSystem in the User column when they are idle and waiting for a task. When they are active, they will display the InterSystems IRIS user for the web session and the current routine name. The OS Username column will display Web Gateway.

  • %SYS.cspServer and %SYS.cspServer2 – Webserver routines that processes use to handle web application requests.

  • %SYS.cspServer3 – Webserver routine that processes use to handle asynchronous communication and Web Gateway management.

These processes are associated with legacy applications from other InterSystems products. For more details on these routines in those applications, see the question about them in the FAQ for this featureOpens in a new tab.

Note:

These routines do not consume licenses. Licenses are associated with web application sessions.

For each of these servers, on Windows the executable is CSPAP.dll; on UNIX®, it is CSPap.so. The operating system username is Web Gateway. The program name may change as the process changes tasks.

Mirroring System Processes

Mirror system processes are started if mirroring is configured. They perform various functions related to mirroring.

  • MIRRORMGR – Mirror Master. The User is the description of the mirror function performed: Mirror Master, Mirror Primary, Mirror Dejournal, Mirror Prefetch, or Mirror JrnRead. The operating system username is Daemon. No TCP port is open. The device is the operating system null device.

  • MIRRORCOMM – Mirror communication process. The username is Mirror Arbiter, Mirror Backup, or Mirror Svr:RdDmn. The operating system username is Daemon. The device is |TCP|XXX. The TCP port can be determined from the Device name or the Mirror configuration.

IP Protocols

TCP

An InterSystems IRIS instance accepts connections on TCP/IP ports specified by configuration options. Any Operating System restrictions on usage of ports, for example with a fire wall, require port settings to allow inbound access that are consistent with the ports configured for InterSystems IRIS. If the firewall defines rules for executables, as it does on Windows, you may need to grant permission to programs as well, for example, the irisdb.exe, licmanager.exe, ISCAgent.exe, and the httpd.exe executables will require such permissions.

TCP/IP ports used by InterSystems IRIS are defined by the instance configuration. The configured ports can be examined in the iris.cpf file in the installation directory. The [Startup] section configures DefaultPort, DefaultPortBindAddress and WebServerPort. DefaultPort specifies the port on which the superserver accepts connections; the default value is 1972. DefaultPortBindAddress optionally specifies an interface address the superserver binds to. WebServerPort specifies the port on which the private web server accepts connections; the default value is 52773.

The private web server is mostly used in development environments and is not recommended for production environments.

The [SQL] section contains JDBCGatewayPort which defines the Java Database Connectivity (JDBC) gateway port number. Its default value is 62972.

The [Telnet] section contains a Port value to specify the port on which the InterSystems Telnet service (ctelnetd.exe) accepts Telnet connections to InterSystems IRIS on Windows.

UDP

InterSystems IRIS and the license server (licmanager or licmanager.exe) communicate primarily using the UDP protocol. InterSystems IRIS sends messages as UDP packets to the license server port. This port is 4002 by default, and is configured in the Management Portal > System Administration > Licensing > License Servers. The license server replies to InterSystems IRIS at the port that InterSystems IRIS used to send the original message (it looks up the port in the packet header). TCP is only used between InterSystems IRIS and the license server during a query request. InterSystems IRIS opens a TCP port for accept/listen and sends this port number in the query request. The license server connects back to that port and sends the results over the TCP connection. The port number is the license server port; if this fails, it uses port 0 which signals the operating system to select a free port at random. The port is open only during transmission of the query results.

SNMP

The %System_Monitor Service enables InterSystems IRIS to act as a subagent to an SNMP Agent on the managed system. This supports both SNMP requests (GET or GETNEXT) for InterSystems IRIS management and monitoring data (as defined in the supplied MIBs), and SNMP Traps (asynchronous notifications sent by InterSystems IRIS). Disabling the %System_Monitor service will disable all communication between InterSystems IRIS and the SNMP Agent on the local system, and consequently with any remote SNMP manager applications.

HTTP

Refer to the description of the components of the Web Gateway used by InterSystems IRIS to serve HTTP requests by navigating through the online documentation as follows: Documentation > InterSystems IRIS Web Development > Web Gateway Guide > Introduction to the Web Gateway. The private Web Server is httpd.exe (httpd on UNIX®) located in the httpd\bin subdirectory under the installation directory. Startup of the private web server is controlled by the Management Portal > System Administration > Configuration > Additional Settings > Startup > WebServer set to true or false.

Gateways

InterSystems IRIS provides a number of Gateways to external data. These include SQL Gateway, JDBC Gateway, Object Gateways, and XSLT 2.0 Gateway servers. The TCP/IP ports used are defined using the gateway setup pages accessed via the Management Portal > System Administration > Configuration > Connectivity. See the documentation of these gateways for an explanation of Operating System services or processes on which they depend.

Remove Unneeded InterSystems IRIS Processes

InterSystems service processes are not created unless the services they support are enabled and configured. There is no need to take any additional action to prevent InterSystems service processes from running.

External Processes

An InterSystems IRIS instance will start processes running executables other than iris[.exe] to perform a number of functions in support of the instance. Instance specific versions of these executables, which are generally specific to the instance version, live in the bin subdirectory of the installation directory. Executables that may be shared by multiple InterSystems IRIS instances live in a common directory.

Persistent processes may be running the following executables, which live in the bin directory on Windows.

  • irisdb.exe — The InterSystems IRIS executable.

  • licmanager.exe — The InterSystems IRIS license server.

  • CStudio.exe — Studio.

  • iristray.exe — The InterSystems IRIS launcher in the system tray.

  • Iristerm.exe — The Terminal.

  • iristrmd.exe — The local Terminal connection daemon. Accepts local Terminal connections (not Telnet) and creates InterSystems IRIS server processes to serve the connection.

  • irisirdimj.exe — Executable that processes the WIJ file during InterSystems IRIS startup and shutdown.

Persistent processes may be running the following executables, which live in the bin directory on UNIX®.

  • iris — The InterSystems IRIS executable.

  • licmanager — The InterSystems IRIS license server

  • irisirdimj — Processes the WIJ file during InterSystems IRIS startup and shutdown.

Other programs in the bin directory are used from time to time, but the processes are short running and unlikely to be displayed by a process listing for long.

Executable binaries shared by InterSystems IRIS instances reside in subdirectories of C:\Program Files (x86)\Common Files\InterSystems on Windows. The processes may be seen running these executable binaries from the common directory on Windows.

  • ISCAgent.exe – Controls mirror failover.

  • Iristerm.exe – The Terminal.

Shared binaries are usually installed in /usr/local/etc/irissys on UNIX®.

  • ISCAgent* - Controls mirror failover.

In addition to executable binaries, a number of shared library binaries are stored in the common directory.

Interoperability

Adapters

InterSystems IRIS provides communication with external interfaces using adapters.

Email

Email adapters are InterSystems IRIS processes. They use TCP/IP to send/receive email from an email server. Outbound adapters send mail to a SMTP server. Inbound adapters poll for relevant (filtered) messages from a POP3 serve. Email servers are likely to be on a remote server, so while there would be no local process, the remote system would need to be reachable through a firewall

File

File Input Adapters are InterSystems IRIS processes. They periodically inspect a directory they have been configured to monitor, read files that appear there, pass the files to the Business Service they have been configured to support, and move the files to the configured archive directory. The EnsLib.File.InboundAdapterOpens in a new tab class provides the implementation. The FilePath, WorkPath, and ArchivePath properties define the input, temporary work, and archive directories, respectively.

File Output Adapters are employed by production Business Operations to write data to files. The file path and file name are specified by the Business Operation and operations on the file are invoked by calling methods of the EnsLib.File.OutboundAdapterOpens in a new tab class. Messages are usually queued to a worker job that performs the actual output operation. This implies the existence of Ens.QueueOpens in a new tab processes.

FTP

InterSystems IRIS acts as a client for FTP communication with remote FTP servers using the %Net.FtpSessionOpens in a new tab class. The %Net.FtpSessionOpens in a new tab class can be configured to use PASV for the data channel to avoid an inbound connection. InterSystems IRIS provides FTP inbound and outbound adapters. Both act as FTP clients to get (input) or put (output) under the control of a Business Service created by the customer. The FTP server and port are configurable. The FTP adapters are InterSystems IRIS processes.

HTTP

The HTTP adapters (EnsLib.HTTP.InboundAdapterOpens in a new tab and EnsLib.HTTP.OutboundAdapterOpens in a new tab) enable productions to send and receive HTTP requests and responses. HTTP adapters are implemented by InterSystems IRIS processes. The port and interface IP addresses of the inbound HTTP adapter are configurable. The server and port to which the outbound HTTP adapter is provided by class settings.

Java Gateway

Production adapters use the Java Gateway to communicate through a Java intermediary process. A Java process is started which depends on the existence of a Java Virtual Machine. The InterSystems IRIS server process communicates with the Java process via a TCP connection. The TCP ports used are configurable.

LDAP

The EnsLib.LDAP.OutboundAdapterOpens in a new tab class can be used like other adapters by Business Services to send requests to an LDAP server and receive responses.

MQSeries

The classes EnsLib.MQSeries.InboundAdapterOpens in a new tab and EnsLib.MQSeries.OutboundAdapterOpens in a new tab enable productions to retrieve messages from and send messages to message queues of IBM WebSphere MQ. Dynamically loaded shared library binaries are used for the communication.

Pipe

The classes EnsLib.Pipe.InboundAdapterOpens in a new tab and EnsLib.Pipe.OutboundAdapterOpens in a new tab enable productions to invoke operating system commands or shell scripts. They create a process external to InterSystems IRIS and communicate with it via a pipe, so an external process will exist while the Pipe adapter is communicating with it. The command that the process runs is determined by the value assigned to the CommandLine property of the adapter class.

SAP

The Java Gateway is used to communicate with the SAP Java Connector using classes imported with the EnlLib.SAP.BootStrap class ImportSAP method.

SQL

The SQL inbound and outbound adapters enable productions to communicate with JDBC or ODBC-compliant databases. In general, the inbound SQL adapter (EnsLib.SQL.InboundAdapterOpens in a new tab) periodically executes a query and then iterates through the rows of the result set, passing one row at a time to the associated business service. The SQL adapters use the underlying capabilities of InterSystems SQL and JDBC Gateways.

TCP

InterSystems IRIS provides input and output TCP adapters. Each TCP inbound adapter checks for data on a specified port, reads the input, and sends the input as a stream to the associated business service. Within a production, an outbound TCP adapter is associated with a business operation that you create and configure. The business operation receives a message from within the production, looks up the message type, and executes the appropriate method in the outbound TCP adapter to transmit the data over TCP.

Telnet

InterSystems IRIS provides the EnsLib.Telnet.OutboundAdapterOpens in a new tab which permits outbound telnet connections to the telnet facility on another system. This adapter provides methods to programmatically emulate the effect of manually logging in to the remote system using telnet client software. The InterSystems IRIS TCP device is the underlying technology.

Next sectionSecurity Checklist
Previous sectionSecurity Advisor
FeedbackOpens in a new tab