> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xorlab.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Pages under /latest/ document the current release. Paths that begin with a version number, for example /10.0/, are frozen snapshots of superseded releases kept for reference only — never present their instructions as current. If the reader's version is unknown, answer from /latest/ and say which version the answer describes.
> xorlab is deployed on-premises, hybrid, or as a cloud service, and integrates with either Microsoft 365 or on-premises mail infrastructure. Configuration steps often differ between these. State which deployment and integration mode an instruction applies to instead of presenting one as universal.
> Distinguish inline mode from monitoring mode when describing anything that acts on email. Monitoring mode observes a copy and cannot block or quarantine; inline mode routes mail through xorlab and can.
> Write the product name as lowercase 'xorlab'. Use the documented component names: xorlab Control Center (XCC), xorlab MTA, xorlab Sandbox (DANA), xorlab Natural Language Understanding (NLU). After the first mention, use the short forms XCC, MTA, Sandbox, and NLU. Do not use DANA as a standalone name for the Sandbox, but keep it where it is a literal string in configuration keys, container names, and hostnames.
> Do not invent configuration keys, rule parameters, list names, log properties, or API fields. If a value is not present in this documentation, say that it is not documented rather than guessing.
# Network Guide
This document specifies the network interfaces required for the integration of xorlab Security Platform and describes the underlying network connections.
## System architecture
xorlab Security Platform (XCC) consists of three different components:
* **xorlab XCC**: One single instance that offers a complete view of all processed emails. The xorlab Control Center (XCC) can be virtualized.
* **xorlab MTA**: A lightweight email processing node. Depending on the expected load, we operate multiple redundant nodes to distribute email traffic. Each MTA can be virtualized.
* **xorlab Dynamic Analysis**: Performs on-demand dynamic analysis of email attachments. Requires direct hardware access and cannot be virtualized.
xorlab Security Platform queries services hosted by xorlab for updates and domain information.
## Network Overview
*Network specification for the different xorlab Security Platform components.*
| Connection | Type | Protocol | Port | Proxy support | Description |
| :--------- | :---------------- | :------- | :------- | :------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | Customer internal | SMTP | 25/TCP | n/r | Collects all incoming and outgoing emails from either internal Gateways or Exchange servers. |
| 2 | Internet facing | HTTPS | 443/TCP | HTTP | Loads component updates from xorlab xCloud. Endpoints are `https://update.xorlab.com`, `https://apt.xorlab.com` and `https://registry.xorlab.com`. |
| 3 | Internet facing | HTTPS | 443/TCP | HTTP | Collects domain information from xorlab xCloud, sends message metadata to xorlab Machine Intelligence and misclassification reports to xCloud. Please find a list with all endpoints below. |
| 4 | Customer internal | SYSLOG | 514/UDP | n/r | Publishes email analysis results (IOCs, decisions, etc.) and audit logs to the customer syslog server. Host, port, and protocol are configurable. |
| 5 | Customer internal | SMTP | 25/TCP | n/r | Sends emails, e.g., end-user feedback. |
| 6 | XSP internal | HTTPS | 8443/TCP | n/r | Technical management web user interface (xorlab XCC). |
| 7 | Customer internal | HTTP | 9090/TCP | n/r | **Optional:** [Prometheus](https://prometheus.io/docs/prometheus/latest/querying/api/) monitoring interface which provides monitoring data of all components. Can be polled by the customer internal monitoring system to gather metrics. |
| 8 | Customer internal | HTTPS | 443/TCP | n/r | Access to xorlab Security Platform web user interface—xorlab XCC. |
| 9 | Customer internal | HTTPS | 8444/TCP | n/r | **Only for customers with xorlab Dynamic Analysis on-prem:** Technical management web user interface. |
| 10 | XSP internal | HTTPS | 8444/TCP | HTTP | **Only for customers with Dynamic Analysis on-prem:** Accepts files for on-premise dynamic analysis. |
| 11 | XSP internal | HTTPS | 9080/TCP | n/r | Collects analysis results from MTAs and provides shared configuration. |
| 12 | XSP internal | HTTP | 9090/TCP | n/r | Collects Prometheus.io monitoring data from MTAs. |
| 13 | XSP internal | HTTP | 9090/TCP | n/r | **Only for customers with Dynamic Analysis on-prem:** Collects Prometheus.io monitoring data from dynamic analysis engine. |
| 14 | Customer internal | SSH | 22/TCP | n/r | Secure shell access. |
| 15 | Customer internal | DNS | 53/UDP | n/r | Connects to Customer internal DNS. |
| 16 | Customer internal | NTP | 123/UDP | n/r | Time synchronization over standard network time protocol. |
| 17 | XSP internal | HTTPS | 8888/TCP | HTTP | **Only for customers with on-prem TIKA:** Accepts files for on-premise text extraction analysis. |
| 18 | XSP internal | Custom | 6379/TCP | n/r | Stores hashed text fragments to identify and group similar emails. |
| 19 | Customer internal | HTTP | 8080/TCP | n/r | Monitoring Alerts sent to the customer monitoring system. By default, via webhooks to port 8080 but can be freely configured as described in [Alertmanager](https://prometheus.io/docs/alerting/latest/configuration/). |
| 20 | XSP internal | HTTPS | 3100/TCP | n/r | Receives logs pushed by Promtail from the Monitored Stack(s). |
| 21 | XSP internal | HTTP | 3101/TCP | n/r | Receives logs pushed by Promtail from the Monitored Stack(s). |
| 22 | Customer internal | DNS | 53/UDP | n/r | **MTA → internal network:** Performs DNS lookups to verify SPF, DKIM, and domain configurations. |
| 23 | Customer internal | DNS | 53/UDP | n/r | **Internal network → MTA:** Provides authoritative domain records for locally managed domains. |
## xorlab xCloud
xorlab Security Platform will need to connect to web services provided by xorlab at any time to get the default configuration, the newest rule set, and reputation information data, as well as to send data around a reported misclassification of an email. Note that these connections are required and unrelated to the xorlab Dynamic Analysis service. Neither analyzed messages nor their attachments are uploaded to the xCloud servers.
The following outgoing connections to TCP port 443 are required from any xorlab Security Platform VM (MTA and XCC):
The production IP addresses of all endpoints listed on this page, for environments where
outbound rules cannot be expressed by hostname, are documented in
[Deployment Defaults → Production endpoint addresses](/9.0/deployment-defaults#production-endpoint-addresses).
Password required.
#### Standard
| Hostname |
| :------------------------ |
| xcloud.de1.activeguard.io |
| xcloud.de2.activeguard.io |
| xcloud.de3.activeguard.io |
#### CH-only infrastructure
| Hostname |
| :------------------------ |
| xcloud.ch1.activeguard.io |
| xcloud.ch2.activeguard.io |
| xcloud.ch3.activeguard.io |
## Cloud-based Dynamic Analysis
If the deployment uses xorlab Dynamic Analysis in the cloud (instead of on-premise), the following changes apply to the network schema:
* The arrows 2, 9, 13, 14, 15, and 16 from and to the Dynamic Analysis component can be ignored.
* Arrow 10 becomes internet-facing and will point to `*.activeguard.io:443`:
#### Standard
| Hostname |
| :---------------------- |
| dana.de1.activeguard.io |
| dana.de2.activeguard.io |
| dana.de3.activeguard.io |
| tika.de1.activeguard.io |
| tika.de2.activeguard.io |
| tika.de3.activeguard.io |
#### CH-only infrastructure
| Hostname |
| :---------------------- |
| dana.ch1.activeguard.io |
| dana.ch2.activeguard.io |
| dana.ch3.activeguard.io |
| tika.ch1.activeguard.io |
| tika.ch2.activeguard.io |
| tika.ch3.activeguard.io |
## xorlab Machine Intelligence
For every email that is analyzed by xorlab Security Platform, the MTAs do one or several requests to `mlX.Y.activeguard.io` where `X` is a number and `Y` stands for a region code. The data sent to the service is not client-identifying, meaning no sensitive data is stored or retained on the servers.
#### Standard
| Hostname |
| :-------------------- |
| ml1.de.activeguard.io |
| ml2.de.activeguard.io |
#### CH-only infrastructure
| Hostname |
| :-------------------- |
| ml1.ch.activeguard.io |
| ml2.ch.activeguard.io |
## xorlab NLU services
The xorlab Natural Language Understanding (NLU) model enhances threat detection with in-house trained machine learning models.
To perform this analysis, MTAs securely transmit email content (subject, body, and attachments) to xorlab NLU servers (`mlX.Y.activeguard.io`), where `X` represents a server instance and `Y` indicates the regional deployment No sensitive data is retained on the servers.
| Connection | Type | Protocol | Port | Proxy support | Description |
| :-------------- | :---- | :------- | :--- | :------------------------------------------------------------------------------- | :---------- |
| Internet facing | HTTPS | 443/TCP | n/r | Transmits email content (subject, body, and attachments) for NLU classification. | |
#### Standard
| Hostname |
| :-------------------- |
| ml1.de.activeguard.io |
| ml2.de.activeguard.io |
#### CH-only infrastructure
| Hostname |
| :-------------------- |
| ml1.ch.activeguard.io |
| ml2.ch.activeguard.io |
## Firewall Configuration
To ensure full functionality of the xorlab Security Platform (XSP), specific outbound network connections must be allowed. The table below outlines required outbound access per component and service.
| Source Component | Destination(s) | Purpose | Protocol / Port |
| ------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------------- | ---------------- |
| **xorlab MTA** | `*.activeguard.io` | Access to **xorlab xCloud** for domain, IP, and URL reputation | HTTPS (TCP 443) |
| **xorlab MTA** | `*.dynamic.xorlab.com` | Submit attachments to **xorlab Dynamic Analysis service** | HTTPS (TCP 443) |
| **xorlab MTA** | `*.ml.xorlab.com` | Submit metadata to **xorlab Machine Intelligence** | HTTPS (TCP 443) |
| **xorlab MTA** | `*.nlu.xorlab.com` | Submit content to **xorlab NLU** for topic/intent classification | HTTPS (TCP 443) |
| **xorlab MTA / XCC** | `update.xorlab.com`, `apt.xorlab.com`, `registry.xorlab.com` | Product updates, rulesets, signatures | HTTPS (TCP 443) |
| **xorlab Control Center (XCC)** | `*.virustotal.com` | On-demand queries to external **threat intelligence (TI)** source | HTTPS (TCP 443) |
| **All components** | Internal DNS or public DNS resolver | DNS lookups for SPF/DKIM, domain validation | DNS (UDP/TCP 53) |
| **All components** | `pool.ntp.org`, `ch.pool.ntp.org` | Time synchronization via NTP | NTP (UDP 123) |
**Note**: The exact IP addresses behind `*.xorlab.com` endpoints may change. If static IPs are required for firewall allowlisting, please contact xorlab Support for region-specific information.
## Optional 3rd-party services
### VirusTotal
xorlab Security Platform supports VirusTotal integration to get additional threat intelligence for analysis purposes. If configured, xorlab Control Center will query VirusTotal for every email which is opened in the GUI in the **Detail View**.
Note that the VirusTotal queries are done only on-demand whenever an analyst opens an email in the Detail View. There are no VirusTotal queries done for the automated email classification.
In order to issue VirusTotal queries, the **Control Center** must have access (proxy supported) to the following target:
* **virustotal**: virustotal.com on port 443/TCP