Skip to main content

Securing InterSystems Products and Operating-System Resources


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.

  • SWRTDMN— Performs write daemon tasks (write daemon secondary 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.

  • — Performs system monitor tasks (various system monitor workers).

  • — 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 – the Web server process

  • %SYS.cspServer2 – the second CSP server process

For each of these servers, on Windows the executable is CSPAP.dll; on UNIX®, it is 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


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.


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 random and is open only during transmission of the query results.


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.


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 Configuration 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.


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.

Removing 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.



InterSystems IRIS provides communication with external interfaces using adapters.


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 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.InboundAdapter 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.OutboundAdapter class. Messages are usually queued to a worker job that performs the actual output operation. This implies the existence of Ens.Queue processes.


InterSystems IRIS acts as a client for FTP communication with remote FTP servers using the %Net.FtpSession class. The %Net.FtpSession 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.


The HTTP adapters (EnsLib.HTTP.InboundAdapter and EnsLib.HTTP.OutboundAdapter) 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.


The EnsLib.LDAP.OutboundAdapter class can be used like other adapters by Business Services to send requests to an LDAP server and receive responses.


The classes EnsLib.MQSeries.InboundAdapter and EnsLib.MQSeries.OutboundAdapter 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.


The classes EnsLib.Pipe.InboundAdapter and EnsLib.Pipe.OutboundAdapter 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.


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


The SQL inbound and outbound adapters enable productions to communicate with JDBC or ODBC-compliant databases. In general, the inbound SQL adapter (EnsLib.SQL.InboundAdapter) 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.


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.


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

Checklist for Hardening Your Deployment

This checklist is intended to provide your organization with guidelines for assessing how secure your environment is and to provide tips for hardening your environment that will help your organization avoid and prevent security breaches. This checklist is not intended to be a “how to list” and is not all-inclusive. The points below are items to consider rather than a definitive list of rules to apply.

You alone are responsible for the security of your infrastructure. If you are uncertain about your approach to hardening and protection, consult a security professional.

Network and Firewalls

Network, hardware, software and policies
Obtain copies of and review security polices, firewall logs, firewall configuration and patch levels, public facing IP addresses, diagrams of network, and firewall topologies.
Auditing the physical environment
Ensure firewalls and management servers are in a physically secure location that can only be accessed by authorized personnel. Ensure that they are patched up to date.
Reviewing change management process, rule base modifications
Review procedures and approval process for changes. Automation tools are available for this.
Vulnerability testing
Run automated tools to analyze and identify unsecured services, protocols, and ports.
Using brute force detection systems
Stop people from guessing passwords, and prevent them from connecting to the server, by blocking their current IP address in your server firewall.
Ongoing audits and real-time monitoring and alerting
Ensure a process is in place for continuous auditing of firewalls. Ensure real-time monitoring is in place to alert on changes to the firewall. Review their logs regularly.

Operating System

Installation planning
Understand the server role, and document the install procedure. Download appropriate operating system securing and hardening guides for more detailed information.
Patch levels
Ensure operating system patches are up to date, especially security patches. Turn off automatic updates.
Antivirus software
Install this software where appropriate, that is Windows servers and client machines.
Disabling unnecessary software, services, and ports
Disable unnecessary network services such as IPv6, telnet, and FTP.
Disable unnecessary daemons that are not used such as DHCP, scheduling and queuing services, and laptop services.
Configure in-use services to be as secure as possible; for example, secure SSH by limiting SSH protocol to Version 2 (Version 1 is not secure).
Maintain server logs and mirror those logs to a separate log server.
Monitoring and alerting
Configure monitoring and alerting settings to notify of events such as changes to the system, and unauthorized access.
Physical security
Configure the BIOS to disable booting from CDs/DVDs, floppies, and external devices; set a password to protect these settings.

Web Server

Installation planning
Understand the role of the web server: what content will it serve; will the pages be static; what web services are provided? Document the installation procedure. Download and review the appropriate hardening security guide.
Patch levels
Ensure web server is up to date, especially with regard to security patches.
Web server header info
Configure the servers so that HTTP headers do not provide information relating to the web server software being run, or system types and versions.
Disabling HTTP TRACE
When enabled, HTTP TRACE request is used to echo back all received information.
Error handling
Implement proper error handling by utilizing generic error pages and error handling logic to force the application to avoid default error pages. These often leak sensitive system and application information.
Disabling modules
Disable all unused modules to reduce surface area of the web server; these modules often provide too much information –
Apache: autoindex, cgi, imap, info, status, userdir, actions, negotiation…
IIS: ASP, ASP.NET, WebDAV, CGI, directory browsing…
Users and groups
Apache: Run Apache as a separate user and group so Apache processes cannot be used by other system processes.
IIS: Remove unused accounts; disable Guest account

Users, Passwords, Groups, Ownerships, and Permissions

User management
Disable root login. All administrators should be named users. Regularly check for unused user accounts, and for default user accounts and passwords.
Password policy
Require and use very strong passwords with mixed case, numbers, and special characters.
Change passwords on a regular basis.
Lock accounts after too many login failures.
Create groups and users before installation.
Install InterSystems IRIS as root. Ensure groups, ownerships, and permissions for InterSystems IRIS databases are maintained as specified.
Install InterSystems IRIS using the Windows Administrator, and then disable the default Windows Administrator account. Also disable Guest and Help Assistant accounts.

Encryption (Data At Rest and Data In Motion)

Data at rest
Ensure all production data at rest on disk is encrypted.
Key management
Review the key management policies and procedures.
Data In motion
Ensure all HTTP data communications is encrypted, such as with TLS.
Ensure that all TLS configurations are using the latest version.

InterSystems Security

Always install with the Locked Down initial security setting type.
Regularly review users and passwords.
Review application requirements; define roles, resources, and services.
Ensure that auditing is enabled. Review the logs regularly.
Disabling services
If services such as ECP and mirroring are not used, do not enable them.
Removing unused databases and applications.
Remove unused databases such as USER.