# Network Surface & Port Reference

This page is the authoritative reference for Flopsar's network footprint. It lists every port the **Flopsar Server** listens on, the direction and protocol of every connection, and the only outbound connection the server is able to initiate. Use it to design firewall rules, plan network segmentation, and complete vendor security questionnaires. 

Minimizing and documenting the attack surface is an explicit requirement of the Cyber Resilience Act (Annex I, Part I, point (j)); this page is the operator-facing expression of that requirement. Where a listener can be disabled or restricted, that is stated explicitly so you can apply the principle of least exposure described in the Hardening Checklist.

## Summary of the network model

Flopsar follows a simple, on-premises network model:

* The **server is the central hub**. Agents, browsers, and OpenTelemetry sources connect *inbound* to it. The server does not connect outward to any of them.
* The **only outbound connection the server can initiate is to a directory service (LDAP/LDAPS)**, and only when an operator explicitly enables LDAP authentication. If LDAP is not configured, the server makes no outbound network connections at all.
* The product **does not phone home**. There is no license-activation call, no update check, no usage telemetry, and no vendor-bound endpoint. The license is a local file; see Licensing. 

This means a fully air-gapped deployment is supported, with the single exception of reaching your own directory service if you choose to use LDAP.

## Inbound listeners (Flopsar Server)

All listening addresses and ports below are configurable in `settings.toml`; see the Server Configuration Reference. The values shown are the defaults.

### Agent ingestion — TCP 9000

* **Configured by:** `[agent].server_ip`, `[agent].server_port`
* **Default bind:** `0.0.0.0:9000`
* **Direction:** Flopsar agents (running inside monitored JVMs) connect inbound to the server.
* **Protocol:** Flopsar's proprietary agent protocol over TCP. The session is end-to-end encrypted and authenticated using X25519 key agreement with ChaCha20-Poly1305; see Cryptography & Key Management.
* **Can it be disabled?** No. This is the core data path; without it the server has no data to process. Restrict it at the network layer instead (see firewall guidance below).

### API and Workstation (web UI) — TCP 9443

* **Configured by:** `[ui_srv].server_ip`, `[ui_srv].server_port`, `[ui_srv].ssl`
* **Default bind:** `0.0.0.0:9443`, TLS enabled
* **Direction:** operator browsers and REST API clients connect inbound to the server.
* **Protocol:** HTTPS (TLS 1.3). The Flopsar Workstation is served from this same endpoint, and the REST API is authenticated with JWTs; see Authentication. The certificate and key are configured in the `[ssl]` section.
* **Can it be disabled?** No — it is the only management interface. TLS can be turned off with `[ui_srv].ssl = false`, but this is **strongly discouraged** outside of a loopback-only test setup.

### OpenTelemetry / HTTP (OTLP) — TCP 4318

* **Configured by:** `[otlp].enable`, `[otlp.http].server_ip`, `[otlp.http].server_port`
* **Default bind:** `0.0.0.0:4318`
* **Direction:** instrumented applications and OpenTelemetry collectors connect inbound to the server.
* **Protocol:** OTLP over HTTP.
* **Can it be disabled?** Yes. Set `[otlp].enable = false` to close both OTLP endpoints. If you do not ingest OpenTelemetry data, disabling OTLP removes two listeners from the attack surface.

### OpenTelemetry / gRPC (OTLP) — TCP 4317

* **Configured by:** `[otlp].enable`, `[otlp.grpc].server_ip`, `[otlp.grpc].server_port`, `[otlp.grpc].ssl`
* **Default bind:** `0.0.0.0:4317`, **TLS disabled by default**
* **Direction:** instrumented applications and OpenTelemetry collectors connect inbound to the server.
* **Protocol:** OTLP over gRPC (HTTP/2).
* **Can it be disabled?** Yes, via `[otlp].enable = false`.

{% hint style="warning" %}
The OTLP/gRPC endpoint is **unencrypted by default** (`[otlp.grpc].ssl = false`). For any deployment where OTLP traffic leaves the host or crosses an untrusted segment, set `[otlp.grpc].ssl = true`, or disable OTLP entirely if it is unused. See the Hardening Checklist.
{% endhint %}

## Outbound connection: directory service (LDAP / LDAPS)

The Flopsar Server can initiate **one** kind of outbound connection: to an LDAP directory, and **only when an operator enables LDAP authentication**. This is the only situation in which the server acts as a network client.

* **When it happens:** during each interactive login while LDAP authentication is enabled. The server connects to the directory, performs a bind with the configured service account, searches for the user, and then attempts a bind as that user to verify the password. No persistent outbound connection is held open.
* **Destination:** the host (and optional port) in the configured LDAP URL.
* **Protocol and port:** `ldap://` when TLS is off (directory default port **389**) or `ldaps://` when TLS is on (directory default port **636**), selected by the `use_ssl` setting. A non-standard port can be specified as part of the URL.
* **Where it is configured:** LDAP settings are managed at runtime through the Identity & Access administration screens / IAM API, not in `settings.toml`. The relevant fields are the directory URL, the bind DN and password, the user base DN, the user filter, the user UID attribute, and the `use_ssl` / `skip_verify` flags. See Authentication.
* **If LDAP is not enabled:** the server initiates no outbound connections whatsoever.

{% hint style="warning" %}
The `skip_verify` option disables TLS certificate verification for the LDAPS connection. It exists only for environments using a private/self-signed directory certificate during initial setup. **Do not leave `skip_verify` enabled in production** — it removes protection against man-in-the-middle attacks on the directory channel. Prefer `ldaps://` with a properly trusted certificate, and place the directory on a trusted segment.
{% endhint %}

## Other participants (not server listeners)

For a complete picture of traffic in a deployment, note where the other components connect. None of these require the server to open additional ports:

* **Agent host → server, TCP 9000.** The agent is the active party; it initiates the connection to the server. The monitored application host therefore needs egress to the server's agent port. The agent does not open any listening port for the server to call back to.
* **Operator browser → server, TCP 9443.** Administrators and analysts reach the Workstation and API over HTTPS.
* **OTLP source → server, TCP 4317 / 4318.** Instrumented applications or an OpenTelemetry collector push telemetry to the server (only if OTLP is enabled).

## Default port summary

For quick reference, the server's default listeners are:

* **9000/tcp** — agent ingestion (always on; encrypted proprietary protocol)
* **9443/tcp** — API + Workstation (always on; HTTPS/TLS 1.3 by default)
* **4318/tcp** — OTLP/HTTP (optional; off when `[otlp].enable = false`)
* **4317/tcp** — OTLP/gRPC (optional; off when `[otlp].enable = false`; unencrypted unless `[otlp.grpc].ssl = true`)

And the only outbound destination:

* **LDAP 389/tcp** or **LDAPS 636/tcp** (optional; only when LDAP authentication is enabled; port may be overridden in the URL)

## Firewall and segmentation guidance

The recommendations below implement attack-surface minimization in line with CRA Annex I, Part I, point (j).

1. **Default-deny.** Block all inbound traffic to the server host and allow only the specific ports you actually use.
2. **Scope each listener to its real source.**
   * Allow **9000/tcp** only from the network ranges where monitored applications run.
   * Allow **9443/tcp** only from operator/administration networks (or place it behind a reverse proxy / VPN). Avoid exposing the management interface to the public internet.
   * Allow **4317/4318/tcp** only from the hosts or collector that emit OTLP, and only if OTLP is enabled.
3. **Bind to specific interfaces.** The defaults bind to `0.0.0.0` (all interfaces). Where a listener only needs to be reachable on one network, set the corresponding `server_ip` to that interface's address rather than `0.0.0.0`.
4. **Control the LDAP egress.** If LDAP is enabled, allow outbound traffic from the server only to your directory service host on 636 (LDAPS, preferred) or 389, and to nothing else. This is the server's only outbound path.
5. **Encrypt everything that crosses a trust boundary.** Keep TLS on for the management interface, enable TLS on OTLP/gRPC if telemetry leaves the host, and use `ldaps://` with certificate verification for the directory.
6. **No outbound internet access is required.** Because the product does not phone home, the server host can run with no outbound internet route at all (aside from your own directory service, if used). This supports air-gapped and tightly segmented deployments.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.flopsar.com/7/security/network-surface-and-port-reference.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.