InterSystems IRIS Data Platform 2019.2

Securing InterSystems Products and Operating System Resources
InterSystems: The power behind what matters   

This document is intended to assist customers who need to harden the operating system on which an InterSystems IRIS Data Platform™ instance runs to reduce the potential attack surface available to an intruder. The operating system services required by an InterSystems IRIS instance are described. An inventory of various types of InterSystems IRIS process is provided and their purpose is explained. Methods for identifying the function of InterSystems IRIS processes in a running instance are described. Instructions are provided for removing or disabling optional InterSystems IRIS processes that not required. External processes, running programs other than iris on UNIX® or irisdb.exe on Windows, required by a running InterSystems IRIS instance are described. TCP and UDP ports used by InterSystems IRIS internal and external processes are listed and their purpose described.
InterSystems IRIS Processes
Most processes comprising an InterSystems IRIS instance will be executing the iris executable on UNIX® and the irisdb.exe executable on Windows which 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 customer code. InterSystems IRIS processes can be examined using the Management Portal > 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. These processes can be identified 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 following core system processes are listed by the name in the Routine column.
The core system processes should not be stopped. Doing so will disrupt the normal operation of an InterSystems IRIS instance. It is possible, if ECP is not used, to prevent the ECPWork process from being started by setting appropriate values in the configuration file. From the management portal, select System Administration > Configuration > Connectivity > ECP settings and set the maximum number of application and data servers to zero. Then disable the ECP service.
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:
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:
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.
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.
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 51773. 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.
Persistent processes may be running the following executables, which live in the bin directory on UNIX®.
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.
Shared binaries are usually installed in /usr/local/etc/irissys on UNIX®.
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.
Audit physical environment
Ensure firewalls and management servers are in a physically secure location that can only be accessed by authorized personnel; and that they are patched up to date.
Review change management process, rule base modifications
Review procedures and approval process for changes. Automation tools are available for this.
Run vulnerability tests
Run automated tools to analyze and identify insecure services, protocols, and ports.
Use 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
Plan the installation
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.
Install this software where appropriate, that is Windows servers and client PCs.
Disable unnecessary software, services & 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
Plan the installation
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.
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.
Disable 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 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 (cachemgr and irisusr).
InterSystems IRIS must be installed as root. Ensure groups, ownerships and permissions for InterSystems IRIS databases are maintained as specified.
InterSystems IRIS must be installed using the Windows Administrator. The default Windows Administrator account should then be disabled. 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, e.g. with SSL/TLS.
Check SSL/TLS configuration is using latest versions of SSL/TLS.
InterSystems Security
Always install with InterSystems Security type Locked Down.
Regularly review users and passwords.
Review application requirements; and define roles, resources and services.
Ensure that auditing is enabled. Review the logs regularly.
Disable Services
If services such as ECP and mirroring are not used, do not enable them.
Remove unused databases and applications.
Remove unused databases such as USER.

Send us comments on this page
View this article as PDF   |  Download all PDFs
Copyright © 1997-2019 InterSystems Corporation, Cambridge, MA
Content Date/Time: 2019-08-23 06:47:59