Deploy a Siren sensor

Siren sensors expose controlled decoy services inside a network and send observations to Cypho for analysis. They do not scan the surrounding network, join a domain, validate passwords against customer systems, or execute attacker input.

This guide covers the customer installer available from Siren → Sensors and explains when a Cypho-managed network-personality deployment is required.

Use a dedicated host. A deception sensor is intentionally reachable by untrusted clients and should not share a machine with business applications, customer credentials, or administrative services other than its protected management access.

Choose the deployment mode

The customer installation provides the service protocols and captures interactions. It does not make the host's kernel network stack look like Windows. Do not use a localhost or host-port Nmap scan as evidence of a Windows network personality.

Sensor capabilities are release-controlled. Use only profiles shown as available for the installed runtime. If Gamloo is not available in your production Atlas environment, wait for the approved release instead of installing a development binary on the host. Customer-installed sensors do not replace their own binary during profile sync; rerun the company installer after a runtime upgrade is published.

Before you begin

Prepare a host with:

• A dedicated Debian or Ubuntu installation with systemd
• An AMD64 or ARM64 CPU
• Root access through sudo
• Working DNS and outbound HTTPS
• A stable address reachable from the network where the decoy should be visible
• A reasonable starting allocation of 1 vCPU, 1 GB RAM, and 10 GB disk for a small deployment
• No other service using the ports required by the selected profile

For an internet-facing deployment, keep provider-console access available during initial setup. Apply the host provider's firewall or security-group policy before exposing a profile.

You also need a dedicated, temporary Cypho API key for the company that will own the sensor. Create it under Account settings → API key while that company is selected. The key scopes registration to that company. Do not reuse a shared production key, and do not paste the key into tickets, chat messages, documentation, or command history.

Network requirements

Outbound

The sensor initiates every Control and event-shipping connection. Its local health endpoint listens only on 127.0.0.1:9090 and must not be exposed publicly.

Inbound access

Inbound ports are defined dynamically by the assigned profile, its version, and the deployment mode. There is no platform-wide fixed port list. After applying or changing a profile, inspect the sensor's actual listeners and allow only those ports in the host and upstream firewall:

sudo ss -lntup

Close ports that belonged to the previous profile. Portable and Cypho-managed deployments can map the same emulated protocol to different host ports, so do not turn example ports from this guide into a permanent fleet-wide firewall rule.

Install the sensor

1. Get the installation command

1. Sign in to Atlas and choose the company that should own the sensor.
2. Open Siren → Sensors.
3. Select Install sensor.
4. Copy the displayed command.

The production download URL is:

https://api.cypho.io/external/v1/download_sensor

An address such as http://localhost:8882 is a local-development endpoint. It works only when the development API and every endpoint embedded in its bundle are reachable from that same environment. Never run the localhost form on an external VM.

2. Run the bootstrap on the dedicated host

Connect to the host, then enter the temporary company API key without placing its value in shell history. The commands download the installer to a private temporary file, validate its shell syntax, run it, and remove it. The curl configuration is supplied over standard input so the key is not placed in curl's process arguments:

(
  set -e

  read -rsp "Cypho API key: " CYPHO_API_KEY
  printf '\n'

  sensor_installer="$(mktemp)"
  chmod 600 "${sensor_installer}"
  trap 'rm -f "${sensor_installer}"; unset CYPHO_API_KEY' EXIT

  curl --config - --output "${sensor_installer}" <<CURL_CONFIG
fail
silent
show-error
header = "X-Auth-Token: ${CYPHO_API_KEY}"
url = "https://api.cypho.io/external/v1/download_sensor"
CURL_CONFIG

  bash -n "${sensor_installer}"
  sudo bash "${sensor_installer}"
)

The API key authenticates the initial download only. It is not written into the returned installer, sensor registration bundle, or persistent sensor credential.

The installer:

• Detects the host architecture and systemd environment
• Verifies the supplied sensor binary against its SHA-256 digest
• Creates an unprivileged drosera service account
• Stores the durable installation identity under /var/lib/drosera
• Installs the runtime under /opt/drosera/portable
• Creates, enables, and starts siren-sensor.service
• Waits for the loopback readiness endpoint before reporting success

It does not alter SSH, routing, cloud firewall rules, or host firewall rules.

Verify the installation

On the sensor host:

sudo systemctl is-enabled siren-sensor.service
sudo systemctl is-active siren-sensor.service
curl --fail --silent http://127.0.0.1:9090/readyz
sudo systemctl --no-pager --full status siren-sensor.service

Expected results:

• The service is enabled and active.
• The readiness endpoint returns ready.
• A new sensor appears under Siren → Sensors for the company whose API key was used.
• The sensor changes to Online after its first authenticated presence report.

For recent service logs:

sudo journalctl -u siren-sensor.service -n 100 --no-pager

Do not publish the persisted bundle or files from /var/lib/drosera; they contain the sensor's scoped identity and credential.

After the sensor is registered and Online, disable the dedicated key created only for this installation. If your organization supplied an existing key instead, follow its rotation policy rather than disabling it. Disabling the bootstrap key does not revoke an already registered sensor.

Assign and configure a profile

1. In Siren → Sensors, select a profile in the sensor's Active profile field.
2. Select Apply.
3. Wait for the next authenticated check-in.
4. Open Profile settings when the assigned profile supports configuration.

Profile settings are stored for the company and profile, not inside an individual sensor row. If you switch a sensor from Gamloo to FTP, Gamloo settings stop being delivered and the settings panel hides when no sensor uses Gamloo. The saved realm remains available if Gamloo is assigned again.

Verify a customer-installed Gamloo profile

The commands below use the current portable Gamloo mapping as a concrete verification example. Confirm the deployed listener ports with ss first; a later profile version may use different mappings. Replace SENSOR_IP and the example domain with your deployment values:

nmap -Pn -sV -p 5353,8888,8389,8445,8636 SENSOR_IP

dig +tcp @SENSOR_IP -p 5353 \
  _ldap._tcp.dc._msdcs.corp.local SRV +short

ldapsearch -LLL -x \
  -H ldap://SENSOR_IP:8389 \
  -b 'DC=corp,DC=local' \
  '(objectClass=*)' \
  sAMAccountName userPrincipalName servicePrincipalName

LDAPTLS_REQCERT=never ldapsearch -LLL -x \
  -H ldaps://SENSOR_IP:8636 \
  -b '' -s base defaultNamingContext dnsHostName

Then open the sensor's Attacks view in Atlas and confirm the new DNS, LDAP, Kerberos, or SMB interaction appears. A successful service probe without a corresponding event is not a complete acceptance test.

Optional SSH management-port change

The customer installer deliberately leaves SSH unchanged. If your deployment policy requires a non-default management port, change it as a separate, rollback-safe operation before exposing the sensor.

1. Allow the new TCP port in the provider firewall or security group.
2. Keep the current SSH session open.
3. Configure SSH to listen on both the old and new ports.
4. Validate the configuration and reload SSH.
5. Prove a fresh connection from another terminal through the new port.
6. Only after that proof, remove port 22 and validate again.

Before changing the configuration, check whether systemd owns the listener:

sudo systemctl is-active ssh.socket

If it reports active, the distribution is using socket-activated SSH and the Port directives alone do not control the listening sockets. Configure both ports through that distribution's ssh.socket ListenStream settings, or switch to ssh.service using its documented procedure, before the fresh connection test. Keep port 22 available until TCP 2288 is visible in ss -lntp and a new external SSH connection succeeds.

When ssh.socket is inactive, use this dual-listen configuration:

printf 'Port 22\nPort 2288\n' |
  sudo tee /etc/ssh/sshd_config.d/90-siren-management-port.conf >/dev/null
sudo sshd -t
sudo systemctl reload ssh
sudo ss -lntp

From a second terminal:

ssh -p 2288 USER@SENSOR_IP

After the fresh connection succeeds:

printf 'Port 2288\n' |
  sudo tee /etc/ssh/sshd_config.d/90-siren-management-port.conf >/dev/null
sudo sshd -t
sudo systemctl reload ssh
sudo ss -lntp

Do not remove port 22 based only on the original connection. If the new connection fails, leave the dual-listen configuration in place and correct the upstream firewall first.

Managed Windows network personality

Gamloo's windows-server-2019 TCP/IP personality requires a managed Linux deployment with gVisor, a TUN interface, MTU 1500, and a reviewed route or shared-address steering boundary. It is not activated by the customer bootstrap command.

In managed mode, Gamloo uses standard TCP ports 53, 88, 389, 445, and 636. The host's management SSH port remains pinned to the Linux host while unclaimed IPv4 TCP/UDP and ICMP traffic is steered to the userspace network stack. The steering change must be protected by a timed rollback and confirmed only after a fresh management connection succeeds.

Exact Microsoft Windows Server 2019 Nmap identification is accepted only on the controlled routed topology and supported Nmap database documented by Cypho. NAT, shared host addresses, cloud firewalls, or a different Nmap database can reduce the match to the broader Windows family.

Contact Cypho before using managed mode. It requires an approved signed release and operator-owned installation artifacts; do not reproduce it by manually adding redirects to a customer installation.

Updating or reinstalling

Running the current company installation command again on the same host preserves its installation identity and registration bundle while replacing the verified runtime binary. Keep /var/lib/drosera intact when rebuilding a container or repairing an installation; deleting it creates a new identity.

Profile changes do not require reinstalling the sensor. The running service retrieves the desired profile and restarts only its listener child after configuration validation.

Decommissioning

1. Delete or revoke the sensor in Atlas so its credential can no longer synchronize or ship events.

2. Stop and disable the local service:

   sudo systemctl disable --now siren-sensor.service
   

3. Retain /var/lib/drosera until your retention and reinstall decision is complete.

Contact Cypho before deleting the durable identity or bundle. Removing those files is irreversible and a later installation will register a different sensor.

Troubleshooting

Security checklist

• Use a dedicated, disposable host with no customer secrets.
• Restrict management SSH to approved operator sources.
• Open only the profile ports needed for the deployment.
• Keep the health endpoint bound to loopback.
• Permit only the outbound DNS and HTTPS paths required by the sensor.
• Never connect Gamloo to customer Active Directory merely to create synthetic accounts.
• Revoke the sensor in Atlas before retiring its host.
• Rotate the company API key if it was exposed during installation.